BDS Software

Square Sizes

When I first started these current game design projects, after deciding to generally use squares instead of hexes (see HexVsSquare.php, I decided to use squares with an odd number of pixels (px) on each side, e.g. 9x9px, 15x15px, 31x31px, 63x63px, etc, primarily to ensure that each of the squares would have a clearly defined center pixel.

This would avoid having unsightly blobs where diagonal lines cross in the center of the square. It would also allow for an underlying grid to be conveniently and easily displayed.

For example, here is a 15x15px green square:      and here is a similar 15x15px green square with two intersecting red lines:     .


Here's a copy of the latter square, blown up ten times:     .


Note the clearly defined center pixel where the two red lines intersect.

This is perhaps a more practical matter than might be immediately apparent; red lines are frequently used on maps to indicate roads.

BTW, each of these lines was made by first drawing a 1px line which was not anti-aliased, and then drawing a 1px anti-aliased line right on top of the first line. This gives the overall effect a little more definition, while still smoothing the "jaggies" somewhat.

Using a different color, such as black for instance, would be helpful for those who are color-blind, but it would then be indistinguishable from the borders of the squares on the grid maps. That would cause enough confusion to make those games unplayable for everybody. I'll leave it to you to make such adjustments where you want whenever you co-opt one of my games as the starting point for making a game of your own.

-----

Now, instead, let's look at a square with an even number of pixels on each side.

Here is a 16x16px green square:      and here is a similar 16x16px green square with two intersecting red lines:     .


And, here's a copy of the latter square, blown up ten times:     .


Note the blob in the center where the two red lines intersect. The blob is caused by the fact that the 16x16px square does not have a clearly defined center pixel.

With the 15x15px square, the center pixel is distinctly located at position (7, 7), where the square's pixel positions range from (0, 0) to
(14, 14).

But, with the 16x16px square, where square's pixel positions range from (0, 0) to (15, 15), there is no distinct center pixel, only the center region consisting of the four pixels (7, 7), (7, 8), (8, 7), and (8, 8).

-----

The other issue is the matter of the grid lines. For example, let's designate a canvas with a five-by-five square grid, like this:


This is an 81x81px grid with the vertical grid line x-coordinates of 0, 16, 32, 48, 64, and 80. The horizontal grid line y-coordinates are also 0, 16, 32, 48, 64, and 80. The grid lines are each one pixel wide.

The 15x15px squares will then fit perfectly within those grid lines. If we take five 15x15px squares, and position their (0, 0) origins at the (1, 1), (17, 17), (33, 33), (49, 49), and (65, 65) positions on the 81x81px grid, we obtain the following:


And, if we fill up all the squares, we get:


And, if we add some diagonal lines:


This clear grid pattern allows the player to more precisely determine unit positions, movement, facing, and other game factors.

-----

Chess Helper, Conroy's Game of Life - Modified, and The Matching Game were all designed using squares with an odd number of pixels on each side; 63x63px, 9x9px, and 31x31px squares respectively.

-----

But, when I designed the Maze Number 1 game, the tiled map design quickly made it clear that I was going to become buried in doing nothing except level designs unless I used a tool such as the Tiled Map Editor to speed and streamline the process. "Tiled" is a free open source tile map editor with excellent features: I highly recommend it.

However, although Tiled will make maps using squares with an odd number of pixels on each side, it does not (at least as far as I can tell) have any way to accomodate the grid line structure that I want to maintain for those squares.

Furthermore, I came across van der Spuy's Note concerning this:

You'll notice that most of the image width and height sizes in this book are powers of two, such as 32, 64, 128, and 256. That's because graphics processors have historically handled images in powers-of-two sizes very efficiently: it's the same format in which binary graphics data is stored in computer memory. You'll find that if you keep your game images to a power-of-two size, they'll fit neatly inside most computer and device screens."

Speed and efficiency are not overwhelming considerations for the types of games I'm currently designing, but I also don't want to needlessly burden the CPU and waste battery power.

-----

Going to the powers-of-two mechanism would, at first, seem to present some significant difficulties. For example, trying to overlay the 81x81px grid with 16x16px squares would look like this:


And, if we fill up all the squares, we get:


And, if we add some diagonal lines:


Note especially the lack of any definitive grid to indicate to the player where they are; as well as the tiny (but annoying) breaks in the diagonal lines at the square corners which are an artifact of how the squares are laid out. The only way to eliminate these breaks would be to encroach on other squares, i.e. in going from a Northwest to a Southeast square, the diagonal line (red pixels) would encroach into the corners of the neighboring Northeast and Southwest squares.

Even if we were to simply avoid using the 81x81px grid base and just use an 80x80px blank base, the results would be:

-----

It then occurred to me that perhaps we could have the best of both worlds. (Okay, it was several days before that occurred to me - but we got there anyway.)

Since the 81x81px grid uses 1-pixel wide grid lines, why not use a 15x15px square with a 1px border attached to the top side, and a 1px border attached to the left side, like this:      The result would be a 16x16px image overall, with a 15x15px "interior".


With the two intersecting diagonal lines, we would have:      (magnified ten times).


And, superimposed upon the 81x81px grid, we see the result is identical between the former (on the left) 15x15px squares, and the present (on the right) 16x16px with borders squares:

-----

Therefore, future games will be designed using squares with borders, with the squares having sides with a number of pixels equal to a power of two.

I will thus use the Tiled Map Editor to make maps which are generally 640x640px with either:

● 10 squares by 10 squares: 64x64px,
● 20 squares by 20 squares: 32x32px,
● 40 squares by 40 squares: 16x16px, or
● 80 squares by 80 squares: 8x8px.

And, I will then superimpose those 640x640px maps onto a 641x641px grid base to provide the right-side and bottom-side borders.



                                                                                                                                                                M.D.J. 2018/08/18


----------

References:

van der Spuy, Rex (2019). Advanced Game Design with HTML5 and JavaScript. New York: Apress, page 41.