SRG Update #14

The Animation Problem

The BAWD rewrite has two underlying systems that combine to produce animations.

The first is the actual data updates, which are scheduled and queued. For simple line clears and gravity, the scheduling is unnecessary, but it enables some pretty neat visuals for abilities.

The second is a rendering layer that watches for those data updates and takes care of all the fiddly details that make the visuals progress sensibly for players.

For far too many hours, I was struggling to get player abilities to animate consistently. Once in awhile, a certain set of actions would render in a bizarre fashion. Because of the way the two systems interacted, it was quite difficult to step through in a debugger, so I ended up building a lot of small tools to expose the progression of the data in different ways.

Eventually, something pointed to the data update system as a potential source of trouble. I was surprised, because that code felt simple, and I had written something very similar for the previous iteration of BAWD.

After a week or so of trying to manually identify what was wrong in the data updates, I resigned myself to writing unit tests to simply validate every state progressed as expected. That meant a lot of additional work, because I hadn’t written the prototype code to be as testable as some would prefer. Oops! More on that below.

The unit tests were successful, and after a brief debug session I was able to correct the issue. A few more tests later and I was able to nail down what had been messing with the animation, and voila, I was free.


Prototypes and Unit Tests

Software development is an endless journey. Every issue is a new lesson, and this one I think was valuable.

I’m generally a big believer in unit/automated testing, but not a zealot. Sometimes unit tests are overkill and don’t provide a good ROI. That said, there are some pieces of code that benefit heavily from a test harness, and the BAWD data updates fit the description.

When prototyping, I think the “this needs unit tests” hurdle is much higher. My 25/100/300h system in particular demands that I minimize unnecessary work.

What I’ve learned will hopefully help me navigate these conflicting values.

My four take-aways:

  1. Writing testable code, within reason, should generally be a priority, even for a prototype. Even if I don’t write the unit tests, being able to quickly introduce them will allow me to make the right choice. This contrasts sharply with my reluctance to add them to BAWD, even when it became obvious they were needed.
  2. When a piece of code starts to require that I find inventive ways to debug it, that’s a vote in favor of adding unit tests.
  3. Certain kinds of code (data manipulation, especially) are often both easy and valuable to test. This is also a vote in favor of adding unit tests, even in a prototype.
  4. Unit tests are a great tool for countering poor focus (from sleep deprivation, stress, burnout, etc.).

I’m sure I’ll continue to refine my sense of when to add tests to prototypes and when not to, but this experience has prompted me to adjust the 25/100/300h plan: Now, as soon as a project passes the 100h hurdle (which could occur before 100h, but either way requires that it’s had a “successful” playtest), that project shifts to a quasi-TDD mode.

I won’t strictly require (yet) that the prototype be rewritten from the ground up, so it won’t be Proper TDD. But all functionality added after that milestone will be TDD, and existing code will have tests added to it as appropriate.

The point of this decision is that after passing the 100h hurdle, I make a commitment to finish and ship the game. If I am to produce low-defect games quickly, such testing seems crucial. It’s even more crucial when working on a portfolio of games simultaneously.

Anyways, here’s to lifelong learning.


Posted in BAWD, Developer Blog Posts, Games, News, SRG Updates

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.

Posted in BAWD, Developer Blog Posts, Games, News, SRG Updates