Archive for the ‘The Spider’ Category

The Development of Smiles, Part 0

Friday, January 2nd, 2009

I know my track record for completing a blog series is pretty lousy, but this one should be easier. I kept a personal log with pictures during the development of Smiles, so most of the work is done for me. I just need need to go through it and regurgitate my notes.

To start, I’m going to give a bit of insight in to what happened when I stopped writing my Engines, Names and Evolution blog series last year.

I apologize, but I am going to skip a significant follow up to that series for now (the Hammer engine), but this series should bring us back up to date.

Here we go.

– – – – – – –

Late 2007 and early 2008 were spent working on libraries, and foundation for my new engine Playground.

Playground was the successor to Hammer (PuffBOMB HD… will talk about this another day), which in turn succeeded Freedom.

– – – – – – –

Before PuffBOMB HD was shelved in late 2007 (Hammer engine), I was working alone on the project. Amicably, but that’s a series for another day.

The core issue with Hammer is that it wasn’t very reusable. As a whole, you could certainly build a new project based on it, but it’s elements were poorly isolated. Triangulation and collision testing code was embedded right in to the physics engine, so I couldn’t use the same code elsewhere without a lot of waste.

I prototype games regularly, and the product of this year of development (2007) wasn’t as useful as it could be.

– – – – – – –

Late 2007, I was at a crossroads. I still had savings left, but only enough to support myself. I needed a break from PuffBOMB HD, so I coined a new project. A suite of libraries and tools I could personally use for prototyping and developing games faster and more efficiently. The end goal may have been to build a Metroidvania derivative, but the core of the project was to build me some tools. If the project was going to fail again, at least I’d have a foundation to try the next thing. This was the Playground project.

Here’s where I get technical.

As mentioned, Playground is a suite of libraries and tools. It started with me collecting what usable parts I could extract from Hammer, and my Ludum Dare games and framework.

I should also mention that by library I’m referring to an element. A directory of files. Either copy the directory in to a project, or set up an SVN External for it. Only a crazy person would compile their work in progress library to a .lib/.a file and install it. If that’s you, you’re crazy! 🙂

One of the first and most useful elements I built was the Data and Serialization library. I decided to finally stop using C++ streams for binary File I/O, but wanted my file reading syntax to be nicer than fopen. The syntax for loading an arbitrary binary file from disk is as follows.

DataBlock* MyData = new_DataBlock( “Data.bin” );

Nice and easy. A DataBlock is an incredibly useful and lightweight basic type. It represents an arbitrary block of memory with a size stored in the first 4 bytes. It’s defined as followed.

