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.
In one of our AI lectures, we discussed simple sets of rules that could be used to guide individual members of an AI population. Herbivores would run away if threatened, try not to bump into one another, try not to get too far from the herd, or do more-or-less what their neighbour was doing. This had the advantage of being computationally practical, yet gave seemingly realistic behaviour for a population of individuals.
Your task is to recommend a simple set of rules to control AI characters in the old west scenario below. (A logical description of the control rules is enough - you don't need to provide actual code.)
-
Our game will be set in the old west, and includes a large number of AI
prospectors hoping to strike it rich. Each miner needs to get enough
food, water, and sleep to survive, needs to work their mine digging for
gold, and needs to take their gold to the bank so it doesn't get stolen.
Suppose we have an AI character that is supposed to be finding its way from one point on a map to another, and it uses the algorithm described below.
-
At each step, the AI looks directly towards its desired
destination.
If there are no obstacles between the AI and its destination it moves directly towards the destination.
If there is an obstacle between the AI and its destination, it sweeps its gaze to the right until it sees the edge of the obstacle, and moves towards that point.
It is sometimes recommended that user manuals be written in the early stages of game design, so that they can form the basis for a detailed test plan to evaluate the game's final functionality.
Outline how you would form a test plan based on a user manual that had the following contents:
- An overview of the gameworld, storyline, and characters.
- A description of the player goals and subgoals.
- A description of the key characters and objects in the game, and any noteable properties or abilities.
- A description of the game controls and interface.
- A section on tactics and advice.
In the course textbook, Steve Rabin lists twelve tips for debugging, including the following:
- Question your assumptions
- Minimize interactions and interference
- Minimize randomness
- Break complex calculations into steps
- Check boundary conditions
- Check code that has recently changed
- Explain the bug to someone else
- Debug with a partner
- Take a break from the problem
Provide several different examples of circumstances in which it is helpful the cursor image to help the user understand what is going on, and discuss any concerns/drawbacks that may arise.
In our lectures we discussed a variety of different ways we could have our AI move about the map in a 'reasonable' fashion, including random movement, fixed/plotted movement, finding best paths, avoiding obstacles, etc.
Describe which approaches would be most appropriate for the AI in your game project and why.
(If your game project does not include any moving AI then pick a mainstream game and describe the approaches you think would be most appropriate for that game and why.)
In our final lecture we discussed the issues associated with developing trial or demo versions of a game for the purposes of marketing to potential players.
Discuss the form of demo you feel would be most appropriate for a game based on your game project, and why.
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: | ||