How Warcraft Went Flacid

*Rise from your grave…*

I’ve been rather busy of late, evidence the lack of posts. The rub: we (Flashbang) are kicking the ass out of Potion Motion, our next title. If you have any interest in such things, there’s an extensive thread on the excellent AIPX Student Game Developer’s Association forum where we’ve been posting test builds and getting fantastic feedback.

On principle, I’m opposed to the concept of crunch, but there are a few exceptions I will make. One is when you’ve got the design by the tail; due designer diligence is to ride it out, to see where the design wants to take you. To be honest, we were sidetracked for quite some time, obsessing over aesthetic polish. We hadn’t user-tested design assumptions in many iterations. Bad designers. Anyhow, lesson learned. E3 was a bit wake-up call and now we finally have it by the tail, due in no small part to the many gracious participant testers we managed to round up. Many thanks to you all and a tip of the hat to Sir Joel who has taken on the role of surrogate lead tester.

It was said many times at GDC this year, and I’ve seen it in action many times before – prototypes solve everything. Make the thing, put it in front of some users and watch design arguments disappear. This is why “Advanced Prototyping” was such a hit this year, and why I believe those skilled in rapid prototyping are poised to lead the game industry into a new world. Making good games is all about iteration and iteration is a function of speed. The math is simple: the faster you can complete a single test –> observe –> change –> test cycle, the more times you’ll be able to iterate over the course of the project. The more times you iterate, the better the game gets. Unlike a painting, it’s not really possible to ‘overwork’ a game, especially a huge, sprawling videogame. The closest thing I’ve ever played to an ‘overworked’ game, I’d say, is Warcraft 3.

Despite many attempts, Warcraft 3 has never managed to hold my interest. Even when I was using it as an assignment in my class I was never able to engage with it. On the surface level, I never fell in love with the treatment, but that’s never stopped me from liking a game with a good design at its core. Warcraft 3 turns me off because the design is overpolished. It’s been played so many times in testing, the numbers balanced and rebalanced so many times, the gameplay’s gone limp. Every possible outcome and type of player has been accounted for, every strategy weighed and balanced against every other. It feels sterile, like playing a game in a vacuum. To most if not all players, this is, like every other Blizzard game, a huge win. They find enjoyment on many levels. For myself, as a designer, as someone who has at least a modicum of understanding about the nuts and bolts of creating a game, there’s just nothing left for me. There’s no interesting asymmetry, no novel mechanics, nothing for my mind to tinker with. It’s just too well balanced. Blizzard games stand as monuments of achievement in design, polish, and playbalancing, but they’ve lost their soul along the way. Give me something dirty and flawed, created by an auteur mind toiling away in some basement. Give me a tool to express myself. Give me something alive.

So, yes, there is a spectrum, and I think it is possible to overpolish a design. So few games are in danger of arriving at that point, though, that it’s pretty much safe for all designers to ignore the possibility and try to power through just one more iteration. Test, observe, change, test. Quick, before the money runs out and the game is lost forever.

Process & Production: a Case Study (In Progress)

Here at Flashbang Studios, we have something called Experimental Mondays. Every Monday, you spend the day making something cool. The informal stipulations are that what you make should be topical (art or tool-related if you’re an artist, a prototype or piece of interesting tech if you’re a designer and so forth) and complete. At the end of the work day on Monday, we show what we’ve created to the assembled studio. The idea is both to continue to develop relevant skills and to compensate in some measure for the soul crushing realities of game production. Very cool.

In the past, I’ve made some cool stuff on Experimental Mondays. And, of course, some not so cool stuff.

Lately, though, I find myself using Monday as a ‘soft’ day, a day I devote to activities that I haven’t found enough time for during the rest of the week. This is lame, and it is in direct violation of purpose of Experimental Mondays. I end up doing the tedious, crappy, and otherwise unmotivating tasks I felt guilty about not having completed the week before. To that I say: shuttlecock!

