View Tags

June 23, 2011

The advantages of shattering your game

Sometimes, in order to save something, you have to shatter it. Making Telepath RPG: Servants of God has taught me some hard lessons about the importance of modularity in designing a larger game. I’ve finally reached a point where, in order to finish creating the game, I must break it into pieces.

Let me explain. Modularity is all about building things in independent parts that will ultimately come together and work in varying combinations. To analogize: it is the difference between carving a Mr. Potato Head statue out of a single slag of rock, and assembling Mr. Potato Head‘s face with interchangeable parts.

image-869

Up until fairly recently, I’d been carving TSoG out of a single slag of code and assets. Sometime last year, I broke off the sounds and music into external files. But then I continued with the old ways. Until this past week, that is. This past week, I spent hours chip-chip-chipping away at the combat engine until finally, it came loose with a groan and a satisfying crack.

It had to be done. Flash is like a wizard: for all its many powers (and believe me, it has quite a few), it is ultimately a fragile thing, unable to shoulder heavy loads. Put another way: Flash is like a particular, well-known wizard, in that it has memory problems.

image-870

As I kept adding content, the program staggered, stooping further down toward the ground. It moved slower and slower, until finally it could only drag itself along in short bursts, arm over arm. Compiling the game made it lose consciousness entirely for an extended period.

Would you believe that each compile took up to 30 minutes? I couldn’t even cancel the compile if I realized I’d forgotten something–the program simply wouldn’t respond once it began the process. Every time I made a change and wanted to see how the changes affected the game, I would have to sit there aimlessly for half an hour. Sooner or later, I would get bored and go clean the dishes or sweep the floor. These heinous compile times ended up as a boon of cleanliness to my apartment. But they certainly weren’t helping me get the game finished.

Eventually, I just couldn’t take it anymore. I reached a breaking point in a very literal sense: I hacked away at the biggest self-contained chunk of game I could find (the combat engine) until I had broken it off.

The combat engine now resides in a separate file. It hovers around anxiously, waiting for the main game to call it into action. And call it does; every so often. But when the dust settles and the battle has concluded, the battle engine must slink back to its own remote corner of the folder. Such is the life of a module.

With the combat engine splintered off the main game, everything suddenly moves much faster. Content is easier to add; build times are cut significantly. But most importantly, I can now finally build the game in AIR, which means downloadable Mac and Linux versions of the game are finally happening.

The dictionary says that “break” means “to smash, split, or divide into parts violently; reduce to pieces or fragments.” But when TSoG is done, I’ll be able to look back on the process of shattering it as a crucial step toward making it complete.

  • Idozen Cair

    Shattering something and putting it back together after modification is indeed a smart way and it does show its usefulness in life, apart from making games. Good luck Craig!

  • Pingback: Gearing up for the next big update « sinisterdesign.net()

  • stinky472

    Code refactoring is a fundamental necessity for the seasoned developer to keep systems ready for change without massive maintenance and code deterioration, to freshen it up and make it ready to accept bold changes again.

    But I’d say, especially in the field of indy game development, don’t overdo it. It’s very easy to fall into the temptation of building the most intricate sound engine or modular GUI widgets only to find yourself forgetting the very thing that drew gamers to your work in the first place: a yearning to have fun. Never lose sight of the end goal: basic code quality safety and maintainability important but code perfection is not something that always translates directly into the product, especially in products whose sole purpose is to entertain.