Archive for March, 2008

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 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 – 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 – Rule #1 of Tank Club is to not talk about Tank-Car.

So attempt #2, the blue tank.

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 – Tank firing, muzzle flash

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.

Game development became a constant burn out for me. Since finishing Secret Agent Barbie (Gameboy Advance) and Polly Pocket (Gameboy Advance), it became clear to me the only thing keeping me going was my fascination with new platforms. Certainly not the subject matter.

After we finished Polly Pocket, I asked for a month off to deal with my burn out. However, we quickly picked up a new game, Barbie: Gotta Have Games (Playstation). The game was incredibly late in the Playstation lifetime, but Barbie’s a hard brand to make fail. This was my last chance to do a Playstation 1 game, with the PS2 nearly 3 years old at the time. I had to take it.

After that was finally done, I took my month off. I wouldn’t say I was recovered, but I was in heck of a lot better shape than I was before I left. That lead to Brown Box, leaving DICE, joining my friends company to “play” management, and eventually to Destructure.

As Atomic Betty was going to be my last project at Big Blue, Destructure was retired as the Atomic Betty engine. Whenever I start an engine project, I always intend on making something reusable. But as usual, I end up with too many things I want to do differently the next time.

So a burned out programmer, all of his last 5 notable projects girl games, anxiously anticipating his chance to finally do the games he wants to. What sort of iconic name has he brewed for his engine?

He calls it Freedom.

Now, I don’t want to give the wrong impression. Big Blue was and still is the best company I’ve worked for, and I’d gladly work with them again. The engine name is about philosophical freedom. I like to joke with friends about my girl game curse. In actuality, I’m just not happy working in the traditional business model of developing licensed games. Of course it’s possible I’ll do a project again to replenish my reserves, but I can still go a while longer.

Outside of my early retirement, the Freedom engine was motivated by the console downloadable game revolution. It didn’t exist yet, but we all knew it was coming (fingers crossed). I was officially “retired” in August 2005, and that’s when my focus became Freedom.

With the 360 only a few months away, I was going to be ready!!

…

Oh… that’s right! It seems I’d forgotten about the burn out.

Truthfully, I don’t think I was ready for anything until at least a year later. That didn’t stop me from chaotically developing whatever seemed cool at the time.

Going back again, Destructure was inspired by the potential of downloadable games of the time. This was mid 2004, where this was Casual games. Back then, I was an Indiegamer regular. I watched and discussed business theory with many who have gone on to become major players in casual games. I’d even gotten myself involved in GameTunnel, to do extra research. At Big Blue, we’d regularly geekishly discuss the casual and mobile games market, as we worked our asses off to recreate the glory days of DICE’s “Team Gameboy”. We came close enough, girl game and all.

But with projects like Gastronaut’s Fuzzee Fever on the original XBLA, and The Behemoth’s Alien Hominid, the juices of inspiration and potential were not only flowing, but boiling and bubbling. Where Destructure started with the goal of breaking in to PC casual games, Freedom was nextgen.

Freedom was designed to be an HD ready 2D game engine. As a result, one of the earliest purchases I made was one of those lovely 24″ Dell’s. Slightly higher resolution than a 1080p HDTV, and *much* cheaper. As before, the PuffBOMB remake was on the agenda, but structure doesn’t come easy to a burn out.

Early Freedom experiments

So the Freedom engine was built, and it became a testbed for physics ideas. Eventually I’d start toying with Gish like squishy blobs, and ropes. This lead to The Spider, a double rope platformer experiment, again, spearheaded by the sound mind of a freshly “retired” burned out coder.

Freedom experiments that evolved in to The Spider

I’ve already talked about The Spider a bunch already (with videos) in my previous attempts to get up to date. Check these out if you want to know more.

During The Spider was also when I recruited my brother to help out. This was near the end of 2005. His main task was editor programming while I built the engine. We’d share the content building duties.

Freedom’s Object Editor

Freedom’s Map Editor

He’d previously worked on some contract mobile games, as well as helping out on my earlier efforts. Of note, he did most of the map and world building on Murmur’s Dungeon (the 6-1997 game above), and helped a bunch with the character design on Islandgates (the 10-1997 game, lots of content we never got around to using).

