Repairing Scheduling Errors

“My name is Carolyn, game dev of games: look upon my screwups, ye Readers, and learn more!”

In other words: I recently made an interesting scheduling error, so it seemed like a good time to talk about how to repair scheduling errors.

(There’s some overlap between this post and Scoping for Game Jams, but it’s a different context.)

The context

18 Rooms to Home is an experimental parser IF serial. It starts at the end and moves backward in time with each installment.

Each installment is just one room large, so the first installment is Room 18, the second installment is Room 17 and 18, and so on. As the player moves backward in time, they gain access to more of the story, and they have more control over how the story unfolds.

The mistake

When I conceived of 18 Rooms to Home, my plan was to release one installment each week. Each installment adds one and only one room to the game. I have no doubt that I can write one room in a week.

And my brain went:

1 room = 1 week of work, so 18 rooms = 18 weeks of work.

Right?

…wrong. Very wrong.

18 Rooms to Home isn’t one room a week, no matter how I originally conceived the project. It’s one room a week, plus connections and updates for every prior room. Not only are the installments larger than one room, but the size of each installment will increase as the project continues. Additionally, many of the rooms contain NPCs, which are significantly more complicated than the rooms themselves.

This isn’t scope creep, because scope creep implies the addition of features along the way. This was a failure to comprehend the scope in the first place.

Oops. (And I’m glad I didn’t advertise my weekly update plan.)

Finding a solution

There are three ways to repair a scheduling error:

1. Add resources.
2. Cut the scope.
3. Add time.

Adding resources (adding people or money)

I note #1 here because it’s an important option for commercial projects, and even some noncommercial projects. AAA studios are particularly prone to use this option, moving handfuls of people from one project to another or hiring external resources as various projects require.

However, bringing more people on is rarely a viable solution for solo developers (money? what money?) or interactive fiction authors (because so much of the “code” is actually prose). And it’s not a viable option for 18 Rooms to Home.

Alternately, this can mean things like additional training. For example, bringing a coder up to speed on an unfamiliar technology may cause a huge difference in productivity. But it’s not a solution for this specific problem.

Cutting scope (removing features from the game vision)

Moving on to #2 – I took a hard look at the scope of the original design, to see if I could bring it down to a once-a-week size. But in order to get a sufficiently large scope reduction, I would have to make significant cuts to the cause-and-effect flow through the game. I feel like that’s the most interesting feature of 18 Rooms, and I’m not willing to do that.

I did figure out a way to improve my efficiency through better source code organization. That was gratifying, but it wasn’t enough of a change.

Adding time (exactly what it sounds like)

On to #3. I could approach this in two ways:

1. Increase the amount of time that I spend on this project each week.
2. Push out the deadline.

And again, there are two ways to tackle A:

1.  Work more hours overall.
2. Spend more existing work hours on this project.

The first is also known as crunch time, and it’s the bane of the game development industry. Extended crunch time means that there’s been a significant failure in the production department (or, in this case, my production brain.) It’s harmful to morale and work-life balance, and 15 weeks of crunch on a voluntary, noncommercial project is completely out of the question for me.

Turning to the next option – in a studio situation, this would mean things like cutting out meetings. In my case, it means siphoning time away from other projects. I’ve already been doing this to an extent, but I can’t continue this trend. If I dropped everything else, I could pull back up to a weekly release schedule – but I have a publisher waiting on a different project, and the opportunity cost is too high.

That brings me around to B, pushing out the deadline. Because I didn’t advertise my original schedule (apart from  this post!), I can shift from every week to every other week – or to every three weeks, if that becomes necessary.

But what if the deadline couldn’t be moved?

If I couldn’t move the deadline, then I’d handle it with some combination of decreasing scope and pulling time off other projects. I would have to. (Assuming I couldn’t backburner the project for some reason, which would be a first choice.)

There is never a solution that amounts to “keep the deadline, keep the scope, keep the same resources, and finish on time.” This is why games come in late, expensive, and missing significant features.

That’s also why it’s important to consider the schedule of any game dev project with a deadline. The schedule will be wrong the first time (it always happens, even apart from cases like this) but without a schedule, then it’s almost impossible to tell whether the  project will miss the deadline or not until it’s too late to do something about it.

My solution – for now

I’m pushing my deadline for 18 Rooms – but scheduling is not a one-time process. A game project’s schedule and scope require constant attention to keep everything on track.

Looking forward, I’m going to keep an eye on the cause-and-effect cascade. I have the advantage of short turnarounds, so it should be obvious to me if anything’s going wrong, but if my installments push into three weeks, then I’ll reevaluate the scope.

I don’t have a publisher on 18 Rooms, but I do have an audience, and by playing the first few rooms, they’ve signed up for a 18-installment serial. I need to keep them in mind so they don’t lose patience or interest.

Reminder to self

Games are always bigger on the inside than on the outside.