struct DataBlock {
    size_t Size;
    char Data[0];

Pretty simple. For completion, the Data and Serialization library includes similar calls for normal non DataBlock data, but they’re so lightweight and flexible I use them anyways.

The great part about writing your own I/O wrapper is you can seamlessly integrate things like compression, munging, CRC’s and checksums. For example, load and decompress a file in 3 lines (one cleanup).

DataBlock* Compressed = new_DataBlock( “CompressedFile.zlib” );
DataBlock* Uncompressed = unpack_ZLIB_DataBlock( Compressed );
delete_DataBlock( Compressed );

The library is also written in such a way that, while it supports many compressors/hash methods, they are not required to be built or linked against the project unless explicitly used. In other words, if I don’t use BZIP2, I don’t need the BZIP2 headers or C files. As lightweight as you can make a library.

The vector math library is borrowed right from Hammer, cleaned up and isolated to be vector, scalar, and matrix math only. Types for rectangles and simple primitives are a library. Coding niceties like template types containing a,b,c or r,g,b,a components are a library. Strings, parsing a whitespace delimited file, and debug console logging as well.

Collision tests, and everything you do between primitives is a library of functions. Extremely long names, but they’re now modular in such a way they can be used in a physics engine, in a primitives library or a GUI/Menu system.

if ( Test_Point_Vs_Polygon2D( ... ) ) ...

Where this one returns a boolean value. I wont bother listing the arguments, but it’s a global C-like function. It takes direct types and pointers where appropriate. The functions follow the form “Action_What_Relationship_Who( … );”. Action is the operation, What and Who are the terms being tested, and the Relationship is the rest of grammar required to describe the operation.

Nearest_Point_On_Chain2D( ... );
Nearest_CornerPoint_OnEdgeOf_Polygon3D( ... );

Where the Smiles story begins is the Grid library.

Grid was a library created for a Ludum Dare game Pillar Caterpillar.

Here’s some concept art.


Pillar Caterpillar wasn’t playable within the compo timeline. It however still featured some great pre-production work, and a useful chunk of code that became it’s own library in Playground. Further work was done on the project, but that mock-up is the coolest looking part.

For the time being, only minor changes were done to Grid.

– – – – – – –

Shortly after the iPhone SDK was official announced in March 2008, I started prototyping some game concepts. The first, Magtraction (since Magnetica was taken, by a game completely unrelated to magnets).


A prototyped game concept deemed “too boring“.

The second, Dungeon Legion.


A prototype game concept deemed “too awesome“. Too awesome to finish in a short period of time. 😀

Both of these prototypes were the projects used to get the geometry tests up and working again.

You might hear more about Pillar Caterpillar and/or Dungeon Legion in the coming months (both projects are on my list I’m considering).

For the 3rd prototype, I wanted to revisit Grid.

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.

Engines, Names and Evolution – Part 2

Tuesday, March 4th, 2008

This next engines name and story is a little complicated.

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.

The Spider
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.

Part 1, Part 2, Part 3, Part 4
Part 5, Part 6, Part 7, Part “+1″
Videos: New Part 1, New Part 2

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.

The Spider
Freedom’s Object Editor

The Spider
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.


Monday, December 10th, 2007

Yeah, sorry. I wanted to do detailed commentary of The Spider stuffs, the in between stuff, and get in to the new PuffBOMB stuff, but it looks like it didn’t happen. I wrote an outline and drafted a couple parts, but I wasn’t happy with the results.

“New PuffBOMB” has been down to just me since October. The artist finished his work, which turned out great. Richard got a job, and has been unavailable to help since. So, I’ve had to make that adjustment, which has been keeping me busier than I’d hoped.

The 2nd video of the retrospective, circa March 2006. It’s actually been online for some time. Just ’cause I don’t like my commentary, doesn’t mean you can’t watch it.

(Click the last button on the top for fullscreen, 2nd last to toggle scaling)

Invisible object in the way. And yes, in case it wasn’t clear, I did not continue with this, the ball+rope game (AKA: The Spider).

Prior to really diving in to doing a “physics game”, I really did think heavy physics were the way to go. But a number of them have come out recently, and after playing them (and my own), the novelty has really started to bore me. If it’s not bad controls, it’s level/puzzle content ‘en mass. 100 levels, because you’re supposed to have 100 levels. Personally, I just don’t care to play them anymore.

Mind you, I don’t play a lot of games anymore.

This wasn’t my reason for switching from The Spider back to New PuffBOMB. After all, it’s just as much a physics game as The Spider was. If anything, it falls in to the new gaming cliché of an Incredible Machine clone with physics. If the Wii isn’t bombarded with these, I’d be surprised.

Switching back to PuffBOMB was one of economics. The Spider was really just a step in the development of a physics engine. The game concept was undeveloped, and lacked an art foundation. As much as I’d have liked to do art, beyond character designs, I’m not all that useful as as artist yet. Every prior game I’d worked on was low resolution, pixel art driven. This project I wanted to be HD ready, with vector/flash graphics. That should have been reason enough to expect outsourcing the art. With my limited art budged, there was no room to take chances on an undeveloped concept. Sure, there were ideas, but nothing concrete enough.

So, PuffBOMB it was decided. This was around October/November of 2006, about a year since Richard came on board to help me out. Take the original game, HD it, and do more with the idea.

We had our ups and downs. We’ve made mistakes. But I do think we still ended up with something interesting.

I suppose the first project always seems to be the toughest, even though I’ve made games before. I keep telling myself I know exactly how to approach the next one. But right now, this one is the important one.

Development continues…

The “New” Project, Part 1

Saturday, September 8th, 2007

Before starting work on “The Spider”, I was building the engine for the “new PuffBOMB”. The concept behind the engine, 2D characters and physics, 3D backgrounds styled to look 2D, HD ready. Pretty standard stuff.

The concept behind “The Spider” is, unlike a normal platformer where you stand on the ground, this one you wouldn’t. Instead you would hang from and move along ceilings. The best idea I had at the time for pulling it off was something I nicknamed “double ropes”, one to support, and one for action.

Eventually over the course of new PuffBOMB’s engine development, it seemed like a good idea to try a squishy ball thing, Gish like. A dense circular shaped thing supported by springs. No problem.

Roll ball roll love hole... ?

These ball things were really cool. Moving them was a simple matter of applying tangential motion to all the points making it spin, and so long as friction did something, they could move along a surface. Very cool.

I suppose it’s of note that I did my collision slightly differently than Gish/Loco Roco, placing spheres on the end of each point. I’m not sure if the method is functionally any better, but in “spring display off” mode with collision display on, I get spirographs. :)


