Milestone 3 Complete!

Milestone 3 is complete!  It took about 16 hours of effort today plus about another six or so last weekend.  So, about 20 to 25 hours total.  Funny, that's less than one week's worth of effort when I couldn't complete Milestone 2 in a month and a half.

So now I have a choice to make:

1. Start wrapping up the documentation and the gameplay video now to make sure I hit next week's deadline.  This is the stuff I'm getting graded on for my capstone requirement.
2. Try to fix those defects in some of Milestone 2's Power Tokens. There are just a few that don't work quite right.
3. Add some better graphics for the items on the floor from Milestone 3. The placeholders I have now are confusing.

I'll decide later. Too tired now.

Here's the recap of Milestone 3:

Milestone 3: The Game World Environment
Requirement ID	Description	Status
3.1.1	The system shall place a coin bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.2	The system shall place a token bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.3	The system shall place a snack bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.4	The system shall place a weapon upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.5	The system shall place an armor upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.6	The system shall place a boots upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.2.1	When a unit travels onto a space occupied by a coin, the system shall add one coin to that unit's team's budget.	Complete
3.2.2	When a unit travels onto a space occupied by a token, the system shall draw one random token from the team's token source and add it to the team's inventory.	Complete
3.2.3	When a unit travels onto a space occupied by a snack, the system shall add one point to the unit's health up to that unit's maximum.	Complete
3.2.4	When a unit travels onto a space occupied by a weapon upgrade, the system shall apply a free upgrade to that unit's weapon.	Complete
3.2.5	When a unit travels onto a space occupied by an armor upgrade, the system shall apply a free upgrade to that unit's armor.	Complete
3.2.6	When a unit travels onto a space occupied by a boots upgrade, the system shall apply a free upgrade to that unit's movement stats.	Complete
3.3	The system shall remove a bonus item from the board after its effect has been applied.	Complete
3.4	The system shall place one invisible hazard in a random, unobstructed location on the game board at the start of each match.	Complete
3.5	When a unit travels into the space occupied by the random hazard, the system shall deduct one hit point from the unit.	Complete
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.	Complete
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.	Complete
3.8	The attack validator shall recognize destructible containers as valid targets to be attacked.	Complete
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.	Complete

Milestone 3 in Progress

Nearly a week after starting Milestone 3, a good number of the requirements are either complete or well on their way.

What's my secret, you wonder?  First of all, Milestone 3 was the simplest milestone by design. I did that on purpose just in case the monstrous Milestone 2 overflowed its bounds...which it did.  And second, I went out of town last weekend to a place with no internet access, so I couldn't work on my job duties.  That meant that the only productive thing I could do was work on TLC, so I hit it hard and fast!

In summary, there are 19 individual requirements in all, of which:

• 11 are completely finished
• 5 have been implemented but not yet tested
• 3 have not yet been started

Milestone 3: The Game World Environment
Requirement ID	Description	Status
3.1.1	The system shall place a coin bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.2	The system shall place a token bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.3	The system shall place a snack bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.4	The system shall place a weapon upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.5	The system shall place an armor upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.1.6	The system shall place a boots upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	Complete
3.2.1	When a unit travels onto a space occupied by a coin, the system shall add one coin to that unit's team's budget.	Untested
3.2.2	When a unit travels onto a space occupied by a token, the system shall draw one random token from the team's token source and add it to the team's inventory.	Complete
3.2.3	When a unit travels onto a space occupied by a snack, the system shall add one point to the unit's health up to that unit's maximum.	Untested
3.2.4	When a unit travels onto a space occupied by a weapon upgrade, the system shall apply a free upgrade to that unit's weapon.	Untested
3.2.5	When a unit travels onto a space occupied by an armor upgrade, the system shall apply a free upgrade to that unit's armor.	Untested
3.2.6	When a unit travels onto a space occupied by a boots upgrade, the system shall apply a free upgrade to that unit's movement stats.	Untested
3.3	The system shall remove a bonus item from the board after its effect has been applied.	Complete
3.4	The system shall place one invisible hazard in a random, unobstructed location on the game board at the start of each match.	Complete
3.5	When a unit travels into the space occupied by the random hazard, the system shall deduct one hit point from the unit.	Complete
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.	Complete
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.	Not started
3.8	The attack validator shall recognize destructible containers as valid targets to be attacked.	Not started
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.	Not started

