R I S K

paltryboarpigSoftware and s/w Development

Nov 3, 2013 (3 years and 8 months ago)

43 views





















R

I

S

K



























Ariagno . Barakat . Parkinson . Smittkamp . Taljanovic . Tran




1


Table of Contents

1. Introduction

................................
................................
................................
................................
..............

3

1.1. UIUC Risk

................................
................................
................................
................................
...........

3

1.2. The Team

................................
................................
................................
................................
...........

4

2. The Process

................................
................................
................................
................................
...............

6

3. Requirements and Specifications

................................
................................
................................
............

7

3.1. Storefront

................................
................................
................................
................................
..............

7

3.2. Board

................................
................................
................................
................................
.................

8

3.3. Status Panel

................................
................................
................................
................................
.....

1
0

3.4. Territories

................................
................................
................................
................................
........

10

3.5. Armies

................................
................................
................................
................................
..............

10

3.6. Production

................................
................................
................................
................................
.......

10

3.7. Turns

................................
................................
................................
................................
................

10

3.8. Attacking

................................
................................
................................
................................
..........

10

3.9. Fortifying

................................
................................
................................
................................
.........

12

3.10. Mini
-
Challenges

................................
................................
................................
.............................

12

3.10.1. Equations

................................
................................
................................
................................

12

3.10.2 Five Different Shapes

................................
................................
................................
..............

13

3.10.3. Hit When White

................................
................................
................................
......................

14

3.10.4 Shrinking Circle

................................
................................
................................
........................

14

3.10.5 Word Matches Color

................................
................................
................................
...............

15

3.11. Winning and Losing

................................
................................
................................
.......................

16

4. Architecture and Design

................................
................................
................................
.........................

17

4.1. Metaphor

................................
................................
................................
................................
.........

17

4.2. Model
-
View
-
Controller Architecture

................................
................................
..............................

17

4.3. Class Diagrams

................................
................................
................................
................................
.

18

4.3.1. Model and
Controller Class Diagram

................................
................................
.......................

18

4.3.2. View Class Diagram

................................
................................
................................
..................

19

4.3.3. Additional Maps

................................
................................
................................
.......................

23

4.3.4. Sequence Diagrams

................................
................................
................................
..................

25

4.3.5. Test Case Design

................................
................................
................................
.......................

27

4.3.6. Third
-
Party Libraries

................................
................................
................................
.................

28


2


5. Afterthoughts

................................
................................
................................
................................
.........

29

5.1. Future
Plans

................................
................................
................................
................................
.....

29

5.2. Personal Reflections

................................
................................
................................
........................

29

5.2.1. Ariagno, Christopher

................................
................................
................................
................

29

5.2.2. Barakat, Ashraf

................................
................................
................................
.........................

29

5.2.3.

Parkinson, David
................................
................................
................................
.......................

30

5.2.4. Smittkamp, James

................................
................................
................................
....................

30

5.2.5. Taljanovic, Nedzad

................................
................................
................................
...................

30

5.2.6. Tran, Dewey
................................
................................
................................
..............................

31

Appendix A
-

Installing and Running from Eclipse

................................
................................
....................

32

Appendix B
-

Installing and Running from JAR File.

................................
................................
..................

33

Appendix C
-

Rules

................................
................................
................................
................................
......

34





3


1. Introduction


1.1
.

UIUC Risk


UIUC Risk is a turn
-
based computer game inspired by the classic Hasbro board game Risk and a 1996
freeware program Risk and Guard. The game is played by two
to five players. The players compete to
conquer all territories on the board map. UIUC Risk includes the same board map as the Hasbro board
game, as well as three other playable board maps. Additional board maps can easily be added. At the
start of the gam
e players are randomly assigned territories on the board map. A territory is painted in
the player

s color to indicate ownership. Above each territory is a box that displays the production
-
per
-
round, as well as the number of armies in the territory.


Production per round
Number of armies


Figure
1
-
1.

Main board
.


During a turn, the player may attack neighboring territories. An attack is a series of battles. In each
battle, a calculated number of armies are at stake. The attacking player and the owner of the defe
nding
territory engage in a mini
-
challenge to determine the winner of the battle. The mini
-
challenges are
reactionary games where players buzz
in when a certain condition is met. UIUC Risk includes five mini
-
challenge games. Additional mini
-
challenges can

easily be added. For each battle, a random mini
-
challenge is chosen to determine the winner. After a battle, the attacker may cho
o
se to stop or to

4


continue attacking. If the defending territory loses the last of its armies in a battle, the ownership of th
at
territory changes to the attacker.


Armies at stake
Attacking territory and army count
Defending territory and army count
Armies at stake


Figure
1
-
2
.

Battling within a Mini
-
challenge
.


The active player may also choose to fortify once during a turn. Fortifying is the process of moving
armies from one territory to another
adjacent territory. When the active player ends his/her turn, the
control is passed to the next player. When all players have ended their turns, the current round ends
and a new round begins. At the end of each round, every territory increases its army cou
nt by its
production
-
per
-
round value. When a player loses ownership of all his/her territories, that player is out
of the game and does not participate in subsequent rounds. Once one player acquires all territories on
the board
-
map, he/she is declared the
winner and the game ends.


1.2
.

The Team


We are online students in CS 428 at the University of Illinois
at
Urbana
-
Champaign. Our team is
distributed across the full span of the U.S.; from Washington State to Florida. During the day, we are all
full
-
time p
rofessionals. To work on this project, we met over Skype and TeamViewer. The team is
comprised of the following members:




