Wednesday, March 28, 2012

Capstone Begins At Last!

This week begins my final term as a graduate student of DePaul University's College of Computing and Digital Media.  My capstone project is...(drumroll, please)...Team Laser Combat!  (Surprise!)

Specifically, it's the gameplay aspect of Team Laser Combat.  These milestones will lead step-by-step to a functionally complete alpha version of the game in which all gameplay details are implemented for a small set of levels.  The final deliverable will, at the very least, provide a one level, single-player game that offers working implementations of every single element of the gameplay experience.

I have defined the three required milestones as follows:

  1. Combat Initiation
  2. Combat Resolution
  3. The Game World Environment

Below are the associated requirements for these milestones as they stand right now.  Further refinement is likely, however.


Milestone 1: Combat Initiation

Requirement ID Description Dependencies
1.1 The system shall perform a pre-validation of actions available to the player when it is that player’s turn. None.
1.2 The system shall construct a UI (the Actions Menu) which allows the selection of an available action based on validation results. 1.1
1.3 If the Attack action is available and is selected from the Actions Menu, the system shall display the directions in which an attack is possible and allow selection of one of these directions. 1.2
1.4 The system shall provide an Auto Attack option that players may select if they would rather have the game select their tokens for them automatically after issuing the Attack command. 1.3
1.5 After the player has selected a direction for attack, the system shall display the offensive combat tokens from the player’s inventory and allow the selection of a token to spend IFF the Auto Attack option is turned off. 1.4
1.6 AI players shall be able to issue Attack commands that are subject to the same validation rules as the human players. 1.4

Milestone 2: Combat Resolution

Requirement ID Description Dependencies
2.1 When a unit is attacked, the system shall notify the player controlling the unit by presenting a Defend UI which allows selection of a defensive combat token from the player’s inventory. 1.5
2.2 The game server shall resolve combat interactions by evaluating the stats of the characters and their selected combat tokens and updating the data model accordingly. 2.1
2.2.1 – 2.2.9 The game server’s combat evaluator shall handle all combat token types: the basic combat tokens, the four types of offensive Power Tokens, and the four types of defensive Power Tokens as detailed in the GDD. 2.1
2.3 The game server shall broadcast a summary of combat results to all connected players. 2.2
2.4 The system shall provide a Combat Results toggle that allows players to opt out of seeing the detailed combat summaries at the conclusion of each combat interaction. 2.3
2.5 The user interface shall display a combat summary screen when combat results are received from the game server IFF the Combat Results option is turned on. 2.3, 2.4
2.6 The system shall provide an Auto Defense option that players may activate if they would rather have the game select their tokens for them automatically when their units are attacked. 2.1
2.7 The system shall display an event log on the HUD which records the actions taken by all units in the game. 2.3
2.8 AI players shall be able to defend against attacks subject to the same rules as the human players. 2.6

Milestone 3: The Game World Environment

Requirement ID Description Dependencies
3.1.1 - 3.1.6 The system shall place six bonus items in random, unobstructed locations on the game board at the start of each match: a coin, a token, a snack, a weapon upgrade, an armor upgrade, and a boot upgrade. None.
3.2.1 - 3.2.6 When a unit travels onto a space occupied by a bonus item, the system shall apply the effect of the item to the unit or the unit’s team as detailed in the GDD. 3.1
3.3 The system shall remove a bonus item from the board after its effect has been applied. 3.2
3.4 The system shall place one invisible hazard in a random, unobstructed location on the game board at the start of each match. None.
3.5 When a unit travels into the space occupied by the random hazard, the system shall deduct one hit point from the unit. 3.2
3.6 When a unit is damaged by a random hazard, the user interface shall display a notification to all players indicating which unit was damaged but not revealing which space contains the hazard. 3.5
3.7 While loading the data from a map file, the system shall recognize identifiers for destructible containers and instantiate them onto the board accordingly. None.
3.8 The attack validator shall recognize destructible containers as valid targets to be attacked. 1.1
3.9 When a container is attacked, it is removed from the board and replaced by a random bonus item: a coin, a token, a snack, a weapon upgrade, an armor upgrade, or a boot upgrade. 3.1, 3.8

No comments:

Post a Comment