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 2)
on Jan 21, 2011

UI placed in Art category. Now i understand the root of the problem. Move UI under design lead.

on Jan 21, 2011

Wishing you guys success when you relaunch with the expansion!

Hope we see MANY great reviews!

on Jan 21, 2011

UI placed in Art category. Now i understand the root of the problem. Move UI under design lead.

Or better yet, get a dedicated interface designer.

on Jan 21, 2011

The hat analogy made me think of only one thing.


But contrary to what Team Fortress 2 has thought us, too many hats can be a bad thing.

on Jan 21, 2011

too many hats can be a bad thing.

Yeah, they make your head really hot.

on Jan 21, 2011

People is missing the point. What matter is: Were they Pirate Hats?

Good to know more about the innards of game development at The Dock of the Star.

on Jan 21, 2011

The hat analogy made me think of only one thing.


But contrary to what Team Fortress 2 has thought us, too many hats can be a bad thing.


Those hats ended up runing a great game turning it into a crappy MMO.  (sorry, very salty off-topic rant)



on Jan 21, 2011



Though UI under the art category and not design is really a bit weird. IMO a UI has to be functional first and it can influence a lot of gameplay by making certain tasks very hard or easy, depending how you can interact with it.

on Jan 21, 2011

Transparency and candor is a wonderful attribute to express.  I appreciate the open window into how Sd organizes the the gaming portion of their enterprise.


My hat is off to you, sir.

on Jan 21, 2011

Thats all fine and dandy. But, it doesn`t change a thing.

You're right that it doesn't change the past, but it is interesting to get an inside glimpse into why things can go so horribly wrong for a development studio.  It's also instructive from the standpoint that those who don't learn from their mistakes will repeat them, and we can see that Stardock has learned from their mistakes and will not be repeating them.

on Jan 21, 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

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

on Jan 21, 2011


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


Freebird out.  

Every day for hours on end.  


I think that was part of the point behind this post - He helped build so many bits and pieces that it was hard for him to see whether or not the game was ready for release. And I understand his perspective. When I was younger I used to write - A lot. I thought it was great, no one else really did. Now that I've distanced myself I re-read some of it and think "Wow, I suck." But when you're attached you don't get that perspective.

Now that he's in his proper role, and after a few months, he can go back to seeing what the game really was to the rest of us. And he's learned to avoid taking on too much when he's the one making the decisions.


Thanks Tydorius!  Glad to see at least one other grown-up in the crowd.

on Jan 21, 2011

I love these little inside views going on here. No other game company, or company I can think of, let the consumer know whats going on behind the scenes! Its really interesting to see how something goes from an idea to a product and the trials and success along the way! Thank you frogboy and thank you, entire stardock team!

on Jan 21, 2011

Ive only thrown out a couple of rants about this title because of the joy that was Galciv.

I play in my spare time, and being a manager/owner myself want to tell you how lucky you are to be doing what your doing.  I cant tell our customers how things work (or maybe I should start) because it would only take up time from their day.

You have a great following that would purchase your product from the first set of 01010101's.

That was an insightful thought you just put out.  Thanks.


on Jan 21, 2011

Thats a really good idea.  You should have a conference call will all your players.  Now that would be an interesting recording and marketing idea.  You could use the same recording for a lifetime of developmental ideas for games like this.

One at a time please.


edit: thought I replied to an earlier post.  now i stand alone.