Studio Stories: How To Get Work Done

This will either be boring, or fascinating. You deci...yaaaawn.

In my effort to sound authoritative and feel like there's actual some use to this blog for interesting game developers, I'm going to talk about the general work schedule we had in Paragon Studios. This is something most studios have, even outside of the game industry, although it something that was completely new for me when I first started. These are schedules that are important not only for producers (the guys who set them up), but also for workers to know in order to pace themselves. So, without further ado, here are some of the basics for the work schedules in a game studio! ... Why does that not sound very exciting?

Milestones

In the grand overview of things, we have milestones. Every studio is different, but every studio should have milestones. Think of these as semesters in school, only much shorter. These can be as little as a few weeks and as long as a month or two. This is the time in which you'll be getting your work done. The studio will set up a goal that a zone or such needs to be done by milestone 5 or 6, and you're on milestone 3.

It's the responsibility of both a producer and of a designer/artist/programmer to have a base understanding of how long it'll take them to do something. For example, when we were setting up the new content for Issue 24, I was confident that I could get 7 story arcs, a zone event, develop more LUA scripts, create several entities, create 30 new maps, and around 10-15 mini-maps, in 3 milestones. I had set up in my mind how long it would take me to do roughly each of those, then added buffer time for QA testing. This is the most important part to remember.

Let's say you've got a month of work for a milestone. You almost never want to schedule yourself so that it's going to be a photo finish when you're done working. Because you're never done working when you finish your last mission. You still have plenty of work to do based off of feedback from other designers and QA. Those people will definitely find bugs, even if you've combed over it a million times. No one's perfect, so don't worry, but you need to leave yourself iteration and bug-fixing time at two crucial points in milestones. This is a nice tie in to the "quality" section of milestones.

You're ten miles away from polish, don't take a wrong turn at screwed.

Rough-In, Playable, Polished

Milestones will have different goals for where content should be. You have rough-in, playable, and polished. The precise definition of what these are varies from studio to studio, but here are the broad strokes for each.

Rough-In means that you have the base framework set up for your mission. This is where things can radically change in your arcs and big additions/swaps can be made. Arcs get removed, added, etc. Your stuff doesn't necessarily need to work in this state. You just need to have the base foundation built to see what you're going to be working on next. For City of Heroes, this meant that the main encounters, maps, and characters in missions were created and put in without any grievous errors popping up. No errors appearing meant that the system was theoretically OK'ing your work, but it didn't mean it worked.

For Issue 24, this meant having the main "what's going to happen" parts of the missions done. Things like ambient spawns, music, exact details for cutscenes, etc. didn't have to be finalized. Think of it as making a blue print for building a house and laying down the initial foundation. The rest of the building of that house, the little details etc., aren't done, but you know the road you have in front of you and what you have to do.

You still have to figure out where to put the torture chamber.

Playable means that you have to take everything you did in rough-in and make it playable by a human being. There should be no SHOW-STOPPING bugs, which is another term for progressing blockers, although show-stopper is a more terrifying description. This means QA should be able to play your mission from start to finish without a problem. The level of testing here can vary. This was a stage where we had a first pass of text in, cutscenes were hooked up and working, maps were in, objectives were all set up, etc. Playable is the stage where you build the foundations and walls for the house. People should be able to walk inside and have the electricity working.

The playable milestone is where some aspects of your missions can change. No new work should be added, just building upon existing work, but it can be allowed as long as you're confident with your schedule. Producers will not be too gung-ho about it though, and you should consider yourself as walking on glass if you're adding new things to do during the playable stage.

Now, a mission can be playable, but that doesn't mean it's ready to ship. How many missions have you guys played in an MMO where it's missing things like waypoints, ambient spawns, or other things that make you go, "this needed something extra"? That's where we get into the POLISH stage.

Not that kind of Polish.

Polish is where all the fun things happen. This is where you decorate the house and actually make it look nice for people to live in. Cutscenes get better camera angles and music, environments get touched up to look pretty/textured, small side bars are added to dialog trees, waypoints are added to make missions smoother, etc. This is a stage where nothing new should be added unless you're a cowboy. There's a lot of temptation in polish to try to add completely new things because, hey, wouldn't it be cool if there was another mini-arc of 2 missions to do on the side here? The answer is yes, it would be cool, but you'd be starting from scratch, and you run a huge risk of neglecting your current work to get it done.

Polish can be the best stage and the worst stage; you need to exert control over how much you're polishing and how much you're adding. This is where QA goes through things with a fine tooth comb to squash any and all bugs. You shouldn't be changing anything to how your missions are completed; it would be like decorating a house by tearing down part of the support structure.

In Issue 24, this meant adding extra say dialog to the allies you had in your missions, sprucing up the environments in maps with extra props and NPC's, putting depth of field and music into cutscenes, adding extra side dialog options into dialog trees, etc.

By the end of polish, you should be just about done with your work. You need to leave yourself some extra time when planning the next milestone for the occasional bug fix here and there, but if you've done everything right, it shouldn't be anything major; most likely a grammar issue here, a small balance tweak there. If you've done something incredibly "hackey" and not full proof, then your 3 milestone deadline just turned into 3 1/2 4 milestones, and you'll find yourself behind on the next project.

That's all for today. Either you're asleep by now, or busy taking down notes. Next time, we'll go over the proper usage of keyboards and how the right mouse can make the difference between not crunching at all.

That's not true, don't worry.