Tell me if this sounds familiar: you have corralled a group of talented people together, and everyone is incredibly enthused about your game. Brainstorming is incredibly productive. You jam out a rock solid concept and get to work immediately. Two weeks later, everyone has either flaked out, quit or dropped off the face of the earth. Maybe you, too, have been wrapped up in other projects or with your actual job or school. Your game has gone from 0 to 60 to 0 in an astounding amount of time. These two week sprints work out pretty well for contests. Just as teams are reaching the point of collapse, the game is finished anyway. But if you’re planning an epic RPG, this is disastrous.

This isn’t the only thing that happens to game teams, of course. Some survive for quite some time. But ultimately the only games that have ever been considered “completed” by Verge community members have been largely one-man shows with the occasional contribution. At the time of this writing, I’m not aware of any fully completed games that have been developed by a team. Why is this?

Nobody plans, that’s why.

Well, ok, that’s oversimplifying. There are several scenarios in which teams explode, implode, or dissolve into a whimpering pile. People get so wrapped up in the excitement of their great new ideas that they just jump immediately into implementation. Artists start drawing, coders start coding, musicians start cranking out tunes. When your game is small in scope, this works out great. You can easily piece everything together. Everyone is still jazzed from the initial excitement and can easily crank out enough adrenaline-powered resources in a weekend to cover the entirety of the project. When the scope is larger, however, a lack of sufficient planning leads to wasted time, discarded work and frustrated developers.

Let me tell you about when I found this out myself!

So, I was working with three other people on a game called Duskbane. It began life as a very short compo title, encompassing a short story about some paranormal investigators researching the aftermath of a death-by-werewolf in a quasi-steampunk city. The story arc supported maybe thirty minutes of game, and it was largely just driven by narrative. An adventure game. We didn’t manage to finish in time for the compo deadline (we squeezed out a pretty crappy facsimile of what we had originally intended. Note to contest people: do not hold short contests on 4th of July weekend) but we liked the premise so much that we thought it would be downright moronic not to make a full game out of it.

From the very start of that process, we were doomed. We just didn’t have the foresight to recognize it at the time. The first thing we had to do was to take our 30 minute narrative and stretch it out into a full game. We did this quickly, because we were having so much fun making creepy buildings with lightning that flashed through the windows and streets that had volumetric ground fog that we wanted to proceed as quickly as we could. So I whipped up some grade-A tripe wherein the city is presented as being in a sort of speculative past, but this city was in fact in our future, but the citizens had collective amnesia and the city fell into disrepair because of a spell cast by the main antagonist who was named Enoch who was also in charge of the werewolves and he was trying to reclaim a talisman that had the power to—ok well you get the idea. It was pretty bad. And it didn’t actually illuminate the gameplay very much. We had a rock solid beginning, and then… well, and then some stuff was supposed to happen. And we were kind of making it up as we went.

The players take control of the player character in a tenement building full of panicky floppers. The player could go into all of the rooms and talk to the people who lived in them, and they would relate unnerving stories about hearing screaming from upstairs and otherworldly howls and the sound of a large dog stalking the halls minutes before the incident. One room has a little girl and her mother and a conspicuously boarded up door. The little girl informs you that daddy opened the door once and got arrested. A notice on the door informs you that entry is expressly forbidden by the City Guard. Walking past the door has a percentage chance to play the sound of something moaning quietly behind it. Taking the hallway staircase up to the third floor reveals a room with a door ripped off the hinges, scratch marks and blood trails and paw prints. Entering the room, the player finds a man dead in his bed, and another man dead in the bathroom, apparently trying to get out to a fire escape through a window. The room is torn apart. Crap is strewn everywhere. When the player shines their flashlight around the room, they find something glinting in the debris: a talisman. With writing on it. But you can’t really make it out by flashlight, so you are prompted to go read it by the window for a less glary light. As your back is to the room, there is a jump moment where you’re attacked from behind and things get suddenly loud and the screen flashes and there’s a scream and a howl and a fade to black.

And that part was totally effing sweet. We wrote it well. The map was well designed. The music was spot on. The effects were great, the characters were great, the sound of your boots clomping in the hall and the rain hitting the roof and the occasional thunder clap outside all came together fantastically. The problem was that we were in such a rush to create this part that when we finished it, this awesome awesome demo, we hadn’t really figured out where we were going with it from there. But we were pressured to not waste any time by the fact that there were four of us. When you’ve got an artist as talented as ours, you use him. Our programmer could bust out features that worked quite well in a very short amount of time. I had to keep him busy. I didn’t want to waste anyone’s time. I didn’t want any bottlenecks to stop anyone from being able to continue working.

