In Search of Bigfoot (The eight elusive phases of game development)

I believe that there’s an idyllic roadmap for all game development.   It can apply to all manner of projects. All small, large, mobile, console, PC, etc. game projects can be fit into this utopian archetype.  I call it the “Bigfoot Model of Phased Development”.  It’s a perfect model.

It’s also mythical.  In reality I’ve never experienced this impossible software development model. It’s like Bigfoot.  There is some circumstantial evidence but no one has actual proof that it exists.  Beyond that, I’ve never met anyone who has either.  Worse, some people think they’ve actually seen it and present it as fact.  Making games is a messy business.  It’s full of failure, course corrections, poor practices, rotten conditions, buggy tools, crunch hours and a myriad of other pitfalls. 

I only wish it worked my way in the real world.  Theory is great but it’s often less than accurate when it comes to day to day, actual game making.   Many producers don’t understand the phases of product development.  They often don’t have a mental model of how to get from point A to point B, from concept to completion to servicing.  For brand new producers it’s completely foreign.  In this article I’ll share my own idyllic Bigfoot Model.  I hope to get lots of feedback since my own skewed vision of the phases is undoubtedly different from what other teams have experienced.

PHASED DEVELOPMENT

Traditional project management advocates phased development for many endeavors.  As defined by the PMBOK® they are:

                Initiating

                Planning

                Executing

                Monitoring & Controlling

                Closing

These phases might be fine for projects like “widget building” but software development can’t work under these strict guidelines.  There are far too many unknown challenges and most aren’t discovered until well into the project.  Video games are a creative endeavor and creative endeavors are notoriously hard to schedule and plan.   

Think of phases like large time boxes with concrete gates the project must pass through before moving to the next.  Alpha, Beta and Gold are the easy ones to point out.  Usually to move onto the next phase the project sponsors or customers must sign off.  In other words, they must approve the continued investment in a title.  They are generally planned around a thematic goal that all the work within the phase is working to achieve.  As an analogy, let’s say you want to go to a concert.  You could break it down like this:

Get the tickets
Drive to the show
Pass through the gates

Each one of those points is a big ticket item that, if not achieved, stops the entire show-going experience.  Along the way you could a) find they are sold out of tickets, b) run out of gas or c) be too late for the showing.  Inside each one are smaller goals called milestones.  For “get the tickets” you’ll need to get enough money and purchase the tickets.  Each of those could be considered milestones.  Within each of them there are any number of activities that teams will do to achieve them. 

Incidentally, one of the best qualities of a producer or project manager is the ability to observe large, confusing goals and apply the ability to break down each into achievable work activities (Work Breakdown Structure).  While this ability is great, it’s just the first step.  Software is complex and misguided and many believe they can do it all by themselves.   We work with experts in their craft.  Use them.  Get their guidance.  The project will be much, much better for it.

THE BIGFOOT MODEL OF PHASED DEVELOPMENT (BMPD)

The BMPD is my attempt to mix traditional project phased development with Agile development.   My issue with any methodology is that they are often too prescribed and rigid (Scrum, I’m looking at you).  While agile methods are a response to the strict nature of traditional methods, they can also go too far sometimes.  If you read my previous articles you’ll know that I do not like the way agile allows and encourages fundamental change deep in a project lifecycle when it’s also the most expensive to make alterations, especially large ones.  For these reasons I’ve decided to create my own model and, so far, it seems to hold fairly well.   This model is built on the following principles:

Traditional and Agile methodologies, in their truest definitions, are sometimes not applicable to the business of game development.
Time boxed goals are beneficial to the creative and business aspects of game creation.
Engaged stakeholders are essential to the betterment of a project.
The BMPD phases will never appear as textbook in real life game making.

The Bigfoot Model is broken down into eight phases, each with hard, reviewable gates to proceed to the following phase.  These phases are:

Initiation:  Establishing constraints.  Start the project.

Conception: Exploring the ideas.

Prototyping: Proving the ideas.

