Jump to content

Tilemaps and code organization


drhayes
 Share

Recommended Posts

Yet more tilemap questions! I'm considering making a Metroidvania so I'm mightily concerned with tilemaps. Sorry in advance for the long post.

 

1. The relationship between tilemaps and states: at first I thought I'd have one state per level with all the customized behavior for that level. For example, the state would know which enemies were which, who collided with who, what order to add the layers in, etc. It seemed like I would be duplicating a lot of code between states like which tiles are collidable, how to instantiate the player, etc. Or maybe I would define a State class that took care of that stuff for me and was specialized in its subclasses?

 

Anyhoo, then I thought I could write a generic tilemap loader that "knew" about certain conventions within my game, e.g. the enemies were all in the object layer named "enemies", the player is an object named "player", or something like that. Then I could go back to having a central "play" state and not have to change it too much per level.

 

Now I'm swinging back the other way. ( = I figure there's not one right way to do things, but have any of you encountered difficulties in doing either of these? Are there other approaches I'm missing? Any recommendations?

 

2. Is there a way to do tilemap collisions where the tile doesn't take up the entire tile? As in, maybe the tile is only half-full? I know there's Ninja physics, but it seems kinda like the red-headed stepchild of the physics systems. Right now, Ninja only collides with the tiles, correct? I can't have multiple sprites colliding with each other? The docs seem to indicate that AABB-to-AABB and -to-circle collisions aren't there yet.

 

Since it sounds like I'm going to be using Arcade physics... does that mean that for any tilemap shape that isn't the exact size of the tile I'm going to be making custom physics bodies and colliding them in the update method of my state? That offers tons of flexibility and I'm actually kinda excited about it, just not sure that's a sane approach or if I'm missing something.

 

Looking at the documentation, is that what I'd use "setTileIndexCallback" for?

 

3. Looks like "scrollFactorX" and "scrollFactorY" are how to do parallax, correct?

 

4. When setting a range of tiles to collide, when would I set recalculate to false?

 

Thanks for any help you can provide!

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...