Moving a User-Generated Spaceship with Physics: Part I

The core con­cept behind co.llide is for play­ers to be able to build and then pilot their own cus­tomized, phys­i­cally sim­u­lated space­ships. This means that when a player stitches together a bunch of pieces into a ship, the game needs to fig­ure out how that ship should move depend­ing on player input. Ours is cer­tainly not the first game to ever address this prob­lem, but we thought an expla­na­tion of our spe­cific solu­tion would make an inter­est­ing post. But why just tell when I can show?

Behold:

A wild DEMO appeared!

Note that the graph­ics you see in the demo are not the same graph­ics that we use in the game. Instead you are look­ing at debug ren­der­ing that we use to see what’s going on inside our game’s physics sim­u­la­tion while developing.

What’s in a Ship?

From look­ing at the demo, you may notice that each ship is com­prised of two things: solid col­li­sion shapes (rec­tan­gles), and thrusters (triangles).

thruster-ai-demo-big-screenshot

The rec­tan­gles define the actual shape of the ship to be used in deter­min­ing how the ship col­lides with other objects in the scene. The actual shape is com­prised of a bunch of tiny rec­tan­gles, which we lump together into larger shapes for opti­miza­tion. If you crash into the walls at high speed (which I highly rec­om­mend because it looks cool), you can see the shape change as some of the tiny rec­tan­gles break away.

Thrusters allow the ship to move by cre­at­ing forces at spe­cific points on the ship. You may notice that there are two dif­fer­ent col­ors of thruster: white and green. The green thrusters are “magic” base thrusters. In addi­tion to being inde­struc­tible, these base thrusters have some spe­cial prop­er­ties that I will talk about in a later post.

Fly­ing the Ship

When a thruster fires, we apply a force to the ship at the cor­re­spond­ing posi­tion and angle. Using a physics engine, (in our case, Box2DWeb), makes this part easy. Like magic, the sim­u­la­tion applies the cor­rect lin­ear and angu­lar accel­er­a­tion to the ship’s rigid­body, inte­grates the veloc­i­ties and posi­tions, and han­dles collisions.

The much trick­ier part of the prob­lem is decid­ing which thrusters should fire based on the player’s input. What is the player try­ing to do? What is the player prob­a­bly not try­ing to do? How do we max­i­mize the for­mer and min­i­mize the lat­ter, given that cer­tain motions might be com­pletely impos­si­ble with a spe­cific ship’s shape and thruster loadout?

First Attempt

Our game is heav­ily inspired by other physics-driven space shoot­ers, par­tic­u­larly Cap­tain For­ever. There­fore, our first attempt in solv­ing the move­ment prob­lem was to mimic the same con­trol scheme as Cap­tain For­ever, allow­ing the player to move for­ward or back­ward, rotate, and strafe using the W, A, S, D, Q, and E keys. I could go into the details of pre­cisely how this is done, or I could just point the reader to this really excel­lent arti­cle on mov­ing 2D ships from thrusters, which explains exactly the process that we used.

Some­thing More to the Point

Over­all the Cap­tain For­ever scheme works well and is pretty easy to imple­ment. How­ever, we wanted to try some­thing a bit dif­fer­ent to make it eas­ier for play­ers to steer and aim at oppo­nents. At the moment we are exper­i­ment­ing with the con­trol scheme shown in the demo. This scheme allows the player to steer the ship by using the mouse pointer to spec­ify the exact direc­tion that the ship should face. Simul­ta­ne­ously, the player must be able to move and strafe rel­a­tive to the ship’s cur­rent fac­ing using the WASD keys.

Spaceship control scheme.

This becomes an even more com­plex prob­lem. We are no longer inter­ested in just turn­ing the ship clock­wise or coun­ter­clock­wise as in the pre­vi­ous exam­ple, but instead want to reach and stop at a spe­cific ori­en­ta­tion, all while doing our best to match the ship’s lin­ear motion with the player’s inputs.

If you’re curi­ous about all the nitty gritty details behind how we do this, as well as those mys­te­ri­ous “Thruster AI Weight” val­ues that you can tweak in the demo, then stay tuned. In part II, I’ll be walk­ing through some of the demo code and explain­ing the math behind the madness.

Andrew Dolce

Andrew has a back­ground in com­puter graph­ics and aug­mented real­ity, and is excited about mak­ing games that look and feel awe­some. He also owns too many board games for his own good.

More PostsTwit­ter

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>