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:

  • What are the issues for programming each type of grid regarding implementation and performance?
  • Is there a tradeoff or specific benefit for using one of them in a game context?
  • 1
    \$\begingroup\$ "Which do you recommend" type questions are primarily opinion based and not fit for the site. I removed that from your question. \$\endgroup\$
    – House
    Commented Jun 4, 2014 at 14:06
  • \$\begingroup\$ This is a very broad question. How do you expect us to answer the question "what are the issues"? Do you want us to list every single problem any novice programmer could encounter while writing an engine using one of these two approaches? Please pick one aspect you would consider problematic and ask for solutions to this one aspect. What do you mean with "tradeoffs"? Tradeoffs in which regard? Performance? Implementation difficulty? Gameplay? Please do not respond "EVERYTHING!". Please narrow your question. \$\endgroup\$
    – Philipp
    Commented Jun 4, 2014 at 15:07
  • 2
    \$\begingroup\$ The following pages, written by @amitp might be heplful: www-cs-students.stanford.edu/~amitp/game-programming/grids and redblobgames.com/grids/hexagons \$\endgroup\$
    – Lokkij
    Commented Jun 4, 2014 at 16:00
  • 1
    \$\begingroup\$ Related: One problem with a square grid, that a hex grid solves \$\endgroup\$
    – OGHaza
    Commented Jun 4, 2014 at 20:15
  • \$\begingroup\$ This is way to broad to post as an answer, so I'll just leave it here as a comment. This post from Red Blob Games has psuedo code, examples and discussions on the hex grids. It discusses orientation of hexes (flat vs pointy top), movement distances, coordinate calculations and much more. I'm sure you'd find it useful if you are going with a hex. \$\endgroup\$
    – Andy
    Commented Jun 5, 2014 at 3:10

6 Answers 6


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 :) ?

  • \$\begingroup\$ SuckerPunch chose a hex grid for their city in InFamous, so it's not unheard of to use hexes for urban environments. In their case, the limited angles of the hex tiles helped avoid long corridors that let the player see from one end of the city to another, which would have required longer draw distances. \$\endgroup\$
    – DMGregory
    Commented Jun 6, 2014 at 1:54
  • \$\begingroup\$ Is there any particular reason you're using code blocks (using "`vertical`") instead of italics (*vertical*) or nothing at all? "Square-based" isn't code. \$\endgroup\$
    – mrr
    Commented Jun 13, 2014 at 3:32
  • \$\begingroup\$ For something like SimCity, if you only allow roads on a grid - probably more common in games created by Americans - then you don't have any issue with lengths: you simply use the 1-norm for distances instead of the 2-norm. \$\endgroup\$
    – mrr
    Commented Jun 13, 2014 at 3:35

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.


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.

  • 1
    \$\begingroup\$ Hi and welcome to the site. Please refrain from posting link-only answers. At least provide a short summary of what is being linked to, otherwise your answer will be pretty much useless as soon as these links stop working. \$\endgroup\$
    – bummzack
    Commented Jun 5, 2014 at 7:42

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.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .