Milestone 3, 5-9 Requirements

Final Project Description

Projects are usually somewhat open-ended. If we do not specify how you have to do something, then you are free to use your own imagination. You may use any of the code from M1 and M2 (that you or your teammates wrote),or you may decide to throw it all out and start over. Many of the economic and play models are left to your development. I have put some information in the description, but you may use other numbers and formulae that make your simulation more realistic/playable.

A few extra credit opportunities are suggested. You may propose other ideas by sending them to me via email. This milestone is in two parts. You will develop your deliverables as detailed below. Then you will set up a time to meet with your TA. Your TA will look over your design and make recommendations. You will then turn in the corrected information. You will have only 1 week total to work on this milestone, so plan ahead to meet with the TA in time to incorporate their suggestions.

Your project team should have 5 people. You may have fewer than 5, but I may assign lone students to your team if you are smaller than 5. The requirements are the same for all teams regarless of size, so most people opt for the full 5 people. Please post your project team pages as soon as possible so I can ensure all students are on a team.

Oregon Trail

As you may have surmised from M1 and M2, this semester's project is designing and implementing the classic educational game and simulation named Oregon Trail. We will be replicating the first version of the game that came out for the Apple ][ home computer. You can play a copy of the game online at: http://www.globalgamenetwork.com/westward_trail.html . You can click on the play link without registering. In our class resources, I have also placed an Apple ][ emulator (for windows) and the disk image of Oregon Trail if you want to experience the original game. Remember that the UI is before the mouse, window, icon era of interfaces. Try to design your game/simulation using a better interface paradigm.

The Game/Simulation

Oregon Trail is supposed to be a simulation of the long trip pioneers took to reach the pacific coast overland. Its educational purpose was to let young people experience the trials and pain of crossing the western frontier.

Minimum Requirements

You should implement the following minimal requirements:

• Configure your wagon for the trip.

1. Designate a leader with a name and a profession
2. Create up to 4 additional party members
3. Buy an initial set of supplies to begin the trip. The user cannot buy more items than they have money or weight to store in wagon.
4. Set the initial pace and ration for the wagon.

• Move the wagon based on pace. Everyone starts the trip on 1 May 1848.

1. Each move should result in distance travelled and food consumption based on number of people

• Allow a basic set of random events to occur
• Stop simulation if everyone dies
• Stop simulation if arriving in Oregon successfully
• Load and save the simulation.
• Create a user interface to allow the player to control the game/simulation and to display current state. For allowable options see paragraph below.

Professions

Players may choose one of 3 professions. Each has advantages and disadvantages.

1. Bankers start with $1600, the most money, but have no other abilities
2. Carpenters start with $800. They can also do repairs to the wagon, so they have to buy fewer (or no) repair parts.
3. Farmers start with $400. They can find food along the trail and therefore don't need to carry as much food as the other characters. He can also care for the oxen better, so they are less likely to die along trail.

Items/Supplies

There are a small number of items in the basic game which help the player make it across the frontier. The prices shown are for the start only. Prices go up as the player tries to make it across the frontier and goes farther west.

1. Oxen $40 a yoke (for 2) (Oxen are outside the wagon and thus do not impact the total wagon weight)
2. Food $1 for 5 pounds
3. Clothing $10 a set. Each set of Clothes weighs 2 pounds.
4. Ammunition $2 for 20 round box. Each box of ammo weighs 3 pounds.
5. Spare Parts for the Wagon, each spare part is $10

• Wagon Wheel weighs 75 pounds
• Wagon Axle weighs 125 pounds
• Wagon Tongue weighs 100 pounds

NOTE: EACH Wagon can only carry 3500 pounds, so plan the load carefully

Pace and Rations

The pace controls how far you move a turn and how tired you and the oxen get. In turn, the more tired you are, the more likely you are to get ill. Some suggested paces:

1. Stopped - 0 miles pers day restful. Recover from exhaustion faster.
2. Leisurely - 5 miles per day slow and restful. Helps recover from exhaustion.
3. Steady - 10 miles per day basic pace. Normal fatigue.
4. Grueling - 15 miles per day hard pace. Oxen and people rapidly become tired, then exhausted.