5


Christopher Ariagno


cariagno@illinois.edu

Ashraf Barakat


barakat2@illinois.edu

David Parkinson


parkins2@illinois.edu

James Smit
tkamp


smittkmp@illinois.edu

Nedzad Taljanovic


taljano1@illinois.edu

Dewey Tran


duytran1@illinois.edu




6


2. The Process


The UIUC Risk team is comprised of six members. Meetings were held twice a week and conducted using
Skype.
The group followed a
modified XP process. Dev
elopment was done in iterations, each lasting
about two weeks. For each iteration, the team:


1.

c
reated and separated user stories into tasks, and estimated completion times

2.

r
otated programming pairs and assigned tasks

3.

w
rote code in p
airs or individually, creating
tests and refactoring
as
applicable

4.

reviewed progress at
semi
-
weekly team meetings


Communication was further facilitated through the use of email and wiki pages. A milestone meeting
was held at the end of each iteration and
included both the team and Steve, the CS 428 TA working with
the group. The milestone meetings were conducted using Skype and the desktop sharing software Team
Viewer. The milestone meetings utilized MARS roles and involved:


1.

review and demonstration of ne
w functionality, code, and tests

2.

discussion of plans for the following iteration

3.

feedback from Steve regarding project progress


All team members wrote code and participated in each milestone meeting.


The team wrote the system in

i
n Java and Swing, using JUnit
3.x
for automating testing.
The team
created the
game
maps
using the

Scalable Vector Graphics (SVG) format and edited

the map

with
Inkscape.
The team used
Eclipse
as the development environment,
and

used
Subversion
for

version
control. Programming was done in pairs or individually. At the end of each iteration, task completion
times were reviewed in relation to estimate versus actual. This information fed into the estimation
development process for

the
succeeding
iteration.


Coding standards were established and agreed to. Pages were created on the team wiki to document
the progress of the project. These included notes from each meeting, taken by the person designated as
scribe. To achieve adequate
test coverage of components for which it was difficult to utilize JUnit
automation, such as for the GUI, manual tests were written and executed. The team adhered to the
concept of collective code ownership, and thus refactoring was performed by anyone to a
ny code if that
person deemed it appropriate.


After Milestone 4, the team split into two groups and held a formal review. This consisted of:


1.

sections of code were identified and provided by each group to the other

2.

each group reviewed the section of code
provided to it by the other group

3.

issues were communicated at a review meeting held for each group

4.

suggestions were evaluated and code was modified to address issues


Near the end of the project, known bugs were addressed and correct functionality was veri
fied. Code
was reviewed regarding adherence to standards, adequacy of comments, and completeness of test
coverage. Finally, project documentation was assembled.





7


3. Requirements and Specifications


3.1. Storefront


Also known as the main menu, the storefront (shown in Figure
3
-
1
) is the first screen shown upon
startup of Risk. The storefront is where the number of players is selected and which colors are used to
represent the players. There are five (5) different pla
yer colors to choose from: Red, Blue, Green, Yellow,
and Purple. The storefront will not allow the game to begin until two (2) or more players have been
selected to play. The
Start Game

button will be disabled and grayed to signify that the game cannot be
started. Players decide, beforehand, which color belongs to which player.


Among selecting players, the storefront allows the selection of the map to play on. By default, the
regular Risk map will be selected. Alongside the original Risk map, available map
s to select include
Arizona (US state), Europe, and Yugoslavia. To begin the game, the
Start Game

button must be pressed.




Figure 3
-
1.

Storefront.





8


3.2.

Board


Shown when the game is started, the board screen is the main screen for which the game is to be
played. Each territory will be colored with the color of its owner to show ownership. Neutral territories
that cannot be controlled will be the color of gray. T
he board interacts with the mouse and its click.
Territories will become highlighted on hover and will become darkened on clicks. Each territory will have
a corresponding pair of displayed number to signify, from left to right, the number of armies occupyi
ng
the territory and the production rate for the territory. Because of varying sizes of territories, some
territories may be as small as its statistical representation (army count and production rate). Due to this
problem, the board will treat the statisti
cal representation
as transparent to the mouse. In other words,
if the statistical representation box is located on top of a territory, hovering over the box with the
mouse will be treated as if the box was not there and will be like
hovering over a non
-
blocked area of
the territory. The board is vector
-
based and is scalable so there can be resizing without quality loss.
When resizing, the board should be scaled while keeping the height and width proportional to each
other.



9




Figure

3
-
2.

Board with Original Risk map and Red, Blue, and Green players.

Also pictured: Status panel (bottom).




10


3.3. Status Panel


Also shown in Figure
3
-
2

is the status panel. Located at the bottom, the status panel keeps track of the
current player's statis
tics (total number of armies, total production rate, and total territories owned).
Also shown is the round number. The font color indicates the current player's turn. The
End Turn

button
will switch to the next player's turn. Details on turns are described

in a later section. The
End Game

button will end the current game and will bring up the storefront to set up another new game. The
status panel will be updated immediately as values change.


3.4. Territories


Each map has a different number of territories
, but in all maps, the territories are distribute
d

as evenly
as possible to players. A player will have at most one (1) more territory than any other player. Territory
to player assignments are random. There are some territories that cannot be controlled.
Such territories
are considered neutral and will be colored gray on the board.


3.5. Armies


Each player starts off with a total of two
-
hundred (200) armies distributed as evenly as possible among
the corresponding player's territories. In other words, a t
erritory will have at most one (1) more army
count than any other territory with the same owner. On the board, the number of armies is shown in
the left box of the pair of boxes on top of each territory.