Milestone 3, Here I Come

Bad news about Milestone 2. Apparently, in order to correct the defects listed in the last post, I will have to redesign the combat evaluator to separate more of the functionality into different methods for handling the more specialized Power Tokens. Since the project is already behind schedule, what can I do about this?

Nothing, I'm afraid. My current strategy is to document the defects in the Milestone 2 requirements and move on to Milestone 3. I will return to the combat evaluator at the end of the capstone phase if there is time. Otherwise, the capstone version of TLC will simply be known to be defective, and these defects will be corrected post-graduation.

So I'm turning my attention to Milestone 3 now, which is defined as follows:

Milestone 3: The Game World Environment
Requirement ID	Description	Dependencies
3.1.1	The system shall place a coin bonus item in a random, unobstructed location on the game board at the start of each match.	None.
3.1.2	The system shall place a token bonus item in a random, unobstructed location on the game board at the start of each match.	None.
3.1.3	The system shall place a snack bonus item in a random, unobstructed location on the game board at the start of each match.	None.
3.1.4	The system shall place a weapon upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	None.
3.1.5	The system shall place an armor upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	None.
3.1.6	The system shall place a boots upgrade bonus item in a random, unobstructed location on the game board at the start of each match.	None.
3.2.1	When a unit travels onto a space occupied by a coin, the system shall add one coin to that unit's team's budget.	3.1.1
3.2.2	When a unit travels onto a space occupied by a token, the system shall draw one random token from the team's token source and add it to the team's inventory.	3.1.2
3.2.3	When a unit travels onto a space occupied by a snack, the system shall add one point to the unit's health up to that unit's maximum.	3.1.3
3.2.4	When a unit travels onto a space occupied by a weapon upgrade, the system shall apply a free upgrade to that unit's weapon.	3.1.4
3.2.5	When a unit travels onto a space occupied by an armor upgrade, the system shall apply a free upgrade to that unit's armor.	3.1.5
3.2.6	When a unit travels onto a space occupied by a boots upgrade, the system shall apply a free upgrade to that unit's movement stats.	3.1.6
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

Milestone 2 Inches Forward

As another night comes to a close, Milestone 2 draws ever closer to completion.  Here's an updated view of the status of the requirements.

In summary:

• 13 complete
• 3 defective
• 2 inconclusive

Milestone 2: Combat Resolution
Requirement ID	Description	Status
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.	Complete
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.	Complete
2.2.1	The combat evaluator shall process Combat Tokens for their basic attack and defense values.	Complete
2.2.2	The combat evaluator shall process the Vampire Power Token | If the attack does damage, the attacker heals one hit point per unit of damage dealt.	Defective
2.2.3	The combat evaluator shall process the Lucky Shot Power Token | If the attack does damage, the damage amount is doubled.	Complete
2.2.4	The combat evaluator shall process the Desperation Power Token | The attack value is normally 4, but if the attacker is the only remaining member of the team, then the attack value is 10.	Complete
2.2.5	The combat evaluator shall process the Blaze of Glory Power Token | If the attack does damage, the damage amount is doubled, but if the attack is blocked, the attacker takes 5 points of damage.	Complete
2.2.6	The combat evaluator shall process the Reflection Power Token | Any attack, regardless of power, is reflected back at the attacker. The defender takes no damage.	Defective
2.2.7	The combat evaluator shall process the Resolve Power Token | Defense value goes up as the character health goes down. DF = maxHP - currentHP	Inconclusive
2.2.8	The combat evaluator shall process the Lucky Break Power Token | If the attack is blocked, any excess defense points are converted to health points for your unit.	Inconclusive
2.2.9	The combat evaluator shall process the Shatter and Scatter Power Token | If the attack is blocked, each member of the attacking team takes two points of damage.	Defective
2.2.10	The combat evaluator shall process Grenade Tokens | The attack functions like a Combat Token but cannot be blocked, has no defense value, and does two points of damage to all characters or containers within a two-meter radius of the primary target.	Complete
2.3	The game server shall broadcast a summary of combat results to all connected players.	Complete
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.	Complete
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.	Complete
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.	Complete
2.7	The system shall display an event log on the HUD which records the actions taken by all units in the game.	Complete
2.8	AI players shall be able to defend against attacks subject to the same rules as the human players.	Complete

