Collision system


Solar2D natively implements a physics engine called Box2D .
Box2D is a proven powerful physics engine. It is used in many games. You've probably already played a game where different vehicles roll on rough surfaces causing the vehicle to bounce in all directions. Or games where objects collide and react perfectly to their collisions. Or finally quite simply to "Angry Birds" which makes full use of the physics engine.
All these games are developed with a physics engine which manage gravity, movements, accelerations, collisions and responses to these collisions in an ultra realistic way since they are based on a real physical model managed almost automatically by the physics engine. .

So there, everything seems to be on track to unload the management of collisions and interactions with the world on a ready-to-use engine.

Box2D manages it!

However, there are still many questions to ask, starting, among other things, with the performance and relevance of these engines!

A platform game will use tiles (square blocks assembled together) to represent the world. A level can be made up of hundreds of thousands of tiles and each of these tiles can be a collision object.
So what's going on in memory, and is the engine going to slow down your game?

I tested and in fact it is not (or I did not put enough 🤔) but it does not slow down!
Not only can you do a first process to reduce the number of collision objects by grouping the blocks that have a common edge, as long as the resulting polygon remains convex and that it does not have more than 8 vertices (and therefore 8 sides), but anyway the engine is able to exclude a whole set of collision objects that it considers too far away to interact with the moving character.

In terms of memory use, the reduction of polygons will also save megabytes in spades!

Note: Regarding the reduction of polygons, in the case of a Super Mario Bros U-style Platformer Game, where you will mainly be moving horizontally, it may make sense (it seems to me) to reduce the polygons by them. merging in the direction of the height. This allows the physics engine to have the ability to eliminate entire columns as you progress through the level.

Polygon reduction

  • Reduction of polygons by merging blocks in height *

And yet ...

All the lights are therefore green!

And yet, there is something disturbing me that is wrong, but I'm having a bit of a hard time putting my finger on it.

So I'm looking for anything that could be complicated to do with a physics engine and regardless of whether a platform game doesn't respect physics too much, here are 3 or 4 things that come to my mind that could cause some problems. to Box2D :

1 - Imagine that your character is jumping and you want to change direction during the jump.
In real life, of course you can't change direction during a jump, but in a platform game, it's a matter of ergonomics to be able to do so!
The physics engine, once you give your character the jump impetus, will internally manage their acceleration and speed. It will not be easy to change the direction of the character in mid-flight.

2 - In Mario, it is possible to cross certain platforms when going up, but not when going down. Then again, I don't know how to deal with this kind of collision with a physics engine.

3 - Now suppose you have an animation that allows your character to stop running. You want to play this animation before your character is in a wall. For this you will need to know not that your character has collided with the wall but that he will collide soon.
Again, the integrated physics engines manage frame-by-frame collisions for you in real time, but will not be able to tell you if an object will collide in half a second so that you can anticipate an action.

4 - Finally, you have planned to be able to play in a network with 2 characters displayed on the screen (As in Super Mario Bros U, except that there, the two players are in a network).
At time t, you have received all the information about the second player via the network and your game is completely synchronous.
Except that the connection is not fast enough and for 5 frames you will not receive anything from the second device.
How will you manage the position of the second player during these 5 frames if you have no information on his movement?
You can provide an early solution by not sending the player's position but his actions, reproducing the player's actions locally. But it's not going to be much better. If you receive an action from the player in a staggered way, the triggering of the movements of the second player will end up being out of sync, and the correction (both of the position and of the movements) promises to be a real headache 😕.

All of these issues I'm (almost) sure can be solved by tweaking the capabilities of the physics engine a bit, but they sure will be easier to deal with if you have your hands on the physics engine code!
And worse, if by chance this was not possible you should make cuts in the functionality of your game, and there is no question of it!

Exit Box2D

Good. You have already understood, my choice has already been made.
I'm going to do without Box2D , but make sure to separate the physical management from the rest of the game so that I can possibly change my mind later if necessary, but I doubt that will happen.

What prompts me to make this choice is not so much that I think Box2D is not a good solution, but rather the need to master the code to avoid me, in the end, to complicate my life. life later.

Obviously, I do not claim to be able to reproduce Box2D (far from it), but collisions in a platform game are still very simplified compared to the real physics that is capable to manage Box2D .
The other crucial point to consider is Lua's poor performance. Here again, even if the language is very slow, I tell myself that the first platform games ran on machines at least 10,000 times less powerful than our current phones and that this did not prevent them from handling collisions "correctly".

A verification is necessary anyway

To be sure, I did some tests to see the scale of the disaster 😉, and it's okay eventually. It seems to me that my engine will have minimal impact on the overall performance of the game.
So I wrote a little routine to calculate in Lua the intersection between a segment and a polygon.
It calculates over 1000 intersections with polygons at 60 FPS on my prehistoric phone 😎. It's more than enough to do what I have to do (it seems to me)
At worst, it will never be too late to develop a small native language plugins, although I would like to avoid it!

I'll stop there for today, but I'll be happy to explain how my physics engine works when it's up and running, but that will be in another Post!


In the meantime, I give you a little link to my Segment / Polygon intersection computation routine (which I have already improved several times as I begins to understand how Lua works).


Hillgreen Dream Team

Etienne: Développeur
Manu: Graphiste et développeur
Luis: 3D Graphes et animations
Reynald: Musiques et sons