3.6
.

Production


After production rates are assigned to territories, each player should have the same total production
rate when summed up among all
their
territories. Each territory can have a production rate of either 0,
1, 2, or 3. The rates are skewed so that the chanc
es of getting the rate are 10%, 20%, 35%, and 35%,
respectively. The rates are skewed away from the lower numbers to make the game more interesting. At
the end of each round, the production rate of each territory is added to the number of armies in the
cor
responding territory. On the board, the production rate is shown in the right box of the pair of boxes
on top of each territory.


3.7
.

Turns


The turn order is randomly chosen. This random turn order is enforced throughout the game. A turn is
ended when th
e
End Turn

button is pressed in the status panel. A player is given only one (1) turn per
round during which they can perform actions (attack, fortify, or no action). Once all players have
completed a turn, the cycle repeats and the next round is started.
Players who have zero (0) territories
will be skipped as they are considered players that have already lost.


3.8
.

Attacking


During a player's turn, the player can choose to attack an opponent's territory with a territory that the
player owns. Attacking i
nvolves two and only two territories. In order for the territory to attack, the
territory must have more than one (1) army count. This is because an army has to stay behind to control
the territory. Also, the target territory must belong to another player
and must be a neighbor of the
attacking territory. Army count between the battling territories
is

reduced through a series of battles.

11


Battles are conducted and a winner is determined through mini
-
challenges. The attack screen
,

shown in
Figure
3
-
3,

display
s the snapshot of the armies right before the battle. At the top, the names of the
battling territories are listed. The attacker is on the left and the defender is on the right. In parentheses
is the current army count for the corresponding territory. At t
he bottom of the attack screen, the risk
and reward for the attacker is shown. The number for risk represents the number to be subtracted from
the attacker's army count if the attacker loses. If the attacker wins, either the defender will lose the
specifie
d number of armies or the attacker will gain a territory. The armies at risk between each battle is
calculated by the following formula:


numRisk = Ceiling( Min(attackerArmyCount, defenderArmyCount) / 3.0) )


The loser of the mini
-
challenge will have its
army count reduce
d

by the calculated number at risk. If the
attacking territory reduces the defending territory's army count to zero (0), the owner of the attacking
territory conquers the defending territory and the defending territory's color will change
to that of the
owner of the attacking territory. Right after a conquering of a territory, the winner can choose to fortify
this newly
-
acquired territory with the attacking armies.




Figure 3
-
3.

Attack screen for Brazil attacking North Africa.




12


3.9
.

Fort
ifying


There are two (2) ways to fortify a territory: directly fortifying
a
territor
y

that
the

player controls and
fortifying

a territory

after
it has been acquired from an opponent
. Fortifying of the former requires the
two territories t
o be neighbors an
d under the control of the same player. The source territory must have
at least two (2) armies to be able to fortify another territory since a territory must have at least one (1)
army occupying it at all times. The most number of armies that can transfer
to the destination territory
is n
-
1 where n is the number of armies in the source territory. A player can only perform one (1) fortify
of this
type

(direct fortify) per turn. The fortify screen is shown in Figure
3
-
4
.


The second type of fortification is after a player acquires a territory. The fortify screen (see Figure
3
-
4
)
will appear after a player acquires a new territory from an opponent. After the territory changes
ownership, one (1) army is automatically transfer
red to occupy the territory. The winner can choose to
fortify the new territory with additional armies from the attacking territory. This type of fortify
(offensive fortify) occurs after a player acquires a new territory and not just once per turn. The for
tify
screen will disallow any invalid input that specifies the number of armies to transfer.




Figure 3
-
4.

Fortify screen for Brazil fortifying Peru with 4 armies.


3.10. Mini
-
Challenges


Mini
-
challenges determine the winner of a battle. These
reactionary
-
based games are played by ringing
in with "buzzers". These buzzers are alphanumeric keys on the keyboard. Before the start of each mini
-
challenge, the attacking and defending player are prompted to choose the alphanumeric keys on the
keyboard t
o use as their buzzers. The mini
-
challenge begins when both buzzers are set. The fastest
person to buzz in when a certain condition is met wins and the other player loses. If a player buzzes in
before the condition is met, that player loses and the other p
layer automatically wins.


3.10.1. Equations


The participating players will be shown random mathematical equations. Some equations will be
incorrectly formed with both sides of the equals sign (=) not being equal and some equations will have
both sides of

the equals sign (=) being equivalent, making the equation correct. The first player to buzz
in when the equation is correct wins. Buzzing in during an incorrect equation will result in a loss.





13




Figure 3
-
5.

Equations with winning condition met.


3.10.
2 Five Different Shapes


The participating players will be shown six (6) random shapes. The winning condition for this game is
when five (5) or more shapes are of different types. The first player to buzz in when this condition is met
wins. Buzzing in when

there are not at least five (5) different shapes will result in a loss. The figure below
(Figure
3
-
6
) shows six (6) different shapes: shell, pentagon, square, circle, triangle, and ellipse (non
-
circle).




Figure 3
-
6.

Five Different Shapes with winning
condition met.





14


3.10.3. Hit When White


The participating players will be first shown a black screen. After a random time period, the screen will
turn white. The winning condition for this mini
-
challenge is when the screen turns white. The first player
t
o buzz in when the screen is white wins. Buzzing in before the white screen shows will result in a loss.




Figure 3
-
7.

