Archive for the ‘Ballistic Force’ Category

Engines, Names and Evolution – Part 3

Tuesday, March 4th, 2008

Ballistic Force wasn’t a long project, but development was dense.

Early on, I attempted a poorly conceived idea of creating densely constructed particle landscape. I wanted a system sort of like molecular/planetary attraction to keep scenery together, and allow clumping like a cartoon snowball rolling down a hill. It might have worked on something highly parallel like a GPU or the PS3’s SPE’s, but my design really wasn’t well thought out. The prototype ran at less than 1 FPS, with a map that only covered a fraction of a screen.

The attraction didn’t work as expected either. A rather simple castle tower had a hard time staying together, tearing due to numeric instability. Interesting, but no good.

Ballistic Force Tower
Ballistic Force dense particle landscape, cracking

Ballistic Force “take 2″ was the Freedom engine again, but the plan was to carve in to polygon scenery. I was already generating 2D collision from 3D geometry, so in theory it didn’t seem unreasonable. Having just come off the particle landscape stuff, I decided my time was better spent diving in to the mechanics without destructible scenery. To start, that meant building a vehicle.

In the early experimentation, I built a tank-car using my equivalent of “Gishes” for tires.

Ballistic Force
Ballistic Force – Constructing the Tank-car

But like other rolling things, it had a hard time sitting on a sloped surface. Not to mention, it wasn’t pretty.

Ballistic Force
Ballistic Force – Rule #1 of Tank Club is to not talk about Tank-Car.

So attempt #2, the blue tank.

Ballistic Force
Ballistic Force – Constructing the better Tank

Better, but it’s obvious I wasn’t too good at texturing.

So I continued working on the mechanics. Making the tank aim and fire, adding a chase camera, and some mechanisms for righting yourself when you fall over.

Ballistic Force
Ballistic Force – Tank firing, muzzle flash

Ballistic Force
Ballistic Force – Genius shot himself

There was a real urgency to get something together sooner than later. This was in May of 2006. Now is not a good time to get in to the details, but it was the first time things got serious.

Art was a big concern. I wasn’t happy with my results, and we weren’t really confident enough in our tools to hire an external artist to work with them. 2D modeling, while similar to 3D modeling, is a niche if I’ve ever heard of one. My “bone like” system is tricky to work with as well, even we didn’t have it completely figured out.

The other problem is we didn’t have a clear idea of what art we needed. The tank was only moderately playable, and the game concept was rather vague. Future work would easily break any art produced now. We can’t really afford to have an artist come in, hang out, and create assets that’ll just be thrown away.

We wanted quick results, but it became clear with so many unknowns, this project wasn’t going to come together quickly.

– – – – –

Some technical notes on Freedom.

Collision geometry in Freedom were either collections of circles/spheres connected by springs (”sphere clusters”), or nodes held together structurally by springs that enclosed a convex polygon collision volume.

Verlet/relaxation solver.

The polygons didn’t work right, since I hadn’t figured out how the general separating-axis test worked. I was aware of it and it’s power, but how it just hadn’t clicked yet. As a result, all moving objects were “sphere clusters”.

Scenery collision was static triangles, axis aligned rectangles, and convex polygons. Eventually we added the ability to import a 3D model, and slice it with a plane to generate 2D collision polygons.

There was a loose system kinda like bones. You could weigh vertices of the display mesh to any 2 nodes of the collision mesh. It proved great for making static squish-able things, but our tools weren’t well set up for anything beyond that.

– – – – –

So when the Ballistic Force debacle calmed down, it was clear we should be making a game with manageable and clear content goals. So PuffBOMB was back on the agenda. With PuffBOMB we had the prototypes, and years of my collected notes and sketches to pull from.

However, Freedom wasn’t suitable for PuffBOMB. Not yet.

To start, it didn’t support animation. In fact, we were motivated to try alternative projects other than PuffBOMB because Freedom lacked animation.

While we were figuring out what else we needed, it sounded like a good idea to support collision animation. That’s not bones, that’s physically interpolated and re-orientable invisible collision geometry. Oh boy! In theory it could have made it possible to create motions and animations like bones would, but it wasn’t going to be as nice an IK system. Not to mention a whole slew of other issues brought on from dynamic collision, but that’s a topic all in itself.

I also wanted the ability to build maps by stamping (tiling) 3D geometry in to a scene. This was related to a problem where I didn’t trust my convex polygon generation code. I always suspected my triangulator was fine, but some shapes just didn’t optimize and generate correctly. So this was a double excuse to dig further in to this code and solve it on a smaller scale.

There were many more things the engine didn’t do, and things I wanted it to do differently. This was a serious overhaul. The foundation had to be rewritten, and significantly reorganized.

It was time for a new engine, and a new name.