Blog Archives

From Concept To Community Management: How A Video Game Gets Made

What is the process of making a videogame? Video game development is a team sport, one that takes the combined efforts of people skilled in game design, programming, art, sound engineering, quality assurance testing, project management, marketing, sales, and customer support. Each game is a unique entity with a development story of its own, but here are the typical steps that a game goes through from the spark of an idea to an experience enjoyed by (hopefully) millions of gamers.

Pre-Production: the planning phase

This is the stage where the game begins as a simple idea, which is then developed into a complete plan for making the game.

  • Idea Brainstorming: All games start out as ideas. Some games come from one single idea, but while others are formed by combining many ideas. Ideas can come from brilliant inspiration (“Aha! I have a great idea for a game”) but more often a game’s idea may come from a movie or other license, a technological hook (such as exploiting a special capability of a game engine), filling a gap in a publisher’s product line, duplicating the success of a current popular game, creating a sequel in a franchise.
  • Pitch: To secure financing for a game (or just to get the “go-ahead” from management to start), the team leads will create a verbal and/or visual “sales pitch” for the game. This pitch usually describes the game’s genre, theme, target audience, play value (what makes the game fun to play), competition, unique differentiation (what make the game stand out from the competition). The pitch may also show off some concept art.
  • Concept Document: More information may be requested about the game before it can be approved, so the basic idea may be fleshed out in a several page game document. This document may describe an ideal play session, details on how the core game mechanic may work, or a synopsis of the game story.
  • Documentation: Once the concept is approved, the team leaders will put together a set of documents together as part of the planning of the game. This includes a Game Design Document, created by the Lead Dsigner, which describes in detail how the game will work, including its rules, goals, obstacles, resources, controls, characters, story and so on; a Technical Design Document, created by the Technical Lead, which describes in detail how the game will be made, including hardware, software, pipelines (steps for creating the art, audio and game levels), and methods for solving the technical challenges of the game; an Asset Document, describing the game’s art and audio; and a preliminary schedule and budget.
  • Prototype: An early version of the game demonstrating solutions to the game’s technical and creative challenges.

Production Phase: the development stage

This is the stage where the game is actually built. After the plan for creating the game has been approved, the development team ramps up in size, adding more programmers, artists, and other staff required to make the game.

  • Playtesting: As the game is developed, early versions of the game are made and played by team members, and later on, by play testers, to try out the basic game mechanics, game controls, game systems, preliminary levels and so on to provide feedback to the development team about what needs to be adjusted.
  • First Playable: A version of the game that demonstrates a few minutes of what the final version of the game will be like. This is used to show that the game will indeed be fun to play.
  • Alpha Version: A version of the game in which the main gameplay is implemented, from game start to game finish, but much of the art, audio and text may be placeholder.
  • Feature Lock: The point at which no new features, assets or design changes are made to the game.
  • Beta Version: A version of the game in which all of the art, audio and text is final. At this point, only bugs (a term for errors) are fixed. The game goes on to Quality Assurance testing, where a team of testers plays through the game to verify that everything has been implemented and find any problems that were overlooked by the development team. (Sometimes games go in for QA testing at the Alpha stage).
  • Code Release: The point at which the development team believes they have fixed all the bugs found in QA testing.
  • Gold Master: The final version of the game that the publisher believes is good enough to sell to customers.

Note: While the game is in development, the development team (represented by the game’s producer) works with the publisher’s marketing, sales, and operations team, to provide information about the game so that it can be properly advertised, packaged, sold and distributed. The development team may be required to create trailers, screenshots, gameplay samples, and other materials needed to publicize the game.

Post Production Phase: Post-launch tasks