As you may have guessed by now, in our rush to keep each other busy, we basically designed ourselves into a bunch of dumb corners. We were constantly retconning things into the already flimsy story to explain features that we were adding. We were coming up with sections of gameplay that required substantial features to be added. And because we were sort of coming up with these things as we went, our codebase and art were generally not designed to accommodate the changes we were trying to make, causing us to be continuously hacking our own code to extend it beyond its original very specific intent.

We added a part where you went through an abandoned sewer and subway and it was full of zombies that you could fight. Their arms and heads could fly off, they could get a hole blown through their torso, and their behavior actually changed depending on what state they were in. If their head was gone, they no longer walked toward you but rather walked around randomly. If their arms AND head were gone, they could no longer even hurt you if they got within range of you. It was pretty cool. But fighting them wasn’t very fun after the novelty wore off, nor was there any tension in particular. But we had put a lot of work into it, so it was in. The maps were being finished faster I was writing, and our artist did not like having to go back and revisit things that had a lot of polish already put into them. When the story called for the player to fight something that wasn’t a zombie, my co-programmer would blanch at the idea of generalizing the highly-specific zombie combat code to support other enemy types. We required a version of the large city map that was completely devoid of wandering townsfolk and had a large mess of werewolf victims in a specific part of it. Again, going back and adding this scene to an area that had not originally had these things considered in its initial construction was more frustrating than rewarding.

Ultimately what happened was I had to tell people to stop working. I was having the opposite of the flake-out problem. I was being inundated with damn near finalized art resources and code features, and in the meantime I was still struggling to make a compelling story out of this thing that wasn’t an arbitrary series of a-to-b fetch quests. And every time I would write something that wasn’t consistent with one of these art resources or that required a code feature to be added or changed, people were getting irritated. So I needed them to stop so I could figure out what the hell I actually needed them to do. This fell apart. It was frustrating now, instead of fun. I had really talented people creating really impressive things, and I was telling them that it wasn’t working. We gradually gave up. The takeaway from this whole thing, dear reader, is that we did not plan a single damn thing from the moment we started. I would go as far as to say that this was an extreme case of not planning. This was ad-lib game design, and it was messy.

The Brainstorm, Implement method of development that the Verge community is prone to is not sustainable. Brainstorming is good. Implementation is obviously good. But there needs to be a part in between: a process of formalization and real design work. Before any implementation occurs, there absolutely has to be a coherent plan. If your design document is sparse enough that you need to hope someone is on IRC so you can ask them a question, your group is not ready to begin implementation. An ideal situation: you have scripts, you have mockups, you should have the game play details worked out to such a degree that a completely unrelated team could pick up your design document and make pretty much the same game. This is not a painless process, by any means, but it is necessary if there is any hope of completion.

Valve designs their games based on a method they call Cabal. These Cabals are comprised of a cross-sectional representation of the team (engineers, writers, artists, etc. People who are actually creating the game) and their task is to generate a document that describes, in reasonable detail, the entire game. A given Cabal session might be a high-level concept for a part of the game: set pieces, monster encounters that sound cool, etc. In successive meetings they begin forming sketches of geometry, chronologies. How it fits in with surrounding areas. Eventually, there’s enough there to actually implement and play-test the designs and iterate on them based on what’s empirically working and not working. Everyone should check out this paper by Ken Birdwell as a preface for the rest of this.

Working collaboratively online has its own set of challenges that Valve didn’t have to face with Half-Life: your team members are probably volunteering, and they probably have full time obligations that have nothing to do with creating your game. You don’t have a conference room with a whiteboard. Your schedules likely don’t sync up. And you almost assuredly will not have the luxury of multiple six-hour design jam-sessions per week. So how can the design methodologies of the Cabal system be applied to a sparsely located team with heavy communication limitations?

Find a collaborative space
There are myriad tools out there that exist for the sole purpose of managing a collaborative document space. The only requirement is that you and your team can all edit rich documents. You can create a wiki, you can create a Google site, you can sign up for Basecamp, you can use a hosted Word document or OneNote notebook. Your tool doesn’t matter, as long as it works for everyone, and everyone uses it religiously.

Make time to jam
You won’t have hours per week to have sessions, but you should still have sessions. Everyone doesn’t have to be there, either, but most of you should be there, and anyone who isn’t should certainly make an effort to be able to get to the next one. Find a part of your document that is either flimsy or completely absent, and pump up the detail. Start with your premise. Construct a complete but sparse story arc (if relevant, of course) and work from there. Remember that you don’t have to agonize or reach to fill in things that you don’t have a good idea for yet. Come back to it later. Figure out roughly how you want it to play, how you want it to look, how you want it to sound. Your game will come together like a slowly loading JPEG: a blurry mess that gradually comes into focus.

