In space, nobody will hear you geek

There you are. I’ve just completed core gameplay programming for the first episode of… well… let me think up a name for it.

This looks like a small adventure/action game in real time 3D. Core gameplay can be summarized as follows:

• 4 player actions
• 9 different NPCs
• 6 items to collect
• 5 stages
• dialogues, here and there, to orient the player towards the right solution

There’s a lot to get the game done, but I still hope this won’t spread over more than another month (part-time). What do I leave out from ‘core gameplay’?

• Bugs. Many bugs.
• Non-committal gameplay elements – more dialogues here and there, minor NPCs without complex behavior and so forth. Non-commital gameplay elements are important. That’s added value on my game. But one needs something they can add value to, right?
• Game tuning – mostly timing / measurements related.
• Prettier rendering
• Production level artwork
• Decent Sound

Technical Design, Methodology

Given the above, you bet I didn’t bother with either of the following:

1. Getting stories ‘done done‘
2. Unit tests
3. … other nice things

Why? Is the nice, agile stuff not nice more? Why is missing the ‘done done’ over and over so irritating while doing team work, but somehow left out when geeking in a small studio? Do unit tests not warrant code quality and so forth? Or is it just that it’s faster to do without all this stuff?

Here are a few things I surely didn’t leave out:

1. Story driven. Even though I had to build an engine before I could even get to thinking of a game, I’ve kept a steady emphasis on getting valuable items done.
2. Separation. Didn’t write big classes, usually separated state from behaviors in the core model, defined a pseudo scripting interface (short of a scripting language integration) atop my game engine. Did write a small engine versus just a game, and so forth…
3. Integrated workflow. I arranged that I could update my assets in one click. No muddling through with cumbersome export procedures. The same goes with poor code and documentation. Poor code might be OK for a while. Poor undocumented code is worth nothing. Good, undocumented code doesn’t generate integrated workflow – not knowing how the code works doesn’t flow much faster than no code, or code that doesn’t run to spec.
4. Optimization. I did follow the time honored (ignored?) command: do not optimize your code… …unless you have to. So I always wrote first the simplest code that did a job, and faithfully relied on a profiler to help me frame-rate on a powerful, yet mobile platform.

Where is Attitude?

In a well funded team project (as in, bucks per hour), earning money needn’t be the primary motivator, but in the long run, there is no clear ‘finish line’ for your staff. They will work on and on, and get happy to get stories done done – work well done completed every one two three weeks.

In a solo project such as this one, or a small, non funded team project, getting the product done is the primary goal for the team, or the ghost out the machine. Psychologically, having half of the product done done half-way through feels much tougher (at least to me) than having the product about half-done half-way through.

So I what felt like was, OK, if I just sit and polish every detail one by one, I’ll be overwhelmed by the task at some point, whereas by attacking frontally every sizable, unavoidable task, I’d get to a point where it would be such a horrible shame not to finish that I’ll definitely manage.

Poor code, OK design

Do you remember your first game engine? Nothing to be proud of except getting a job done, right? Same here. Dead code, flawed code, even deep flaws in the design here and there, but it sort of works, and I would argue that’s enough.

This is what refactoring is for, and to some extent this is the (maybe illusory) benefit of strong ownership and solo programming. It’s much easier to get the product done and defer refactoring if you’re soloing. After all, if you don’t get any benefits from the product, you might just as well give up the code. I felt it was OK. On the other hand, really badly design code with large classes, no separation of responsibilities and no usable game development API, that didn’t seem tractable. Not only it could be impossible to refactor, it would have made finishing the product draft prohibitively hard.

I look forward to refactoring this stuff. In particular, I look forward to doing it while fixing the bugs. If a bug is impossible to fix with my current code, then there’s a case for redesign.

Docs are up

There’s been a point where I felt this stuff was so messy I’d never get out of it. Then I managed to delete a lot of dead code, crossing fingers every time that the code was really dead since I didn’t fancy getting it back from the attic, not even the recycle bin. That I mostly threw away whole classes rather than code fragments brings the point home regarding separation.

Then there was a point when I started designing the game, and I felt like throwing half of the working code away, because the code didn’t seem to support the design. So I did the unholy thing that you can only do if you control both the technical and artistic design – Instead of throwing my stuff away, I documented it, putting on top what seemed to actually work, and tried to redesign my game around the highest confidence bits of functionality. Finally this helped improving stuff that could be used in a design empathic to the engine, and throw stuff that was neither necessary, nor stable.

Looking at my docs, I’m reminded of a harsh, fun comment about docs masking poor code. But actually, even docs over poor code can be better than good. If code is bad enough that it can only be used in one or two well documented ways, that’s still functionality I can flow with, never mind indexing essential behaviors that should be maintained and improved, versus stuff that needs to be forgotten and deleted.

Spaghettis, Meatballs and a Haircut

In the next days, I’ll try to tend this blog more often. Because I’m gonna fix this mess, and hope to find design insights worth sharing along the way.

Until then, let’s write dirty code. Or if you can’t, get help from above.

Yea I know… screenshots… another time.