Crooked Legacy #1 – Intro

Welcome to my first devlog post!

For this first post, I’m gonna quickly introduce the idea behind this series. In it I’ll explore the practical legacy of mistakes and misguided decisions I made early in the process of creating Dark Stars. Maybe other rookies can learn from these mistakes. More importantly, I think it’s useful to reflect aloud on such decisions, because doing so will strengthen my Programmer’s Intuition, hopefully preventing me from blundering into such things in the future.

When I started working on the earliest versions of the game, tiny proof-of-concept builds with placeholder art, I didn’t necessarily anticipate its eventual scope, nor even really what it would be. That’s not uncommon, despite the sternness with which students are endlessly drilled with the adage “design first, then implement.” In the only real programming class I took in college, for every project, no matter how small, we were made to write pages of pseudocode in semi-plain English, step-by-stepping through what would become the code.

That’s really boring. And with a game project, you really can never know what it will become when you start. So instead I just started prototyping: getting a ship on screen and playing around with it, tossing in mechanics on a whim and testing their playability and fun factor myself. For the most part, this turned out fine. The central mechanical hook of the game, The Maw, wouldn’t exist were it not for this approach.

But on the other hand, this approach in general leaves your code sagging with ugly baggage. Old assets are still loaded into memory at runtime but never displayed, piles of forgotten variables are still initialized but never used, and whole class files get compiled despite serving no purpose. But that’s not the worst of it; that junk can be cleaned up without much trouble. What is even harder to anticipate are the quirks and limitations introduced into your flow of information, your broader structures. What was once a temporary solution has become your permanent one, and instead of refactoring square pegs into round pegs when you should have, you improvised temporary adapters to make them fit into round holes. These temporary adapters become permanent adapters.

I was going to use a picture of a regular Jenga tower but I found this picture of a fish stick Jenga tower.

Before you know it, you’re left with a late-game Jenga tower of code. You want to expand some capability or feature of your code to let you implement a new idea, but that means pulling out a block near the bottom. You tear your hair out because you cannot fathom how to get that brick out without toppling the whole mess. This can lead to some serious headaches, most of which I resolved a long time ago, some of which I’m still working with, and some of which I’ll be writing about in future pieces.

In one sense, I’m proud of the code beneath Dark Stars. It is built on Microsoft’s XNA, a very useful and friendly game environment for C#, but I’m using no packaged engine. Apart from a few borrowed blocks of code and techniques, the code is all mine. For being my first large scale project, I’ve come up with some elegant and powerful solutions. On the other hand, much of it would make any intermediately skilled object-oriented coder wince. Live and learn.