If you have ideas outside of a session, or have kind of a mini-session with a small number of other team members, keep those ideas around as well. Take some time to develop and think about them and pitch them at the next full meeting.

Prototype
According to Birdwell, Valve waited two months before implementing anything. This is too long for an online collaboration simply because people tend to drift away when tangible things aren’t happening. I propose that every feature under consideration for inclusion in the game be mocked up or prototyped. This allows not only for the positive reinforcement of tangible progress, but it is also very illustrative to the team as to whether a given design is too vague, or if considerations were overlooked, or if something just isn’t going to work. These draft creations require no polish and no TLC of any kind, as long as they are accurate to the designed specification. For example, don’t put a lot of time into creating a robust and well-animated battle system to test your mechanics. Hard code a lot. Write it like you’re expecting to throw it out, because you most likely will throw it out. Draw in MS Paint. As long as it fully represents the specification, it has served its purpose. You can come back and make the nice version once you have specced out everything that is necessary for its full implementation.

Get feedback
So now you have a design that has reached a level of completion that has allowed you to actually create a somewhat polished slice of your game! You can’t get the Cabal in a room and watch people play, but it is important to get hands and eyeballs on your game before you continue implementing the current state of the design for the reasons expressed in Birdwell’s paper: things that seem obvious to you, the creators, may be obtuse and baffling to regular humans who are trying to infiltrate your thought process, and after spending so much time being close to a project like this, it becomes difficult to gauge for yourself whether it’s actually fun. How do you get this feedback in an online environment? Well, I must confess that I haven’t thought this one all the way through yet. One thing I do know is that putting out a demo and then hoping for feedback from the comments is probably not the way to go. The reports you get are going to be too vague or otherwise difficult to extract useful data from. I propose a team member sitting a tester down at his or her computer and recording their session with Fraps or some other capturing software, then adhering to the Cabal’s method: no helping, then let the team analyze the session and generate action items. If anyone tries this and has success with it, please let me know.

Realize that nothing is finalized
This may sound like an extension of prototype, but this comes into play when you have a completed design and are in the process of making the game proper: be mentally prepared for the fact that ideas you love are not going to work, things you draw will need to be tweaked, and code you write will need to be changed. Even with a lot of pre-planning, these will all be true at some point during the development of your game. The important thing is that no work is wasted: your resource was created to an agreed upon specification, and if that specification changed, it was done so by consensus and in response to something learned about the initial design. Structure your work so that it can be iterated on with minimal impact. For example, if you’re an artist, leave the flourishes of detail off of a sprite until the team is confident that the design for that sprite is correct.

Stay organized
Keep your documentation tidy. Keep everything under version control. The specifics of how you do this are not of any great importance, as far as I can see, but establish your group’s methodology early and stick with it. And make sure everyone is doing it.

I’m considering this a living document and I request feedback. These guidelines are theoretical and based on my observations. If someone tries this and it turns out I am full of crap, let me know in detail where and why this model breaks down. If you try it and have great success, I would also appreciate feedback on the specifics of how and why.

Then I saw this and that all changed. I cannot wait to get my hands on this. I first saw this trailer a while ago, but just now read Scooter’s new preview over at 1up and now I am furiously into it.

The parts that make me require it:

In the Serenity universe, Whedon said, “The empire isn’t evil — it just thinks it’s right and can’t understand why people wouldn’t want to live by its rules.” O’Brien says that at a particular point in the commentary, Whedon noted that “you can’t make other people live by your rules of society, even if your society is better” — and that turn of phrase actually serves as the main catalyst for the concept and feel of the city in [Mirror's Edge].

…

That’s one of the central issues of the game: How much freedom are you willing to give up for a comfortable life? So there are people on the outer edge of the city who have an inherent distrust of technology, which is where the concept of Runners.

Oh yeah. This is my jam.

I keep putting off Stick Ninja work. I’m at an annoying place with it where I have to sort of hack together some different things that other people wrote and get them working together before I can move on to actual content, which is pretty much my least favorite programming task of all time. It’s the grunt-work before I’m allowed to be creative. I don’t like it. I’ll force myself. Soon. Or someone else can force me! That works too.

Here’s a countdown page, and a 1up news story confirming. Apparently there’s scans floating aruond out there somewhere, but I have yet to see them. Someone hook me up.