I have a simple Tower Defense game using a tiled world. Creep and towers are on a tile at all times.

How should I represent the position of creeps in code? (Do creeps know their current tile and position on said tile or are they aware of their absolute world position?)

I'm basically looking for best practices, design pattern-type tips or general insight about how one manages positioning in a tile-based world.

Thank you.

  • \$\begingroup\$ How many characters do you expect to have in this game during busy times? Less than a few hundred, or thousands, or tens-of-thousands? (I assume "Creeps" and "Towers" are types of characters in your world that can move on their own.) \$\endgroup\$ Commented Jun 13, 2011 at 6:05
  • 1
    \$\begingroup\$ Definitely less than a few hundred. Creeps are moving monsters, towers don't move and shoot at the creeps. \$\endgroup\$
    – anthonyvd
    Commented Jun 13, 2011 at 6:20
  • \$\begingroup\$ (+1 because the answer is clearer now.) For a small number like that, you can just keep their positions in memory with an array. The advantage of being in RAM is speed -- your code for the Towers can easily search the array for Creeps then aim only at those who are in range. \$\endgroup\$ Commented Jun 13, 2011 at 6:24
  • \$\begingroup\$ Hopefully people will suggest a variety of methods/approaches so you can do some experimentation to determine what works best for your game. It would help to elaborate a little bit more on what you mean by tiles as you hinted at having tile-specific positions as well as global world positions -- is the world comprised of "tiles" that can accommodate a number of positions on a small grid? \$\endgroup\$ Commented Jun 13, 2011 at 6:26
  • 1
    \$\begingroup\$ Possible duplicate: How do I tackle top-down RPG movement?, going by the principle that if two questions can be given the exact same (correct) answer, they're probably a duplicate. Specifically, I think my answer from that thread might answer this question too. \$\endgroup\$ Commented Jun 13, 2011 at 8:06

2 Answers 2


In my experience, the best way to handle positions in a tile-based world is to ignore that you're in a tile-based world. That is, keep your entities stored in world-positions, keep the path(s) which your entities will be travelling on stored in world-space, and if at all possible, don't let your entities or other game logic know about tiles at all.

The problem with considering tiles is that they introduce corner cases into your game code; lots of new places where your code can misbehave in subtle ways. Not only do (for example) towers need to be able to tell how close they are to entities on their own tile, but also to the entities on other tiles. And as soon as you're thinking about tiles, you start thinking about finding the neighbours of tiles, which is also easy to introduce bugs into (particularly along the edges and corners of the playfield).

Tile-based worlds are really convenient for level editing. But my advice is to only use the tile structure for editing; don't let the way the level is built spread into the game logic itself.

  • \$\begingroup\$ Thanks a lot, bonus for refering to level-editing, which is the reason this game has tiles to begin with. \$\endgroup\$
    – anthonyvd
    Commented Jun 13, 2011 at 17:52
  • \$\begingroup\$ One problem that can arise from editing in a tile-based world is that if you're building a rather large town that spans many tiles, then you're having to flip between different tiles and end up spending quite a bit of time making sure things line up between tiles that are side-by-side. (I'm assuming that a custom world editing tool will be developed by the same game developer anyway.) \$\endgroup\$ Commented Jun 13, 2011 at 17:55

I would use world-positions for your entities. That will work just fine as long as the world doesn't become really huge (where world positions become impractical due to precision, so that you'll have to divide the world into chunks).

You can easily calculate the current tile from your x and y coordinates. Also having world coordinates makes comparing entities much easier (eg. is entity X in the range of tower Y?).

Using the other approach works too, but you'll have to deal with 2 sets of coordinates all the time (tile index(es) and position within said tile).

So in conclusion: Both approaches work, but using world coordinates seems much more practical (less coordinates to deal with, fewer calculations necessary). For your convenience, your entities could even have a getter method for their x and y tile index which will calculate the current tile position on the fly.


You must log in to answer this question.

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