Hit When White without winning condition
satisfied
.


3.10.4 Shrinking Circle


The participating players will be first shown a black cir
cle that will keep shrinking until there is nothing
left but a white screen. The winning condition for this mini
-
challenge is when the screen is completely
white. The first player to buzz in when the screen is completely white wins. Buzzing in before this
condition will result in a loss.





15




Figure 3
-
8.

Shrinking Circle without winning condition
satisfied
.


3.10.5 Word Matches Color


The participating players will be first shown a word in a colored font. The winning condition for this mini
-
challenge is
met when word describes its font color. The first player to buzz in when the word correctly
describes its font color wins. Buzzing in before this condition will result in a loss.






Figure 3
-
9.

Word Matches Color without winning condition
satisfied
.





16


3.11. Winning and Losing


For winning and losing mini
-
challenges, see the Mini
-
Challenges section described earlier.


In order for a player to win the game, the player must conquer and own all territories on the board.
Once a player has won, a pop
-
up will
appear to signify the win (see Figure
3
-
10
). When a player does not
own any territories, that player loses and can no longer participate. Player
s

that have lost will be
removed from the turn order. The winner screen will prompt for the players to end the g
ame or begin a
new one. Beginning a new game will bring up the storefront.




Figure 3
-
10.

Red Player
has won

the game.





17


4. Architecture and Design


4.1. Metaphor


Because our application is a computer version (or reasonable facsimile) of the Risk board

game our
metaphor is quite simple: represent the board game. Where our application differs is in the use of
mini
-
challenges to determine the outcome of battles. Instead of rolling dice and using some
probabilistic measure, the outcome of battles is det
ermined by the player who can respond to the mini
-
challenges the fastest.


4.2. Model
-
View
-
Controller Architecture


The Risk architecture follows the Model
-
View
-
Controller pattern. Classes in the project are grouped into
the following five packages:


risk
.controller

risk.model

risk.resource

risk.view

risk.view.minichallenge


Package names clearly designate their roles in the MVC pattern. The
risk.resource

package
contains general utilities for logging, representing colors, configuration definitions, maps
for boards, and
adjacency lists for territories.


Class diagrams for
risk.model
,

risk.controller
, and
risk.view

are below. For each
diagram, getters and setters for private member variables have been left out. Only interesting
additional methods are shown.





18


4.3. Class Diagram
s


4.3.1. Model and Controller
C
lass
D
iagram


+
getListOfPlayers
(
in numberOfPlayers
:
int
)
+
assignTerritory
(
in territory
:
Territory
)
+
ownsTerritory
(
in nodeId
:
string
) :
bool
+
ownsTerritory
(
in territory
:
Territory
) :
bool
+
getTotalProduction
() :
int
+
getNumTerritories
() :
int
+
getTotalArmyCount
() :
int
+
startTurn
()
-
color
-
name
:
string
-
territories
:
Territory
risk
.
model
::
Player
+
getStateString
() :
string
+
transferTerritory
(
in territory
:
Territory
,
in player
:
Player
)
+
fortifyterritory
(
in from
:
Territory
,
in to
:
Territory
,
in amount
:
int
) :
bool
+
produceArmies
()
+
getNumPlayers
() :
int
+
getPlayer
(
in color
:
Color
) :
Player
+
getCurrentPlayer
() :
Player
+
incrementCurrentPlayer
()
+
removePlayer
(
in player
:
Player
)
+
getTerritory
(
in nodeId
:
string
) :
Territory
-
config
:
Config
-
players
:
Player
-
territories
:
Territory
-
currentPlayer
:
Player
-
boardDescriptor
:
BoardDescriptor
risk
.
model
::
Game
+
hasOwner
() :
bool
+
getProductionNodeId
() :
string
+
getArmyCountNodeId
() :
string
+
subtractFromArmyCount
(
in casualties
:
int
)
+
addToArmyCount
(
in support
:
int
)
+
addAdjacentTerritory
(
in territory
:
Territory
)
+
getAdjacentTerritories
()
+
isAcquired
(
in territory
:
Territory
) :
bool
+
isEnemy
(
in territory
:
Territory
) :
bool
+
isNeighbor
(
in territory
:
Territory
) :
bool
-
displayName
:
string
-
nodeId
:
int
-
owner
:
Player
-
armyCount
:
int
-
productionRate
:
int
-
adjacentTerritories
:
Territory
risk
.
model
::
Territory
1
42
+
showStoreFront
()
+
startNewGame
(
in numPlayers
:
int
,
in armyCount
:
int
)
+
startNewGame
(
in listOfPlayers
,
in armyCount
:
int
)
+
startNewGame
(
in config
:
Config
)
+
fireChangeListeners
()
+
activePlayerOwnsTerritory
() :
bool
+
canAttackFrom
(
in territory
:
Territory
) :
ActionResponse
+
canAttack
(
in attackFrom
:
Territory
,
in attackTo
:
Territory
) :
ActionResponse
+
canFortifyFrom
(
in territory
:
Territory
) :
ActionResponse
+
canFortifyTo
(
in territory
:
Territory
) :
ActionResponse
+
getWinner
(
in attackFrom
:
Territory
,
in attackTo
:
Territory
) :
Player
+
endTurn
()
+
endRound
()
+
updateView
()
+
registerBattleResults
(
in attacker
:
Territory
,
in defender
:
Territory
,
in loser
:
Territory
) :
BattleResponse
+
registerFortifyResults
(
in fortifyFrom
:
Territory
,
in fortifyTo
:
Territory
,
in amount
:
int
,
in trackChange
:
bool
)
+
getNumCasualties
(
in attacker
:
Territory
,
in defender
:
Territory
) :
int
+
showWinnerSequence
(
in winningPlayer
:
Player
)
+
showPlayerKilledSequence
(
in losingPlayer
:
Player
)
-
changeListeners
-
game
:
Game
-
frame
:
MainFrame
-
hasFortifiedThisTurn
:
bool
-
roundNumber
:
int
-
losingPlayer
:
Player
risk
.
controller
::
GameController
1
1
risk
.
controller
risk
.
model
-
boardXMLDocument
-
boardName
-
boardSVGFile
-
isDefaultBoard
risk
.
model
::
BoardDescriptor
1
1
1
2
..
5
risk
.
model
::
ProductionGenerator
This class generates skewed production values so we get more
2
'
s and
3
'
s
-
canPerformAction
:
bool
-
errorMessage
:
string
risk
.
controller
::
ActionResponse
-
CanContinue
-
Conquered
-
PlayerIsDead
-
WeHaveAWinner
«type»
risk
.
controller
::
BattleResponse


