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 from
the INFACT grouping result posted in GoPost.
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.
- 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?
- Communication: Will it be important for the players to be able to
communicate with each other outside of the game itself, while playing the game?
If so, would a chat room be sufficient, and would it make any difference whether the
chat client was embedded in the game platform and possibly "aware" of game events?
For example, game moves might be printed in the chat log, and thus the chat history
would show a chronology of game play and chat communication.
It is also possible that parts of the story of a game session could be printed into
this chat history to help the players understand the unfolding events and see their
participation in the context of whatever you might want them to know about the
wicked problem they are dealing with.
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
5 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 SZ001.py
server program on Nicto.cs.washington.edu. Also, please be ready to
demo this if asked.
Here is a tar file of the
SOLUZION code framework
that you can untar and
put in your own Nicto directory to enable you to develop and test your
own problem formulation code. See the README.TXT file within this archive for
an explanation of the folder structure.