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

Project Proposal

My project proposal has been formally accepted by the university.  Click here to read the latest draft.

I know that my readers are smart people.  (In fact, at least one of my regular visitors to this blog has a Ph.D.)  I also know that you're not all game developers and may not be familiar with all of our "geek speak."  Some of the people who were kind enough to review my proposal for me were also not game developers and had questions about some of the abbreviations that I used, so here's a brief explanation of the abbreviations used in the document referenced above, as well as in my previous blog post.

• GDD:  Game Design Document -- A non-technical document written in "plain English" that provides the overall creative view of a game by describing the rules, challenges, characters, locations, story, and all of the other things that will go into the game.
• UI:  User Interface -- The things you see on screen that provide information and/or things that let you enter data by typing, pressing keys, clicking on things, etc.
• IFF:  If and only if -- an expression from discrete mathematics which asserts that something is true when a correlating condition is true.
• HUD:  Heads-Up Display -- the part of the UI that visually overlays the game screen and provides additional information about things in the game world.  In many games, this includes things like lives, ammo counts, health levels, mini-maps, etc.

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

Progress Report (03/03/2012)

I only had one evening this week to work on this project, and I shouldn't have taken even that much time.  The rest of the week was squandered in a futile effort to catch up on my job and grad school, neither of which was completely successful.  Still, the few short hours that I spent on it did bear fruit, so all was not lost.

Accomplishments:

• The AI players wait their turn before issuing commands. 
• The AI characters wait their turn before moving.
• Fixed the bug where units were getting stuck in place.
• Designed the client/server communication protocol and data structures for how the Attack command will be validated and initiated.  
• Still to do: Decide on the best way to handle combat results. Can probably just use the combat summary data and let the clients figure out what to display/animate based on that information.

Known Issues:

• The game gets stuck in the lobby if the host is a spectator rather than a player.
• Several bugs specific to Join LAN mode:
• Network latency causes character upgrades to not show up right away.  The client needs to wait for the updated character to return from the server before returning to the team screen.
• The lobby doesn't turn control over to the player until the host has signaled ready. (I believe this is the exact same bug mentioned above that traps players in the lobby.)
• Chat messages get lost when switching between the lobby and the team/character configuration screens.
• When a player drops off, their team data is orphaned.  The server needs to recognize this and place the orphaned team under AI control.

Next Steps:

High Priority:

• Make the inventory screen customizable for attacking and defending.
• Implement the Attack action.
• Implement destructible containers.
• Add validation to the actions menu so that unavailable actions have a different appearance.

Medium Priority:

• Investigate ways to dynamically color the team uniforms.  Experiment on the placeholders.
• If this works, add the ability to dynamically color MHFont objects too.
• Add hazards and bonus spaces to the game board.
• Finish the level design guide.
• Finish asset lists for current set of level designs.

Low Priority:

• Create the in-game chat component.
• But first, fix the issue with the lost messages by making the data structure static.
• Implement the Defend interface.
• Model the characters.
• Animate the characters using Shaun Hager's animations.
• Add sound effects to the actions menu buttons.
• Implement the Heal action.
• Finish the "whose turn" display.
• Finish voice scripts for narration.
• Finish the team creation screen.
• Put in the floor image for the captains to stand on.
• Replace plain gray buttons with captain character images.
• Let's see if we can allow the player to change video modes dynamically from the options screen so they don't have to close the program and rerun it to change resolutions.
• Design the web site.
• Get coin display graphics from the former art team.
• Add it to the team configuration screen.the character configuration screen and the recruitment screen.
• Replace the temporary column header graphic on the character equip screen.
• Test and troubleshoot the multiplayer modes.

Click here to check out
The Indie Video Game Developers Association!