Home › Games › BAWD › SRG Update #13

SRG Update #13

This update is a bit of a mid-mortem/behind-the-scenes mashup. I enjoy reading other devs’ meta-development experiences, so here I’ll share my own.

Playtests of BAWD and several other small games last year were largely unsuccessful, from my perspective. In response, I’ve changed my process/policies in two ways:

 

BAWD rewrite:

I know rewriting software is generally a bad idea, but there are some scenarios where it’s appropriate.

In the case of BAWD I decided it was justified for two main reasons:

  1. I’ve improved dramatically as a game dev since starting BAWD, and
  2. The scope of BAWD has changed a lot in the meantime

The main playtest feedback for BAWD has been that gameplay feels unintuitive. I identified a handful of changes I thought would help, then fleshed out the changes a bit before estimating them. One, I figured would take around 50 hours to address, since the architecture around that feature was quite stubborn.

Out of curiosity, I then estimated how long it would take to build BAWD clean, from the ground up, with the new feature in place. I came up with around 100 hours. 50 hours to fix, or 100 to rewrite? A siren song as old as time.

The second part is just that I know what the game is, now. It’s changed a lot over the years, and those changes created scar tissue. This meant that implementing the content updates would take many more hours than it should.

So I went for it.

With January ending, I’m around 70% through my estimate.  I started with the two hardest parts of the game, and though I think I’m a bit behind schedule, it’s not dramatic. It is dramatic how much cleaner the code is without all the prognosticative abstractions.

I’m hoping to have it to an alpha/testable state within the next week, beta by end of February, and ship by end of March. That schedule seems very doable, assuming (very big IF) the changes successfully address the intuitiveness feedback.

 

The “25/100/300” Idea

The core problem with BAWD has been, from the beginning, that I wasn’t testing it correctly.

In the time since I started on BAWD, I’ve worked to refine how I approach game development. I’m sure there are many lessons waiting to ambush me down the road, but this approach has been fairly stable for awhile now. That approach is summarized simply: “process and portfolio”.

What this means, in short, is that:

  1. Process: Every SRG project follows a simple, well-defined funnel-style path, trusting the process to produce good work, and
  2. Portfolio: SRG projects will focus on producing a wide range of lightweight titles, investing more in titles that have stronger feedback

I’ll write more about both parts later, but the important part now is a prototyping process I refer to as “25/100/300”:

  1. Every project must be playtested by someone who hasn’t worked on it at least once for every 25 hour chunk of work. Until then, it gets shelved.
  2. If a project hasn’t had a “successful” playtest by the 100h mark, it gets shelved.
  3. If a project hasn’t shipped by the 300h mark, it gets shelved.

There is some flexibility built into this, of course.

First, a “successful” playtest is essentially one where I believe the tester genuinely enjoys the concept. This is of course hugely subjective and arbitrary, but it will prevent the kind of playtest procrastination that – even now – plagues BAWD.

Second, there is a “grace period” at the end of each segment: 25h gates allow up to 5h extra work, but it comes out of the next 25h. This 5 hour grace period is purely for polishing to get it testable. There aren’t special grace periods for the 100h/300h gates.

Third, I maintain a count of “stretch credits”: each credit is worth 5 hours of time, spent on any project I want. I get 1 token for each project that passes a gate.

This third mechanism allows some leeway for projects that turn out more difficult than expected, where crucial feedback arrives late in the process, or sometimes just for personal passion projects.

The goal of this process is two-fold:

  1. to systematically minimize time and effort sunk into projects that won’t pan out, and
  2. to orient my prototyping process towards finding out if a project will pan out ASAP

I.e., by seeking good feedback from the beginning, I am forced to identify the core “spark” to the idea. Then, I’m pushed to find a way to bring it out as quickly as I can. Through this, the spark will have as long as possible to be defined, refined, and polished.

Ideas are cheap; I don’t need to be precious about ones that aren’t as fun as I hoped.

Time will tell how this pans out, but at least that time won’t be spent on one giant boondoggle of a project.