T w e n t y S i d e d

Some other indie developers were nice enough to play the game and send us their feedback. A common theme in the feedback was that things were too chaotic. Or too random. Or unfocused. Or too busy.

Looking at the game, it’s easy to see why, and it’s easy to see how we slipped into this state. We made a system that let you make wildly divergent robots, simply by tweaking a text file. Since creating robots is easy and variety is good, then more robot types = more good, right? Aren’t games always bragging about how many enemy types they have? Isn’t this a selling point? “Fight over 12 different enemy types!” it says on the back of the box.

Only 12, AAA game? Pshaw. We have that many in the first 15 minutes of the game!

It made sense at the time, but when the feedback rolled in it was a forehead-slapping moment for all of us. Of course this will seem like random chaos to someone who hasn’t played the game constantly for 6 months.

It’s like a version of Half-Life 2 where your first fight is against a group of foes with the behaviors of an antlion, a zombie, two soldiers, a metrocop, a strider, and a gunship. It’s not about being “too hard”, really. Even if you lower the hitpoints and damage output on the gunship and the strider to bring them into line with (say) a metrocop, the player still can’t be expected to parse all this chaos. They’re not going to appreciate the differences between the soldier and the zombie when both foes die in the same panicked volley of weapons fire.

Continue reading ⟩⟩ “Good Robot #39: Teaching Players to Good Robot”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.

When you’ve got more than one person working on a complex bit of software, you generally need a specification (spec) for new features. The bigger the team, the more you need a spec. The more complex a feature, the more you need a spec.

According to stereotypes, big firms usually lean too hard on specs, to the point where they might spend more time writing the specs than coding the feature:

“The button will be ten pixels from the left margin and will conform to the usability guidelines sheet 201-a. It will be labeled “Join Game” and will – after a confirmation popup as outlined in the interface framework – begin polling the designated server in request for an open slot. If no slot is found, then the fallback behavior […]”

Meanwhile, little indie houses have a slightly less formal approach:

Bruce: Can you add a button that will let players join the game?

Barbara: Sure.

Stuff gets done either way, but sometimes indies are a little slapdash and sometimes big firms are a little too bureaucratic. On Good Robot, our spec is usually a sentence or two in the shared Google doc that we use as a universal to-do list.

But this week I ran into something that I realized was too complicated for that. It was one of those features that sounded obvious and simple in the meeting, but then became mysterious when I sat down to write the damn thing. (This is the point of a spec: To reveal the unknowns BEFORE coding begins. This is important in big firms, since once you’ve begun coding you’ve ALREADY been allotted a fixed time budget, which means this is a bad time to begin figuring out what you need to do.)

So I proposed a spec. And then I thought I’d post it here, just to show what the non-exciting bits of game development look like. This is pretty informal as these things go, but it should give you an idea of what needs to be hammered out before you start coding.

Also note that I’ve replaced the names of the stuff in our game with DOOM references to make it easier to follow.

Continue reading ⟩⟩ “Good Robot #38: Spec’ing a Feature”

Shamus Young is a programmer, an author, and nearly a composer. He works on this site full time. If you'd like to support him, you can do so via Patreon or PayPal.