Forces of Conquest
A Strategic Game of
Territorial Domination
Design Document
Version 1.0
Jon John, Erik Hayes, James Lacovara, Yu Ding, Lori Gratch
May 24, 2002
Table of
Contents
7.
Splash Screen Art Requirements
8. Music
and Sound Effects List
1. The Game Concept Overview
"Forces of Conquest: A Strategic Game of Territorial Domination" will
be similar to a board game but complex enough that a computer is necessary for
enjoyable game play. The game is for
two to four players. The
"board" will consist of a map on which resources will be arranged.
The object of the game will be to enter the territory containing the enemy flag
with at least one infantry unit, defeat the opposition (if it exists) and win
the game. To stop your opponent you need to accumulate resources to improve and
maintain your army units and build up walls to protect your flag. Rogue Armies
are included in this game, acting on their own and adding to the challenge.
During each player's turn, resources will be accumulated and the computer will
advise of potential purchases based on the resources the player owns.
Theme
of the product. Strategic battle
game.
Character art style.
Medieval.
Target age group .
Teens and older.
Target platform .
Any Java-capable platform.
Special hardware .
A mouse will be required.
Hardware
requirements. Mouse, 16 MB RAM Pentium/100 or faster, 15 MB
hard disk space, SVGA monitor supporting 256 colors, Java-compatible platform.
Estimated production
team size. Five.
Scheduled completion
date.
Reference products. This game incorporates ideas from
games such as Civilizations, Settlers of Catan, and Magic: The Gathering (The
card game).
Sample
Board
Below
is a very basic example of what a map might look like. Keep in mind this map has no textures, no
ownership, and no units on it.
The following is a list of
the various packages used in the game.
There are UML diagrams for each package and a description of what each
class consists of.
Click here to view a key of UML symbols.
Click here to view a full high level uml.
3.1
Package:
Purpose:
To maintain all information that is part of the global scope of the game.
Special
Notes:
-None.
Click here to view main lower level uml.
Class:
GameEngine
Purpose:
To control the flow of the game. This
is the core that puts everything together.
Attributes:
event_calculator: object that
handles various computations important to the semantics of the game.
players: the people that are
involved in the game.
map: the board that is used for the
game.
gui: the interface that the user
interacts with to play the game.
Operations:
main: the core that controls all
aspects of the game from a high level.
initialize: sets the game up in a
starting position so that play can commence.
getPlayers: returns the players of
the game.
getMap: returns the board that is
being used for the game.
Class:
EventCalculator
Purpose:
To handle various computations that are needed throughout the course of the
game.
Attributes:
Operations:
attack: performs the calculations
necessary for armies to battle.
buildStructure: performs the
calculations necessary for a player to build a structure.
buildMobileUnit: performs the
calculations necessary for a player to build a mobile unit.
Class:
Player
Purpose:
To maintain information relevant to each person playing the game.
Attributes:
id: an identifier for the player of
the game.
name: the name of the player.
borders: all of the borders that the
player has control over.
territories: all of the territories
that the player has control over.
stationary_units: all of the
structures that the player has control over.
mobile_units: all of the armies that
the player has control over.
resources: all of the user’s
accumulated resources.
Operations:
getId: returns the identifier of the
player.
getName: returns the name of the
player.
getMobileUnits: returns all of the
forces that the player controls.
getStationaryUnits: returns all of
the structures the player controls.
getResources: returns the player’s
accumulated resources.
getTerritories: returns all of the
territories that the player controls.
getBorders: returns all of the
borders that the player controls.
Class:
Resource
Purpose:
To provide a structure that can hold resource information.
Attributes:
type: the type of the resource
(food, wood, stone, etc).
amount: the quantity of the
resource.
min_amount: the minimum possible
yield of a resource (for use by territories).
max_amount: the maximum possible
yield of a resource (for use by territories).
is_ranged: Boolean indicating if the
resource yield is fixed or within a range (for use by territories).
Operations:
Resource: constructors.
getType: returns the type of the
resource.
getAmount: returns the amount of the
resource.
addAmount: total a resource (for use
as the user accumulates resources).
subtractAmount: remove some of a
resource (for use as the user spends resources).
3.2
Package: Board
Purpose:
To maintain all information that is related to the landscape of the game.
Special
Notes:
-Two
path finding methods: While the
adjacency matrix in the Map class is responsible for maintaining connections
between territories, it is also possible to follow paths by moving from a
territory to a border and then onto the next territory. However, it is important to note that the
original adjacency matrix may not account for movement costs and walls while
the territories and borders will maintain this information.
Click here to view board lower level uml.
Class:
Map
Purpose:
To maintain an overall viewpoint of the landscape of play.
Attributes:
adjMatrix: an adjacency matrix that will manage
position (relative, not graphical) and connections between territories of the
map. This choice of representation
will allow for a great deal of flexibility as it does not place any
restrictions on the number of neighbors (sides) that a tile can have. And while the first draft will most likely
just denote an undirected graph with unweighted edges, more advanced versions
could easily represent a directed graph with weighted edges (and removable
edges denoting walls) to support more sophisticated path algorithms that
support gameplay.
territoryTable: since the matrix above is simply rows
and columns, it is necessary to have a means to associate a given row/column
with a territory. This table will
have a reference to the territory corresponding to each row/territory.
numberTable: this structure is the inverse of the
above table allowing for row/column lookup provided a territory reference.
Operations:
getNeighbors: function takes a territory as a
parameter and returns a vector of all the territories that border the given
territory.
pathExists: function takes a start territory, an end
territory, and a number of movement points to determine if it is possible to
move from start to end with the given movement points. The result is returned via boolean value.
newTurn: function used to indicate a new turn has
begun so that any turn-based values can be adjusted appropriately.
Class:
Territory
Purpose:
To maintain information relevant to an individual territory.
Attributes:
borders: each territory has a set of
borders. This number can vary with
each map.
resources:
each territory is capable of producing this set of resources each turn (empty
vector if barren land).
mobile_units: the armies that are currently on the
given territory (empty vector if no armies currently present). If a player owns the territory, it is
possible for a given player to have a maximum of 2 armies on a territory (1
mobile, 1 within a structure). Every
other player can only have 1 (mobile, attacking) army on the territory.
stationary_unit: 1 stationary unit can exist on a
tile given that the structure is built by the owner of the territory (null if
no structure present).
owner: the player that currently owns
the territory (null if not owned).
tempBarren:
integer that denotes the number of turn the territory will not produce
resources (0 if land if okay).
harvested:
boolean indicating whether or not a Territory’s resources have been harvested
this turn.
type:
an integer value used to denote the type of the Territory's terrain.
Operations:
getBorders: returns a vector of the
territory's borders.
getResources:
returns a vector with the resources the land normally produces (empty if barren
land).
harvestResources: first checks tempBarren. If tempBarren is 0, return a vector with
resources provided by the land for the current turn. Otherwise, decrement tempBarren and return an empty vector. If the land is normally barren, return an
empty vector.
getMobileUnits: returns a vector with all of the
mobile armies currently occupying the territory (empty if no armies).
getStationaryUnit:
returns a structure if there is currently one on the territory (null if no
structure).
getOwner: returns the current owner
of the territory.
getContents: returns a vector with
everything currently in the territory (armies and structure).
addMobileUnit: adds an army to the
territory.
removeMobileUnit: removes an army
from the territory.
setStationaryUnit: sets the structure on the
territory if the player owns the territory and there is no existing
structure. If the parameter is null,
an existing structure is removed.
setOwner: sets the owner of the
territory.
attacked: takes a severity parameter and temporarily
makes the land barren for a number of turns (tempBarren = severity).
newTurn: funciton used to indicate a new turn has
begun so that any turn-based values can be adjusted appropriately.
Class:
Border
Purpose:
To maintain information relevant to the borders between territories.
Attributes:
wall: each border can contain one wall (null if no
wall). The player must own a
territory that shares the border in
order to construct a wall.
neighborTerritories: a pair of
territories that share the border.
Operations:
getWall: returns the wall currently
on the border (null if no wall).
setWall: if the player owns a territory that shares
the border and the border does not already have a wall, the wall is placed on
the border. A boolean is returned
indicating success or failure.
getTerritories: returns a vector with
the pair of territories that share the border.
3.3
Package: Stationary
Purpose:
To maintain all information that is related to the stationary structures
available in the game.
Special
Notes:
-None
Click here to see stationary lower level uml.
Class:
StationaryUnit
Purpose:
A super class that contains all of the information that will be held by any
structure.
Attributes:
owner: the owner of the structure.
cost: the resources needed to
construct the structure.
base_defense_rating: the initial defensive power of a
structure.
current_defense_rating: the defensive
power that the structure currently has.
base_protection: the initial
protection that the structure provides.
current_protection: the protection
that the structure is currently able to provide.
valid_territory_types: all of the
territories on which a given structure can be placed.
defense_upgrade: an upgrade for the
structure that increase strength and protection.
Operations:
getDefenseRating: returns the
defensive power of the structure.
getProtection: returns the protective
power of the structure.
damage:
perform a level of damage to a structure.
This results in a decrement of the protection and defense of the
structure. A boolean value indicates
successful application of the damage.
repair:
performs repairs on a structure given appropriate resources and a need for
repair. A boolean value is returned
indicating the success of the repair operation.
addDefenseUpgrade:
adds an upgrade to a structure if the upgrade does not already exist and the
player providing the upgrade owns the structure.
removeDefenseUpgrade:
removes an upgrade from a structure.
This only happens when the upgrade is destroyed by an attacking army.
getOwner: returns the
player that owns the structure.
getCost: returns the
cost necessary to construct the structure.
getValidTerritoryTypes:
returns the types of territory that the structure is capable of occupying.
Class:
DefenseUpgrade
Purpose:
To maintain information on an upgrade performed to a structure.
Attributes:
cost:
the resources needed to construct the upgrade.
base_defense_increase:
the amount of defensive power that the structure gains due to the upgrade.
current_defense_increase:
the amount of defensive increase the upgrade is currently able to provide.
base_protection_increase: the amount
of protection that is gained due to the upgrade.
current_protection_increase:
the amount of protection that the upgrade is currently able to provide.
Operations:
getCost: returns the cost necessary
to construct the upgrade.
damage:
perform a level of damage to the upgrade.
This results in a decrement of the protection and defense of the
upgrade. A boolean value indicates
successful application of the damage.
repair:
performs repairs on an upgrade given the appropriate resources and a need for
repair. A boolean value is returned
indicating the success of the repair operation.
Class:
DefensibleUnit
Purpose: A super class that contains all the
information that will be held by any structure that can be inhabited by an
army.
Attributes:
defense_army: the army that is
positioned with the structure.
max_defense_army_size: the maximum
size of an army that can inhabit the structure.
Operations:
addDefenseArmy:
places an army within the structure if there is not already an army there and
the player owns the structure. A
boolean is returned indicating success of the operation.
removeDefenseArmy:
removes an army from the structure as long as the player owns the structure.
getMaxDefenseArmySize:
returns the maximum size of an army capable of inhabiting the structure.
Class:
Bridge
Purpose:
Represent a bridge for the purpose of certain types of terrain.
Attributes:
base_defense_rating: inherited and
set to 20.
base_protection: inherited and set to
0.
Operations:
Class:
Wall
Purpose:
A super class that conatins all the information that will be held by any wall.
Attributes:
Operations:
Class:
WoodWall
Purpose:
Represent a wall that is made of wood.
Attributes:
base_defense_rating: inherited and
set to 10.
base_protection: inherited and set to
25.
Operations:
Class:
StoneWall
Purpose:
Represent a wall that is made of stone.
Attributes:
base_defense_rating: inherited and
set to 30.
base_protection: inherited and set to
50.
Operations:
Class:
Tower
Purpose:
A super class that contains all the information that will be held by any tower.
Attributes:
Operations:
Class:
WoodTower
Purpose:
Represent a tower that is made of wood.
Attributes:
base_defense_rating: inherited and
set to 15.
base_protection: inherited and set to
35.
Operations:
Class:
StoneTower
Purpose:
Represent a tower that is made of stone.
Attributes:
base_defense_rating: inherited and
set to 60.
base_protection: inherited and set to
75.
Operations:
3.4
Package:
Purpose: To maintain information for all of the
mobile aspects of the game. This
includes everything from armies to siege weapons.
Special
Notes:
-None
Click here to see the lower level mobile uml .
Class:
MobileUnit
Purpose:
An abstract super class that represents any mobile unit..
Attributes:
cost: the cost (in resources) of the
unit.
owner: the owner of the unit.
Operations:
getMP: returns the current movement
points of the unit.
refreshMP: resets movement points.
getAttackRating: returns attack
rating of the unit.
getDefenseRating: returns defense
rating of the unit.
getCost: returns the cost (in
resources) of the unit.
getOwner: returns the owner of the
unit.
Class:
Army
Purpose:
A container for a group of army units.
Attributes:
units: all the units in the army.
max_size: size limit of the army.
Operations:
Army: constructor.
getMP: returns the minimum mp value
of all the units.
getAttackRating: returns the sum of
the attack ratings of the units.
getDefenseRating: returns the sum of
the defense ratings of the units.
refreshMP: refreshes the movement
points of all the units.
getUnits: returns a vector of the
units.
getMaxSize: returns the maximum size
of the army.
addUnit: adds the unit if the maximum
size has not been reached.
removeUnit: removes the unit if it
belongs to the army.
Class:
ArmyUnit
Purpose:
A super class that contains all of the information that will be held by any
army unit Attributes:.
SHORT_RANGE: a constant representing
short range.
LONG_RANGE: a constant representing
long range.
SHORT_AND_LONG_RANGE: a constant
representing both short and long range.
base_mp: base movement points of the
unit.
current_mp: current movement points
of the unit.
attack_rating: power of an attack for
both short and long range attacks.
base_defense_rating: the initial
defensive power of the unit.
current_defense_rating: amount of
damage that can be taken before destruction.
attack_range:
distance of attack ability, either SHORT_RANGE, LONG_RANGE, or
SHORT_AND_LONG_RANG.
Operations:
getMaxMP: calculates the adjusted
maximum movement points.
getCurrentMP: returns the current
amount of movement points.
refreshMP: resets current_mp to the
adjusted maximum.
reduceMP:
reduces the current movement point value by amount only if the amount is less
than
or equal to current_mp.
getAttackRating: returns the attack
rating corresponding to the given range.
getDefenseRating: returns the
defense rating of the unit.
getAttackRange: returns the attack
range of the unit.
damage:
perform a given amount of damage to an army.
This results in reduction of the army’s power. A boolean is returned indication successful application of the
damage.
Class:
DefensiveArmy
Purpose:
Same as Army with the restriction that it contains only Infantry.
Attributes:
Operations:
Class:
Infantry
Purpose:
A super class that contains all of the information that will be held by any
infantry unit.
Attributes:
Operations:
getMaxMP: returns the calculated
maximum movement points.
getAttackRating: returns the
calculated attack rating for the given range.
getDefenseRating: returns the
calculated defense rating.
getAttackRange: returns the
calculated attack range.
Class:
Soldier
Purpose:
Represents a soldier.
Attributes:
base_mp: inherited and set to 4.
attack_rating: inherited and set to
{2,0}.
defense_rating: inherited and set to
2.
attack_range: inherited and set to
SHORT_RANGE.
Operations:
Soldier: constructor.
Class:
Ranger
Purpose:
Represents a ranger
Attributes:
base_mp: inherited and set to 6.
attack_rating: inherited and set to
{1,2}.
defense_rating: inherited and set to
2.
attack_range: inherited and set to
SHORT_AND_LONG_RANGE.
Operations:
Ranger: constructor.
Class:
Defender
Purpose:
Represents a defender.
Attributes:
base_mp: inherited and set to 2.
attack_rating: inherited and set to
{1,0}.
defense_rating: inherited and set to
3.
attack_range: inherited and set to
SHORT_RANGE.
Operations:
Defender: constructor.
Class:
SiegeWeapon
Purpose:
A super class that contains all of the information that will be held by any
siege weapon.
Attributes:
ammo: all the ammunition (resources)
allocated to the weapon.
current_ammo_type: current ammo being
used by the weapon.
operator: the infantry unit that is
operating the weapon.
ammo_attack_values: a vector of
attack values for each ammo type.
Operations:
getMaxMP: returns the calculated
maximum movement points.
getAttackRating: returns the attack
rating based on the range and ammo type.
getDefenseRating: returns the defense
rating of the unit.
getAttackRange: returns the attack
range of the unit.
getAmmo: returns the ammo currently
allocated to the weapon.
getCurrentAmmoType: returns the type
of ammo currently being used.
setCurrentAmmoType:
sets the current ammo type to the given type only if the weapon currently has
that type, or if the type is empty string.
addAmmo:
adds the given ammo type to the list if it is not already there, updates the
amount if it is already in the ammo list.
getOperator:
returns the infantry unit operating the weapon, null if no operator is
assigned.
damage:
perform a given amount of damage to a weapon. This results in reduction of the army’s power. A boolean is returned indication
successful application of the damage.
Class:
Catapult
Purpose:
a catapult used to attack at a distance
Attributes:
base_mp: inherited and set to 2.
defense_rating: inherited and set to
5.
attack_range: inherited and set to
LONG_RANGE.
Operations:
Catapult: constructor.
3.5
Package: Graphics
Purpose: To maintain information for all of the
graphics operations that will take place for the player to interact with the
game.
Special
Notes:
-None
Click here to see the lower level graphics uml
Class:
GUI
Purpose: To maintain all information relevant to the
graphical user interface that the players of the game will use to play the
game.
Attributes:
graphics: an object that holds all
necessary rendering information.
parent: the game engine that is
responsible for the flow of the game.
Operations:
getGraphics: returns the object that
contains all of the graphics rendering information.
getParent: returns the game engine
that is responsible for the flow of the game.
Class:
Graphics
Purpose:
To hold all of the rendering information needed to portray the game
graphically.
Attributes:
graphics_info:
a hash table containing an entry for every possible item that may need to be
rendered.
Operations:
getGraphicsInfo: returns the hash
table with all of the graphics rendering information.
Class:
Controls
Purpose:
To manage any special controls that may be placed within the game.
Attributes:
Operations:
Class:
GraphicsInfo
Purpose:
To manage all of the rendering information needed for any object in the game.
Attributes:
image: the basic rendering of the
object to be portrayed.
transform: a transformation applied
to the image.
Operations:
getImage: returns the basic rendering
of an object in the game.
getTransform: returns the
transformation to be applied to the image.
Click here to view low level product flowchart.
5.1 Initialization
The game initialization consists of 3 steps: player
creation, board setup, and initial resource allocation. Upon completion of these stages, the game
commences.
Player Creation
The first step in the game initialization is player
creation. This is dependent on the
number of people that are going to be playing the game. This step must occur first because every
other step of the game will involve the players in some way.
The players are initially created as a blank slate. Attributes will be obtained later in
initialization and throughout the play of the game.
Board Setup
Once the number of players has been determined, it is
possible to provide an appropriate board.
This stage cannot occur earlier because given the nature of the game a
board that is appropriate for a two-player game will not be suitable for the
needs of a three or four-player game.
Besides just determining the board to be used for the game,
this step also involves assigning players an initial starting point or base of
operations. This is done by giving
the player a valid range on the field of play in which to designate as his or
her base. This start location is an
important decision as it determines the location of the players flag and is
where all of the player’s units will originate throughout the course of the
game.
Initial Resource Allocation
In order to speed up play on the first few rounds, players
start with a set amount of each resource at the beginning of each game. This amount is not great enough to perform
any significant operations, but is enough to start the player without the need
to wait for resources to accumulate from the base location.
5.2 Turns
Each player's turn consists of 4 stages in this order --
Resource Stage, Upkeep Stage, Main Stage, and Rogue stage. The computer handles the Resource, Upkeep,
and Rogue stages automatically. The
Main stage is the only stage where a player has any choices to make.
Each player takes turns building up armies, building up
defenses, gaining territories, and attacking other players. A player must click the end turn button
to end their turn and let the next player have a turn. Players continue alternating turns in this
manner until one player captures an opponent’s flag. Once a player’s flag is captured, they are removed from the
game. Play continues until only one
person is left as the winner.
After
a game is complete, an end of game screen is displayed, and then the players
have a choice of playing the same game again. If they choose to do so, the game is started again with the
same game options. If they do not
choose to rematch, the main menu is displayed again.
All operations that a
player can perform should be easily done through the use of a mouse. The user will not be able to change the
mouse controls. However, if keyboard
controls are added, the user should be able to change these.
7. Splash Screen Art Requirements
There are not very many requirements for this section. The splash screen (if any) will be simple. The artwork should be simple yet enjoyable to look at for long periods of time. Below is a very basic outline of what the main play screen should look like:
Main
View:
The
abstract screen shot displays a map on the center of the screen. This will be the most important part of
the interface as it contains the layout of everything in the game. Since every player is allowed to view the
whole board, there is no need for the main view to be updated between
turns. However, the position may be
altered so that the new player is looking at his or her forces rather than the
forces the previous player last modified.
-The
map will show each territory with a color and/or texture to represent the type
of land the territory contains.
-On
each territory, it will be possible to see any mobile units and stationary
units that are present. The same goes
for borders between each territory.
Overhead
Map:
The
overhead map provides a means for viewing the entire field of play at a reduced
level of clarity. The boards will be
too large to fit entirely within the main map window. So rather than for the player to constantly scroll the main map
window, it will be possible to obtain some limited information from the
overhead map. For example:
-Current
relative view of the main map window against the entire map.
-All
player owned territories and their positions.
-Possibly
more information if it can be shown in a manner that is reasonably easy to
reference.
Current
Player Armies:
Since
there is a limit of 10 armies per player, it is possible to provide a toolbar
that allows quick access to the attributes of any of the armies under the
player's control. Clicking on an army
within this toolbar will display the units within the army in the next toolbar
to the right. During the transition
between players' turns, this toolbar will refresh to show the next player's
forces.
Units
In Current Army:
Since
there can only be 10 units per army, it is also possible to provide a toolbar
that displays each unit within the selected army. Clicking on a unit within this toolbar will display all of the
relevant characteristics of the unit in the window below the map.
Selected
Unit Info Display:
This
display will provide information on a specific unit. The information will contain information concerning strengths,
upkeep costs, etc. If the evolution to
accessories for units is created in the future, this information will also be
displayed within this window.
Current
Player Name:
As
a means of reducing confusion, a window will display the name of the player
that should currently be taking a turn.
This will refresh between each turn.
Resource
Meter:
The
resource meter will provide information about the amount of resources the
current player currently has available.
This will provide a guide as to how the player should manage his or her
resources. The information will most
likely be conveyed as bar graphs (one for each resource) with number at the
bottom. This will also refresh for the
next player between turns.
Structure/Army
Unit Cost/Info Display:
This
window will contain all of the current player's options as far as building new
objects, performing repairs, etc. The
computer will assist the user by not allowing the player to try and select
anything that he or she cannot afford with his or her current resources. The only thing that will change in this
window between turns is the availability of certain items given the player's
resources.
Menu
Bar:
This
will contain all common functionality normally associated with a menu (new
game, quit, etc.). There will also be a
help menu that will contain a tutorial that allows the users to learn the game
or brush up on certain features.
8. Music and Sound
Effects List
Music and sound effects
need not be implemented. However, if
they are added, they should not be distracting to the game, and the user should
be able to adjust any music and sound effect settings.