The ration controls how much people eat. Some suggested rations might be:

1. None - There is no food available. Generally leaders don't choose this ration, it is a result of running out of food.
2. bare-bones - 1 pound of food per person per day. Greatly Increased likelyhood of illness and death.
3. Meager - 2 pound of food per person per day. Increased likelyhood of illness
4. Normal - 3 pounds of food per person per day.
5. WellFed - 4 or 5 pounds of food per person per day. Recovery from illness more likely.

Random Events

The original game had many random events. You are required to implement these events. Other events you want to do would be extra credit. You should check for an event at each move. Note that some events can only occur when conditions are right (ie the right pace, ration or location).

• Severe storms, lose X days. X should be between 1 and 3. Your movement is 0, but food consumption continues for X days.
• X is ill. One of your people (Person named X) is ill.
• X has died. One of your people named X who was already ill has died. If all people die, the game is over.
• X has recovered. One of your people named X who was ill is now well.
• Wagon is damaged, requires Y to fix. Your wagon cannot move. You must have repair part Y to fix it (where Y is a wheel, axle or tongue.) This chance is greatly reduced for carpenter.
• Wandering UGA grad steals X from wagon. You lose item X (if food, clothes or ammo, take a random amount up to 10% of total available or if a repair item, lose 1.)
• First Nation hunting party feels sorry for you, gives you X food. You receive X pounds of food. X can vary from 10 to 100.
• Wagon flips in river This can only occur at the major river crossing where the player decides to ford or chaulk the wagon. Result is either 1 party member drowned or loss of a random supply item.
• An ox has died One of your oxen has died. If all oxen die, the game is over. This chance is reduced for farmer.
• Oxen are tired Movement reduced by 1-3 miles per day. Only occurs during grueling pace, or a steady pace for 10 days with no rest. This chance is reduced for farmer.

Player Control and Interface

The player should have the following abilities:

1. Change the ration
2. Change the pace
3. View the wagon inventory
4. View the people in the wagon and their status
5. Move
6. View a map which shows the oregon trail and their current location.
7. Stop and Rest
8. Attempt to trade. (There is a percentage chance that someone is passing by that has a random item for trade. This person will request some random item and amount in exchange). If implementing the multiplayer extra credit, you could try and trade with another human player.
9. View the current date, the total miles traveled, the pace, the ration and heath of the leader.
10. Hunt for food. For basic credit, you are not required to implement the hunting game, so just give a random change to kill some quantity of food and use up some amount of ammunition. If you are not a farmer, you must have ammunition to hunt. Farmers may forage for food.

If at a location with a store, the player should be able to enter the store and buy items.

River Crossings

When you reach a major river location, you must do one of 3 things to cross

1. Take Ferry - If a ferry is available, you can take it for a fee of 25-50 dollars. This is safe and no bad things can happen (other than the money)
2. Ford - You try to pull wagon across. Only works if water depth < 3 feet. Even then there is a chance of the wagon flip event.
3. Chaulk - You plug up the holes and try to float across like a boat. Chance of a wagon flip is higher.

Locations

You are not required to replicate these exactly, but the original game had the following locations

Extra Credit:

• Database back end
• Multiple Concurrent Players (have a wagon train rather than individual wagon)
• More extensive graphics and interactive play
• Implement the hunting game
• Implement the river crossing game (like frogger)
• Create a more intense/realistic simulation. Weather, grass for oxen, water, etc.
• Add additional random events
• Create more items (that have some interaction with the simulation). For instance, you might have trade goods that can be used to barter with First Nations folks for food or other supplies.
• Allow different start dates like the original game and factor in weather effects.

M3 Requirements

• Create team page and indicate your team members. (PLEASE DO THIS AS SOON AS POSSIBLE)
• A brainstormed list of Domain classes
• A list of candidate classes after filtering
• A set of CRC cards for the candidate classes. Cards should be filled out on both sides (role stereotypes and responsibilities/purpose). These should real index cards, not a word document.
• A set of scenarios that cover typical uses of system and exercise the CRC Cards. The number of scenarios is left to you, but they should cover the major uses of the system.
• Meet with assigned TA to discuss your design and get corrections.

