I'm looking to build a Zelda: LTTP style top-down RPG. I've read a lot on the subject and am currently going back and forth on a few solutions. I'm using C#, MonoGame, and Tiled.

For my tile maps, these are the choices I can see in front of me:

  1. Store each tile as its own array. Each one having 3-4 layers, texture/animation, depth, flags, and maybe collision(depending on how I do it). I've read warning about memory issues going this route, and my biggest map will probably be 160x120 tiles. My average map however will be about 40x30. The number of tiles might cut in half if I decide to double my tile size, which is currently 16x16. This is the most appealing approach for me, as I feel like I would know how to save maps, make changes, and separate it into chunks for collision checks.
  2. Store the static parts of my tile map in multiple arrays acting as the different layers. Then I would just use entities for anything that wasn't static. All of the other tile data such as collisions, depth, etc., would be stored in their own layers as well I guess? This way just seems messy to me though.

Regardless of which one I choose, I'm also unsure how to plan all of that other tile data. I could write a bunch of code that would know which integer represents what tile and it's data, but if I changed a tileset in Tiled and exported it again, all of those integers could potentially change and I'd have to adjust a whole bunch of code.

My other issue is about how I could do collision. I want to at least support angled collision that slides you around the corners of objects like LTTP does, if not more oddball shapes as well. So do I:

  1. Store collision as a flag for binary collision. Could I get this to support angles?
  2. Would it be fine to store collision as an integer and have each number represent a certain angle of collision?
  3. Store a list of rectangles or other shapes and do collision that way?

Sorry for the large two-part(three-part?) question. I felt like these needed to be asked together as I believe each choice influences the other.

  • 1
    \$\begingroup\$ What's your target platform? (This is important to judge how likely memory issues will be) \$\endgroup\$
    – Philipp
    May 26, 2014 at 13:16
  • \$\begingroup\$ PC. I'm mostly making it for fun, but if it's not a lot of extra work I'd like it to be expandable to other platforms. \$\endgroup\$
    – Delerat
    May 26, 2014 at 15:44
  • \$\begingroup\$ Related to the diagonal collisions thing: How Link to the Past handles sub-tile collisions. \$\endgroup\$
    – Anko
    Oct 14, 2015 at 19:31

2 Answers 2


For collisions I would simply store a polygon per tile.
I don't know if you need three degrees of movement, but for two, this would be very simple. In that case I would simply store a convex polygon per tile. For example a triangle, quad, hexagon or whatever shape you need.
Then simply do circle (player) vs polygon (tile) or box (player) vs polygon (tile) collision detection. This can be done with SAT (Separating Axis Theorem). Maybe XNA already offers you something like that.
With this approach you'd automatically get nice sliding on slopes and stuff.

If I wasn't clear enough, I mean something like you see in this video (the red lines around the objects): https://www.youtube.com/watch?v=-Q6ISVaM5Ww

  • \$\begingroup\$ How would I go about creating the polygons for each tile and knowing what shape to make? I'd like to automate it if I could. Otherwise, Tiled does have polygons, but they would be entities. I could break up larger polygons into small pieces and convert the entities into tile data I suppose. Any suggestions on how to go about it? \$\endgroup\$
    – Delerat
    May 26, 2014 at 18:12
  • \$\begingroup\$ Well to be honest, I don't see how one would automate this. You create your tiles by hand too, don't you? I don't think you can magically let a converter decide the right collision shape for you. I would simply create them by hand. It's not a big deal. I can imagine only having to place 3-4 vertices per tile (and you could even reuse all those shapes). "How would I go about creating the polygons for each tile and knowing what shape to make?" You're making the sprites/tiles, so you decide how they collide. \$\endgroup\$
    – Tara
    May 27, 2014 at 7:23
  • \$\begingroup\$ I would simply store a collision shape PER TILE. Then when you make your maps, you simply place those tiles where you want them and you'll automatically get nice collisions, since the collision shape is stored inside the tile. \$\endgroup\$
    – Tara
    May 27, 2014 at 7:49
  • \$\begingroup\$ I create my tiles by hand, and build my maps using Tiled. By automated, I meant having the collision shapes generate based on the tile or something. I'll try doing it manually and build smaller polygons for each tile. SAT seems cool, but will take me a bit of time to wrap my head around it and try implementing it. I still need to figure out how to store my tiles though. This method for collision sounds like I should go for storing each tile and its data as separate arrays, so I guess I'll just see if I encounter slow-down and expirement. \$\endgroup\$
    – Delerat
    May 28, 2014 at 23:02
  • \$\begingroup\$ I see... Sorry, I've never heard of Tiled before.^^ I don't know how you can integrate that stuff into it. Maybe store it in a small text file next to the tile bitmap. You could also simply ask another question about this on this site. Also: I highly doubt you will get any noticeable slowdown as long as you do the collision detection in a smart way. For example by only checking the tiles which the player currently touches. Even if you don't, you can test hundreds of polygons without a real performance impact. Doesn't XNA offer any polygon collision detection library? \$\endgroup\$
    – Tara
    May 29, 2014 at 11:12

Well old zeldas for static geometry had everything collide as squares. You could just have an array of flags where a single bit was 'occupied'. If the bit is occupied then you just do a basic AABB to AABB test for collision. Not a terrible system for tile. You can also do something like 1 bit means texture 1, next bit means texture 2 and so forth if your not wanting to do alpha mapped textures or blending. That means a single 8-bit values can store a plethora of info. No reason to have an array per tile ... 1 Array per chunk with a width / height parameter should be fine or if you have a standard dimension of chunk you can do it that way.


You must log in to answer this question.

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