The Buddy System

posted by Chris on 2 Mar 2012

We’ve been experimenting a lot with our creative process. For a few months after we released Alight, Joel and I both worked on separate projects in some sort of creative version of communism. From each according to their ability, to each according to their need, right? Joel would do graphics for both projects, I’d write code for both, but we’d work separately on the design and story of each one. It was an interesting experiment but not a successful one. We divided our talents more than we combined them and neither of us was that in love with the other’s idea, so instead of working hard on one project, we half-heartedly worked on two.

Now we’re working on a single concept, but we’re still tweaking our workflow. Although Joel and I live only about 25 minutes apart from each other, in the past we mainly worked together via IM. It was one of the laziest possible ways to collaborate, and though it worked fine for our previous projects, it seemed silly to use long-distance collaborative methods when we had a simple, powerful one easily available: just hang out.

We’ve had a standing weekly game-making date night since the new year, and I can say that it’s been an unqualified success for me. I’m having more fun working on this game, it’s inspired me to work harder in general, and I’ve got more structure when I code on my own. On random weekday nights, instead of throwing random features in based on what I think is needed or (more realistically) what’s interesting to code, I’m thinking about what I can work on that will make our in-person sessions productive. When we’re together, it feels like we’re playing creative leapfrog. I’ll add a feature, Joel fleshes it out with graphics and sounds. Joel builds out a level and needs a locked door, so I add that in. Synergy has become a buzzword but it’s the best word I can think for it.

(Joel, I am also finding out, mixes a mean gin and tonic.)

I’ve also been thinking a lot about how to structure our code. Lua imposes a lot less structure on your code than the Java-inspired ActionScript ever did. At first this is scary, as it’s easy to shoot yourself in the foot. My constant, annoying refrain when we’ve been working together has been you forgot a comma. But once you realize it’s not so bad — at least, no worse than JavaScript — there are some interesting possibilities.

I’ve been thinking about ways I can make Joel more productive as a designer, e.g. how to make it easier for an idea in his head to become an actual thing he can test out. I think the most succinct way to explain how I’ve been doing it is, I’ve been separating configuration from mechanism.

To give you an example, we have bullets in our game. (Quelle surprise, right?) Joel as a designer isn’t particularly concerned with how a bullet aimed at a particular position onscreen decides how to set its velocity components. He is, however, very interested in the sprite each type of bullet uses, and how much damage it does to something it strikes. I’ve split up the definition of our Bullet class into two files. One is the traditional class definition with methods that handle aiming, playing the appropriate sound when it hits a wall, and so on. The second is full of statements like:

Weapons.basicBlaster.bullet = { width = 16, height = 16, damage = 10, speed = 800 }

It’s code, but only just barely. It’s closer to shudder XML in that it describes data only. So what? you may ask. This could easily be done with constants inside the class definition. But there are two advantages here:

We’ve never separated mechanism and configuration this much previously; each time we needed to load some data from text file, I had to write a custom importer. It’s not difficult, but it is relatively time-consuming, especially because the easiest format to parse is CSV, but CSVs are brittle. Imagine that you decide a CSV list of enemies should have its lines formatted in this order:

  1. X position
  2. Y position
  3. Enemy type

It’s fine until you realize you need to add a z-index so that bird enemies appear above snails. Either you append the new bit of data at the end of the line, which gets awkward as you keep amending the format, or you rewrite the importer to do the right thing. Either way, you’re spending time working on things that are not actively making your game better.

I realize this approach is adding complexity. It’s dangerous to spread the definition of a class out among several files, since you don’t want to play hide-and-seek in your code. But I think putting require 'settings.weapons' at the bottom of a source file is clear enough. The closest analogue I can think for this separation is the classic .c/.h division the C language makes.

It remains to be seen how effective this will turn out to be. We only started doing this last week, but it feels intuitively to me that we are going in the right direction. Ironically, the more independent we can make ourselves, the more productive I think we’ll be.