You hear about executive producers sending “notes” down to the director or producer of a movie.  That’s what I’m doing these days. “Maybe we should have robots in this scene instead of a dragon?” I’m leaving the dream.

I assume a lot of people read these journals because they like seeing what happens at a game company that they would normally not get to find out about because most game companies these days are publicly held and thus there’s a strict PR leash on everyone. So today I’m going to outline to you what a medium sized game production looks like in terms or organization.

I’m also going to try to show those of you who are aspiring game developers some of the things to look out for that can lead to disaster.

A Stardock Game Org Chart

First, let’s look at the general Stardock game project org-chart.

Stardock Entertainment Model

It looks huge but many of these spots are occupied by 1 person. In fact, some people wear multiple hats in here.  For instance, our art lead also does all the UI. Kael is the Project Manager and also the Design Lead.

The object is to find the right balance between maximizing your “resources” usage (people) and the overall output. That is, sometimes, it’s fine for someone to wear more than one hat – it’s often preferable. The challenge is to find out when they are wearing too many.

Sometimes, you end up having little choice but to stretch people thin. That’s where “crunch” time comes in. It’s when you’re asking people to do far more than they really should be expected to do. Crunch time occurs because someone – usually management – screwed up.

Now, if you look at the titles listed in the chart above, you’ll notice that they don’t sound that gamey.  For marketing, we try to translate our software engineering titles into something that remotely conforms with industry norms such as:

Product Manager = Executive Producer & Lead Designer

Project Manager = Producer & Designer

And so on.

Other Org Charts

Other companies do it differently. At Gas Powered Games, the Lead Designer is on a separate track from the Project Manager. This has some advantages in that the designer doesn’t have to be a software engineer or project manager. With larger teams, you really do need someone with a background in project management to run the show.  Gas Powered Games teams tend to have 30 or more people on it. Hence, finding someone who is both a game designer and someone capable of managing that many resources would be very difficult.

Stardock teams tend to be much smaller. Historically, our game teams are 10 or so people. Elemental: War of Magic  got to be about double that and that’s one of the reasons it got into trouble.

For the first 2.5 years of Elemental’s development the org chart looked like this:

I wore two hats. Product Manager and AI. 

My job was oversee the overall product and provide AI.  Unfortunately, during a good chunk of this, I got diverted to help out another project that was struggling for several months. This turned out to have been a fatal decision – I didn’t assign someone else to take over for me while I was gone.

When I finally got back into the thick of things, it was clear that I needed to add more hats since we couldn’t readily bring in people easily (one of the downsides of being in Michigan, I can’t just go up the local Digipen and get people).

By the time War of Magic shipped, it looked like this:

With the benefit of hindsight and common sense, that’s too many hats (the orange spots). 

Each new hat has its own unique story behind it (Marketing Manager left the company, The printing deadline got changed by a month and I type faster than anyone else, our Producer’s wife was having a baby and could no longer put in the time necessary, the lead developer was having health problems, the tile creation (part of concept) was far behind, etc.). But in the end, I had assigned myself across the whole project. If you’re a new game developer, you may think you can do everyone else’s job. Maybe you can. But you shouldn’t. If you’re the one who gets to decide the game is “ready for release” you shouldn’t be too involved in the parts that determine whether it actually is ready for release. You can get way too close. This is a very very common problem in small software studios. One we knew about but after a shelf of Editor’s Choice Awards, you start to think the rules of software engineering no longer apply.

This is why, if you’re an aspiring game developer, that you should never forget, even for a second, that making a game is an exercise in software engineering  -- and has to be treated as such.  None of the above hat acquisitions occurred overnight. Only gradually, does one realize that people were taking over more and more spots.  Our Art Lead, for example, had taken over all UI and was involved in a lot of the design (XML) implementation. Our Engine lead and I were doing debugging scenarios, etc.  I cannot overstate just how talented our staff here is.  It’s the thing that comes up all the time when people visit us – you did THIS with this few people? It gets dangerously tempting to forget that such a team has any limits at all.

I’m friends with “Chantz”, the guy Atari sent in to try to rescue Master of Orion 3 and we have talked a lot over the years about this kind of thing. Beware of the combination of the phrase “I can do it” and also being the guy who gets to evaluate whether they can actually do it. The guy who says “I can do it” and the guy who gets to determine whether they really can do it should never be the same guy.  Because sometimes, you really can’t do it no matter how sure you are that you can. Fatigue, overconfidence, external factors can all weigh in to create a fractured evaluation of a given project.

If it’s a team of a half dozen guys, you can wear a lot of hats. But as the scope of the project gets bigger, you have to be careful because those hats start to get really really big.

Process Matters

This is why delaying a project is pointless if the process is broken. If the process is broken, the result will be broken. Time isn’t the issue in such a case.  This was one of the principle reorg challenges we went through this Fall. Hiring very talented people to fill in some of these key roles.  The biggest piece of advice I can give to game start-ups is this, make sure you separate the business decision makers from the development decision makers. 

I hope you guys find this interesting and useful.