As expected, bringing on somebody new (especially someone as familiar and opinionated as a sibling) encouraged a bit of an identity crisis for The Spider project. Despite, as I’ve suggested before, the game wasn’t well developed either. Adding him probably helped more than hurt.

During development of The Spider, it became clear that the goals of the project weren’t clear. More ambitious than anything. With tools, a working engine in hand, and some outside “encouragement”, we started discussing games of smaller scope we could pull off.

The Spider was followed by the destructible scenery project, Ballistic Force.

Over the years, I’ve given names to game engines I’ve worked on. Most of my professional experience has been working on platformers and mini-game collections. Mini-games rarely share much in common, so by engines I’m referring to platformers, or engines for games very much like platformers.

I’d like to start talking about what I’ve been thinking about whilst designing my next engine. I need to set some context though, so I’ll be walking through some of more significant engines I’ve worked on.

Going way back, I really didn’t start naming my engines until after Secret Agent Barbie (Gameboy Advance). I did name my GCC driven Gameboy Advance tool-chain “ATK” for Advance Toolkit, but my priorities eventually changed. As a team we used the interal code name of “Bond“, but I’m sure that was just us wishing we were doing a James Bond game instead.

“Bond“, like each of my platformer engines before it, was a “Megaman Physics” engine. Megaman Physics are what I call platformers that solve moving characters against static scenery, but do something artificial to solve object vs. object collisions. Pretty much every 2D Megaman games sets you to an injured state and gives you a brief constant velocity opposite your facing direction, followed by temporary invincibility. That meant you could walk right through the enemies after that brief interruption. In retrospect, I’ve started to think Megaman Physics might be superior for playability, but that’s a topic in itself.

Before I left DICE, I was working on a project with a coworker that we referred to as “Brown Box“. The name was a play on the idea of a black box, with a cynical inside joke a handful of us had. The essense of the joke was, if you came in one day and found a brown cardboard box on your desk, you were fired. Pleasant.

Brown Box was a 3D R&D project. On my own time, I was working on some 2D physics experiments. My early efforts became the Zooble prototype (with it’s very wrong physics), a verlet testbed Phiz, and a series of further physics experiments adopting such strange names as Popcorn, Cactus, and Canadianese Simulator.

Phiz, where my verlet fascination began

Canadianese Simulator… isn’t it obvious… they’re red.

Destructure was conceived as my “Post DICE” engine effort. The name was chosen ’cause it sounded cool. I left in June 2004, just over a year after making the original PuffBOMB prototype. I left with the intention of building an engine for the PuffBOMB remake (and other projects), and eventually to help out a friend at his new company. I left as quickly as was appropriate, hoping to get a couple months of work on Destructure in. Alas, all I had time for was a couple weeks of R&R, and to start a compo game before I was called upon.

Destructure eventually became the engine for Atomic Betty (Gameboy Advance). I was well versed in classic and verlet physics at this point, and was using that experience to build a low spec cross platform game/physics engine. Beefy goals as usual. We landed the Atomic Betty project, so I re-purposed my design to suit the game. A fun aspect of Destructure is it, for a while at least, it compiled both on the PC (with Allegro) and for the Gameboy Advance. As the project kicked off, the GBA specific code grew so fast, it wasn’t practical (or necessary) to concurrently develop.

Early PC version of Destructure. Red boxes are the overlap.

Some technical notes. Objects in Destructure used circles and axis aligned rectangles for collision, though Atomic Betty only used the rectangles. Objects were moved and solved with a bare bones verlet/relaxation solver. The rectangles were actually the 2 corner points, with a pair of verlet spring constraints (width and height) keeping it from collapsing in on itself. No square roots required . Solving two rectangles was rather novel. I took the overlap/union rectangle of the two, and used it’s shape to determine how to solve. If the overlap was wider than tall, I’d push them each half the height up/down out of each other, and vice versa. Unlike moving a center point, this actually squished the rectangles. Then the next frame, the springs restored it’s size to normal.

The next engine’s name and story is a little complicated, so we’ll save that for next time.

About tooNormal

tooNormal is the digital notebook of Mike Kasprzak. Some may call it a blog, but it's more a collection of notes and thoughts, when Twitter just isn't verbose enough.

Mike is a long time veteran game developer, having done time at various game studios plus "the indie thing" for well over a decade. He owns and operates SYKRONICS. He also organizes and runs Ludum Dare with some awesome people.