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.