Wednesday, 9 July 2014

Physics Engines for things other than puzzles and explosions.

What's a Physics engine good for anyway?

I made my own Physics engine for Crashblock
 - cue rapturous applause - 
Thank you, it was hard work and there were times when I thought I couldn't resolve all of the issues, but I got there in the end. 
- applause intensifies -
It's main tasks were to prevent the player from passing through walls 
-hang on, that's a collision detection and resolution system - applause dies down slightly- 
and to simulate gravity 
- so it's basically, move everything down and use the collision detection and resolution system to stop things from falling off the level? - rapturous applause stops and crickets are heard -

Yup, that's basically all it did and it took a long time to get right; and isn't it basically what most games need?
So why do we keep re-writing the same code and why is it always hard?

I think it's because we re-write each game basically from scratch for a very specific idea.

If only there was some sort of library which could take the effort away and focus on the game...

Enter the Physics Engine

At it's heart a physics engine keeps track of entities, their energies and attributes and makes sure that changes in energy are correctly applied and objects don't move through other objects.
Come to think of it, that's quite a task.

Serious people spent serious time writing serious software to do all of this.

Something that can handle velocity, friction, acceleration, elasticity, gravity, mass and the resolution of collisions, calculating and transferring energies to other objects seems to be something that should only be used in serious games just to do it justice - anything else would be a waste right?

It is true, you can get a really good racing game written using a physics engine - but they're useful for other things too; and if you bear with me, I'll explain why I don't think it's overkill and actually very beneficial to even the simplest of games.

Most game requirements are the same

You see, the tricky parts to any game are simulating a world. Every 2D platform game does this.

Consider Mario:
Mario describes a world where a man runs along a blocky world jumping over obstacles and collecting gems. Mario must simply reach the end of each level to complete the game.

The world has physical attributes, gravity, collision detection and solid objects and destructible scenery when hit from underneath.

Consider Sonic the Hedgehog:
Sonic describes a world where a hedgehog runs at ridiculous speeds through a world filled with hazards to be jumped over, loop the loops and enemies to be killed. Sonic must reach the end of a set of levels and defeat a boss in various guises to complete the game.

The world has physical attributes, gravity, collision detection and solid objects. It also has things to increase velocity and destructible scenery when hit at a certain speed.

Consider Treasure Island Dizzy:
Dizzy describes a world with a cute egg who jumps over obstacles and tumbles when he lands. He avoids hazards and interacts with the environment. Dizzy must solve puzzles and collect items to unlock areas of the world to reach an island via a boat.

The world has physical attributes , gravity, collision detection and solid objects. It also has hidden objects to find and underwater sections.

With just these three different games, there are quite a lot of overlapping areas.

  • Physical Attributes 
    • Mass
    • Friction
    • Velocity
  • Gravity
    • Global
    • Local
  • Collision Detection
    • Projectiles
    • Hazards
    • Hidden objects
    • Zones
  • Solid Objects
    • Static
    • Destructible
    • Movable
For just these three games, the same problems were solved in different ways to simulate a world and to provide the game mechanics.

Back when these games were made, there really wasn't much of a choice; You made a game engine for a game or series of games and you optimized it to within an inch of it's life. 

Having a common system (if one existed) would have introduced inefficiencies. The simulations needed to be as bare bones as possible to be as fast as possible as every CPU cycle counted. That means bespoke code each time.

Those days are mostly gone. Processors are powerful and memory is plentiful. 
Games are often written in cross platform languages where you have little control over the actual implementation at the machine level. The chances are that a Physics System will be written in a more efficient way to any code you or I could write ('Serious People' remember)

So why do so many people still write their own physics simulations?

Well, It could be because it seems like overkill to use something so powerful for a simeple game. 
Or there's the challenge of rolling your own. There are a lot of interesting mathematical problems to get your head around. But for me, it's a distraction to the game. It's a problem someone else who is possibly much smarter than me and a whole lot more interested in solving said problems than I am.

I choose to use an engine.

This decision is fairly recent however. But now I've seen the light, I'm sold on the benefits. I'll never roll my own again.

What are the benefits of using a generic physics engine over rolling your own to your specific needs?


Writing a collision detection system is to be fair - Tedious - and at it's most primitive, involves testing each object in your game with other objects in your game to check if they collide. 

The mechanism you use for this will have a massive impact on the performance of your game.

From the outside it seems simple enough so it's a common thing to write early on. 
The most common is a simple bounding box test.