Figure
4
-
1.

Model and Controller Class Diagram
.


The
GameController

class is used to initialize and start new games as well as provide an interface
for view classes to perform attacks, fortifies, and general game controls. View classes manipulate the
model classes t
hrough the
GameController
.


The
Model

class represents the state of a given game. It encapsulates all information needed to
describe a model, players, and territories and provides methods for altering game state.
Player

and
Territory

define information r
elevant to players and territories respectively. When constructing the
model, a
Config

element is required and it defines all the parameters needed to build a game
including, among other things, a list of players, army count, and a board descriptor. The
BoardDescriptor

class provides the game with a specific map. In this way, we can load different
maps for a given game by passing in different board descriptors.


ProductionGenerator

is used to skew production values such that we have more 3’s and 2’s for
production. The skewing is 35% for 3’s, 35% for 2’s, 20% for 1’s and 10% for 0’s.



19


The
ActionResponse

class represents the result of some attempted action such as attack or fortify.

It wraps a Boolean result indicating whether the action is allowed and a message if the action is not
allowed.


BattleResponse

is actually an enumeration. In the diagram, it is stereotyped as <<type>> because
Microsoft
Visio doesn’t have an <<enum>> ste
reotype. This value is used during an attack sequence to
determine how the attack sequence can progress.


4.3.2. View Class Diagram

+
repaint
()
+
setTextElementToInt
(
in elementNodeId
:
string
,
in value
:
int
)
+
resetState
()
-
svgDocument
:
SVGDocument
-
gameState
:
State
-
source
:
Territory
-
destination
:
Territory
-
cachedPlayer
:
Player
BoardPanel
-
buttonEndTurn
:
JButton
-
buttonEndGame
:
JButton
ControlPlanel
+
showStoreFront
()
+
showBoard
()
-
serialVersionUID
:
long
-
board
:
BoardPanel
MainFrame
+
closeFrame
()
+
render
()
PopupFrame
-
from
:
Territory
-
to
:
Territory
FortifyFrame
+
playAgain
(
in attackerBuzzer
:
int
,
in defenderBuzzer
:
int
)
+
refreshStatsPanel
()
+
refreshInfoPanel
()
-
minigame
:
MiniChallengePanel
-
attacker
:
Territory
-
defender
:
Territory
-
statsPanel
:
JPanel
-
infoPanel
:
JPanel
-
attackLabel
:
JLabel
-
defendLabel
:
JLabel
-
riskResultLabel
:
JLabel
-
rewardResultLabel
:
JLabel
AttackFrame
+
paint
()
+
declareWinner
() :
Territory
+
doGameSpecificLogic
()
+
startNewGame
()
+
winningConditionSatisfied
() :
bool
-
serialVersionUID
:
long
-
attacker
:
Territory
-
defender
:
Territory
-
winner
:
Territory
-
attackerBuzzer
:
int
-
defenderBuzzer
:
int
-
timer
-
isShowingWinnerMessage
:
bool
MiniChallengePanel
-
serialVersionUID
:
long
-
currentColor
-
hasScheduled
:
bool
HitWhenWhitePanel
-
serialVersionUID
:
long
-
diameter
:
int
-
diameterRate
:
int
ShrinkingCirclePanel
-
serialVersionUID
:
long
-
colorIndex
:
int
-
colors
:
int
-
numberOfCombinations
:
int
-
colors
:
string
-
words
:
string
WordMatchesColorPanel
1
0
..
1
1
0
..
1
1
0
..*
1
*
+
getRandomMiniChallengePanel
(
in attackingTerritory
:
Territory
,
in defendingTerritory
:
Territory
)
-
MiniChallengeRegistry
1
*
risk
::
risk
.
view
-
selectedPlayers
:
Player
StartNewGamePanel
0
..
1
1
-
nameLabel
:
JLabel
-
checkbox
:
JCheckbox
-
player
:
Player
PlayerCheckboxNamePanel
5
1
+
updateTurnStatusPanel
()
-
turnNumberLabel
:
JLabel
-
numArmiesLabel
:
JLabel
-
totalProductionLabel
:
JLabel
-
numTerritoriesLabel
:
JLabel
TurnStatusPanel
WinnerFrame
+
evaluate
() :
int
-
serialVersionUID
:
long
-
numberOfCombinations
:
int
-
operand
1
:
int
-
sign
:
int
-
evaluatedResult
:
int
-
displayedResult
:
int
EquationsPanel
-
serialVersionUID
:
long
-
positions
-
radius
:
int
-
shapeBag
-
possibleWinningCombination
-
maxRuns
:
int
-
runs
:
int
-
minRuns
:
int
FiveDifferentShapesPanel


