Progress Report (04/28/2012)

First, happy birthday to my dear friend Genny! I'm sorry I can't celebrate with you, GM, but my love and best wishes are with you nonetheless. Have a good one!

OK, getting down to business: This entire week was sort of a micro-sabbattical/vacation to take a break from my job and other responsibilities so I could spend some time relaxing and some time focusing on my capstone. Both of those efforts were mostly successful.

The vacation aspect of this week involved exploring the American southwest in New Mexico and Arizona. I finally visited Roswell, enjoyed a lot of parks, trails, caves, and historical sites, and got to experience all kinds of great new things. As a game designer, I feel that it's vital to have a variety of real-life experiences because every single one of them has the potential to someday contribute to the design of a compelling player experience.

The sabbatical aspect involved making some tremendous progress on Milestone 2. My laptop makes my work portable, so I took advantage of the travel time in the car and quiet evenings in hotels and campgrounds to concentrate on one task at a time. Check this out:

Accomplishments:

• Implemented Combat Tokens
• Includes functionality for attack and defense.
• Is usable by humans and AI alike.
• Implemented Grenade Tokens
• The human troopers use them perfectly.  
• Has not yet been tested for AI troopers.
• Implemented Power Tokens
• All eight power tokens are now supported, but very little testing has taken place yet.
• Fought violently with an issue where the character objects are being accidentally duplicated somewhere so that the unit being used by the player (AI or human) and the unit on the server were two separate objects.  This problem has not yet been resolved.

Known Issues:

• Several intermittent bugs with taking turns, but all seem to be related to the same root cause -- the bug where character object references are somehow diverging onto different objects.
• Symptoms:
• Units sometimes do not get their action points reduced when performing actions.
• Drawn tokens may end up in the captain's inventory no matter who drew them.
• Proposed fix:
• Reacquire the reference to character object on each iteration through the AI loop and on each "advance" of the actions menu.
• Sometimes Client 0, the default name of the first network connection, appears as a player on the Lobby screen.
• 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:

• Broadcast combat results from the server.
• Display the Combat Results Summary screen. 
• Implement the Combat Results toggle.
• Fix the character reference bug listed above.

Medium Priority:

• Implement destructible containers.
• Add hazards and bonus spaces to the game board.
• Fix the broken map editor. 
• Record gameplay video.
• Write preliminary postmortem (capstone edition).

Low 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.
• Finish the level design guide.
• Finish asset lists for current set of level designs.
• Create the in-game chat component.
• But first, fix the issue with the lost messages by making the data structure static.
• 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!

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

Missing Requirements?

Today I was doing some requirements verification by looking over the game design document to make sure that my Milestone requirements are actually correct.  From the perspective of my capstone, they have to be because they've been incorporated into a binding contract with DePaul University, but that doesn't necessarily mean that they're properly aligned with the game's design.

Thankfully, all of the requirements that I included are indeed correct.  But there is a potential problem: I may have omitted two requirements that maybe should have been specified:  Grenades and the Heal action.  So the question is this: Do I write them in anyway even though they're not part of my independent study agreement, giving myself extra work to do before the deadline and possibly, hypocritically, exposing myself to further scope creep?  Or do I hold off until the capstone phase is over and throw them in later?  I love and hate both choices.

Grenade Tokens

