I'm developing a 2D city-building game and trying to decide on the type of grid. There will be vehicles, so the unit movement is important too.
I know there are visual differences for using Squares or Hexagons, what I want know is:
I'd consider a Square-based grid as a "base" type of tiles in any game. Such grid is simple to imagine and moves over this grid are simple to understand. It's also very simple to implement "under the hood". Those are few reasons why even the Chess game uses it :). Additionally, this grid helps you make "regular" levels, because Vertical and Horizontal are natural directions here. So if you make, let's say a SimCity clone it's very easy to have perpendicular roads.
The biggest disadvantage of Square-based grids is that they doesn't keep distances very well, because when you move by one tile in N/W/E/S directions you basically move by one tile size, but when you move in directions like NW/ES/... then you'll move by sqrt(2)*tileSize.
It's not so big problem in computer games but it was a big flaw in strategy/tactical board games.
Because of this problem people tried to find some other way to divide 2D space, so the movements between tiles would be more similar to the real movement. It happens that the only possible way, better than squares is to use Hexagons.
Hexagon-based grids are much better for strategy-like games because movements are more natural, but they are much harder to implement. They have also 3 main directions, where one of them may be Horizontal OR Vertical but not both! So try to imagine a city with perpendicular roads built on a such grid...
Personally, for a game like SimCity I wouldn't think much and used Squares. In fact, I'd use squares in every game that is not a turn-based tactical game. But depending on your taste you need to choose your own. Maybe you'll want to make a one-of-its-kind, Hex-based SimCity clone :) ?
"`vertical`") instead of italics (*vertical*) or nothing at all? "Square-based" isn't code.
– mrr
Jun 13 '14 at 03:32
Can't comment yet, so I'll give answer short answer.
From my experience, square tiles are a little simpler to implement. If you are using e.g. a two-dimensional array, tile position is array index multiplied with tile size (at least that's what it boils down to). Finding neighboring tiles is as simple as adding one to the index (and maybe wrapping the value to not go outside of the map).
Hexagonal tiles however have more neighbors and require a little more work to position correctly. Nothing complex though, just a few multiplications usually. What you will need to look out for is that every other row/column has one less tile than the others, since their edges don't line up.
Bottom line: Both aren't too difficult, just choose what is right for your game design.
One last thing to look out for with hexagons in your specific case may be something like roads, and when a straight road leads out of a tile at its pointy end, how do you implement that? Is it connected to the tile it does not share a border (only a corner) with? Do the tiles touching that corner need to know about the road? However, questions like that exist for squares as well (e.g. diagonal road). The answer to your overarching question is probably something only you can arrive at, depending on what you plan to do.
For a city-building game, I'd definitely use a square grid, for one simple reason: many real-world cities are built on a square grid plan, while very few if any are built using a hexagonal grid.
The main disadvantage of square grids is that, if you allow diagonal movement, a single diagonal step covers a bit (about 1.414 times) more distance than an orthogonal step. The solution to this issue is to make diagonal movement slightly slower to compensate; if you're also measuring time in discrete ticks, having an orthogonal step tack two ticks and a diagonal step take three ticks gives a pretty good approximation to realistic movement.
The other option would be to go "gridless", allowing the player to place roads and buildings at (more or less) arbitrary positions and angles. This could be implemented by having a very fine underlying grid (say, 0.1 to 1 meters per grid step), allowing roads to drawn in a straight (or curved) line between any two grid points, and allowing buildings to be placed at arbitrary positions and angles. Of course, this makes overlap and proximity checking a bit more complicated, but it's not that hard to implement.
To make things easier for the player, you'll probably want to snap road endpoints to existing roads and building entrances, and snap building positions and orientations to nearby roads. (In particular, if I try to move a planned building on top of a road, the game should position it along the road instead.) You may also want to give the player the option to snap roads and building to a secondary, coarser grid (possibly with a customizable grid spacing) to make it easier to keep things tidy. Depending on how fancy you want to get, you could even let the player rotate the grid or set up multiple grids and custom guide lines.
In any case, using a gridless (fine grid) design and a fine time step gets rid of any issues with diagonal movement: instead of counting ticks to move one grid step in some direction, you just measure the distance along the road from point A to point B (using the Pythagorean theorem) and make the time proportional to that; the fine grid and time step make any roundoff errors negligible.
One tradeoff for using hexagon in a game context is in strategy games: the number of sides could cause inbalance in strategy games (say Fire Emblem).
In this example, everyone from enemy's side can act at in one go. Your character has to defend at maximum from 4 sides and survive a round. Now if it is hexagon, then there will be additional sides of attack.
Therefore, for hexagon boards, either the attack point/health point ratio is lower, or the design would not allow every unit from one side to act at once, but instead have a system which shuffles next active unit.
I would suggest using a "stagger grid", in which every row is displaced half a square west of the one to its north [somewhat like the keys on a typical keyboard]. From a programming perspective, a stagger grid can be processed much like a square grid except that movement will be permitted NW and SE, but not NE and SW, and a map whose sides run north-south will to the program appear as a "diamond" shape. A stagger grid can easily be rendered to look like a hex grid (just scale the X and Y axes suitably and superimpose hexagons on it) and doesn't require any really weird programming.
I recommend Amit Patel's extensive writing on the subject of grids in games. I recommend that you start here, and then if you like his expository style, read more here.
If you still have specific questions, then come back and ask them here.
