Controlling hero in platform/tile based games

[Aatos_Media]

There are a few different approaches how the game hero controlling can be coded in platform/tile based games. I also noticed some pretty interesting problems occuring, so it would be nice to hear different approaches and pros and cons of them.

The tile engine we are using is Dusk.

For example - if I want to create a game like Mario where character can jump and move left/right. I could move character with hero.x=hero.x+speed or with hero:setLinearVelocity(30,0). Are there other possibilities? And what would you prefer? Is there any example codes available?

Then there are some “stuck problems” and how physics work in tiles that collision shape is triangle (or slope). Any help is appreciated

[Caleb_P]

I’m a big advocate of using “homebrewed” physics engines in platformer games. For one thing, they’re pretty fun to make, for another, they’re much more “see-through” than the “real” physics engine, and for yet another, it’s just a nice thing to have a working physics engine you wrote in your game.

The “definitive guide” to platformer physics can be found here: The guide to implementing 2D platformers | Higher-Order Fun

A really good practical guide to platformer physics (Sonic) can be found here: http://info.sonicretro.org/SPG:Solid_Tiles

An argument against using a real physics engine in your game can be found here: http://www.learn-cocos2d.com/2013/08/physics-engine-platformer-terrible-idea/

Here’s a quote from a post I made on a similar question for more information:

Another very important reason not to use Box2D physics is tile borders: The usual way to add physics to tiles is to add a body to each tile. However, then, when the player goes from one tile to another, it may or may not “catch” at the seam between them. You have to work through this with changing the player body shape, setting the velocity every frame, and such as that.

This issue (as well as others, most of which are outlined in the article) has bothered me for a very, very long time. I’m using custom-made physics in my platformer game as a result.

And as for difficulty to implement, it’s not too difficult if you have a good guide. For example, it took me about one programming session (which for me is only about two hours) to get the initial version (walls, floors, ceilings) of platforming physics down with the Sonic guide I linked to. There’s no feeling like having a solid platformer physics base that you wrote yourself :D.

But! Platformer physics above the basic level can be a slightly advanced field of programming, and if you just want to “get it done”, you can try with Box2D. You just need to be aware of the pitfalls.

• Caleb

[Aatos_Media]

Thanks (again) Caleb!

Writing own physics engine sound a bit too hard for me So maybe I try to cope with the Box2D.

Please check this Youtube-video (10 secs): https://www.youtube.com/watch?v=nOyZUYQF9lQ

When time is 7 secs you’ll see that the character “hits” the unvisible wall, though the character is on solid ground the whole time. Is this typical problem with tile engine games that are using Box2D physics. And if it is, is there a fix for it (I think you mentioned something about this, but could you be a bit more precise)?

[Caleb_P]

I’m a big advocate of using “homebrewed” physics engines in platformer games. For one thing, they’re pretty fun to make, for another, they’re much more “see-through” than the “real” physics engine, and for yet another, it’s just a nice thing to have a working physics engine you wrote in your game.

The “definitive guide” to platformer physics can be found here: The guide to implementing 2D platformers | Higher-Order Fun

A really good practical guide to platformer physics (Sonic) can be found here: http://info.sonicretro.org/SPG:Solid_Tiles

An argument against using a real physics engine in your game can be found here: http://www.learn-cocos2d.com/2013/08/physics-engine-platformer-terrible-idea/

Here’s a quote from a post I made on a similar question for more information:

Another very important reason not to use Box2D physics is tile borders: The usual way to add physics to tiles is to add a body to each tile. However, then, when the player goes from one tile to another, it may or may not “catch” at the seam between them. You have to work through this with changing the player body shape, setting the velocity every frame, and such as that.

This issue (as well as others, most of which are outlined in the article) has bothered me for a very, very long time. I’m using custom-made physics in my platformer game as a result.

And as for difficulty to implement, it’s not too difficult if you have a good guide. For example, it took me about one programming session (which for me is only about two hours) to get the initial version (walls, floors, ceilings) of platforming physics down with the Sonic guide I linked to. There’s no feeling like having a solid platformer physics base that you wrote yourself :D.

But! Platformer physics above the basic level can be a slightly advanced field of programming, and if you just want to “get it done”, you can try with Box2D. You just need to be aware of the pitfalls.

• Caleb

[Aatos_Media]

Thanks (again) Caleb!

Writing own physics engine sound a bit too hard for me So maybe I try to cope with the Box2D.

Please check this Youtube-video (10 secs): https://www.youtube.com/watch?v=nOyZUYQF9lQ

When time is 7 secs you’ll see that the character “hits” the unvisible wall, though the character is on solid ground the whole time. Is this typical problem with tile engine games that are using Box2D physics. And if it is, is there a fix for it (I think you mentioned something about this, but could you be a bit more precise)?