This is the stage at which after the main version of the game has “gone gold”, or shipped, the development team focuses on other versions of the game or maintenance tasks. (Note some of this work might be done in the Production Phase instead).

  • Localization: Creating versions of the game in other languages. For example, a game made first for American gamers might then be localized into British English, Spanish, French, German, Japanese, etc.
  • Porting: Creating versions of the game on other platforms. For example, a game made first for the X-Box might be ported to the PlayStation and Wii.
  • Source Code and Assets: The development team might be required to create a package of all the materials required to create the game and instructions for how to make a version of the game form those materials should other developers need to fix problems afterwards.
  • Patches: If errors are found in a game after it is released, new versions of the game may need to be made that correct those problems and updates are sent to the customers who have bought that game.
  • Customer Support / Technical Service: These departments help customers with technical and other problems customers have with their game.
  • Downloadable Content (DLC): New content (levels, missions, characters, virtual goods, etc.) may be continually created for players of online games. This requires a “live team” of designers, programmers, artists and producers to oversee them.
  • Community Management: For online game, Community Managers have the dual responsibility of running contests and special events to keep the game exciting for players, while dealing with abusive gamers that make the playing the game less fun for everyone else.

Now, the exact process of creating the design, art, code, sound, marketing and other tasks needed to develop and publish a videogame is far too complicated to be described in a single blog post. Entire books have been written about each of these individual tasks. However, this should give you a general idea of the overall approach that is taken from getting a game from idea to reality.

Milestone ABC’s: Alpha, Beta and Contract

ABC'sOne of my clients recently complained to me that a developer he had contracted was planning to deliver an Alpha milestone but that it would not be composed of final art. When I told my client that it was common for Alpha builds to have some amount of placeholder art, he replied, “I spoke to several people in the game industry, and I was told that an Alpha is essentially the game minus possibly a few features and is not bug free, but the gameplay and final art are there.”

I tried explaining to my client that, regardless of what others may have told him, he was confusing the Alpha milestone with a Beta milestone. Unfortunately, the most authoritative reference to which I immediately could think of directing him was Wikipedia:

Alpha is the stage when key gameplay functionality is implemented, and assets are partially finished.
Beta is feature and asset complete version of the game, when only bugs are being fixed.

“Assets”, I further explained, were the game’s text, audio, and, yes, art. So an Alpha milestone is comprised of art that is only partially finished.

But what does “partially finished” mean? Generally, when I am negotiating milestone definitions with a developer, we specify the percentage of art that may be placeholder (temporary assets taking the place of actual artwork until it is finalized). For example, an Alpha might be permitted to be composed of 50% placeholder art, while a Beta might required to have no more than 90% placeholder art.

However, I do like to have some artwork completed and approved well before the Alpha is due, so I usually specify an early milestone composed of final or near-final artwork early in the production so that the game’s art style and quality can be nailed down before art production begins in force.

Then there is the question of what “key gameplay functionality” means: what’s key, and what are the minor details that do not need to be implemented until Beta? Certainly the main game engine should be operational by Alpha (if not before), whereas it may be no big deal if one of the hidden bonuses in level 99 is not implemented until Beta. But there might be dozens of features in between about whether a publisher and developer may honestly disagree are key.

Ideally this should be determined up front, but usually many game features are not even determined until a preproduction phase that does not even being until after the contract is signed. However, a detailed milestone delivery schedule should be mutually agreed upon long before the milestone is to be delivered. Few things can sour a development relationship more than ambiguity or disagreement about what a developer is supposed to be delivered when a developer needs to get paid for that delivery to meet his payroll.

Another questions is “what does ‘implemented’ mean?” Does it mean that the developer only need to make a first pass implementation of a feature, or does it need to be fully debugged? To answer this question, I often have my milestone definitions specify the degree of “bugginess” that is permitted in a milestone. I categorize bugs as follows:

  • A: Renders the game or feature inoperational
  • B: Everything not classified as A or C
  • C: Purely cosmetic bugs

I may then specify that an Alpha milestone can have no A Category bugs, and that a Beta Milestone may have no A Category Bugs and only a specific number of B or C Category bugs.

Of course, how strict you make your milestone definitions will vary upon the needs of the individual project. What matters is deciding upon mutually agreeable definitions with your developer before you sign your contract.