I've been keeping my head down lately trying to finish my first commercial independent project, Deep Sea Descent. Currently expect it to come out sometime late February or maybe early March. I was going for early February, but pushed back my dates a little.

Today I rode the bus up to the UC Santa Cruz campus for somewhat of a fun diversion - dropping in on a game design class. The specific class I attended on this occasion was "Game Design Studio 2," led by the well-known Michael Mateas. The class doesn't have a heavy lecturing component, but this particular session was on Scrum, and I thought to myself when I saw it in the course listing, "Hey, I've put in about 200 days or so of Scrum standups. I know how it works in a 'real world' environment, maybe I can contribute a little."

But instead of offering up-front to contribute as an outsider I just posed as a student and asked questions in such a way that it forced to the forefront some issues that I knew were important. It was more fun that way. Mateas did just fine and recommended that if any of the problems I presented came up, the students should see him for advice. :)

But to get to the point, the lecture and Q+A let me reflect on a problem I have with Scrum's sprint planning mechanisms - that sprints are supposed to start with a certain direction and stick to it for the duration. The problem I have with this "unchanging direction" philosophy comes, I think, from the subjective elements; if it's purely technical tasks, it works. It's when that isn't the case that problems arise. The idea that you can research some gameplay mechanic or level concept one day, and then it's "done," for example, is one that I found plaguing my design estimates.

It always worked out that one big feature would be planned, e.g. "combat," you designed and prototyped it as much as you could, and much later, it would recieve a final implementation. You would make near-zero progress in everything related to that feature regardless of time allocated, right up until the final implementation hit, and then afterwards you'd have to pick up the pieces and cobble together some gameplay from whatever was there, because it would never turn out to be exactly what you thought it would be. Planning was disrupted at every turn.

So on any given day I often had no idea what was going to happen, and as often as not the entire day would just be spent supporting everyone else as the "idea filter" or getting called on to make detailed design decisions about subtle nuances like "how should the timing of this HUD popup look," but for the purposes of Scrum, I would fabricate a design task and some number of hours - it was not an intentionally deceptive practice, but an honest attempt to convince myself that this time, I had actually found an appropriate match between what I had written on the card and the events of the next eight hours.

Sometimes I knew in advance that I would be supporting others and could plan appropriately, but I couldn't ever plan a whole sprint like that. I'd usually get impeded two days in by a missing feature that I didn't know I needed. Even if the project wasn't totally strapped for resources, I'd be blocked on most design tasks most of the time until "full production" hit and I could really dig into how each level would work, specific enemy designs, specific tuning elements, etc.

And then once into production, it became a challenge to figure out just which things to tackle first, to "guess at the desired gameplay" when things were still unfinished, and how to avoid doing something that would just get crushed by later features. Going for weeks on end with almost no form of feedback, it was extremely difficult to make any kind of progress.

Scrum only really worked out well if I was doing clearly defined technical or asset-creation work: "Level 2 enemy placement"  is fairly reasonable and well-defined, albeit still hard to make a time estimate for, since you could take any number of passes and still have to come back to it later if a core gameplay feature gets rebalanced. "Level 2 concepting" is wide open and hard to nail into any particular process other than "copy what worked for Level 1," which still doesn't help with time estimates.

And yet at the same time, concepting has to be done on some level, or else you're just spamming some random layout down with no consideration at all to game flow or the player. The gameplay-optimal schedule essentially required a feature lockdown to come months in advance of a content lockdown so that all of these things could be worked out meticulously, and that was never possible.

Oh, and sometimes sprints would blow up mere hours in after the publisher demanded something unexpected for the next milestone. Good times. I still don't know how to deal with all of these problems. I stumbled through them and probably would stumble again. If anyone has ideas, I'd love to hear them.

Anyway, all of this thought on the nature of subjective elements in game productions led me back to Mateas, and an interesting thought: He's known for "Façade" alone, and on close reflection, that project really seemed to be driven only by the technicals of "build these really cool systems for procedural narrative, and a test case for them." Classical CS research at work, and it seemed to lead him strongly towards a view of Scrum that kept the aformentioned subjective-task problems out of the picture.

But what if I went back to the Façade concept and reconcieved it like a commercial game? That is, instead of building research-level tech to see it through, I were to depend on brutish, traditional design techniques, as if it had to be slammed out in three months to fit within some tiny shoestring budget? And what if all I did was iterate on that core concept and try to make it appealing, try to focus ONLY on subjective elements and try not to code anything remotely novel or sophisticated?

An interesting exploratory project. I might make it the thing I do next, as time and resources permit.