In continuing with “neat things to try”, I wanted to give ropes a try.

I'm stuck!

Here you can see a “ball thing” tethered with several points along a rope. Initially to get it working, I simply locked the end point to the scene, so this rope was more like a bungee rope than an umi rope.

This is about when I came to the conclusion that, hey, I should do this game instead. I was convinced PuffBOMB couldn’t work well on a gamepad. But aiming with an analogue stick, and pressing a button to fire a rope, that was way more gamepad friendly.

So a big number of things happen at this time. I get Richard involved, building tools to produce game content, and generally work with me on the game. The design evolves from “hanging spider”, to tentacle goo ball alien. I would eventually hacked in a method of firing ropes, adding a spring between the character and the point hit on the contact.

But before we get to far, while writing that original “And the Project” series, I recorded a gameplay video. I decided to sit on it until things were further along with the game. Well, now is as good enough a time to show what it was all about.

“The Spider”, February 2006.

(Click the last button on the top for fullscreen, 2nd last to toggle scaling)

Here you can see Richard’s lovely test level, impaled Blender monkey head and all.

At the time I thought we were doing something pretty cool. The scenery would be built in 3D in Blender, and be arranged in such a way that parts of it crossed a “plane” conveniently assumed to be placed on the origin. I’d then slice all the 3D geometry crossing this plane, and generate 2D collision polygons for the physics to use. Technically cool, but this eventually turned in to quite a headache.

You also get to see my other mechanic that I thought was pretty clever. Expanding. Pressing a button toggles between being normal to doubling your size. What I really found fascinating about it was how multipurpose this mechanic was. You can use it to jump, to push things, or even to attack.

So now that we had some cool gameplay work with, it was up to me to make the game look cool. How the whole art thing went, next time.

The “New” Project, Part 0

Wednesday, September 5th, 2007

Pestering works. :)

So it’s September now. Last time I gave a *real* update was a year and a half ago. A 7+1 part blog series titled “And the Project”, where I introduced what went in to a concept I called “The Spider”. You can read it here:

Part 1, Part 2, Part 3, Part 4
Part 5, Part 6, Part 7, Part “+1″

Well, nearly a year and a half later, as expected a lot has happened. My loyal reader might even remember the job posting I posted a copy of in January. Stories you must have, yes?

I’m not ready to reveal everything today, especially not the latest stuffs. But after a year and a half, you accumulate quite a backlog. And I figure, there is much to take away from the process.

So, I’m taking a few steps back, and will starting talking about what’s been going on. My apologies, but I am starting with PuffBOMB lore, and working my way forward. After all, it’s kinda important to what’s been going on. ;)

There you have it. Consider yourself teased.