Brad Wardell's views about technology, politics, religion, world affairs, and all sorts of politically incorrect topics.
Published on January 20, 2011 By Draginol In Elemental Dev Journals

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. Smile

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. Smile

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.

Comments (Page 3)
on Jan 21, 2011

@ BoggieBac, Some of Life's lessons  involve a considerable amount of pain. I learned to avoid smacking myself in the face with concrete the same way!!

Live learn and move on, Thanks for the news also!! Have some Pie

on Jan 22, 2011

  You can pay freelance reviewers to do a write up of a build to get a better view of how someone not used to the game will view of the many practices we'll be using this point forward I'm glad we're to the point where we can take a healthy look back on what happened with's really a facinating case study on the "small team becomes a large team" tipping point. It was bound to happen eventually, but I wish the lessons hadn't been so brutalally learned

Cheers, and good luck!

on Jan 22, 2011

What's a mock review?  You can pay freelance reviewers to do a write up of a build to get a better view of how someone not used to the game will view of the many practices we'll be using this point forward

Ha ha, so now we can honestly say that Stardock pays off reviewers.

on Jan 22, 2011

Thats all fine and dandy. But, it doesn`t change a thing. Brad, did you even play the game before it was release ?


Freebird out.  
One of these days you will post something useful. Keep trying. Its almost there, I can see it coming. One day you might post that your never coming back. OH wait you have...such a liar you are.


on Jan 23, 2011

These org charts don't look all that unusual to me.   Only one thing I don't get:   Libraries?   Under Asset Support??    What kind of libraries are these?  The libraries I think of go under Programming Lead.


on Jan 24, 2011

I believe that would be under the category of asset library which would be a collection of artwork and sound effects/music they can call upon by the game program when they need something to happen above the hood rather than under the hood.

EDIT: also i think the look and feel of an interface and the functionality of the self same interface are completely separate issues ie: the button looks perfect, but when i click on it nothing happens (i'm looking at you search function thingy) or "whose brilliant idea was it to make a purple button with an orange highlight with a yellow happy face on it with a pink mustach? but boy, when i click on it the game opens up like a dream and the game keeps gettin mo' fun"