SPLOIDZ programmer's post-mortem

The programmer for SPLOIDZ, Andreas "Black HC" Kirsch (a German chap), posted an entertaining (and unsolicited) read about his experience with the project on his blog @ http://blackhc.wordpress.com in three parts, reposted here for the GG crowd to enjoy:

###

Sploidz - About a Game

Finally after 8 months of hard but fun work Sploidz is done and has been released by Red Thumb Games. I was the lead (and only) programmer for that project (David House did code the prototype, however) and I'm so proud to see it released and played by you!

Here check out this screen:



Weee, exciting, isn't it?

If you want to find out more about the project, don't forget to check it out in the project area or download it directly from http://www.sploidz.com.

Enjoy the game,

Andreas

###

Sploidz for RedThumbGames

Sploidz is free game that I have developed for Red Thumb Games/Joshua Dallman in first half of 2006 using Torque 2D.



It is similar to Bejewelled - although neither my fish nor I have played that game yet, but so I've heard- and Tetris in that you have to drop differently colored gems and create as many matches as possible. Additionally, to keep you excited, there is a conveyor belt and a platform that keep adding new rows of gems from the bottom.

To create matches you have to arrange at least 3 same-colored gems horizontally or vertically, which will then trigger all same-colored gems around them to explode, too.

Look at these beautiful screenshots for example:




There are also different levels with prebuilt gems and you've got to collect all letters of the word SPLOIDZto finish a level and continue to the next. The conveyor belt and the platform also become faster and faster with increasing level number, so it should keep you fairly busy later.

We've also included a few special gems that make life easier like the bomb item, which destroys all gems in a certain radius, the missile item, which starts to destroy all gems in the same column one by one, and the magnet item, which destroys all gems of the same color like the one underneath the magnet.

This looks like there's a lot of action - almost too much for my fish's weak heart, if you ask me, so don't let him play! - and a lot of fun waiting for you.

If you want to learn more of how I developed it, and what exactly my tasks where while doing so, go the Inside Sploidz's Development page. If, on the other hand, you're easily bored and weak-hearted, go to http://www.sploidz.com and give my baby a try.

Product reviews, comments, feedback, etc etc are always welcome, just add a nice comment how much you loved to play it below.

###

Inside Sploidz's Development

So.. you've really dared to enter this page. I'm stunned. Be prepared to become bored beyond death and - um - beyond..

It all started with Joshua Dallman starting a RentACoder bid and me starting to bid on it. I wrote a long bid text - like always - and enumerated my long list of cool things I've worked on: Nexuiz and Nexuiz and Nexuiz. But since I've been working on so many different things during that project, he was convinced that I was the right coder for the job. Maybe my bid amount was also cheaper than the other bidders's, or I wasn't from India or something along those lines. We will never know, since I don't plan to ask him. I'm quite happy that we work together and I don't care for the rest.

Anyway, he chose me and I started to work on Sploidz during my winter vacation 2005/2006. I've never looked at Torque, let alone Torque 2D/Game Builder before, and spend quite some time - about 1.5 weeks - learning TorqueScript and the ins&outs of the code that was available to me:

You see, I wasn't the first one to work on Sploidz or rather ShellStack which was the name it was called in the very beginning. Someone else - if I recall correctly David House - created the "prototype" version which didn't employ gems but turtle shells back then and was buggy like hell. I guess Joshua has hoped not to be forced to call it a prototype but a release version, but as things were I had to start from scratch since code entropy had approached something my brain couldn't grasp - and I was unwilling to debug all that mess.

I started with the new codebase sometime around New Year's eve and I made good progress in the first two months. Joshua bought the Torque 2D Early-Adaptor License for me early on, so I had all the sources and the lacking documentation ready in the first weeks. My fish is still singing my old "Doxygen's my only friend" singsong from those days now and then.

Communication with Joshua wasn't always the best because he was travelling around and didn't always have an internet connection. I didn't know it and panicked quite a bit when the first deadline drew nearer and nearer and I hadn't heard back from him for a whole week. I've always been afraid of failing a project since at RAC there's quite some competition and the coder ratings are a major factor for winning or losing a bid.

Thank god, Joshua didn't expect me to finish it by the first deadline but apologized for not having been so responsive those days and for scaring the shit out of me and communication has been best since then.

He gave me some valuable feedback and I started the second iteration sometime around march. I tried to change the engine as little as possible since I believed and even stronger believe today that the less you change or code, the less can naturally go wrong. So I tried to keep my changes in TorqueScript and only consider a few thousand lines when debugging the game compared to the probably 100,000 lines of code the engine contains.

However, I still remember one nasty little sucker that wasn't even introduced by me. I experienced a very strange behavior in the game when moving from one Torque 2D release candidate to another: the game suddenly ran a lot slower and jumpier than before. It took me quite some time to find out the reason: due to performance optimizations or some other work on the engine, my frame rates went much higher, so high that the msec integer based timing inside the engine would start to lose to many time fractions per frame - e.g. 1 second in real-time would only appear as 600-800 ms inside the game. It took some time till I found that out and it took even longer to find out a clean way to fix that problem. In the end it turned out that the engine had a cvar that controlled the minimum of accumulated time per timer event which allowed me to cap the FPS on the one hand and get it to run stable again on the other hand.

Such precision bugs were the only real problems I've encountered while developing Sploidz in the engine. A similar bug, for example, was in the engine physics movement code. When you drop a gem, I wanted to have it fly a parabola curve like you would expect. So I simply set the force to a certain acceleration - yay, this sounds weird but this exactly how the engine calculated the relation between acceleration and force the last time I looked at the code - and asserted that the gem would fly correctly.

Well, I thought wrong, due to bad precision the gems had a different trajectory each time which caused some very bizarre bugs in my game code. So I wrote my own movement code which used some checks and resets to correct the flight trajectory. Again this was done inside the TorqueScript game-code and not in the engine to reduce possible debugging areas.

Sploidz as you can play it now is hardly the game it was in the beginning anymore. I have added, removed and changed so many aspects to/from/in the game with the game design guidance from Joshua that I can barely remember the first beta releases. They were fun to play nevertheless and if Joshua gives his OK, I might upload some of them and let you play them, just to see the transition the game has gone through its development life.

One of the aspects I'm most proud of is that my initial design worked out quite well: I've used a design that separates the game logic from the T2D simulation to protect the game against possible engine bugs (which were still frequent in the first early-adaptor releases). This turned out to be a great help both against the precision problems that I've explained above and against code entropy and complexity. The code is split among many files and many different modules and ScriptObjects (the TorqueScript equivalent of self-written classes) and is pretty clean and easy to edit in most cases.

Once again, Code Complete's pragmatic guideline "Code into a language, not in it" turned out to be true and helpful during development. Just because TorqueScript doesn't require OOP principles, variable declarations before use or type checking doesn't mean that one can't emulate these features in one's own code to drag out all benefits they offer.

All in all it was a great project and I experienced a whole development cycle from beginning to release and I'm thankful for that experience. It was also good luck that I've met Joshua for he has been very helpful and insightful and he knew how to make the best out of the various design ideas for Sploidz.

PS: There is the slight possibility that there is a secret menu hidden somewhere... Find it and unleash the power of the easter egg on the game perhaps.

###