Trooper units may have Grenade Tokens in their inventory that they can use during an attack.  These are played like normal Combat Tokens, but have special rules for how they affect the defending side.  (Specifically, that they do area damage and can't be blocked by the defender.)  The implementation of Grenade Tokens was omitted from Requirement 2.2, but it definitely belongs there.

Healing

The Heal action on the Actions Menu has not been implemented.  One complication here is that it doesn't seem to fit within any of the stripes defined by the three milestones.

• Milestone 1: Combat Initiation
• This is about validating player actions, setting up the attacker's input to the combat evaluator, and shipping the data off to the game server. Healing doesn't belong here.
• Milestone 2: Combat Resolution
• This is about getting the defender's response to an attack, computing the results according to the game rules defined in the GDD, and notifying the players of what happened.  Healing doesn't belong here either.
• Milestone 3: The Game World Environment
• This is about interactive things in the game world that influence the units or the teams in some way.  Healing happens straight from the inventory except when...hey, wait a minute.  One of the random events in the game world is "Found a snack" which restores one hit point to the unit who encounters it. That's the same thing that the Heal action does except it doesn't require the player to sacrifice a Heal Token.  

Maybe I'll slip this requirement into Milestone 3...or maybe I'll just let it slide and implement it when the capstone phase is over because it doesn't really fit here either.

The Very First Successful Attack!

My friends, this is a momentous occasion in the history of Team Laser Combat.  Just now, for the very first time ever, an attack was successfully processed in its entirety.  My character, Captain Karen of the Blue Team, attacked Officer May of the Green Team.  As you can see by May's health bar in the lower left corner of the screen, she actually took damage!

Coincidentally, this also shows that the health bars work.

Here's exactly what happened:  When it was my turn, I moved Karen so she had a clear shot at May.  I clicked the Attack button, clicked the arrow pointing toward May, and then chose my most powerful offensive Combat Token.  As a result, May's health was decreased by a lot!

Success!

Progress Report (04/14/2012)

I haven't been doing these "traditional" progress reports lately because the project and I are now in "capstone phase." So, as you may have noticed, we're doing things a little bit differently.  The sprints are now more tightly focused and the urgency of progressing each week has multiplied exponentially.

Still, I think it's important that the quality of the project management documentation is maintained if not improved.  Milestone 1 of 3 concluded last week and Milestone 2 is now being planned, so this seems like a good time to post one of my regular progress reports to mark the occasion and bridge the three-month gap between pre-capstone and post-capstone development phases.

So here's a progress report in the old, familiar style.

Accomplishments:

• Fixed the bug where AI players would continually ask the server for movement points even when it wasn't their turn.
• Made the inventory screen customizable for attacking and defending.
• Added validation to the Actions menu.
• Implemented the Attack action on the client side.  Server side support still needs to be completed and tested.
• Implemented the Auto Attack option.
• Uncovered several more defects for the bug list.

Known Issues:

• AI players occasionally perform more actions than they should be allowed.
• Sometimes Client 0, the default name of the first network connection, appears as a player on the Lobby screen.
• The only action that appears in the Event Log for AI players is movement.  Drawing tokens and attacking are not being reported correctly to the Event Log.
• 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:

• Implement the Defend interface.
• Create the combat evaluator in the server.
• Broadcast combat results from the server.
• Make clients respond to combat results by showing indications on screen (special effects, event log updates, etc.).
• Fix the Event Log so it shows all player actions.

Medium Priority:

• Display the Combat Results Summary screen.
  
• Implement the Combat Results toggle.
• Implement destructible containers.
• Add hazards and bonus spaces to the game board.
• Fix the broken map editor. 

Low 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.
• Finish the level design guide.
• Finish asset lists for current set of level designs.
• Create the in-game chat component.
• But first, fix the issue with the lost messages by making the data structure static.
• 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!

Milestone 2 Dependencies

Assuming that I go forth with the phases described in my last post (and I am assuming that), there is a certain order in which the phases must be completed.  That is, until I finish Phase 2.  Then I'll have a choice between Phases 3, 4, and 5, which all depend on 2 but don't necessarily depend on each other.  I have some time to think about which I'll do first because I won't arrive at that particular decision point for quite a while still.

I expect this (barely adequate) Pert chart to guide some of my decisions as I work my way through this milestone.

Six phases in five weeks.  Can it be done?  That's not a rhetorical question!

Planning Milestone 2

With Milestone 1 out of the way, Milestone 2 now looms. From my current vantage point, it looks like a pretty steep mountain to climb, so let's see if I can find a way to break it down into something manageable.  Some of the following chunks are a bit large to be called "bite-sized", but they do provide a logical division of related functionality so I'm going to try to move forward with this plan.

• Phase 1:  Completing the UI for player-controlled combat factors.
• Requirement 2.1
• Phase 2:  Combat using basic Combat Tokens.
• Requirements 2.2 and 2.2.1
• Phase 3:  Offensive Power Tokens
• Requirements 2.2.2, 2.2.3, 2.2.4, and 2.2.5
• Phase 4:  Defensive Power Tokens
• Requirements 2.2.6, 2.2.7, 2.2.8, and 2.2.9
• Phase 5:  Handling combat results
• Requirements 2.3, 2.4, and 2.5
• Phase 6:  Auto Defense and the Event Log
• Requirements 2.6, 2.7, and 2.8

Here's the complete set of requirement statements, expanded for clarity.

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	The combat evaluator shall process Combat Tokens for their basic attack and defense values.
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.
2.2.3	The combat evaluator shall process the Lucky Shot Power Token | If the attack does damage, the damage amount is doubled.
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.
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.
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.
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
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.
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.
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 1 Complete!

In a fortuitous event rarely seen in the software industry, Milestone 1 was completed on schedule.

You don't believe me?  I don't blame you; I wouldn't either if I hadn't verified it myself.  But it's true, all stated requirements in the scope of Milestone 1 have been implemented.

When I get a chance to return to the project (probably later in the week), I'll try to break Milestone 2 apart into phases as I did for Milestone 1.  I'm not sure if it has the same clear divisions, but I'll see what I can do.  One thing I know for sure about 2 is that it's easily the most difficult and complex of the three milestones, so a respectable design process is justified.

And by the way...HAPPY EASTER!

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.

Requirement 1.3 in Progress

I spent all day today working on Requirement 1.3 (aka Milestone 1, Phase 2).  I estimate that it's about 75% done.  Part of the validation is working and the directional buttons and labels are showing up correctly.  Check it out:

Captain Tom of the Blue Team has a combat token and, as the labeled arrows indicate, a clear shot at two enemies:  Matt and Debra of the Yellow Team.  Of course, he's also in their line of sight too, which will be a bad place to be once they're actually able to attack.

Here's what's remaining before this phase is complete:

• The validation rules need to be completed.  Right now, they consider any character to be a target, including your own teammates.
• The arrows need to respond to mouse clicks by tracing the line of sight to get a reference to the chosen target and then storing it somewhere temporarily so it can be transmitted to the game server along with the selected combat token to finish the combat interaction.

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!