Complete the following review based on the game project you are working on for this course. For each question, answer yes, no, or sometimes, and provide a short sentence of explanation/clarification:
- Did you have a clear, unambiguous vision statement for the game?
- Was this vision realistic?
- Was the core gameplay and user interface fleshed out early in the project, so that you clearly understood what the game is and why it would be fun?
- Did the team members think the game will be fun?
- Does the game have a detailed, written game design document?
- Did you keep a detailed project schedule, listing all of the tasks that needed to be performed and the dependencies between them?
- Were all the design and planning documents (including readme files, user manuals, etc) kept thoroughly up to date throughout the project?
- Were all the features of the game prioritized (e.g. core, secondary, and tertiary) to make it easy to trim features if necessary to maintain the schedule?
- Did the project have a written test/QA plan?
- Were all game deliverables submitted on time, according to the original project deadlines?
- Were sources and rights for all artwork (sound, images, etc) clearly documented and tracked throughout the project?
- Was a clear plan followed throughout development to create and track backups of source code and documentation, and track changes made from one version to another?
- Did you create and maintain a list of risks or potential problems associated with the project?
Suppose you were given a budget to hire six additional people to work on an expanded version of your game project for the period of one year. Describe the six positions you would choose to hire them in (e.g. software developer, manager, artist, etc) and justify your decision.
One of the components sometimes recommended for the early stages of a game design document is "60 seconds of gameplay": a detailed written description of one minute of "typical" gameplay, identifying everything the user sees and does during that minute. Discuss the potential advantages and disadvantages of including something like this in your game design document.
- "A player must always feel like the failure of a challenge is entirely
his own responsibility, and not a fault of a poorly designed product."
"The player must understand how and why he failed, so that he can learn from his mistake and increase the feeling of failure being his responsibility."
Provide reasoned arguments either in support of or in opposition to those two ideas.
(1) Save anywhere, anytime: the player can always invoke the save game option, and save the exact currentstate of the game.
(2) Triggered saves: the game is automatically saved when key events take place, the player can only load games stored from those points.
(3) Save locations: the player can save whenever they reach certain states or location (e.g. they can save when in a city, but not when in combat).
One of the biggest problems in playtesting is identifying what should be tested at each point during development. Testing some aspects of gameplay too early means testers spend much of their time reporting issues that would naturally have been fixed later in the development process anyways, but leaving testing too late may cause key problems to go unnoticed so long that it becomes much more difficult to fix them.
Pick a style/genre of game you are familiar with, and outline a preliminary test plan that you would recommend for testing different typical features. These features may include the user controls, the interface and display, the sound and graphics effects, the user guidance, setting of difficulty levels, the effectiveness of the AI, the game speed, game stability, "fun", etc).
Using one of the five games listed below, discuss the dramatic elements of the game in terms of the player's objectives, the choices they have to make, the information available to them, and the means used to escalate tension during the game.
Game Choices: poker, backgammon, go, risk, battleship
Name your favorite computer/console game of all time, and describe the dramatic elements of that game in terms of the player's objectives, the choices they have to make, the information available to them, and the means used to escalate tension during the game.
Many games increase tension by encouraging players to pursue paths that could become mutually self destructive. Perhaps the simplest example is "chicken", where two players race towards one another risking a head on collision: if one player turns away the other gains a small victory, but if neither turns away they both suffer a major loss. Discuss how similar ideas can be used on a much larger scale to produce tension in mainstream games.
In lectures we discussed the concept of Schelling points - values or decisions whose outcome is based on group behaviour, when individuals must make their own decisions independantly and without shared information.
One example is the "two-thirds average" game: everyone participating must guess a number between 0 and 100, and the winner is the person whose guess is closest to two-thirds of the average of all guesses.
Describe strategies you would recommend for a player (or an AI) to use in this game, and justify these strategies.
In lectures, we discussed several different approaches to visual interfaces for games:
- minimalist interfaces, in which no actual controls are shown on-screen
- total control interfaces, in which controls for all player actions are always on screen
- accessible option interfaces, in which access to the seperate control modes or panels are always on screen
Dynamic game balancing is the process of automatically updating the state of a game to keep the game interesting - e.g. keep it from getting too easy (boring) or too difficult (frustrating). This can involve giving the player or the AI a wide range of handicaps or advantages, increasing or decreasing the hazards a player must face, etc. However, dynamically altering the balance needs to be done quite subtely, otherwise the player's actual skill/involvement seems less important ("If I play really poorly the game will just dumb down the AI for me, or if I play really well the game will give the AI a huge boost that wipes out the advantage I gained through all my hard work.")
In the context of a racing game, discuss ways in which the game difficulty can be dynamically balanced to keep interest levels up, but without making the dynamic balancing obvious to the player.
The IGDA Quality Assurance group includes the following in its "Ten commandments of QA":
-
"Understand the difference between playing a game and
testing a game. Spend most of your time doing the latter."
One area of concern in the industry is the topic of "game addiction". Many games now incorporate features that encourage players to limit (within reason) the time they spend playing the game.
Discuss two possible ways of encouraging players to limit their playing time, and discuss the advantages and disadvantages of each.
Below you will find a list of adventure game actions (in no particular order) that must be supported using a typical 10 button controller with a D-pad and two analog sticks. (A snapshot of a sample controller is also supplied below.) Identify either one or two modes of operation for the game controls, map the individual actions to specific controls, and provide a set of justifications for your choices.
| Supported list of actions | |||
|---|---|---|---|
| move forward
jump switch weapon zoom in fire weapon |
move backward
crouch switch item zoom out use item |
move left (sideways)
run grasp or pick up item turn left view objectives |
move right (sideways)
climb drop or release item turn right aim weapon |
| Mapping of actions to controls | ||
|---|---|---|
| Control | Mode: | Mode: |
| Button 1 | ||
| Button 2 | ||
| Button 3 | ||
| Button 4 | buttons 5,7 are front left, 6,8 are front right,
|
|
| Button 5 | ||
| Button 6 | ||
| Button 7 | ||
| Button 8 | buttons 9, 10 and mode selection are on top | |
| Button 9 | ||
| Button 10 | extra space is provided for describing analog/d-pad use | |
| D-pad | ||
| Left analog | ||
| Right analog | ||
Justification: | ||