You can do broad testing using rectangles to check if any corner of one object intersect with any other, hopefully this means that you've zoned your level otherwise you'll be checking a lot of objects. 
As you can see, the bounding box test is clearly not good enough to detect accurate collisions with the planes.

Then what happens when you collide? Do you need to do more granular collision checking? Pixel level? Polygonal? With each step comes more work. 

Pixel level checking is more accurate but old-school and was always CPU intensive. 
With more and more work being done on the graphics card, you don't have access to pixels these days. So you're more than likely looking at a collision mesh.

Then what happens when you've detected the collision? Do you let each object know about it and allow them to decide the outcome? Do to compute the energies exchanged as part of the collision and apply the resulting energies to the objects? 

What about really fast moving objects? Will you implement some form of ray-casting? Do you care about transferring rotational forces or velocities to your objects as a result of collision?

Are all objects Solid? Do you need sensors? Will you have Passive or Active checking?

Can all objects move or do you have static objects which cannot move no matter what?

Just this first part has uncovered a mountain of work. 

These decisions will need to be made before the game development can begin. or you can let a Physics engine do it for you.

X = X + 1 // Movement

Most early games have a section which reads something like this:
If Left is pressed Then Player.X = Player.X - 1
If Right is pressed Then Player.X = Player.X + 1

This code normally evolves to:
If Left is pressed Then Player.SpeedX = -1
ElseIf Right is pressed Then Player.SpeedX = 1
Else Player.SpeedX = 0
For each object in game
object.X = object.X + object.SpeedX

The origins of a physics system. You are tracking velocity in the X axis.
With a physics engine, you can apply an impulse to an object and have it calculate the energies appropriately.

Collisions Pt2 Sensors

The Physics Engine I wrote for Crashblock was also used in a game which was tragically shelved called Guns-Reloaded. 

The AI for enemies was assisted by attaching sensors around an enemy tank which could inform the tank's brain of things like incoming projectiles and dangerous terrain. This meant that the enemy flying tanks could in theory fly close to rocks but not close enough to become damaged by collisions. It also meant they could raise shields to save themselves. 

The data from these sensors was fed into an AI routine and appropriate behaviour was determined. All in all, it worked pretty well.  

Unfortunately, the game failed to mature but the lessons learned from that were carried on to a recent game which I did complete, called SchemeWars. 

In that game aliens were aware of their own positions and the position of the ground as well as dangerous objects flying towards them so they could defend themselves. They also used other collision objects to keep each-other a nice distance from other aliens.
This behaviour was much easier to code that with Guns-Reloaded as I was using a Physics Engine.

Box2D is fast and awesome, you should use it.

I first heard about Box2D when I first saw a game called Crayon Physics. A simple game where you draw objects in order to get a ball from one place to another. 
It was very clever and used the majority of Box2D's features.

I seemed to be a perfect fit for that game, but it never occurred to me to use it in a platform game.
I started building the Reversion Bureau (working title) and again, I rolled my own physics and collision detection within the MOAI framework early on; not giving a second thought to the Box2D implementation already built in. My collision code sucked. It was buggy and it was inflexible.

So one day after reading a book from the writers of MOAI, I gutted my game and implemented everything using Box2D. Suddenly, I had perfect collision detection, silky smooth movement and slopes (gasp!). The previous collision code used the tile set and slopes would have required specialised code.

This is a screenshot from a very early build of the game with a debug layer showing the collision rectangles. Anything collidable has a green hue and 2 lines (green and red ) showing it's orientation. 
As you can see if you look closely, there is a rectangle around the red guy on the right. That's his collision rectangle. 

There's also a little block underneath him, intersecting the floor. This little block is a sensor attached to the sprite to detect the floor so that the sprite can see whether it is falling or standing; very useful.

There's a block to the left over a door, this is an interaction sensor.

So in this one screenshot you can see Rectangular collisions blocks, polygonal collision blocks, sprite collision blocks and sensors; and it's FAST!.

This does involve a bit more work building your maps in such a way as to provide an object layer to create the collision blocks and polygons. 

Tiled does this very nicely.

The end result being a smooth and reliable collision resolution system, far better than anything the average developer could write as well as accurate simulations of bounce, torque, friction, gravity.. pretty much anything you need to build a game world - realistic or cartoon.

In Closing

Physics Engines are amazing and useful, they're not just for realistic simulation games and you should absolutely consider using one if you're serious about making any game.. spend your energy wisely and don't reinvent the wheel... literally.

Wow that was a long blog post.

No comments:

Post a Comment