Milestone 2: A New Hope

I'm feeling better about things now. The project is recovering, though it's still at risk because the Milestone 2 effort has consumed about one-third of the Milestone 3 budget so far, with more to come.  My goal for the remainder of this week is to finish testing all of the Power Tokens, fix the Auto Defense and Combat Results toggles, and correct any other issues discovered in the meantime.

If I cannot get all of Milestone 2 accomplished by the end of the week, I'm going to shelve it temporarily and move on to Milestone 3.  I figure that it's better to have all three milestones mostly complete than to have one that's entirely absent.

Below is an updated status of the Milestone 2 requirements as they stand right now. In summary, here are the stats:

• All 18 requirements of Milestone 2 have been verified.
• 11 requirements have been validated successfully.
• 3 requirements had inconclusive test results.
• 4 requirements are defective.

Milestone 2: Combat Resolution
Requirement ID	Description	Status
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.	Complete
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.	Complete
2.2.1	The combat evaluator shall process Combat Tokens for their basic attack and defense values.	Complete
2.2.2	The combat evaluator shall process the Vampire Power Token | If the attack does damage, the attacker heals one hit point per unit of damage dealt.	Inconclusive
2.2.3	The combat evaluator shall process the Lucky Shot Power Token | If the attack does damage, the damage amount is doubled.	Complete
2.2.4	The combat evaluator shall process the Desperation Power Token | The attack value is normally 4, but if the attacker is the only remaining member of the team, then the attack value is 10.	Complete
2.2.5	The combat evaluator shall process the Blaze of Glory Power Token | If the attack does damage, the damage amount is doubled, but if the attack is blocked, the attacker takes 5 points of damage.	Complete
2.2.6	The combat evaluator shall process the Reflection Power Token | Any attack, regardless of power, is reflected back at the attacker. The defender takes no damage.	Defective
2.2.7	The combat evaluator shall process the Resolve Power Token | Defense value goes up as the character health goes down. DF = maxHP - currentHP	Inconclusive
2.2.8	The combat evaluator shall process the Lucky Break Power Token | If the attack is blocked, any excess defense points are converted to health points for your unit.	Inconclusive
2.2.9	The combat evaluator shall process the Shatter and Scatter Power Token | If the attack is blocked, each member of the attacking team takes two points of damage.	Defective
2.2.10	The combat evaluator shall process Grenade Tokens | The attack functions like a Combat Token but cannot be blocked, has no defense value, and does two points of damage to all characters or containers within a two-meter radius of the primary target.	Complete
2.3	The game server shall broadcast a summary of combat results to all connected players.	Complete
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.	Defective
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.	Complete
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.	Defective
2.7	The system shall display an event log on the HUD which records the actions taken by all units in the game.	Complete
2.8	AI players shall be able to defend against attacks subject to the same rules as the human players.	Complete

It just occurred to me as I was updating the requirements status list that the inconclusive Power Token tests all involve a specialized modification or referencing of a unit's health in a way that is beyond the basic processing of a combat interaction. I wonder if that's a coincidence or if there's a common root cause of a defect. More testing will happen ASAP to find out.

Timeline Threatened!

I have no more time today to work on TLC. I must stop and get back to my job.  I made some progress and did some testing, but the milestone has not yet been reached.