Grading Criteria

• Brainstormed Classes................................. 10
• CRC Cards............................................... 30
• Scenarios................................................ 20
• Role Stereotypes, Purpose and Responsibilities …10
• Team page setup...................................... 10
• TA Meeting.............................................. 20

You will continue your design by moving from the Domain-level model to the actual application design.

M5 Requirements

• Create your Software Architecture and Trust Boundaries
• Identify your Application and Utility Objects (those new objects specifically developed for the design. You do not have to say which are which, just id the ones that were added from the domain analysis) This should be easy, as all classes that were not identified with a CRC card will be in this category. You can annotate them on the class diagram, or you can list them separately.
• Add necessary CRC Cards and any new scenarios needed (for newly discovered domain classes if any). If you have no new classes, and nothing to fix from your TA meeting, then you may not have anything for this point. In that case you will receive the points for "free" as a reward for doing a good job the first time.
• Submit a UML Class diagram of your refined design (shows all domain and application/utility objects)
• Submit 2 UML Sequence diagrams that shows your full design handling one or more scenarios. You should make your scenarios interesting so these diagrams help you.
• Submit screen mockups that show your preliminary user interface. These screens can either be hand-drawn, or prototyped with the VW Painter and then captured.
• Submit a written contract (1 per person on the team) for an object or method in the design
• Submit a short paragraph on your error handling and exception handling design strategy.

Although not required, it is recommended you have begun some implementation of basic Domain Model objects.

Criteria Breakdown:

• Architecture/Trust Boundaries.............. 10
• Application/Utility Class Identification .....10
• Updated CRC Cards...............................5
• Updated Scenarios................................5
• UML Class Diagram...............................20
• UML Sequence Diagrams.......................20
• User Interface Screen Prototypes...........15
• Contract .......................................... 10
• Exception Handling Strategy ................ 5

Domain Coding

In M6, you will implement the Basic Domain Objects. You should also start some of the UI screens necessary to populate that model. You may also use SUnit to populate some of the model. You should have basic load/store functionality for the model. (Now you see why we recommended you get a head start in M5). If you are doing a variation of the original theme, then just substitute as appropriate (space ship for wagon, etc).

M6 Requirements

• Implement Domain Objects
• Create SUnit tests to unit test your core Domain Objects (you do not need to write tests for trivial accessor/modifier methods or for gui-specific methods)

The TA's will not type anything in the workspace except XXXAppModel open. Or TestRunner open. You have to have code written for them to test your application.

Criteria Breakdown:

• Wagon Configuration to start Simulation................................................05
• Wagon Move changes location and consumes supplies based on configuration............05
• Random Events occur occasionally during move..........................................10
• Simulation ends when appropriate..................................................05
• Simulation can be saved ......................................................................10
• Saved Simulation can be loaded ............................................................10
• Professions influence game (starting money and events)..............................10
• Items can be purchased in stores and inventory updated.............................05
• Wagon max weight constraint enforced.................................................05
• Wagon pace ..........................................05
• Rations .................................................05
• River Crossing ........................................05
• SUnit Tests ...........................................................................10
• Good Smalltalk comments, code and style....................................10

Do your best to get as much done as possible for the milestones. If you make a valid effort to complete this milestone, you may demo missing functionality later in the class without penalty.

Be sure to have the abilility to demo functionality to the TA. We do not code read for credit. You only get credit for features that are executing either from SUnit tests (preferred) or from a gui mockup.

M7 Complete Implementation with UI

We saved the best for last (well, almost last). Now code the remainder of the graphical UI portion. All the M6 functionality should now be available through a user interface.

Criteria