Figure
4
-
2
.

View Class Diagram
.


Probably the easiest way to describe the view is to provide

a few notes about class relationships and
then provide screenshots for each relevant class.


PopupFrame

is used to show any panel that needs to serve as a modal dialog.
WinnerFrame
,
FortifyFrame
, and
AttackFrame

are all subclasses of
PopupFrame
.


MiniChallengeRegistry

is responsible for providing the game with a random set of mini
-
challenges when an attack sequence begins.
MiniChallengePanel

is the base class for all of the
mini
-
challenges in the game. New mini
-
challenges can easily be added to t
he game by sub
-
classing from
this class.



20




Figure
4
-
3
.

StartNewGamePanel
.





Figure
4
-
4
.

MainFrame
,

BoardPanel
, and

ControlPanel
.


The outer portion of this screenshot is the
MainFrame
. It hosts both the
BoardPanel
, which
represents the map, and the
ControlPanel
, which provides status information and controls to end
turn and game.



21



Figure
4
-
5
.

AttackFrame
.




Figure 4
-
6.

FortifyFrame
.





Figure 4
-
7
.

EquationsPanel
.




22




Figure 4
-
8
.

FiveDifferentShapesPanel
.




Figure 4
-
9
.

HitWhenWhitePanel
.



Figure 4
-
10
.

ShrinkingCirclePanel
.



23




Figure 4
-
11
.

WordMatchesColorPanel
.


4.3.
3.

Additional Maps




Figure 4
-
12
.

Arizona.




24




Figure 4
-
13
.

Europe.





Figure 4
-
13
.

Yugoslavia
.


25


4.3.
4. Sequence Diagrams


Loop
Loop
While
Loop
Loop
Loop
aGame
GameController
Start New Game
new Game
(
numPlayers
,
armyCount
)
initialize
(
numPlayers
,
armyCount
)
createTurnOrder
(
numPlayers
)
createPlayers
(
numPlayers
)
aPlayer
new Player
(
color
)
createTerritories
aTerritory
new Territory
(
name
)
assignNeighbors
addAdjacentTerritory
(
territory
)
assignTerritories
getTerritory
territory
assignTerritory
(
territory
)
setOwner
(
player
)
While territories are unassigned
assignInitialArmies
(
armyCount
)
setArmyCount
(
count
)
assignProductions
setProductionRate
(
rate
)


Figure 4
-
14
.

Initialization.


26


board
:
BoardPanel
singleton
:
GameController
Red
:
Player
setGameState
(
SOURCE
)
setSourceTerritory
(
Quebec
)
clickedOn
(
Quebec
)
clickedOn
(
Ontario
)
setGameState
(
DESTINATION
)
setDestinationTerritory
(
Ontario
)
:
AttackFrame
AttackFrame
(
Quebec
,
Ontario
)
HitWhenWhitePanel
minigame
:
HitWhenWhitePanel
setVisible
(
true
)
doGameSpecificLogic
Ontario
:
Territory
getRandomMiniChallengePanel
windowClosing
fireChangeListeners
repaint
Available States
:
UNSELECTED
,
SOURCE
,
DESTINATION
Scenario
:
Red Player makes Quebec
(
of Red with
14
armies
)
attacks Ontario
(
of Blue with
14
armies
)
with
5
armies at stake
.
handleEvent
(
Quebec
)
handleEvent
(
Ontario
)
declareWinner
(
Red
)
registerBattleResults
subtractFromArmyCount


Figure 4
-
15
.

Attacking.


27


board
:
BoardPanel
singleton
:
GameController
Red
:
Player
setGameState
(
SOURCE
)
setSourceTerritory
(
Quebec
)
clickedOn
(
Quebec
)
clickedOn
(
Ontario
)
setGameState
(
DESTINATION
)
setDestinationTerritory
(
Ontario
)
:
FortifyFrame
FortifyFrame
(
Quebec
,
Ontario
)
windowClosing
fireChangeListeners
repaint
Available States
:
UNSELECTED
,
SOURCE
,
DESTINATION
Scenario
:
Red Player chooses to fortify armies
from Quebec to Ontario
render
()
:
JButton
:
Game
fortifyTerritory
()
Quebec
:
Territory
Ontario
:
Territory
setArmyCount
()
addActionListener
(
ActionListener
)
actionPerformed
registerFortifyResults
setArmyCount
()
handleEvent
(
Quebec
)
handleEvent
(
Ontario
)


Figure 4
-
16
.

Fortifying.


4.3.5.

Test Case Design


For our project we have a combination of automated test cases that use the JUnit framework as well as
interactive test cases. Interactive test cases are necessary because it is difficult to automate UI tests and
the majority of our application is UI.


Test cases are broken up into packages of which names correspond to the package names of the code
we are
testing. The default package contains a class to run all of the automated tests. The
risk.model

test package contains two classes used to test game initialization. These tests ensure
that players are given fair production, territories, and armies.


28


The
r
isk.view

test package contains a launcher to start the main application. After launching the
main application, interactive tests can be performed. The
risk.view.testcases

test package
contains text files that provide instructions for the tester to carry
out the interactive tests for attacking,
fortifying, etc.


The
risk.view.minichallenge

