next »

[Hima]

Hello all,
I want to move away from Game Maker and writing a platformer game using C++. However, I'd like to know if there's any best practice or a common way to approach making a platformer game? The main thing I'm curious about is the physics stuff in platformer game.

I know that there are tile/grid based collision detection which is not so difficult to use, but what about a platformer that isn't tile based?  Do you think implement a physics SDK such as box2d or chipmunk would be a good idea or would it be an overkill?  Any other stuffs I should know before making a platformer is also greatly appreciated!

Thank you in advance

[___]

I would suggest staying away from premade 2d physics engines unless your game design is going to rely a lot on the physical interactions of objects.  It's really freaking hard to make a good feeling platformer character in the bounds of chipmunk and box2d.

[Amirai]

Why do you want to make it in C++?

I ask because is it something like you want to learn C++, or want to make your own engine? Or do you want to make a platformer but haven't found anything that can do what you want?

Engines take a long time to make, and from what I hear, it's best to ask yourself what your goal actually is. If your goal is to make a platform game, and you're fine with 2D, I recommend trying construct. It's got great tools for platformers and physics (box 2d) as well.

[Glaiel-Gamer]

If you need:

land, movement, enemy movement, collision, moving platforms, and rolling balls:
Don't use Box2D

If you need rotating boxes, ropes, joints, motors, and other "physicsy" stuff:
Use Box2d

Also my suggestion, when doing Closure I didn't want the character to really feel "Physicsy" within the game, which is tough with slopes and stuff, but he/she needed to react to balls and boxes rolling down at him/her appropriately, so the solution I came up with is to treat the surface normal of the ground for the character as straight up for angles below a certain threshold, and it worked pretty well. No sliding on slopes, walks pretty much the same horizontal speed even going up a slope.


Tile based platformers can be fun, a good level editor makes making content super easy, but it's much more difficult to make levels feel organic.

Bitmap-Based platformers allow for more freedom in the level design at the expense of a lot more work (you basically have to draw the collision area) and a lot more memory and generally smaller levels.

[Saint]

Well...

There are a bunch of small things, really, but in general how complicated you want to make the design of a platformer engine depends a lot on what you want to use it for. If you are just starting out I would suggest keeping it simple and trying out what works for you to create small games, then come back and ask about specific areas you encounter.

As for physics, I'll narrow it down to three basic choices - discrete blocks (either pixels, tiles or whatever you choose), full-blown physics simulation or floating-point primitives - that is, rigid bodies without the physics. These are, of course, not the only way to do it but they are the three main, distinctively different ways to handle physics.

- Discrete blocks basically can be thought of as physics based off tiles or the pixels themselves. The main advantage here is that it is very easy to do and you can usually use the same data as you use for visibility, and that since the collision information is discrete you do not have to deal with floating-point precision issues. The drawback is that it is very inflexible, making things that involves slopes, rotating, scaling or the like becomes a chore.

- Having your physics handled by floating-point primitives can be a more modern approach, essentially a 2D version of how Quake-style FPS:es handles physics. The world is defined by a set of shapes that you choose to write collision handlers for, and when you move an object around in the world you simply check to see if it collides with these shapes and if so, separate it and continue. The big advantage is of course the flexibility of it, and it makes it possible to easily create very organic environments, both shape and movement-wise. The drawbacks are that the code becomes a lot more complex, the physics gets decoupled from the visual elements of the world (if you consider this a drawback) and perhaps most importantly - that you will have to deal with floating-point precision.

- Having a full-blown physics engine take care of everything is taking it even further; you can use the same physics primitives as earlier for collision but you allow the dynamics simulation final control over the objects' movement and interaction. The advantage is that if you can get it to work, you will have a very good system that provides for a lot of emergent gameplay since people intuitively "know" physics. The downside is that it takes a lot of tweaking to get there since you have limited control over how you want your character to move, and unless managing the player character's physics is an element of the gameplay (think "Gish") it might not be worth it.

... So in short; if you are going to have a game based around physics, use a physics engine. If you are going to have a tile-based engine, use those for physics. If you want to have a lot of weird angles and funky geometry, use primitives.

[BorisTheBrave]

Box2D, and other physics engines, do usually allow allow you to turn off the physics, and just use the collision detection. Corresponding the "use primitives" suggestion above, just with some code already prewritten. It's not a popular option though, as it's not usually the primary goal of physics engines, and secondly, when you can get arbitrary collisions, it's quite hard to write consistent responses to it. It gets basically impossible when you start trying to mix and match physical/custom collision responses, but I believe simple schemes should be no harder to implement than in a system written from scratch.

[Hima]

A lot of good information here. Thanks a lot everyone!
----------------------------------------------------------------------------

Why do you want to make it in C++?

I already have a basic game engine set up in C++ and I want to make a game using it. I have worked on other genres of game before , like shmup and puzzle game but platformer is something new to me and I'd like to learn how it works and algorithm behind it etc.

I'd love to try Construct but I've heard that the python scripting part is still not working. I'll wait until it's stable first before I try my hand on it.
----------------------------------------------------------------------------

It seems like I should go with writing my own collision detection if I want to go with bitmap-based platformer. I don't really need a lot of physicsy stuff, so I guess I misunderstood thinking that physics engine would magically make collision detection a breeze 

Again, thank you very much! I'll try working on a small, simple platformer first, using floating-point primitives.

BTW, do you create your own level editor? Or do you use other applications like mappy? Right now I'm putting together a map in Photoshop and I don't think that is the quickest way to do it :S

[Glaiel-Gamer]

BTW, do you create your own level editor? Or do you use other applications like mappy? Right now I'm putting together a map in Photoshop and I don't think that is the quickest way to do it :S

My bitmap based platformer had an editor I wrote that deals with triangles, you can click and drag to draw triangles, then edit them individually on a per vertex basis if I need more. It's super efficient to lay out land.

My artist draws and imports art into the level and overlays it on top of the collision. Not super efficient, but nice control.

[salade]

What are you planning on for your space partitioning? that seems like the real issue to tackle(at least for me ). As acceptable as it is to have one screen environments load in at a time (i.e. knytt stories, untitled story, N way of Ninja, etc.), there must be more one can do...

[Golds]

It's really freaking hard to make a good feeling platformer character in the bounds of chipmunk and box2d.

Is it? Try clamping your character's angular rotation in each axis to 0, and manage its linear velocity directly.  For things like restitution on bounces and friction, you can handle all of that too if you want.  

You can even use their raw collision systems directly, without using their full simulations if you really want to.  

I think libraries like box2d and bullet are the way to go.  I'm sick of sinking time into custom collision systems for every project, and these kinds of libraries give you a lot of power, for very little cost other than the learning curve up front.