• Wagon Configuration Screens (setup, loading, setting pace etc).....................10
• View Inventory and People ..........................................05
• Taking a turn (move) ............................................10
• Map/Location View ............................................ ...............15
• Rest/Stop View ................................................................05
• Trade Windows .................................................................05
• Game Status (current date, miles traveled, etc) ................................. 05
• Ability to exercise admin functions (load/save, start/stop, end) ..... 05
• Hunting screen (does not have to be game for basic credit) ..... 05
• River Crossing (options for crossing) .............. 05
• Random Event Displays ................... 10
• SUnit tests (for any non-gui classes added)..............................10
• Good Smalltalk code and style.................................................10

TA/Instructor Discression extra credit awesome graphics/ui concept ..10

M8 User Interface Evaluation

You have put in a lot of effort designing and implementing your project. This project milestone will have you focus on uncovering significant usability problems with your prototype and suggesting ways to improve upon it.

But there is a little bit of twist in this assignment. You are going to do a usability evaluation of another project team's prototype and report back to them. And when you receive the usability evaluation from the other team, we are going to ask you to reflect on how significant a design and implementation change would be required to address any problems uncovered.

Meet the other team

Your team will conduct a usability evaluation of another team's prototype. The team assignments are posted here:

You should make every effort to meet up with the team you are evaluating during the Milestone 6 presentations.

Passing-on / Getting code

It is essential that you get your code to the team that will be evaluating your project by Monday November 10th. . Contact the team you are evaluating ASAP to get their code. Ideally, a person from that team should meet with a person from your team and (1) get you the Visualworks image / fileout / Store parcel, (2) make sure that you know how to use it, and (3) answer some of your questions. This is advantageous to the other team as the higher quality your understanding is, the more likely it is your evaluation will be informed. A more informed evaluation leads to a better rebuttal. Teams that do not pass on their code to their evaluating team before or on Wednesday, November 12th, may get a 0 for the M7 assignment.

If you never got anything to work, pass to the other team UI mockups, or drawings that they can use to evaluate your UI conception. Remember this a usability evaluation, not a functionality one.

To complete this milestone, you must form a usability evaluation plan, execute it, submit a usability report to the team whose prototype you evaluated, and then react to the usability report you receive on your own project.

Plan your usability evaluation (10 points)

In lecture, you have been introduced to three different usability evaluation techniques: heuristic evaluation, cognitive walkthrough and think aloud protocol analysis. You are asked in this milestone to select one of these evaluation techniques and justify why you feel it would be appropriate to evaluate the prototype from the other team. You then need to make sure that you have prepared all of the required inputs to conduct the usability evaluation. This section should clearly indicate which method you chose, why you chose it and what you hope to learn from it. You should also detail any preparations (ratings scales, criteria) that developed for the evaluation.

Execute the plan (30 points)

Your team needs to conduct the usability evaluation that you defined in your plan and present the raw results in (e.g., the usability bug reports from h.e., the believability story for one or more canonical tasks for cognitive walkthrough, the transcript and observations done for the think aloud) in a form that can be understood by the instructor and TA. These results need to be produced in written format, so be sure to plan your evaluation in such as way as to make it easy to collect these results and share them. This section has all the details for your plan execution. This section has to convince me that you actually carried out the plan. You should include the raw data, any checklists and other information, and a discussion of the results as deliberated by your team.

Usability Report (30 points)

You need to write a report of your usability findings that will be submitted to the instructor as well as the team whose prototype you evaluated. This report should be no longer than 3 printed pages and should clearly highlight and explain the top 3 or 4 recommendations for altering the prototype to enhance its usability. You are writing this report for the design team to read and react to, so make sure you are clear and constructive in your comments so that they understand what you are asking them to change and why. If there are some things that were particularly good, you can mention them also. Don't be afraid to be honest. Your evaluation has no effect on their grade -- regardless of whether their UI is magnificent or horrible.

These first three parts of the milestone are due Friday, November 19th to be turned in in-class in hard-copy. You must also provide a copy of the 3-page Usability Report to the team whose prototype you evaluated. This is to facilitate the final part of the project. Please be sure you get the other team the report in a timely manner.

Response (30 points)

