Modules

This diagram shows the major models of the Ad Gladium Game and their relationships. (Click the image to enlarge).

Discussion of Concepts

Many of the design decisions came directly from the High Level Design Document developed by the managers. The hierarchy of classes storing the data is very similar to the one envisioned by the manager, but with more detail and a couple necessary additional classes.

The Squad is a team of Warriors. It contains general information about its team, including credits information, a combat rating, and its unique ID. In battle, the Squad's main purpose is to determine whether any of its Warriors remain standing.

The Warrior class holds all information specific to each warrior, including its equipment information, attributes, statistics, icon, and accessors/mutators for necessary things such as attributes and stats. Warriors also know what team they are on. In battle, Warriors are responsible for keeping track of their own action points and current health.

Most Warriors have collections of Equipment and Feat objects. Equipment objects represent items that the Warrior possesses. It knows all aspects of the item, such as any attribute bonuses it confers to the user and whether it is a weapon (and, if so, what its range and damage are). Similarly, a Feat object knows all aspects of one special ability, such as any new actions it allows the Warrior to take. Both Feat and Equipment objects are able to verify whether a given Warrior can "equip" them.

The Store class contains methods to load the rules for equipment purchase, and methods to buy and sell equipment. It also populates a list of equipment to the Squad Management screeen.

The Upgrader class is implemented similarly to the Store class. The applyMath() function accounts for the fact that as your gain higher attributes, buying additional attributes costs more. One method would be to have each attribute have a constant that is multiplied by the number of experience a Warrior already has, and that number will be the cost of adding an additional point to this attribute. In addition, this class loads the rules for purchasing equipment and feats, and allows Warriors to buy/purchase them.

Connect allows for network play. It waits for a network player to connect, and gets its connection information. Then, after getting the squad XML file information, it registers the player and lets the UI handle the rest as if it were just another player.

The ArenaController class controls all inter-hex map work. It constructs the map and has functions such as getRange() and getMovementPath() to determine the relationships between hexes. It is also responsible for alerting the ArenaView to changes in the arena's state. It also oversees the Hex objects which comprise the arena. Each Hex knows its terrain type, its height, and whether or not it is occupied (a person, obstacle, etc). When occupied by a Warrior, the Hex is the only object that knows the Warrior's position (though the ArenaController can determine this through accessors).

Turn Manager keeps track of which Warrior's turn it is and checks with the Squads to determine when the battle has ended. It also keeps a "wait list" of non-instantaneous actions and performs then when appropriate.

Classes that implement the Action interface represent actions that a Warrior can take, such as moving and attacking. The Action implementors can verify whether a given actor can perform the action on a given target; they are also responsible for performing the action, once validated.

Dynamic Diagrams

Initialization

This collaboration diagram shows what happens when the Game is first run.

Squad Management

This diagram shows what happens in a normal execution of Squad Management, and how it interacts with other classes.

Playing the Game

This diagram depicts what occurs between the modules during one iteration of a turn in a battle

Software Evolution

The software is to be designed in five levels of incremental features

Module Evolution
	Milestone 1	Milestone 2	Milestone 3	Milestone 4
Squad - Squad contain a list of Warriors and the information for that team, and can load and save itself.	N/A	Multiple warriors on a team.	Interaction with Squad Management System	Save/Load capability
Warrior - The main unit of gameplay. He is part of a squad, and knows most information about himself and even about his squad. Most game interaction will be through a Warrior.	- Basic unit object with attributes and appropriate interfaces	Still single unit.	Characters can improve their starts, purchase equipment, earn and use XP points. Warriors can be part of a squad.	Advanced units with different base types.
Store - responsible for purchasing equipment.	N/A	N/A	Ability to purchase and equip items.	Wishlist implementations.
Upgrader - responsible for using XP to upgrade attributes and feats.	N/A	N/A	Ability to earn and use XP points and improving stats for characters.	Wishlist implementations
Connect - connects network players.	N/A	N/A	N/A	Network play
Arena - the playable arena, made up of hexes.	Functional flat map with interface through a UI, working isometric view, ability to click on and highlight individual tiles.	Integrate units onto the map, derive algorithm to determine which squares are valid for a unit to move into, include obstacles, including disallowing two characters to occupy the same tile.	Map Details, including different terrain types, height, and a map validator to ensure units to not get stuck behind terrain.	Wishlist implementations
Turn Manager - manages the order in which Warriors take their turns and determines when the game is over.	Ability to handle a one-on-one fighting system.	Implement protocol between the turn-scheduler, combat system, and the UI.	Intermediate gameplay, win/loss conditions, repeating play game/squad management cycle.	Wishlist implementations
Action - manages the actions that Warriors can execute within a battle.	N/A	Basic gameplay with a simple map and two units.	Intermediate gameplay	Wishlist implementations