I hope that if you are here reading dev journals then you are curious about the game development process.  There are a lot of ways to manage a game, so I don't mean this to be the bible of game development.  Only a talk about my thoughts.

High Level Design

The first step to creating a new game or an expansion is to write a high level design.  My design for the expansion was about 30 pages (I tend to have problems summarizing).  The important part isn't that every detail is laid out in the high level design, but that all the systems that will be touched are included.  I don't need every spell, but I need the way the spell system works and the structure if it is being changed.

Good design work takes time.  It isn't something that's done in a weekend.  It's like writing a book.  You write it all out, then you go back and write it again, and again, and again.  Every detail is scrubbed.  Is this really needed?  Is there a way this can be more fun?  Is this going to require too much effort to implement?  And most importantly for an expansion, how will this integrate with the base game?

Stakeholders Meeting

Once the High Level Design is complete we have a meeting with the stakeholders and go through the concept, focus and design of the game.  They can see what needs to be done to create it, get an estimate for how much time and money is required and talk about systems they want to add or remove.  For the expansion it was the Executive Producer (Brad), the associate producer, the Art Director, and the former producer.  The executive producer is the most critical member of the meeting as he has to pay for it.

In most gaming companies this would be a meeting with a publisher.  There would be contracts around the deliverables, milestones and budget.  The best thing about working for a self-publishing independently owned company is that there is only one guy that needs to approve the design, and he's Elementals biggest fan.  (did I mention that my job is awesome)

The trick to a successful meeting is to make sure everyone has been introduced to the topics before it starts.  That way I know what everyone thinks about each part, where I can expect to get push back and that everyone is generally onboard before we start.  I also have the opportunity to adjust the design to their good ideas and any issues they find, rather than being surprised with them in the meeting.  I don't like surprises.

For this expansion the meeting went well.  The hardest part is balancing features and the schedule.  There are a million things we can do and there is no lack of good ideas.  But choosing the right few is the hard part.  By the end of the meeting everyone knows what the expansion is going to be and has a fairly good idea on the schedule and budget.  We have all agreed to the design, there won't be any major changes.

Detailed Design

The next step is to take that high level design and turn it into something that programmers and artists can pull tasks out of.  Every spell needs to be detailed, exactly what it does and how it works.  Every place we need a new model, a new animation, a new texture or a new painting need to be specified.

Implementation can start as the detailed design is being written as long as the high level design was very through and it truly is locked.  If your high level design is just a concept doc then there is going to be a lot of time and confusion when people try to implement on ideas that aren't ready.  But assuming a through high level design programmers and artists can get started on the framework for the systems while designers spec out the unfinished parts.

Its almost impossible to have too much detail at this stage.  The more ambiguity, the more you rely on the programmers to be creative.  Stardock has amazingly talented programmers who know the game and are accustomed to designing as they work.  But their focus and creativity should be on implementing clean systems, on making the code as efficient and bug free as possible.  Not on trying to figure out what I meant in some obscure sentence about tactical combat.  Ambiguity also causes them to misinterpet and not implement the system I've imagined which will come back as bugs later on.

The detailed design is not a one man job.  Those that are interested are invited to sit down and talk about various systems.  Some team members have a lot of passion and ideas around city sieges, or spell ideas or quests and they should be invited to brainstorming sessions to pitch and share ideas.  Review meetings are also scheduled to go over the design and get lots of input throughout (especially if you are like me and the newest member of the team).  Everyone on the games team is a member of the design team.

The Schedule

In conjunction with the detailed design the schedule can be built.  This is an estimate of all the tasks that are needed to create the game assigned out to each team member.  Once the schedule is complete a team member should know what they are expected to do throughout the project.  Vacations are entered on the schedule, tasks are lined up so that if one system requires another the required system is completed first.

The schedule is what breaks game developers.  There is never enough time.  So much we would love to do, but the weeks slip by so quickly.

The nice thing about a good schedule is it allows you to see how you are performing.  Are you a week ahead or behind?  Would adding another artist make life easier for everyone?  What sort of artist do you need most?  Can you afford to have a team member spend a week working on another project?

Implementation

I enjoy design, but this is my favorite part.  This is when I get to see those things we talked about coming to life.  Every day bring some new tweak or detail to play with.  Given a balanced schedule this is the reason we decide to make games.  Those people that think that programming is programming, that making a game is really no different than making a business application have never created a spell that damages all enemies and causes those killed by it to rise as demons under your control.  It's cool stuff.

