Straight to the Source

Last year I said if I ever decided to take Cogmind beyond the 7DRL stage I’d rewrite the entire thing from scratch. Note that “from scratch” is not to be taken in the absolute literal sense, since my intention was to simply do what I did for the 7DRL: Strip down a copy of X@COM, then proceed from there to create Cogmind.

That’s not happening.

Development actually started that way, but after a couple days I had to trash the results due to the sheer amount of modifications necessary. Last year the X@COM code base wasn’t all that huge after less than a year of work on it, but since then it’s ballooned into a huge number of complex features, many of which would have to be removed with surgical precision since Cogmind doesn’t want them.

Nope.

Of course I also wasn’t looking forward to the prospect of having to re-implement a bunch of the same Cogmind code that, combined with post-7DRL updates, originally took a couple months to write.

In any case, any way to speed up this project is welcome. One of the most important lessons you can learn in game development is that the ultimate goal is the most important one--you have to finish or you lose*, that and the longer the process drags on, the less likely it is to succeed. (*Unless you’re just doing it for fun or experience, but those shouldn’t be primary goals if you intend to sell the game.)

The main thing that annoyed me with the 7DRL code was a few nasty bug reports that I couldn’t replicate, but those aren’t so scary now that the engine has a better built-in solution for debugging post mortem call stack traces, which always gave me a headache before. Now… NO BUG IS SAFE!!! (If you’re using C/C++, for a nice little Windows-only solution w/source see here.)

Another reason to rewrite would be to change certain architectural considerations born of rapid development constraints inherent in a game jam game, but fixing those piecemeal as necessary will still take less time than a complete re-write, so…

Cogmind has gotten a significant jump start by beginning with the old 7DRL code base. This also means feature testing can happen immediately since the game is already playable--what a bonus! Seriously, being able to do iterative testing on individual new features helps push development along quickly. With the chopped up source code I was thinking of working from, proper testing would have been impossible until a large portion of the code was in place, which would then devolve into a debugging nightmare. I’m all for skipping nightmares and going straight to the party.

Speaking of parties, next post we should talk about something more fun, like new weapon modes.