test package contains launchers that allow interactive testing of
each of the mini
-
challenges in the game. Along with this package we have
risk.view.minichallenge.testc
ases
. Similar to the view tests, this package contains text
files to help testers carry out interactive tests for each of the mini
-
challenges in the game.


4.3.6. Third
-
P
arty
L
ibraries


For rendering map graphics, we used SVG in combination with Batik and Inkscape. Batik provides
utilities for manipulating SVG documents and rendering graphics on a JSVGCanvas. In our project,
BoardPanel

is a subclass of
JSVGCanvas
. Inkscape is used to r
ender the production and army
counts in the center of each territory on the map.





29


5. Afterthoughts


5.1.
Future Plans


We plan for this project is to be distributed to colleagues, friends, and family and also to develop the
game further based on feedback. A lot of opportunities for future development exist for our Risk
-
derived project. Some developers see opportunities fo
r Artificial Intelligence support such as playing
against the computer. Other developers would like to add a more personal touch such as adding local
maps. Another major area of exploration is the development of mini
-
challenges. Adding more mini
-
challenges

would greatly benefit the game. The focus for this project this semester was to develop
reactionary games of skill. However, any variety of quick
-
style games could be added. If a significant
library of mini
-
challenge games is developed,
giving the user

th
e ability
to choose which mini
-
challenge
games
to play during the game would also be a significant improvement. Plans are being made to
request from users what types of games they would like to play and to develop furth
er any
improvements that would make the game more enjoyable.


5.2. Personal Reflections


5.2.1. Ariagno, Christopher


"The UIUC Risk project was a great experience and the first time I had worked with a team to write code.
I learned about and practiced com
munication and documentation, Eclipse and Subversion, Java and
Swing, all while separated from the team members by hundreds of miles. Without prior similar
experiences for reference, a comparison cannot be drawn; however I did enjoy the process very much
a
nd look forward to participating on future software projects."
-
Christopher Ariagno


5.2.2. Barakat, Ashraf


"Part of the success of the Risk Team was that the team employed successful best
-
practices. One of the
successful practices utilized was prearrangi
ng who would take which roles throughout the project and
spreading out the roles as evenly as possible. Whether it was being a moderator or a scribe for any given
meeting, the team always tried to spread out the roles as evenly as possible. Even when assig
ning tasks,
the team attempted to spread the load as uniformly as possible. For the majority of the semester, the
team tried to focus on fairness and teamwork. In many cases, developers would volunteer when
necessary to consistently maintain fairness amon
g team members. A healthy understanding existed
between teammates that some members had circumstances that might be different from others, so the
team tried to be flexible with scheduling and tasks when necessary. Naturally, this flexibility comes with
a
n amount of trust that is placed on each developer. In most cases, each developer fortunately did not
break this trust and all tasks were completed timely.


More important than task equality, the team created an atmosphere where teammates felt comfortable
expressing their opinions and provided the notion that teammate opinions were valued. In many cases
the team did not agree on certain implementations, but th
e civility and professionalism that was
displayed was pinnacle to completing the task. A decision was made by the team concerning the design
and teammates whether they agreed with it or not, followed it for the sake of consistency and team
unity, which ult
imately led to a successful project. Therefore little in
-
fighting existed and tasks were
dependably completed.



30


Items that did not work so well for the team, but at no fault of the team, were some of bad software
tools used. Since this team did most of
their work in a virtual manner, it would have behooved the team
to spend some time exploring the best virtual tools as well as other development tools. Some items that
worked for us moderately well in the end were TeamViewer and Skype. The team used TeamV
iewer for
remote desktop sharing and Skype for most verbal communication. Nevertheless, there were many
instances where Skype had many network or software problems and time was wasted debugging.
Another instance where time was wasted was when the team had

not agreed on which UML tools to
use. It was not until the team decided to use Microsoft Visio, which was chosen more out of
convenience than utility that the team was able to quickly move on with tasks. Tools nonetheless did not
ultimately slow the team,

but did introduce the need to standardize what to use among team members.

It was a pleasure to work with a talented and considerate team. I hope to continue to employ the best
practices that were employed and the processes that were followed."
-
Ashraf B
arakat


5.2.3. Parkinson, David


"This project was a fun and engaging use of software engineering principals. Our application was
interested to make as it was a game we all had played many times throughout our life. Given that the
business requirements a
nd the play of the game was well know by most all of the team, and that the
technology was quickly learned, we were able to focus more on the process than the technical details of
how to solve the tasks at hand. I am pleased with the way our team worked t
ogether and the fact that
we kept to our schedule and delivered (even over delivering compared to the initial estimates) a solid
application.

Our team also worked very well together, which was another plus. Too many times at work I have
encountered people

that were difficult for one reason or another. The additional hassle of dealing with
those people usually cost the project time. This wasn’t the case here. We changed our paired group
members after each iteration and were successful in working with eve
ryone. I think all these factors
really helped us workout our process and make our weekly schedule and updates all the more effective.
I was specifically impressed with the efficiency of our meetings as our process was tweaked more and
more. Our first c
ouple weekly meetings lasted more than 2 hours. Towards the end, we were able to
just report quickly and be done in about 20 minutes."
-
David Parkinson


5.2.4. Smittkamp, James


"Overall, I think this project was interesting and successful. Our team work
ed well together and the
division of labor seemed pretty even. It would have been nice to be able to build some AI into the game
for computer players, but we just didn't have time. The one thing this project definitely confirmed for
me is that Java sucks

