JAMS Participant Materials

Welcome to the JAMS workshop! This document contains useful reference information for the workshop, including schedule, team assignment, and team evaluation criteria. This document, as well as all of the PowerPoint presentations that will be used throughout the week, may be found at

Contents of this packet:

Schedule......

Version 1 – assuming Eid falls on Friday, 10 September......

Version 2 – assuming Eid falls on Thursday, 9 September......

Team Assignment......

Project Description......

Deliverables & Due Dates......

Evaluation......

Document Templates......

Samples......

Functional Specification......

Overview......

Goals and Non-Goals......

Goals......

Non-Goals......

Scenarios......

Functional Design......

User Interface......

Game Play......

Player Management......

Game Statistics......

Computer Player......

Security......

Implementation Plan......

Deployment Plan......

Implementation Details......

Namespace......

Gameboard......

Player......

Game......

Open Issues......

Test Plan......

Test Plan Objectives......

Scope......

Features to be tested......

Features NOT to be tested......

Test Strategy......

Test Cases......

Feature 1: Alternate between Players......

Feature 2: Validate Basic Moves (legal moves only)......

Feature 3: Declare the Winner or a Tie......

Feature 4: Statistics Table......

Feature 5: Play Timer......

Feature 6: Machine Player......

Open Issues......

Schedule

Version 1 – assuming Eid falls on Friday, 10 September

Monday, September 6 / Tuesday, September 7 / Wednesday, September 8 / Thursday, September 9 / Friday, September 10
9:00 / Introduction: Expectations for the Week, Software Lifecycle(Kenny Wolf & Lauren Lavoie) / Morning Session: Project Management (Lauren Lavoie) / Morning Session: AppLab & Community Knowledge Worker (Luke Kyohere) / Group Work Session / Holiday
9:30
10:00 / Writing Functional Specifications (Kenny Wolf) / Group Work Session / Group Work Session
10:30
11:00 / Test-Driven Development (Lauren Lavoie)
11:30
12:00 / Object-Oriented Design (Kenny Wolf)
12:30
1:00 / Lunch Break
1:30 / Facilitator Office Hours / Facilitator Office Hours / Facilitator Office Hours
2:00 / Introduction to the group activity (Kenny Wolf & Lauren Lavoie)
2:30
3:00 / Initial group work session: setup, assign roles, start working
3:30
4:00
4:30
5:00 / Team Presentations (15 x 8 minutes each)
Awards
5:30
6:00
6:30
7:00
8:00

Version 2 – assuming Eid falls on Thursday, 9 September

Monday, September 6 / Tuesday, September 7 / Wednesday, September 8 / Thursday, September 9 / Friday, September 10
9:00 / Introduction: Expectations for the Week, Software Lifecycle(Kenny Wolf & Lauren Lavoie) / Morning Session: Project Management (Lauren Lavoie) / Morning Session: AppLab & Community Knowledge Worker (Luke Kyohere) / Holiday / Facilitator Office Hours / Team Presentations (15 x 8 minutes each)
Awards
9:30
10:00 / Writing Functional Specifications (Kenny Wolf) / Group Work Session / Group Work Session
10:30
11:00 / Test-Driven Development (Lauren Lavoie)
11:30
12:00 / Object-Oriented Design (Kenny Wolf)
12:30
1:00 / Lunch Break
1:30 / Facilitator Office Hours / Facilitator Office Hours
2:00 / Introduction to the group activity (Kenny Wolf & Lauren Lavoie)
2:30
3:00 / Initial group work session: setup, assign roles, start working
3:30
4:00
4:30
5:00
5:30

Team Assignment

Project Description

