Other Technical Roles
Some roles on the game team aren't specific to one particular discipline. They might be staffed by people who have broad skills experience. Unless you are part of a very small game team or game company, these are roles you grow into over time after gaining experience and showing aptitude , usually with some time previously spent being mentored by someone in that same position.
Project Manager
The project manager's job is to see that the game gets done on time and within budget. Both the game developer and the game publisher may each employ their own project manager, who is also referred to as the game's producer. To help accomplish this, a schedule is made with dates for particular "milestones," which define a set of tasks or goals that should be achieved. The milestone provides an indication that the game is making sufficient progress and builds confidence that the game will be ready on time.
In addition to the milestones, schedules may assign specific detailed tasks to specific people or job roles, along with a due date for each task. At any point in time on the schedule, the project manager can know how many people are needed, which tasks should have been completed, and which tasks should be in progress. Adding up all of the people at each point in time provides a staffing budget.
In addition to staffing, which translates into wages , the project manager may need to budget monetary expenses for equipment, supplies , and services. This includes new computers, hardware, and software tool licenses for programmers, artists , and testers.
The staffing, scheduling, and budgeting details may get written into a formal Software Project Management Plan. This plan makes the project plan visible to the team and the game company.
A Risk Management Plan may also be created and provided as a separate document or as part of the project management plan. This document lists risks that the project manager has identified as being possible for the current project. These risks may be based on the team's experience with previous games , or on new factors. Some examples of project risks are:
-
Two games will be tested at the same time; may not be enough testers for both.
-
Next-gen console hardware may not be ready in time to begin testing on schedule.
-
New graphics concept depends on rendering tool plug-in that is not yet available.
The project manager collects status reports from team members to evaluate game progress. When some aspect of the game seems to be falling behind, he may call for more resources, or figure out how to reduce the scope of work in order to keep things on track. Likewise, the project manager should participate in the Change Control Board to help make judgments about defect priorities and which approach to take to fix or work around a defect when there are alternatives.
Game Designer
The game designer is usually the person who is primarily responsible for conceiving and defining the game you are testing. He is a storyteller, entertainer, and inventor all rolled up into one. It is his concepts that give birth to game worlds , characters , and mythologies. Persistence is a useful trait for game designers who may have to make many proposals before getting game company approval to go ahead and make the game.
The game designer also tries to define game mechanics that are easy to learn, remember, and access during gameplay. Successful games lead to sequels and become a standard to which new games are compared. Some examples of successful long- lasting designs are the Pok ƒ mon , Final Fantasy , Madden Football , and Ultima titles. When testing any new game in a series, you implicitly accept the responsibility for testing the consistency and continuity with its predecessors.
Game design might develop from a top-down approach, where the designer starts with a high-level idea and then breaks it down into more and more detail until it's described sufficiently for artists, sound engineers , and programmers to develop the game. Alternatively, the game designer might have a bottom-up approach, starting with a few ideas for some detailed scenes or events he'd like to put into a game, and then working his way up to come up with the higher-level story and settings that tie together the low-level concepts.
Whichever way the game designer arrived at the design, he is responsible for producing the game design documents that are used by the other disciplines to guide how they do their parts of the work. This document can also be a useful resource for testers to ensure that the designer's ideas are incorporated into the game, and that the game maintains the proper relationship between design elements.
Figure 4.2 shows a game state flow diagram from the game design document for Super Street Racer , which was produced by students of a game programming course at the University of Calgary. Figure 4.3 shows the screen layout design for the Dealership screen, also from the game design document. Testers can use this information to get an early jump on planning and creating the tests for the game. The full document has been provided on the CD-ROM that accompanies this book.
Figure 4.2: Super Street Racer game state flow.
Figure 4.3: Super Street Racer Dealership screen layout.
Testers should use this design documentation as the basis for providing a complete range of tests. From the flow diagrams provided, write tests to cover all of the states and transitions. In addition to checking the flows that are designed to work, make sure you can't make any transitions that are intentionally left out of the design. For example, using the game state flow diagram in Figure 4.2, you want to test that you can Pause while Racing and also test that you cannot Pause during the Race Wrap-Up.
The same approach should be used with any screen layouts documented in the game design. You can use the screen layout test checklist in Table 4.2 as a guideline.
|
EAN: 2147483647
Pages: 205