This unavoidably impacts the timeline by eating into the Milestone 3 budget.  My only hope is to get through my work as quickly as I can this week so I can spend as much time as possible on the completion of Milestone 2...and, of course, the subsequent start on Milestone 3.

Here's a status report of all Milestone 2 requirements as I'm leaving them today.

Milestone 2: Combat Resolution
Requirement ID	Description	Status
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.	Complete
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.	Complete
2.2.1	The combat evaluator shall process Combat Tokens for their basic attack and defense values.	Complete
2.2.2	The combat evaluator shall process the Vampire Power Token | If the attack does damage, the attacker heals one hit point per unit of damage dealt.	Test inconclusive
2.2.3	The combat evaluator shall process the Lucky Shot Power Token | If the attack does damage, the damage amount is doubled.	Complete
2.2.4	The combat evaluator shall process the Desperation Power Token | The attack value is normally 4, but if the attacker is the only remaining member of the team, then the attack value is 10.	Untested
2.2.5	The combat evaluator shall process the Blaze of Glory Power Token | If the attack does damage, the damage amount is doubled, but if the attack is blocked, the attacker takes 5 points of damage.	Complete
2.2.6	The combat evaluator shall process the Reflection Power Token | Any attack, regardless of power, is reflected back at the attacker. The defender takes no damage.	Test inconclusive
2.2.7	The combat evaluator shall process the Resolve Power Token | Defense value goes up as the character health goes down. DF = maxHP - currentHP	Complete
2.2.8	The combat evaluator shall process the Lucky Break Power Token | If the attack is blocked, any excess defense points are converted to health points for your unit.	Test inconclusive
2.2.9	The combat evaluator shall process the Shatter and Scatter Power Token | If the attack is blocked, each member of the attacking team takes two points of damage.	Test inconclusive
2.2.10	The combat evaluator shall process Grenade Tokens | The attack functions like a Combat Token but cannot be blocked, has no defense value, and does two points of damage to all characters or containers within a two-meter radius of the primary target.	Complete
2.3	The game server shall broadcast a summary of combat results to all connected players.	In progress
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.	In progress
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.	Designed; not implemented
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.	Test failed
2.7	The system shall display an event log on the HUD which records the actions taken by all units in the game.	Complete
2.8	AI players shall be able to defend against attacks subject to the same rules as the human players.	Complete

Redefining Milestone 2, Phase 2

I have made a decision regarding the missing requirements that I explained in my last post. Implementation of the Heal Action will be postponed until the relevant Milestone 3 requirements have been implemented and verified, and the Grenade Token functionality will be incorporated into Milestone 2, Phase 2, which I am currently working on. Grenade Tokens have been assigned their own requirement statement as follows:

Requirement 2.2.10: The combat evaluator shall process Grenade Tokens | The Grenade Token cannot be blocked, has no defense value (can only be used for attacking), and does two points of damage to all characters or containers within a two-meter radius of the target object. 

 So Milestone 2, Phase 2 is now defined like this:

• Phase 2:  Combat using basic Combat Tokens.
• Requirements 2.2, 2.2.1, and 2.2.10

Milestone 1, Phase 3 in Progress

This post is just a quick update on the status of Milestone 1 Phase 3.

Requirement 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. 

Requirement 1.4 is complete.  The Auto Attack option exists and it functions correctly, both on the interface and in the data structures behind the scenes.

The in-game Options menu contains the Auto Attack option.  When it is turned on, players are not prompted to select a combat token to spend when attacking.  Instead, the game employs a simple but strategic algorithm to select one automatically.  This is the same logic that will be used by the AI when I get around to Requirement 1.6.

Requirement 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.

Requirement 1.5 is in progress.  The Inventory screen has been parameterized so that it can initialize itself appropriately for each of its three purposes:  viewing the inventory, selecting a token for attack, and selecting a token for defense.  It also allows selection of a combat token to spend on an attack.  The token is correctly removed from inventory when it is selected.

Here's a demonstration of the differences between the "view inventory" mode and the "select an attack token" mode.