Iteration

The first test build allows you to try the game out and see if it's working.  2/3 of development should be spent implementing, and 1/3 for iteration.  The reason so much time is allocated for iteration is that some ideas just aren't going to work and have to be changed.  2 additional weeks of implementation may allow you to add more stuff, but 2 more weeks of iteration improves the quality of your game.  Given the choice, pick iteration.

It's also important to remember that iteration doesn't mean much if all the systems aren't implemented yet.  It's too easy to blame pacing or game problems on systems that aren't implemented.  To be of any real use a beta must be full featured.

Gaming companies have differing opinions on Alpha/Beta builds.  Some release beta builds to a private community months before and play test for a while before issuing a public beta, which is then more about balance.  Stardock releases quickly.  This is good and bad.

Some players may comment that our first priority should be stability, that is tough to do.  Anytime you make significant changes you introduce bugs.  Let me give one example, multi-threaded AI.  There is a reason most games don't use multithreading.  It's difficult to code, it's difficult to support and it introduces issues.  With multithreading the computer is doing more than one thing at a time independently.  So while you are attacking a city the AI may be going through and planning its production.  If the AI builds a list of cities to check and goes through city 1, 2, 3, 4... and if between the time it built the list of cities and got to city 4 you destroyed city 4 the game will crash.  The AI tries to query city 4, there is no city 4, boom.

The good point of AI threading is that it dramatically speeds up the game.  Human players spend a lot of time planning their turn, lots of time that the AI could be doing their actions.  But in a single threaded world the AI waits and that 30 seconds that would have happened while you were moving has to happen while you wait.  It also allows us to make the AI smarter.  In a single threaded world you wouldn't want to add an AI function that causes the AI to spend an extra 5 seconds a turn.  But with multithreading the players don't even notice the difference.  If a player spends 90 seconds on his turn, that's 90 seconds that is open to the AI.

Understanding that we want multithreaded AI, but we know that it will introduce issues we could either keep it internal for a few weeks and allow the QA guys to beat on it.  Or after verifying some base stability (it should be playable, but not perfect) we can release it and allow the community to help us find issues, report on balance issue and offer feedback.  Of course we do this with the huge disclaimer that it is a beta.  But we do it because the community asks for it, it's a community option (in that you have the choice to play betas or not) and frankly its very helpful to us.  We know it can be frustrating.  In fact I didn't play the Elemental beta at all because I was so looking forward to it that I didn't want to dirty my impression of it by playing flawed versions.

Lockdown

At some point before release, at the very least a week, all changes stop.  Only bug fixes are allowed and those are usually by approval only.  Code checkins may have to go through the most experienced programmers and even good ideas are rejected.  Now is the time when stability becomes king and every precaution is taken to make sure that some late game defect isn't introduced that causes issues.

Lockdown is an act of willpower.  It's tough because there is always things that need to be done.  There are always late ideas that would make something better.  And a lot of anticipation about the upcoming release that makes people want to make everything perfect, just like a bride fiddling with her dress before the wedding or some other more masculine analogy.  But the time for fiddling is past.

The biggest misconception about game development is that the game has been relatively consistent throughout.  Many people imagine that the set and we add things to it throughout development.  Like a cake with frosting (or some other more manually analogy).  So they are surprised when things don't work.  That the developers should have had the entire process to work those things out.  But the only real time to see the game in its final form is the lockdown time.

I see it right now with patches.  The game changes every day, sometimes the game changes every few minutes.  Players may update to a new patch and wonder why after playing for an hour they run across an issue that the developer didn't catch.  Hasn't the developer had that patch for weeks/months.  Why didn't they see it?  Mostly that's because that issue got in just before lockdown (assuming patches have lockdown at all).

Release

The bugs have been slain, the schedule bested, though at times weak and weary we have overcome and produced a game.  XP is handed out and we head to the pub where the bards sing of our victory's.  Or the bard's give us a bad metacritic score, those crazy bards.

But release is only a new beginning, especially at Stardock.  There is support left to do, there is a ton of community feedback and ideas that are accepted and adopted.  The beta process gives a lot of that but release is the real opportunity to see where we stand.

I don't know if the time we spend posting and talking with the community is the best use of our time (as compared to making the game).  But its undeniable that it effects the game.  And although it takes a lot of time the game is better for it in the end.  It is in a very real sense a community effort and it exists at every level at Stardock.  From Brad asking if I read one post or another, to the team members talking directly to community members or asking about community feedback in our meetings.