Implement a computer game version of your favorite board or card game
For example: Checkers, Omweso, Boggle, Hearts, Blackjack, Othello, Scrabble, Yahtzee
The game must have at least two players
The game must have a basic visualization
The program must implement the rules of the game being implemented
Only allow valid “moves”
Keep score if appropriate
Determine the winner and end the game
There are a number of optional enhancements that will help improve your score, such as:
Networked play
Computer player
Use whatever technology you want
All of our examples have been in Java and VB
You are welcome to implement your game as a website or a desktop application
The machines in the lab are pre-installed with:
JCreator, Eclipse (Java)
Visual Studio (Visual Basic, C#, ASP.NET)
WAMP Server
Dreamweaver
You are required to implement some visual representation of the game
In order to meet the baseline requirements, the visuals need not be sophisticated
A range of options exist for visual representation:
HTML
.Net Winforms (Visual Basic or C#)
Java Swing
Console UI (ASCII art)

Deliverables & Due Dates

Item / Description / Due Date
Functional Specification / A functional specification describing the application to be built, based on the provided template. You will be judged on how well your final application adheres to the spec. / Tuesday afternoon
Test Plan / A test plan describing the application’s success criteria and defining the individual test cases to be built, based on the provided template. You will be judged on how well you implement the test plan, and your project will not be considered successful if your tests do not pass. / Tuesday afternoon
Demo of Partial Application / Sometime before the end of Wednesday, show a demo of your partially-completed application to one of the workshop facilitators in order to receive credit for this deliverable. / Wednesday afternoon
Demo of Working Test Cases / Sometime before the end of Wednesday, show a demo of your in-progress, passing test cases to one of the workshop facilitators in order to receive credit for this deliverable. / Wednesday afternoon
Presentation & Demo for All Participants / Presentation to your peers on the final day of the workshop, including a demo of your application and tests. A PowerPoint template will be provided. / Thursday or Friday (TBD based on Eid)

Evaluation

All projects will be evaluation by JAMS facilitators. There are two components to evaluation:

Baseline criteria. These criteria are required to completed by all teams, and comprise the baseline score. Up to 100 points may be earned for satisfying the baseline criteria.
Optional criteria. These criteria are optional, and will allow teams to differentiate themselves by implementing more advanced features. They should only be attempted by teams who are confident that they will satisfy all of the baseline criteria. Teams may earn bonus points by implementing the optional criteria, as a percentage of their baseline score.

Baseline Criteria: Required / Max Points / Additional Criteria: Optional / Max Bonus
Functional specification / 15 / Application has relatively complex rules/game play / 20%
Test Plan / 15 / Application has sophisticated graphics/UI / 30%
Application compiles & runs / 10 / Application implements a computer player (max points awarded only for a very “smart” AI implementation) / 30%
Application adheres to the spec, and implements the rules of the game, including scoring (if appropriate) and ending the game / 25 / Networked game play / 20%
Demo of working test cases for facilitators / 20 / Other cool features / 30%
Presentation & demo for workshop attendees / 15

Document Templates

You may download templates from the following locations:

Functional Specification Template
Test Plan Template
Application Presentation & Demo Template

Samples

Functional Specification

The following is a sample functional specification for a Tic-Tac-Toe game.

Overview

Tic-tac-toe is a game for two players, X and O, who alternate marking spaces in a 3x3 grid with their symbol. The player who successfully places a set of three marks in a horizontal, vertical, or diagonal row wins the game. If no player can create a horizontal, vertical, or diagonal row then the game is a draw. Player X goes first. As it has a simple set of rules, tic tac toe provides leisure entertainment for people of all ages.

Goals and Non-Goals

Goals

[P1] Support two human players in a game that is run as a client application
[P1] Use a graphical representation of the players and game board
[P1] Alternating turns between the players starting with X
[P1] Declare a winner when a player has successfully placed three marks in a row
[P1] Declare a tie when no player can make a winning move
[P1] Support for starting a new game after the initial game has completed
[P2] Allow the game to be run inside a web-browser
[P2] Use multi-colored graphics in the game visuals
[P2] Support custom player names
[P2] Tabulate, store, and display statistics on players’ performance
[P2] Support menu-based commands for new game and quit
[P3] Add a timer to limit the amount of time a player is allowed to spend on a turn
[P3] Allow for the two players to be on separate machines and play through the network
[P3] All the user to save in-progress games
[P3] Have one player be a computer-based (AI) player
[P3] Allow player O to start a game

Non-Goals

Support for any grids larger than 3x3
Support for non-grid shaped game boards
Animation of game play

Scenarios

Richard has an afternoon free. He calls up his friend Joseph and invites him over to play tic-tac-toe. Richard launches tic-tac-toe and a 3x3 grid appears on the screen. They play a game, Joseph connects three Os on the right-most column and is declared the winner.

Lydia has tic-tac-toe installed on her machine and wants to know how many games she has won so far. She launches tic-tac-toe, chooses Player Performance, and enters her name into the edit box. The system tells her that she has won 32 games so far, lost 2 games and tied 19 games.

Functional Design

User Interface

Main Window

The UI for tic-tac-toe is a Windows Form that consists of line and button controls arranged in a 3 x 3 grid:

Players alternatively interact with the grid by clicking on an available button. A label on the upper-left corner identifies the current player that needs to make a move.

When a player wins, or no player is able to win, the label is updated with the appropriate game conclusion text.

High Scores

[TODO: insert screenshot of side pane that shows top-10 scores + timer]

Menus

File->New Game…

At any point, a user can select this optionto start a new game. If a game is in progress, then a dialog will appear to confirm that they want to abandon their current game.

File->Exit

At any point, a user can select this optionto exit the application. If a game is in progress, then a dialog will appear to confirm that they want to abandon their current game.

Game Play

Game play for tic-tac-toe should conform to the following flowchart:

Ending the Game

The game will conclude in one of two ways:

A player completes a row of three squares with their mark – that player is declared the winner.
There are no possible ways for either player to create a row of three squares with their mark – the game is declared a tie.

On conclusion of the game, the UI is updated.

[TODO: add screenshot of game ending]

Player Management

[TODO: Add details about player names, preferences, etc.]

Game Statistics

At the conclusion of each game, tic-tac-toe records the following information:

Start and end time of the game
Which player’s icon (X or O) won the game
A win or loss for each player involved in the game

With this information, tic-tac-toe displays the top players and other statistics about the game.
stores information about how many games each player wins and loses. It also stores information about how many games have been won overall by X or O.

Storage Format

In order to report on high scores, player statistics, and game statistics, a log of the results for all games that are played are stored on disk in the following format:

<?xml version="1.0"?>

<GameHistory xmlns="

</PlayerStatistics>

</GameStatistics>

</GameHistory>

While using a database with Player and Game tables would allow for richer data management and queries, as well as avoid redundancy in the above XML format, we have prioritized installation simplicity and do not want to require a database to be available for playing tic-tac-toe.

Computer Player

If we have time to implement a computer player, we will need to calculate a game tree based on the status of the game after each move. The game tree tracks the possible legal moves and whether they are favorable for the computer player or not.

The most straightforward algorithm to calculate our next move is minimax.

Security

Priority / Security Concern / Mitigation
2 / If we decide to implement a web-based version of the game, then we need to account for denial of service attacks. / Add encryption (https) and HTTP authentication

Implementation Plan

To implement tic-tac-toe in such a way as to address the goals in priority order, the game will be implemented in the following phases:

Gameboard and game-play logic
UI design and visuals for gameboard, players, and winner notifications
Hooking up the UI gestures to the game-play logic
Advanced features, such as customized player names, timing moves, and showing high scores

Deployment Plan

Tic-tac-toe will be packaged as a single Windows executable. There are no features that require special setup tasks.

Implementation Details

Internally, tic-tac-toe has a few major concepts that we represent through objects. These include the game board, players, and games.

Namespace

All of the classes in our implementation will use a namespace of Jams.Samples.TicTacToe

Gameboard

[TODO: insert details on Gameboard object]

Player

[TODO: insert details on Player object]

Game

[TODO: insert details on Game object]

Open Issues

Should we use Windows Forms or WPF for the UI?
Should we secure the high-score file, or at least obfuscate it?

Test Plan

The following is a sample test plan for the Tic-Tac-Toe game specified above.

Test Plan Objectives

[P1] Test functional correctness of the game’s underlying methods using white-box unit testing
[P1] Test that only valid moves are allowed
[P1] Validate that the game can correctly switch between players and declare the end of the game
[P2] Test advanced features, like the statistics table, play timer, and computer player, if implemented
[P3] Performance testing

Scope

Features to be tested

Basic game play
The game alternates between players
Players can place moves
Only legal moves are allowed
Ending the game
The game can declare a winner
The game can declare a tie
Player statistics table (if implemented)
Timer (if implemented)
Machine player (if implemented)

Features NOT to be tested

User interface rendering
Networked play

Test Strategy

We plan to employ mostly white-box unit tests in order to test the application, using Visual Studio’s built-in unit-testing framework. Each of the following major classes will have at least one unit test:

Game
GameBoard
Player
GameStatistics

Test Cases

Feature 1: Alternate between Players

Test Case ID / Test Case Name / Steps / Expected Result
1.1 / Test basic play switching /

Place an X at TopLeft
Assert that it is now O’s turn
Place an O at Center
Assert that it is now X’s turn

/ The game control switches to the next player after each turn (assertions pass)

Feature 2: Validate Basic Moves (legal moves only)

Test Case ID / Test Case Name / Steps / Expected Result
2.1 / Test basic moves /

Place an X at TopLeft
Assert that the board records an X at TopLeft
Place an O at Center
Assert that the board records an O at Center

/ Markers are present at expected positions (assertions pass)
2.2 / Disallow player from placing his marker on a square occupied by his opponent /

Place an X at TopLeft
Place an O at TopLeft

/ Move 2 fails
2.3 / Disallow player from playing on his own occupied square /

Place an X at TopRight
Place an O at Center
Place an X at TopRight

/ Move 3 fails

Feature 3: Declare the Winner or a Tie

Test Case ID / Test Case Name / Steps / Expected Result
3.1 / Declare winner for a horizontal win /

Place an X at TopLeft
Place an O at Center
Place an X at TopRight
Place an O at BottomLeft
Place an X at TopCenter

/ X is declared the winner
3.2 / Declare winner for a vertical win /

Place an X at Center
Place an O at TopRight
Place an X at BottomLeft
Place an O at BottomRight
Place an X at TopLeft
Place an O at MiddleRight

/ O is declared the winner
3.3 / Declare winner for a diagonal win /

Place an X at Center
Place an O at TopRight
Place an X at TopLeft
Place an O at MiddleLeft
Place an X at BottomRight

/ X is declared the winner
3.4 / Declare a draw when no player can win the game /

Place an X at TopLeft
Place an O at TopCenter
Place an X at TopRight
Place an O at MiddleLeft
Place an X at MiddleRight
Place an O at Center
Place an X at BottomLeft
Place an O at BottomRight

/ The game is declared a draw

Feature 4: Statistics Table

Test Case ID / Test Case Name / Steps / Expected Result
4.1 / Update player statistics after a completed game /

Start game with two players, ‘Joseph’ (X) and ‘Richard’ (O)
Play a series of moves such that Richard wins the game
Check that the statistics table shows Wins incremented by 1 for Richard, and Losses incremented by 1 for Joseph

/ Statistics log has updated win/loss counts for Richard and Joseph
4.2 / Update game statistics after a completed game /

Start game with two players, and record the time that the game started
Play a series of random moves until someone wins
Record the time that the game finished and the winner
Check that a new Game has been added to the game log, with the correct start time, end time, and winner

/ Statistics log shows a new entry for this game, with the correct information

Feature 5: Play Timer

Test Case ID / Test Case Name / Steps / Expected Result
5.1 / Player runs out of time /

Place an X at Center
On O’s turn, sleep(maxTurnTime)

/ X is declared the winner

Feature 6: Machine Player

Test Case ID / Test Case Name / Steps / Expected Result
6.1 / Machine player will block human player’s win /

Place an X at Center
Machine player places an O
Place an X on a square that will give the human player two X’s in a line that does not already contain an O
Machine player places an O
Assert that the O placed on step 4 blocks X’s win

/ Machine players blocks X’s win
6.2 / Machine player goes first /

Machine player places an X
Assert that there is an X in the center square

/ Machine player plays in the Center

Open Issues