Game Storyline
An important planning document for building a game is a description of
the story or stories that players will experience when playing your game.
Please put your answers to these issues into a file with a name like
AMETHYST-Milestone-B.doc, but replace AMETHYST with your group name
(e.g., INSECURITY, etc).
Include the following:
- Your names: List the names of your team members.
- Tentative Title: Make up a name for your game.
This can change, but please make your title reasonably descriptive for now.
- Wickedness:
Explain the extent to which your chosen problem has each of the 10 characteristics
of wicked problems given by Rittel and Webber. In addition, explain the extent to
which there exist multiple stakeholders for your problem, and what conflicts exist
among them. You should have strong cases for at least four of these 11 characteristics.
Put a star next to each of the four characteristics that you believe most strongly apply
to your problem and explain in detail.
- The Setting: Use about half a page or more to describe
the situation that a player (or multiple players) will be faced with
when they are playing your game. Where will the story take place --a government or
corporate office,
outdoors, the United Nations, or somewhere else? Is it set in the past, present, or future?
(most of our game stories should be set in the present or near future).
What aspect of your wicked problem (from Milestone A) is involved in this game?
What major aspects of the wicked problem are you intentionally leaving out?
(You probably need to rule out some significant aspects, but also leave in
some significant aspects!)
- Initial Situation:
What is the initial situation that the player is in? This will correspond to the
initial state in your game. Also explain how the initial situation will be
affected by the very first move by any player in the game.
- Roles: Will there be only one role? (This is OK). Will there be multiple
roles? If so, do the roles correspond to different characters in the story?
Are these roles collaborative, competitive, neutral, or unspecified and/or changeable
during the game?
- Objective: What is the player trying to do? If there are multiple roles,
will there be different objectives for the different roles, or are they all striving
for the same goal?
- Player Affordances: What can each player do? What operators might be
available to them, and how should they think about these operators? What will players
be able to see? All the details of the current state? Or will some parts of the state
be hidden? Will all roles get the same view of the state, or will the views depend on
the roles?
Implementation Considerations
- Initial State:
What are a couple of the variables that should be a part of your state representation?
Do you have any idea what their initial values should be?
Are there other variables that you would like to include?
- Operators:
What is the first operator you would definitely want to have in your
game formulation? Is it a direct action in solving the problem
(e.g., ban activities that are causing the problem), or is
it more organizational or indirect? (e.g., invest in research that
might find a partial solution).
Will this operator change one or more of the variables you mentioned that are
involved in the state? If not, how will this operator affect the game?
- Goals and Scores:
Do you plan to have a goal state in your game? If not, will there be
a scoring facility, so that players try to achieve a high score?
- Specification of First Working Code:
Can you describe a possible role, initial state, and operator that will permit
you to have a working "pre-alpha" version of your game? No visualization would
be expected, no goal criterion or scoring would be expected. But you should have
at least one state variable in your State class, and a real operator that has a
name, a precondition, and state-transformation function. The precondition can
be as simple as
lambda s, role: True.
- Specification of Second Working Code:
Please describe an "alpha-test" version of your game that includes states with
at least two state variables, a definite initial state, at least three operators,
and a goal criterion or scoring function. Mention if there will be more than one
role.
Presentation
Once again, please prepare a presentation involving about 5-8 slides.
This will be a design presentation, at which you'll share with the class
your basic conceptions of the game you are designing.
Please include
three illustrations. One of these should be a sort of "map" or timeline
that shows an imaginary game session, with the initial state on the left,
two or more waypoints, and a last state (which could be a goal state or simply
the state at which the players have finished the game, according to you).
Label these timepoints on the game with brief descriptions of what happens
at these points in time.
The presentation should last about
6 minutes when delivered.
The slides may be in Powerpoint or similar format.
Actual First Working Code
The last required item for Milestone B is Python code that corresponds to
what you specified for "First Working Code" above. This could be just
a single Python file. It would be capable of running with the Tk_SOLUZION_Client.py,
but it does not have to have any visualization at this time. If it has no visualization
then the string representation of the state should be descriptive enough that someone
unfamiliar with your game could make sense out of it.
Also, please be ready to
demo this if asked.
Optional Testing with the Autoplayer
If you would like to test your code with the autoplayer, it is
available
here.