Designers and the Development Process
Depending on the company and the game in production, there might be only one designer who is responsible for creating and maintain- ing all data. Designing simple games is relatively fast compared to designing a complex game, for there are far fewer game elements to think up, test, and balance. More complex games usually involve a team of designers, with a senior designer overseeing the workload of junior designers and level designers. The senior designer is responsible for the overall design and play of the game, while the junior designers help out with various tasks during development. The level designers know how to use 3D modeling programs like Autodesk’s 3ds Max or Maya to create the environments of the game world and also scripting languages to trigger events in the environment.
Designing a video game is certainly not a solitary task. Designers work closely with other team members—programmers, artists, audio engineers, and management—during the whole process. Actually, all team members should be encouraged to come up with ideas to make the design better. A good designer is willing to listen to what other people suggest and select those suggestions that improve game play. There does come a time, however, when changes to the design have to end so that the game can be completed on schedule. But any remaining good ideas can be written down and then incorporated into add-ons or sequels.
Game Development Cycle: Preproduction Phase
Each company has its own method for coming up with a game design and implementing it, but there are generally three phases in game production. The first phase is preproduction, where game ideas are evaluated until one stands out. The idea for a game can come from many places within the company, depending on how the creative process is handled, and if the design involves a license, it is likely that marketing will want to be involved to make sure the design stays within the parameters of what the licensor demands. In many cases, the originator creates a one- or two-page paper called a pitch paper and presents it to the design staff and management.
Once a concept has been accepted, a designer might develop it by writing a game proposal, a longer document describing the game world and major game play elements. It usually includes a marketing section that points out competing products and explains why the new game will successfully compete in the market. The designer receives feedback from artists and programmers during the process of writing up the game proposal to make sure the final product can be done as presented.
A developer or publisher might evaluate a number of game proposals before deciding on one that everyone thinks will succeed. Once the game idea has received the green light, the designer (perhaps with help from other designers) writes up a game design document that describes in detail how the game works and what the game world looks like. At this point, a senior programmer and several sketch artists might assist in the process of creating the final document. By the time the design document is complete, the team should have a very good idea of what they plan to build. The documentation process is particularly useful for complex games that include a lot of data, and its creation allows the designers and other teams to think through what will be involved in turning the idea into a final commercial product.
Some companies do not go through a documentation process and instead use an iterative design process. For example, a developer planning to create a first-person shooter (FPS) game—like Doom—might decide to create a prototype of the game rather than spend time documenting his or her ideas. The basic game play of FPS games is pretty well defined, and the main challenge is coming up with new and interesting weapons, enemies, and game worlds. The company might build a number of prototypes to experiment with different fictional genres before settling on one concept to pitch to management or to a publisher. These prototypes are played by focus groups and their feedback helps the designers and management understand which ones are most appealing from a game play and commercial perspective.
Once management approves a game design, either at the end of the documentation process or after agreeing on a prototype, the team starts to assemble and more programmers and artists are added. Before barging ahead with production, however, the teams take time to analyze the design objectives through a technical review.
Technical Review
Another important part in the preproduction process is for other teams to look at the overall design to see what work is expected of them during development. The programming team often creates a technical design document in which they analyze the requirements for the game engine and figure out the architecture for making the code modules interact with one another. They also decide what tools they will have to create for various teams working on the project. Likewise, the art team might create their own art design document (sometimes called the art bible) in which they not only determine what objects and characters in the game world will look like but also agree on the technical requirements for creating the art assets. Although audio is often worked on later during development, the audio team lead should look at the design document and start creating their own audio design document—a list of sound effects, voiceovers, and possible musical themes for the game. Finally, the lead tester (also known as Quality Assurance) should also look at the design document to determine what will need to be tested and then begin writing a test suite for checking the product as the components come together.
After all the teams have worked on the project, the team leaders meet with the producer and management to nail down the final production schedule and budget. They determine when new hires should be made and when additional hardware and software is needed. The final schedule is broken down into a series of milestones. The team should also make sure to run the production schedule past marketing so they can point out where working demos and screenshots of the product are required.
The final step in preproduction is often the creation of a work- ing interactive prototype of the game. Not only can it demonstrate to management how the game will play and what the game world will look like, it also lets the design team test some of the mechanics before full production begins. In a very complex game such as a role-playing game, having a prototype of the combat system is a huge help in determining how the values assigned to characters and objects interact. The designers can then tweak the game mechanisms if they detect a problem with the original design. It is far better to make changes as early as possible in the production cycle rather than later when many assets have been created since changes often require ex- tensive modifications to code, art, and audio.
Game Development Cycle: Production Phase
Once the whole production team knows what they want to build and how they plan to create it, they can start work on the real as- sets that will be used in the game. The artists start building the 2D sprites or 3D models that will be used for characters, objects, and environments (Figure 1.2). The programmers begin writing the code for the game engine. The designers continue refining the data in the game and work with the level builders to determine how the environments will be laid out and what they will contain. As the play elements come together, they are incorporated into the game to be tested and changed as necessary. Based on the feedback they receive, the designers may decide to make significant changes to the design, with the game design document being updated to reflect any changes.
Eventually, the game reaches a point where it can be played from start to finish, even in a very rough form. This point is referred to as the alpha build. By this time, the design should be solid with very few changes being needed to the basic design. The teams continue pumping out art and code assets for the final version, and the final audio assets are created and incorporated into the product as well. Meanwhile, testers look for any problems in the game so they can be fixed.
When all assets have been added to the game and the team is down to final polishing and debugging, the game reaches beta build. There should be no more design changes at this time and only bug fixes should be allowed. The final product is then shown to the publisher for any final changes they might demand. The final step is when the final version of the game—called the gold version—is sent out for manufacturing.
Production is the longest part of game development. It can take several years to complete the code and turn out all the assets that appear in the final product. Many developers and publishers add additional milestones during this phase so they can make sure the game development remains on target. Third-party developers who are independent of the publishers get paid for meeting their milestones, and so there is often a period where everyone has to put in a lot of extra time and effort to get the next build ready—a period known as crunch time.
Game Development Cycle: Post-Production Phase
The post-production phase overlaps the later stages of the production phase and involves the marketing and distribution of the final game. The designers may be tasked with writing a first draft of the manual to explain all the controls and features in the game. The final version of the manual is usually written by a professional writer that the marketing departments hires. The marketing department works up a marketing campaign for the product, deciding where to advertise and what additional materials will be needed—e.g., a demo version or strategy guide. Otherwise, the development team is not much involved with the creation of the CD/DVD disks that contain the game, with the package assembly, or with the distribution of the final product to retailers.
The team might be involved with promotional materials after the game ships—for example, web chats and meeting players at trade shows and conventions. The team might also be required to create a downloadable patch if significant bugs slipped into the final shipped version. Even before the final version is released to manufacturing, most of the team is reassigned to other projects. Some might already be at work in preproduction on a new title.
The Designer’s Role in Game Development
The senior designer on a game helps define what the team will build. He or she then becomes the keeper of the flame to guarantee that the final product turns out as envisioned and is fun to play. Many mistakenly think that the designer’s primary responsibility is coming up with the story for a game, but that is only one part of the job. Many game genres (adventure games, first-person and third-person shooters and, in particular, role-playing games) do demand a central story to link together the parts. Developing a full-length story with interesting characters, settings, enemies, and items is challenging and takes considerable time to work out all the details.
Many game genres, however, have no central story. There are no stories in most sports games, simulation games, puzzle games, or arcade games. If story elements do appear in these types of games, they are only tangential to the central play experience. Nevertheless, there is considerable work for the designer to figure out how all the play elements will hang together as a cohesive whole. It can take just as long to develop the game play elements for a non-story game as it does the central narrative for a huge role-playing game.
Ideating and Pitching Concepts
One of the most important—and enjoyable—tasks for a designer is thinking up an idea for a game and then expanding on it to deter- mine what the player does that is fun. While some designers prefer to come up with their ideas in solitude, many prefer to work with others. Sitting in a bull session with everyone shouting out ideas while the designer steers the discussion and jots down ideas on a whiteboard is exhilarating. Afterwards, the designer writes down notes about the suggestions and then circulates them to the participants for their comments. The interplay of ideas can lead to some interesting and creative suggestions.
The designer then has to take all the ideas and come up with a concrete central concept for the game. Many companies use a process where anyone can come up with the original idea and write it down in a short document, the pitch paper, to present to management and the creative staff. The pitch paper is meant to illustrate the essence of the game and explain why it would be new and fun to play. It should make an indelible impression on the reader and therefore should be written as creatively as possible. It should define the game genre, describe the fictional setting (if necessary), and then talk about one or two of the most exciting aspects of game play. It is intended as a sales tool to get management (especially marketing and sales) interested in producing the title. Ideally, the central concept for the game should be encapsulated in a sentence of 20 words or less in the first paragraph. This sentence is your high concept for the game and can be a useful tool for the marketing department to sell the concept of the game.
If management decides an idea is good, they then have a designer flesh it out in more detail in a game proposal. Good game ideas are cheap and many ideas are pitched to management but then tossed aside. For every ten ideas presented, only one or two will be deemed worthy of more work.
Game Proposals
A game proposal elaborates on the pitch concept and describes in some detail the major game play features. It is still a relatively short document and should not go into too much detail on any one feature. The idea is to excite management about how the game will be played and what the game world will be like, and it should show that the concept is worth further development. A designer often works with a sketch artist to come up with ideas for characters, interesting world locations, and objects, but actual in-depth design is not appropriate at this stage. Again, the proposal works as a marketing tool to sell the concept, and one of the most important features is a market- ing analysis in which the designer, in conjunction with marketing, demonstrates that the new game will either fill an existing hole in the market or can successfully compete against similar products. In total, the proposal might run about 6–10 pages. If it is too long, management probably won’t study it, and if it is too short, it won’t cover all the fun elements in sufficient detail.
It takes a designer about a month or two to flesh out a game proposal before showing it to management. Aside from help by concept artists, the designer usually works alone on the document. Sometimes a series of storyboards are helpful tools allowing man- agement and marketing to visualize the game action or the world setting (see Figure 1.3). Asking the company’s technical director for advice on the feasibility of the concept is highly recommended.
Again, if management thinks the idea is worth pursuing, they will request the designer expand the concept as a full game design document. However, for every five or six game proposals, only one will likely be given the green light for further development.
Game Design Document
The final step of the design process is the game design document. It can be a very large document since the designer tries to explain in extreme detail how the game play elements interact and what the game world and characters look like. At first, the document can feel highly conjectural because the designer won’t know how things actually behave in the world until a prototype is created. Thus, the design document is a “living” thing that grows and evolves over time.
Each company has its own approach to structuring the document. Here is a structure the author has used repeatedly over the years. The idea is to break the piece into sizeable chunks so the rest of the team doesn’t have to absorb the whole document at once. They can focus primarily on their areas of interest and then read about other parts of the game if they so wish.
■ Introduction. Written specifically for management. It starts off explaining the high concept of the game (often drawn directly from the game proposal) and gives an example of play from the game so the reader can visualize what is happening. It also includes the basic information about the game genre, fictional world (if necessary), target platform and audience, and a very rough estimate of budget and schedule. This section should be short, about 4–6 pages maximum.
■ Game Mechanics. Aimed specifically at the programming team. Each element of game play is discussed in detail, with appropriate charts and tables as necessary. In addition to explaining how everything works—movement, combat, resource management, magic, etc.—it also includes the designer’s suggestions for user interfaces for each screen and descriptions of all the control functions. By the end of this section, the programmers should have a very good idea of what is required for the game engine and what they will need to test first to get the design working as imagined.
■ Game Graphics. Aimed specifically at the art team. The designer tries to include all the materials the artists will have to make— characters, environments, and items. There should be a physical description of each character, the actions the character can perform (referring to the game mechanics section for more detail), and any special visual effects required. The environment and items are also described in detail. Note that the initial ideas for world objects can change during development, but it is important to provide a starting place for the artists and then update the document over time as changes are made and the final art assets are completed. By the end of this section, the art team should have a good idea of what they will have to create.
■ Appendices. In this section, everything else that hasn’t been described is dumped. It is a good place to include audio requirements for the game, plus all the charts, tables, user interface screen schematics, and anything else the designers might come up with. As the game enters development, this section can become the largest one as other elements are added— maps of finished levels, dialogue, flow charts, storyboards, and more.
The game design document goes through two stages during preproduction and development. The first stage is the concept version of the game design document where the elements of the game play and art requirements are specified, as described above. The designer might have to revise the concept document many times until management is satisfied that all details are explained sufficiently. The second stage is the production version (called the “Bible” since it acts as a reference tool for everyone working on the project), which is used to track changes to the original design throughout the Production Phase. This version includes both frequent updates of changes made to the original design and also some materials created during the Production Phase—for example, maps of the final levels, dialogue, scripts created with a scripting language, bug report updates, and even directory listings for all assets in the game. The production version of the game design document can be hundreds of pages long by the time the game is finished. It can prove useful later as an invaluable resource for the team (or for an outside developer) tasked with making add-on modules or a sequel.
Prototyping
With complex games, a designer often needs to experiment with game play elements before settling on those to be used. One way to experiment is to create some simple prototypes, both paper and electronic. A prototype is an abstraction of a game system and gives the designer feedback on how well the system works. For example, the designer of a role-playing game might have an idea for an unusual combat system, and creating a simple paper prototype can be used to test the system and modifying how it works before any other teams get involved. A paper prototype can be used to try out systems for combat resolution, resource management, technology tree evolution, and puzzle solutions. They are also very useful for fleshing out the structure for levels and determining where things will be placed in the playfield. The designer doesn’t need to involve other employees working on other projects except to involve them in testing and getting feedback about how well the system works.
As useful as a paper prototype can be, any final design decisions will not likely be made until the game engine is up and running. What looks fine on paper can change radically once assets become available and the engine is working as expected. If possible, a designer should ask for an interactive prototype in electronic form as part of technical review. The prototype can still be very simple, using an existing game engine and art (see Figure 1.4). Once the game appears on the screen, even in a rudimentary form, it can look and feel quite different than what the designer had in mind. The scale of objects might need to change, forcing the designer to rebalance the values used to resolve game actions. If there is going to be a multiplayer version of the game, having an electronic version for early testing can prove to be a godsend. By working with a programmer and artist or two, the designer can have a very useful tool to test multiple versions of the game at a minimal cost.
The whole idea of using prototypes is to nail down how things will work before other teams start buildings the final assets for the game. There is nothing worse for artists than to invest a large amount of time in art assets only to find out that they don’t look right once they appear in the game. Likewise, programmers hate rewriting code because the designers keep changing their minds. Simple prototypes can help designers determine and balance the values assigned to game objects and guarantee that game mechanics work as described in the documentation.
Asset Creation
Once the whole team is ready to work on the game, the design team either joins in creating the assets or oversees the work of other team members. Depending on the type of game being developed, the tools used to make the assets might be simple enough for designers to use, or they can be so complex that only skilled team members can use them confidently and with ease. Sometimes, companies will build tools like map editors and scripting languages for the designers to use. In this case, the designers can build assets directly and test and balance them while testers send in their suggestions and bug reports. At other times, companies prefer not to spend the time building tools for the designers and rely on commercial products. Most designers, for example, aren’t adept with complex 3D modeling applications such as Autodesk’s 3ds Max or Maya, and so they would have difficulty building environments with these applications. Instead, the work of creating environments is left to artists who work with the designers to determine the layouts of the levels. The paper prototypes of the levels can help the artists visualize what the designers have in mind and thus make level creation much quicker.
The designers also work with the programming and art teams to make sure that the various game systems work as planned and that the characters move and act as envisioned. The designers massage the data in the charts as necessary, revising values and modifying attributes assigned to objects until the game system is balanced and complete. Meanwhile, they work with artists and programmers on the graphic user interface so that players will understand at a glance all the information presented on each screen, and they also help to solidify the control scheme until it feels intuitively obvious to players.
Testing and Debugging
One of the most important jobs for a designer is continually testing the game to make sure that the values are balanced and that there are no holes in logic or storytelling. As levels are finished, they are given to testers to check over both for play value and for problems in the game elements. The design team constantly has to tweak the values for game objects until they are at a point where both novice and veteran players enjoy the experience. As development winds down, the designers also have to take care that any changes made during later stages of production don’t unbalance assets that have been completed earlier.
It is always a good idea to get fresh eyes to look at the product starting at alpha stage and later. There is a temptation to make finished levels more difficult as testers who are overly acquainted with them complain that they aren’t hard enough. It is important to get a stream of new players looking at the game in order to evaluate the orchestration of action throughout the whole product. As the game reaches beta, some of the designers might be pulled off to start work on the next project. The last round of debugging is devoted to fixing problems with the code and the final art, and usually designers are no longer needed at this point (unless there are problems with the database or loose story threads that need to be tied up). The end of a project usually means a well-deserved vacation for the designers, so they can recharge their creative batteries for the next project. Then they begin the process all over again—coming up with ideas, pitching them to management, and documenting game play.
The above copy is taken from The Basics of Game Design by Michael Moore. Please purchase at Amazon »
Turning Game Strategy into Game Introduction:
While having a client centric game strategy is important, it may be just as important to have marketing copy that establishes the voice and tone of your game. A good product overview should always take audience into account. FarmVille 2 uses the word “nurture” to appeal to children who want to take care of animals, while “a crazy Farm” implies that the game is going to be unpredictable and fun.
Homepage:
Nurture a crazy Farm on the Countryside with FarmVille 2!
Create, build and nourish the farm of your dreams in FarmVille 2. You’ll interact with a variety of interesting characters, grow and unlock special crops, take care of animals, and make your farm come alive. Trade with neighbors, contribute to your friends’ farms, and join a Co-op to work with farmers you can count on to complete a shared Order Board and progress on the Co-op Delivery Map for huge rewards!
Breakdown:
- A Brand Voice — “the farm of your dreams”
- Tell them what they will do in the game — “create, build and nourish”
- Highlight key features — “take care of animals”
- Communicate the end goal — “huge rewards”
SimCity™
Here is another example with a very different audience. This game appeals to an older age range but note how similar the structure of the overview copy is.
Build the city of your dreams and watch as the choices you make shape your city and change the lives of the Sims within it. Every decision, big or small, right or wrong, has real consequences for your Sims. Invest in heavy industry and your economy will soar—but at the expense of your Sims’ health as pollution spreads. Implement green technology and improve your Sims’ lives but risk higher taxes and unemployment. In SimCity, you’re the Mayor and how you run your city is entirely up to you!
For the first time, SimCity will feature Multi-city play where you can go solo, invite friends or join with neighbors to build multiple cities in your region! Collaborate or compete with friends to grow the fastest population, create the most jobs, educate the most Sims and much more! Access SimCity World to connect to global markets and participate in regional challenges!
Breakdown:
- A Brand Voice — “build your dreams”
- Tell them what they will do in the game — “create a city, change the lives of people in it”
- Highlight key features — “decisions have real consequences”
- Communicate the end goal — “run your city any way you want”
Assassin’s Creed
Another example is a story-based game. Here in Assassin’s Creed note the slight differences.
The setting is 1191 AD. The third crusade is tearing the holy land apart. You, Altaïr, intend to stop the hostilities by suppressing both sides of the conflict.
THE GAME THAT STARTED IT ALL
You are an Assassin, stalking your prey with a hidden blade. A warrior shrouded in secrecy and feared for your ruthlessness. Your actions can throw your immediate environment into chaos, and your existence will shape events during this pivotal moment in history.
KEY GAME FEATURES
- Master the skills, tactics and weapons of history’s deadliest and most secretive clan of warriors including the deadly Hidden Blade.
- Stalk your prey through richly detailed, historically accurate, open-ended environments. Scale buildings, mount horses, blend in with crowds. Do whatever it takes to achieve your objectives.
- Experience heavy action blended with fluid and precise animations. Use a wide range of medieval weapons, and face your enemies in realistic swordfight duels.
Breakdown:
- Establish the historical context — 1191 AD
- Establish the role of the player — Altair
- Assign the player the mission — the same as #2 above, but this time with more drama
- Provide Key Features — the same
- Brand Voice — the same
Farm Simulator 15
Take on the role of a modern farmer in Farming Simulator 17! Immerse yourself in a huge open world loaded with new content: new vehicles, animals, crops, gameplay mechanics and a detailed North American environment!
Farming Simulator 17 offers rich online activities: play in co-operative multiplayer up to 16 players, and download mods created by the passionate community for unlimited content and an ever-evolving Farming Simulator 17 experience.
Lastly let’s examine the game that is closest to our genre and industry, Farm Simulator.
Breakdown:
- A Brand Voice — “the modern farmer”
- Tell them what they will do in the game — “Simulation + Immerse yourself + huge open world”
- Highlight key features — “vehicles, animals, crops,.. ” — Note the order here, vehicles is the most important
- Communicate the end goal — “become a modern farmer”