As an experiment in game production, I’m undertaking a full scale project, to be completed as a series of Mondays.
I’m calling it “Tune”. The idea is basically that it’s a game about making games. It stems from my experiences with the Jumper exercise, and subsequent fiddly tests, as well as my desire to try out some of the things I learned about rapid prototyping from Chaim Gingold and Chris Hecker’s Advanced Prototyping session at GDC. And at a bunch of other Spore-related GDC sessions, I suppose. Eric Todd had some interesting things to say about his experience as a producer on Spore, though it mostly amounted to ‘rapid prototyping is awesome, here are a few hints about how to do it right.’

So, yeah, ready-fire-aim! I wrote up a detailed project plan, which I haven’t ever done before. I’m determined to try out a more detailed approach to the entire process of creating a game. I need more data on what works and what doesn’t. I’ve tried not doing a bunch of preproduction, time to try the opposite. If it ends up taking too long, I can calibrate between the two extremes.

The process, as written up, goes like this:

1. Brainstorm - Collect up all the current, crazy scrawlings I have related to the idea and examine them as a whole. Spend some time researching other, similar game ideas, asking the question ‘what’s out there already I can borrow inpiration from?’ Cast my inspiration net out there and look for things that fit with, compliment, or extend my vision for the game. Music, movies, art, whatever: it’s time to watch some Miyazake, some Kurosawa, listen to “Grace” and Faith No More’s cover of “Easy Like Sunday Morning.” Then some traditional brainstorming, stuff from Von Oech or De Bono, divided into questions about mechanic, level, system, and UI design. The objective here is some churning idea fertilizer from which to create a cohesive vision, as fleshed out as I can make it.

2. Create a Vision – Something that gets mentioned over and again in business, personal development, and game production is the power of focus. A clear vision is the key to doing something brilliant. In my limited experience, the best possible way to define focus is by framing the problem through questions. For example, the Harmonix guys let the question “does it rock?” drive the entire design of Guitar Hero. Arguably, Keita Takahashi had a similar question about rolling a ball around picking things up that led to Katamari. So – and I haven’t really done this externally before – I’m going to define my design for Tune as a overriding question, a series of smaller questions, and answer them with prototypes. This was one of Chaim’s main points at the Advanced Prototyping session: “Behind every successful prototype stands a good question, a clearly articulated problem to solve.” So, what are my questions? In addition, based on my own observations, I want to see if it’s useful to create a map of player experience (as in, the experiences the player is supposed to have playing the game.) I also want to see if there’s value in creating visual mockups for UI, control flow diagrams, and an abstract of the overall game structure with an eye for Flow. At that point, I’ll have a pretty clear vision and some cool data about these various approaches.

3. ‘Rubber, Meet Road’ - The other thing that made an impression on me at the Advanced Prototyping session was the concept of creating a map of questions to drive game design. Questions to which the prototypes provide answers. So, I’m going to create a map of interesting questions to answer with small prototypes. This is just good sense. What are the series of outcomes that must be completed for the game to be done? How am I going to go about getting those things done? What are the prototypes I’ll need, how am I going to attack and order them, and how will they all fit together in the end? What are the potential pitfalls technologically, design-wise, art-wise, and how will I stay motivated? One way is posting to my blog here every Monday with progress updates (prototypes.) The point here is to try to wind my vision string around a thumb of reality, to make some sense of it in real, here’s a list of things now do it terms.

4. Schedule it – Scheduling it makes it real. The trick here is to take the mindset of data collection; all I’m trying to do is provide impetus. If I miss a deadline, it was probably too aggressive. At least I’ll have some data. And, of course, I’ll put those milestones up here for all to see to encourage myself not to miss them.

So that’s pretty much it. I’m putting my other projects on hold for the time being to see if I can’t upgrade my process and methodology. Empirically speaking, my current method has gotten me some interesting, aimless little prototypes. Time for some new data!