Preproduction: Preparing the vetted ideas for execution and demonstrating examples of expected quality.

On-Boarding: Preparing the full production team for execution.

Execution: Making the ideas.

Closing: Finishing the ideas.

Servicing: Monitoring, controlling and fulfilling the customer wants.

I’ve heard of variants on this model but for me it’s the most reasonable for mentally mapping the path of a project. 

The phases are clear but require some explanation:

Initiation Phase:  This is the start of game development.  Usually it begins well before the team even knows they’ll be working on a title.  Fundamentally, the organization has recognized a business need or opportunity.  Maybe a person began a start-up.  Perhaps the president of a large company requires revenue in quarter X. Maybe someone organized a Kickstarter campaign.  In all cases someone, somewhere saw an opportunity or need and began down the long road of game development.  It starts with a basic decision: To “start”.  The sponsor may begin gathering a team, creating a business plan, gathering resources, identifying the roles, specifying the scope of work, describing the sort of project that will meet the organization needs, etc.    Basically, the sponsor provides some fundamental constraints and conditions that the project must meet, not to mention the approval of funding.  It consists of any activity that best prepares a team to begin production. By following some very specific steps a sponsor can make a real difference in the project preparation.   A project manager might create a project charter, identify the team requirements, engage stakeholders, etc.  This steps sounds formal and it’s designed to be so.  That said, I’ve never worked on a project that actually started in such a prescribed, planned way.

Conception Phase: The conception phase is the act of narrowing down the ideas based on the specified goals set down by the sponsor.  Theoretically, the team can do nearly anything it wants so long as the organization’s portfolio and strategic needs are met.  Often the goals are very stringent.  For instance, the startup might require the project to be completed within ten months.  Perhaps the large company requires that the project be a sequel to an existing title.  Both examples should place significant constraints on the team.  They might work within those constraints however they like but they are still bounded by immovable borders. 

When exploring concepts there may be a lot of writing, art exploration, code design, etc.  No concept is ever promised to become reality.  It’s up to the Product Owner, Game Director, Producer, etc. to evaluate all the concepts so that they all congeal into ideas that play well together.  Often times on smaller games this might come down to the business owner to make the call.  More importantly the concepts must support the strategic goal of the organization.

Prototyping Phase:  A prototype can be described as any demonstrable way to prove out a concept. Hacking in this phase is not only accepted, but encouraged.  Fail fast and often is the mantra for the prototype phase.   Prototypes must be tangible and usually created with a small but strategically staffed team. The more unknown the idea is, the more tangibly it should be demonstrated.  In the case of a very unknown concept it generally requires actual working code that can be experimented with tactilely.  The team needs to touch and play with the idea. When an idea is fairly known, for instance when it’s already been implemented by another game, then comparative reference is fine.   The collection of all prototypes should begin to eliminate the questions surrounding the game development.  The Shangri-La of game development is when ALL the risks and questions are discovered and answered in the prototyping phase.  Of course, as you already know, this never happens.  In the best case scenario the most highly impactful features and risks are demonstrated or dealt with.  The whole point of this phase is to recognize and answer open questions.

Pre-Production Phase:  In my view this phase is the most misunderstood across our industry.  Many teams simply use this as a “catch all” for any pre-execution activity.  To me this is a bit naïve and doesn’t take into account the actual activities in this phase.  I believe this is simply the table setter for the execution phase.  It’s the collection of work that is designed to coalesce all the prototypes into a representation of the finished work.  Since prototypes are often disjointed there may be little understanding by the team as how they all fit together.   This phase attempts to pull it all into a neat package.  Some teams call them “vertical slices”, some call them “beautiful corners”, etc.  This phase is the first time a team will attempt to show their definition of what “done” looks like in a demonstrable way.  It may come together as a demo that shows the core game loop, systems and art in a way that represents an inkling of finished quality.  As we are all aware, this first attempt is just that.  Along the way new discoveries will be made, new systems will come on-line and new content will be added.