for building windows GUI applications. We could have built a much richer user
interface in the .NET framework in probably about 1/10th the time."
-
James Smittkamp


5.2.5. Taljanovic, Nedzad


"I really enjoyed working on this project. I was one of the ori
ginal proposers of the project and it was
great to see it come to life. We delivered everything in the proposal, as well as some additional features.
At first, I was a little hesitant about the geographical distribution of our team due to some past
experie
nces at work. I was pleasantly surprised at how well the team worked together. All members had
different strengths and everyone found ways to contribute equally to the success of the project. I am
proud of the quality of work we delivered."
-
Nedzad Taljano
vic



31


5.2.6. Tran, Dewey


"This was definitely one of the better projects I've worked on. The end result was much better than
expected. This is no surprise when everyone pulled their weight. I like the fact that we were given such
freedom to do what we want
ed to do. Steve, the TA overseeing our project, kept us grounded by
providing important advice and suggestions from a third
-
person point of view. This project definitely
taught me how to plan ahead and pair
-
program. The team meshed together well and everyo
ne
understood the structure from beginning to end, and that made communication and quality
exceptionally better. Extending the project further and further every iteration was made easier because
of this as well."
-
Dewey Tran





32


Appendix A
-

Installing
and Running from Eclipse


To download the Risk a
pplication source from SVN, compile and run the code from within Eclipse, follow
the directions below.


Pulling the Risk Source from SVN and importing into Eclipse:

1.

Install Eclipse with the SVN plug
-
in added.

2.

Right click in the project’s window of the Eclips
e workspace and select 'Import…'

3.

Select SVN
-
> Project from SVN as the source and click Next.

4.

If the Risk repository
is not already created, select '
Create a new repository locat
i
on
'

and click
Next
.

a.

Enter '
https://csil
-
projects.cs.uiuc.edu/svn/sp10/cs428/Risk
'

as the URL and your login
credentials in the user / password fields and click Next.

5.

Select the
'
Head Revision
'

and click Finish.

6.

On

t
he Check Out As screen, Select '
Check out as a project configured using the New Project
Wizard
'

and enter Risk in the corresponding text box then click Finish.

7.

Select Java
-
> Java Project and click Next.

8.

Enter Risk for the Project Name and leave the othe
r selections as default, click Finish.

9.

The source will be downloaded, the project created, and the project will be built.

10.

If build errors occur that are JUnit related, make sure that you add JUnit 3 to the project’s build
path.

a.

Right click on the Risk proj
ect
-
> Build Path
-
> Add Libraries…

b.

Select JUnit and click Next.

c.

Select JUnit 3 and click Finish.

Running the Risk Application from Eclipse

1.

Expand the package:
test.risk.view
.

2.

Right click the MainFrameLauncher.java file
-
> Run As
-
> Java Application.




33


Appendix B
-

Installing and Running from JAR File


To download and run the Risk application without the source, follow the directions below.

1.

Download the JAR file at

the following location:

______________

2.

Double click the JAR to start the application.




34


Appendix C
-

Rules


1. Starting a Game


1.1. Players

The game can be played by two to five players. At the start of the game, each player must choose one of
the following colors: red, blue, green, yellow and purple. When choosing colors, a younger player h
as
priority over an older player. Each color that was chosen must be selected on the welcome screen.
Colors that were not chosen must be de
-
selected.


1.2. Board
-
map

The oldest player will choose what board map to use. Once the board map is chosen, the gam
e can be
started.


1.3. Territories

Territories will be distributed automatically to players. A territory that is colored by a players color
indicates that it is owned by that player. Each territory has a box with two values displayed above it. The
value o
n the left is the current number of armies inside the territory. The value on the right is the
production
-
per
-
round.


2. Playing the Game


2.1. Turns

The game will randomly assign a turn order to the players. At a given time, it is only one player’s turn.
That player is called the active player. The game indicates the active player by displaying statistics in the
player’s color under the board map. The active player may attack, fortify or end turn. To end a turn, the
active player must click the end turn bu
tton. Once the active player ends their turn, control is passed to
another player. Once all players that have not lost have played a turn, the current round ends and a new
round begins. At the end of a round, the current armies are increased by the product
ion
-
per
-
round for
each territory.


2.2. Attacking

In order to attack, the player must click on a territory he/she owns, and then click on a neighboring
territory that an opponent owns. The attacking territory must have at least two armies.


2.2.1. Battles

An attack consists of a series of battles. A battle is fought between the active player and the owner of
the defending territory. In each battle, a calculated number of armies is at stake. The competing players
engage in a reactionary challenge. The first
player to buzz in when the winning condition is met wins. If a
player buzzes in before the winning condition is met, he/she loses the battle. The loser of the battle has
the armies at stake deducted from their territory. After a battle, the active player m
ay choose to
continue attacking as long as they still have at least two armies in the attacking territory.


2.2.2. Conquest

If after a battle, the defending territory has no armies, the ownership is transferred to the active player.
The active player then

has a choice of transferring one or more armies from the attacking territory to
the newly acquired territory. The active player must leave at least one army in the attacking territory.
This transfer of territories does not count as a fortify.


35



2.4. Fortif
ying

Fortifying is the act of transferring armies from one territory to an adjacent territory. The active player
must own both the source and destination territories. The source territory must have at least one army
left. A fortify can only be done once pe
r turn.


3. Ending the Game

3.5. Losing

A player loses when he/she does not own any territories. A player that has lost will not play any more
turns.


3.6. Winning

A player wins the game when he/she owns all territories on the board map.