Category: PM

1 Big red flag that your project won’t succeed.

Shadowrun Returns has announced that they are pushing back the release date to expand the scope of the game…  The delay is not the issue. The expanding scope, however, is a big red flag.  Expanding scope is the bane of all projects and the death of first projects.

I still have high hopes for seeing Shadowrun goodness.  These guys are professionals.  However if you are on your first project, don’t let the scope creep.  Read more about their development process on their blog.

Kinda regret not getting a Doc Wagon card.

Game design document? How about ‘game bible’?

When you’re working with 4 coders,  an artist, a couple musicians, a writer, and a project manager how do you keep everyone on the same page about what the game is and what the game is not?  The Creative Lead or the Project Manager must be the arbiter of the contents of the game.  They must have a method for making sure that everyone on the project has a way of understanding that vision.  What is ‘canon’ and what is ‘not canon’, to borrow the terminology use by Star Wars (one of the most curated intellectual properties in existence).

Whatgamesare.com had a post recently about Game Design Documents.  Tadhg was commenting on a problem that all project managers have whether they are in game design or not.  It a bit like ‘scope creep’.  As a project moves forward stakeholders start to ask for new features.  Changes and additions start to creep in and your scope and project can veer wildly off course without careful curation.  A good Project Management Professor will warn about scope creep.  It sounds like in the Game Industry the GDD suffers from the same problem.

A game design document should not contain information about the overall project.  The game design document should be subordinate to the project document.  The project document should consider aspects of the project outside of the game itself.  There shall be no marketing information in a good GDD.

Game Design documents are not bad, and you should work with one.  Especially when you are new to this  field you can learn a lot from a good GDD template.  They are immensely useful for filling in the gaps of what you have and have not yet thought about.  They force you to consider aspects of the game which haven’t immediately jumped to mind.

The ZoRTS Project uses a great game design document.  It was made a number of years ago by Chris Tayor.  The document is linked to by wikipedia and hosted by Runaway Studios.  You can download a copy here.  If you are experience or running a game design company it may be a good idea to create your own format.  But if your an amateur use someone else’s document as a place to start.

If you have any doubts or internal conflict about what a game design document should be take a look at the Battlestar Galatica Series Bible.  The game design document should define the setting of the game, and how the game is played.  The UI and the HUD.  Get the flavor of the game into the document.  Record your ideas about the game and what it should be.  Make the GDD a repository for your games canon.  Make it a bible that explains the universe you want to play in!

Basic Project Management is important.

Although failure is always an option, and something we should learn from, what are some things that we can do to reduce failure?  Two tips tied together into one: Deadlines and Feedback.

Not everyone has taken on Project Management as a studied discipline which is unfortunate as some of the tactics a project manager will use can be really handy when making a computer game.  Any good business college will have you take at least one class in PM, and you might walk out of it with a PMBOK (Project Managers Body of Knowledge).  As an Amateur Computer Game Designer you most likely will not need every piece of information in the PMBOK, but you can still benefit from a couple points that project managers are fond of.  They also happen to be popular advice among Indie game developers.

During his talk at PAX Scott MacMillan stated that Deadlines are very important.  It was something that he learned the hard way.  You can see his slides from that presentation, but you cannot see what he discusses during those slides.  It’s something that I have also been learning about on the ZoRTS Project.  Let me synthesize what has been learned first hand, what Scott was trying to say in his presentation, and a couple things picked up from Boston University.

Deadlines should be small tasks which can be completed regularly.  There is an art to setting deadlines (with deliverables) in that they should not be made too big, nor too small.  For example, here is a little list of things that could be deadlines for a computer game project.

  • Game engine (due 1 year from today)
  • Art (due 1 year from today)
  • Sound (due 1 year from today)
  • Text (due 1 year from today)

These are some of the major components when building a computer game.  You have to produce the engine that runs the game.  Someone has to produce the visual and the auditory art and someone has to write text (could be in the game, could be website material).  What is wrong with this list of deadlines?  They have no specificity to them, and no deliverables.  Which means it will be harder to determine if progress is being made within the project (no feedback).

Instead lets try goals which are tied directly to a deliverable and have much shorter durations.  The actual times, deliverables and goals are going to be based on your project, theses are just used as an example, they are not specific suggestions.

  • Game Engine Prototype, with 1 unit, 1 building, 1 vehicle (due in 1 month).
  • Art for each of those basic entities (due in 1 month)
  • Intro music (due in 1 month), sound effects for each basic unit (due in 2 months).
  • Completion of the Game Design Doc (due in 1 month)
  • Basic website text (due in 2 months)
Chances are that upon reading the first list team members get a sense of dread and unease as it feels like an impossibly large task with a very long time frame is looming over them.  The second list, however, feels much less intimating for those who are trying to complete the tasks.  There is an added bonus here.  The next step is much clearer based on the second list.  What do we do when the first prototype is done?  Revise!  Add more units.  Debug.  Repeat.  
There should be someone on the project who can see the big picture and break it down into reasonable tasks for the rest of the team to complete.  In an Amateur setting this might be the whole team discussing the project together during a planning session.  Or it could be one person, a creative lead/project manager.  They should be applying the second list to drive the project.  If they were so inclined (or a business major) they might create a Gantt Chart or a timeline.

Failure is always an option.

The Zorts Project is most likely going to fail.  TapDave asked me a direct question about the future of the project, and point blank the answer was “I am planning on the project failing”.   The reason behind that is the project may come to a point where we stop working on it.  That does not mean that we have failed.  Quit the opposite actually.  Learning something is never a true failure.

What are we learning from the ZoRTS Project?

There is, of course, another school of thought that only when you embrace that something could fail are you actually prepared from something great to happen.  Failure could even be the very thing that drives the economy!  What are your stories of success through failure?  Share in the comments!