On-Boarding Phase:  Up until this point it’s likely that the entire team is not working on the title.  It’s probably grown as new staff comes on to help prove out concepts but the big team hasn’t started yet.  This phase is a shorter one than the others and is designed to capture the imagination, prepare the skills and engage the new team into the creative and production vision of the title.  While it’s generally a smaller portion of the development cycle it’s still very important.  Bringing on a team the right way will prepare them for the road ahead.   Unfortunately, it’s often forgotten or even recognized as a phase by many teams, small or large.

The phase is supported by documentation, initial execution schedules, art, production plans, etc.  I recommend making this phase a formal event over a week or so.  Conduct workshops, solicit ideas on how to create the project and engage the new team members.  Get them to buy into the core concept of the project. 

Execution Phase:  This phase is about creating value for the customer.  Anything created here will likely find its way into the finished game.  This phase is not about exploration or finding new ideas.  It’s about implementation of the agreed upon established ideas.  It’s about monitoring and controlling the content included into the title.  If the team is still exploring fundamental ideas in this phase something definitely broke along the way.    The team is at its highest burn rate in this phase and any changes can prove costly.  In general terms I find that waterfall methods work best when the work is known.  This phase is as close to an assembly line as software development gets. 

Closing Phase:  The content work is done (at least version 1.0) and the bugs are getting closed.  The closing phase usually starts with Pre-Alpha.  It’s the first time the team is attempting to reign in content creation and whittle down the game into a shippable state.  Often it requires teams to “kill their babies”.  This means features that are near and dear to their creative hearts just can’t be fit into the schedule. For the uninitiated…

                Pre Alpha:  First attempt at Alpha.  It will fail but you’ll know what to clean up.

                Alpha:  All content, while not final, is in the game.  Memory footprint is represented.

                Beta: All content is final, just bugs are left.

                Gold: Ship, and pray!

By the way, this never happens.  Some parts of the project will probably be in each of the phases.  Eventually, with luck all projects achieve beta but given some games that I’ve played in recent years this too is questionable.

Servicing Phase:  In the old days, servicing existed but not at the level it does lately. In the mobile space it’s critical to provide players with updates, content additions, bug fixes, etc. to make sure their iPhone or Android device gets the always desired “update available” pop up.   These pop ups are designed to be drivers for players to come back to a game and are particularly important in the free to play space.  Players have come to expect service after buying or downloading a game and this doesn’t come cheaply.  A development team must have integrated code to collect metrics on game use so that they can have guide posts to supply new content or fixes.  While this is assumed in the F2P mobile space it’s slightly foreign to packaged goods providers, but they are coming around.

YOU: “I SAW BIGFOOT!”  ME: “NO, YOU DIDN’T.”

The phases as described above sound very neat and tidy.  On paper they are a fairly reasonable roadmap for game production.  Unfortunately, they don’t exist…at least not in the way I’ve described.

The phases might hold true in academia but you’ll never come across them so cleanly in the real world.  Although traditional project management does account for phase overlap I believe it doesn’t go far enough.  The Bigfoot Model of Phased Development can be viewed as a primer guide for game making but since software creation is fundamentally about discovery phases nearly always overlap.   Teams could still be partially in the concept phase and partially in the pre-production phase.  They could have one foot in the execution phase and one foot in the on-boarding phase.  It doesn’t matter how big or small the team is, though, teams with smaller size and less funding often find themselves spread across many phases at once.  This is true of big, AAA titles with lots of team members, but the spread tends to be more isolated in certain disciplines. 

IN CONCLUSION

The BMPD seems like a reasonable, high level view of game development.  In practice, it’s hard to find and very elusive.  The nature of game development is far too complex to be pinned to one model.  That’s why I’m a student of all methodologies.  The producer must be aware of the wide array of project management tools in order to best apply the right one for the right problem.

Even if this perfection of phased project development is unachievable, it’s still worth striving for…isn’t it?