In the normal mode, the Inventory screen does not allow a token to be selected.  Instead, it allows you to switch between viewing offensive and defensive tokens for each of the three character types.

When a player is attacking, the Inventory screen opens in a different mode that removes the buttons for switching between views.  The only way to interact with the screen in this mode is to click on a token to select it.

Remaining tasks in Requirement 1.5:

• Choosing the Attack action should deduct an action point.  It does not currently do this.
• Power Tokens should be selectable as well, but currently only Combat Tokens can be selected.

Requirement 1.6: AI players shall be able to issue Attack commands that are subject to the same validation rules as the human players.

I haven't really started this one yet.  It seems simple on the surface, but there are a number of really bad bugs in the limited functionality that the AI already has, and these may need to be addressed before this requirement is implemented.  Further investigation is necessary before I'll know for sure.

Milestone 1, Phase 2 Complete

Requirement 1.3 is verified and validated!  Here's the actual statement for reference:

Requirement 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.

When I left off on Monday, there were just a few details left unfinished...so I finished 'em.  The target validation works correctly for all conditions now, and the attack direction arrows are clickable.

This signals the end of Milestone 1, Phase 2.  So next I'm moving on to the final phase of Milestone 1, which consists of the following three requirements:

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.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.6	AI players shall be able to issue Attack commands that are subject to the same validation rules as the human players.

Milestone 1, Phase 1 Complete

The first phase of Milestone 1 is finished!  Seem fast?  Well, it was, but only because it was pretty easy stuff.  Phase 2 is significantly more difficult, but I'll get to that later.  First, a recap of Phase 1.

Requirement 1.1:  The system shall perform a pre-validation of actions available to a character when it is that character’s turn.
Of the four action commands that a player can give to a character, three require validation:  Heal, Move, and Attack.  That validation is now taking place with the following conditions:

• Heal:  Available if the character has taken damage and has at least one Heal Token in inventory.
• Move:  Available if the character can move at least one space in any of the four valid movement directions.
• Attack:  Available if the character has a line of sight to a valid target in any of the eight valid attack directions and has at least one Combat Token with offensive value.

Requirement 1.2:  The system shall construct a UI (the Actions Menu) which allows the selection of an available action based on validation results.

I may have cut some corners here, but I found a way to get this done without any dramatic changes or additional graphics.  My secret?  First, I validate on the client side instead of confirming everything through the server.  Second, I don't show disabled controls.  I just hide the buttons if the validation from Requirement 1.1 says they're not available.  It's not quite my original vision for the UI, but it'll do for now.  That sort of thing can be fixed in beta if feedback from testers seems to warrant it.

So now it's on to the next phase, which contains just one big, hairy requirement:

Requirement 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.

I'll tackle this one tomorrow.  Goodnight, world!

Embarking Upon Milestone 1

Alright, now that the initial paperwork is out of the way, it's time to hit the ground running.  Milestone 1 comes first, so let's break it down.

Everything in this milestone is related and interdependent.  The best plan of attack seems to be to break it apart into three separate phases like so:

• Phase 1:  Validation and handling of the Actions Menu
• Requirement statements 1.1 and 1.2
• The menu already exists but has no validation rules and no way to represent unavailable actions.  This will require new logic, graphics, data structures, and possibly some architectural modifications.
• Correction:  Requirement 1.1 should have said "character" instead of "player".  The validation rules are based on a character's state, not the player's.
• Phase 2:  The Attack Directions UI
• Requirement statement 1.3
• This is a significant design challenge if implemented the way it's described in the GDD because it shows not only the directions, but also labels them with the name of the target in each direction.
• Phase 3:  Selecting a token for the attack
• Requirement statements 1.4, 1.5, and 1.6
• This requires heavy modification of the existing inventory screen as well as parameterized initialization of it.

So this is how it's going to go.  Milestone 1, Phase 1 begins now!

Milestone 1: Combat Initiation
Requirement ID	Description	Dependencies
1.1	The system shall perform a pre-validation of actions available to a character when it is that character’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

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