Project 3:
Milestone B

CSE 481p, University of Washington, Spring 2018


 

Overview

Work in your project groups to plan a game based on your wicked problem. Then create a report and short presentation addressing the issues below.


 

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:

  1. Your names: List the names of your team members.
  2. Tentative Title: Make up a name for your game. This can change, but please make your title reasonably descriptive for now.
  3. 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!)
  4. 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.
  5. 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?
  6. 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?
  7. 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?
  8. 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

  1. 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?
  2. 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?
  3. 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?
  4. 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.
  5. 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.