Non Gameplay-related Development
Posted by Alex Jordan on
Cute Things Dying Violently was something I expected to program in three or four months. It wound up taking fourteen. Even so, most of the major gameplay stuff was done by Chrsitmas. So what the hell happened?
I'm assuming that the back eight months of development mostly involved tying everything together. To figure out whether or not this is true, I'm going to go through my code base and determine what was gameplay-related, what wasn't, and where certain tedious batches of code were downright inevitable:
- Handles all the in-game code that runs and organizes objects, input, gameplay, and does all the related drawing
- Animal Stuff (so named because I thought I was going to have real animals in the game)
- All the information and behavioral characteristics of Critters
- Unique handling of Critter deaths
- Voice and animation instructions for Critters
- "Prediction" code for Critters, so that they can yell out ahead of time if they know they're about to die
- Singleplayer-specific rule handling (for scores, departing elevators, etc.)
- Multiplayer-specific rule handling (scores, level timers, Powerups, etc.)
- Special level rule handling (huge, huge chunks of code to handle the specific scripting and events of each Special level)
- Information on the structure of any given in-game level
- Information on every single Level Object that appears in-game or can be used by the Level Editor
- Particle creation and management
- Routines for each special Particle Effect in the game
- Special collision rulesets to make Particle collisions more efficient
- Level Editor Menus
- The Level Editor itself, including all the input rules and tooltip displays
- The main game loop that mostly delegates to other game loops depending on what screen the player is on
- Loads game art
- Handles those iris-out transitions
- Heads Up Display (notifications, message visibility)
- Instructions on what constitutes each Message (things like tooltips)
- Message Box handling and input for them
- Achieve Mint displays
- The end-game Credits roll
- Detection and error-checking of a storage device
- Specific Save and Load routines for every bit of custom data that gets saved or loaded (e.g. player scores, custom levels, etc.)
- Main menu
- Singleplayer Campaign menu/Trial Campaign menu
- Custom levels menu
- Special levels menu
- All the score/unlock displays for each menu
- Submenus for choosing levels and Powerups
- Changing rules
- Detecting a second player
- Toggling various settings
- Information on menus, locking/unlocking menu items, and handling input
- Loading sound effects and music
- Playing/adjusting music volume depending on level
- Categorizing various sound effect types and playing them as needed
- Categorizing various Critter/Hate Boy vocalizations and regulating their use
That's not everything, but that covers the big-ticket items.
In reviewing the list, I find it astonishing that only the first three sections (CTIngame, Rules, and Animal Stuff) directly handle gameplay. That's it. Everything else regulates the game.
I'd find that horrifying, but pretty much every other section handles crucial, unavoidable systems that were necessary for the game to run well. In LevelInfo, all of the level object types had to be enumerated, period, or else I wouldn't have much to do with levels. Ditto for CTLevelEditor, which had to be finished so that I could easily make levels for the game. Data needed to be saved and loaded, so there's the StorageHandler. I needed menus and instructions, so of course I needed to put a lot of work into the MenuSystem and CTHUD stuff...
The unfortunate conclusion is that CTDV took forever to make because I did a (mostly) thorough job of making it. The in-between stuff is there so that the player can swiftly and cleanly move from one level to another, and be properly informed about what they're playing and doing. Nothing in there is really superfluous... if I spent a ton of time on it, it's because I knew I was going to use a lot of that feature (like Menus) and I wanted the code to be solid every single time I deployed it.
Which brings us to a problem with XNA: it's relatively easy to setup gameplay (and doing so only took me six months, remember), but since it's a bare-bones library with no support features, everything else has to be done from scratch. Saving, loading, menus, messages... you name it. Most modern engines are going to unified development environments these days, giving you a framework and the tools to quickly implement this filler stuff. Not so with XNA.
And now I'm sitting here and pouting, realizing that I worked my ass off in XNA despite the fact that it's not a very rewarding library (development-wise). Harumph.