We are not asking the design teams to do any additional implementations to the project. Instead, we are asking you to read the report from the evaluation team and respond to the way you would modify your design and implementation to accommodate the recommended changes. This report should be no longer than 3 pages and should focus on explaining how you would adapt your prototype. We also want you to reflect on whether the object-oriented approach to your design makes it easier or more difficult to make the recommended changes. Please do not be defensive. Your grade is not based on how bad the UI faults were, it is based on your corrective action proposals. Don't try to convince me there are no problems with your UI and the other team was just stupid. Instead detail what you would fix and what changes to the design would be required. Remember this is a design class, so be sure and discuss the impact of your design on the ease of incorporating the changes requested.

Checklist of Things to Complete

You are responsible for turning in two separate reports:

• Report 1: 70 points, due Wednesday, November 19th (by midnite to Bob's Office)

1. (10 points) Clearly identify the team whose prototype you evaluated and provide a one-page description of your evaluation plan and the rationale behind the plan, i.e., why you chose to conduct that evaluation on this prototype.
2. (30 points) Results of execution of usability plan, providing clearly documented printed evidence that you conducted the evaluation plan correctly. For instance, this includes the actual raw data sheets and evaluator notes in addition to the synthesized data. I need to verify you did the evaluation you claimed to do.
3. (30 points) 3-page usability report highlighting the three top concerns arising from the usability evaluation. The report should identify clearly what each usability concern is and the evidence you have to support this problem being a real problem that should be corrected by the design team. One copy of this part of the report goes to Bob, and one copy should be given to the team you evaluated.

• Report 2: 30 points, due Wednesday, November 25th (in class)

1. 3-page response of the usability report submitted to your project team. Be careful not to get defensive in this report (resist refuting that the findings of the evaluation team are incorrect). Make a clear argument for how you would address each usability concern. Assess whether the object-oriented design you developed for your prototype made it any easier to address these usability concerns.

REMEMBER: This is a usability evaluation NOT a functionality evaluation. Don't spend time checking whether the application actually works or not. Focus instead on overall usability of their system using the techniques we discussed in class. You can do a usability evaluation on screen drawings if you have to.

M9 THE TWIST

the big reveal - actually kind of anti-climactic after the hints and announced lecture on web design, but here it is:

Place a web front-end on your application.

Obviously, we are not requiring you to reimplement the entire application with a web front end. Instead, you will demonstrate the ability of your application to be adapted to a web application.

Your application must demonstrate the following features:

• Use of a style sheet (css) to standardize look and feel
• Use of query strings (?msg=111) to communicate information between the browser and web server
• Use of session variables to maintain state between server calls
• Static and Dynamic Web Pages
• Use of forms to transmit data to the web page
• Use of html include files for common data
• Embedded smalltalk code (.ssp)

You do NOT have to have any graphics output. Web pages can be all text. If your application does not demonstrate the above features after implementing the basic requirements below, then you must add additional features that will allow you to demonstrate those basic requirements if you want full credit.

Required Features

• Display a welcome screen and allow input of a leader name
• If name > 6 characters, allow the wagon to be configured as below, otherwise reprompt for leader name with error message
• Configure the wagon by setting the pace, ration, and chosing a profession.
• Display back a game status showing that your game has accepted the input parameters
• Any additional gameplay functionality (buying items etc) would be extra credit for M9.

Grading Criteria

Basic Requirements (30)

• use of style sheet ............... 5
• query strings ...................... 5
• session vars ....................... 5
• dynamic web page................ 5
• html forms........................... 5
• include files ........................ 5

Design (15)

• Basic Site Map .....................5
• Flowchart ...........................5
• Wireframe ...........................5

Specific Feature Requirements (50)

• Display welcome screen and display leader name form ............................................. 10
• Leader Name length check and error message for name too short .............................. 10
• Wagon Configuration Screen with form controls ..................................................... 15
• Game Status screen showing web interface actually talking to smalltalk app................ 15

Coding Style and comments (5)

Link to this Page

• Team Menfinity last edited on 11 December 2008 at 5:49 am by r59h146.res.gatech.edu