Saturday, June 2, 2012

Final Delivery Checklist (Complete!)

AT LAST IT IS DONE!  All I have to do now is turn it in.

No, not the game.  Just the capstone phase of it.  There is still quite a bit left to do in order to make this into an actual, desirable product.  Lots of threading issues mostly, but also a little refactoring and a TON of testing and asset creation.

But let's not think about that now.  Tonight we celebrate!  See my final video on YouTube.


Final Delivery Checklist

DeliverableDone?
Demo video showing all major features and gameplay.Yes
Project blog (You're lookin' at it.)Yes
5-8 page post mortem / reflection paper on the projectYes
Executable buildYes

Tuesday, May 29, 2012

Final Delivery Checklist (3/4 Complete)


The postmortem is complete!  Click here to read it if you'd like.  Only one more bit of "homework" to do and then I can graduate!


Final Delivery Checklist

DeliverableDone?
Demo video showing all major features and gameplay.No
Project blog (You're lookin' at it.)Yes
5-8 page post mortem / reflection paper on the projectYes
Executable buildYes

Monday, May 28, 2012

Final Delivery Checklist (1/2 Complete)

The build scripts have been repaired and updated to reflect the new package structure of the MHFramework engine and the newly added directories in Team Laser Combat.  I can once again build a stand-alone version of the game.

Final Delivery Checklist

Deliverable Done?
Demo video showing all major features and gameplay. No
Project blog (You're lookin' at it.) Yes
5-8 page post mortem / reflection paper on the project No
Executable build Yes

Sunday, May 27, 2012

Final Delivery Checklist (1/4 Complete)

In order for my work on TLC to be evaluated as my Master's capstone, I must submit the following deliverables per the independent study agreement with Professor Keenan.  This is my primary objective for the week...along with my suffocating workload, of course.


Final Delivery Checklist

Deliverable Done?
Demo video showing all major features and gameplay. No
Project blog (You're lookin' at it.) Yes
5-8 page post mortem / reflection paper on the project No
Executable build No

Saturday, May 26, 2012

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 

Thursday, May 24, 2012

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

Friday, May 18, 2012

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

Thursday, May 17, 2012

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


Wednesday, May 16, 2012

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.

Tuesday, May 15, 2012

Combat Results Screen

I'm trying hard to catch up to the project timeline, and though I'm making some decent progress, I'm not there yet.  Tonight I implemented the Combat Summary screen, though it's not 100% finished yet.

Specifically, the things that are not finished are:
  • The "Close" and "Don't Show Again" buttons are still missing.
  • The Power Token descriptions are not yet being populated.
  • The Combat Results toggle is currently being ignored.
Once these things are finished, then Requirements 2.3, 2.4, and 2.5 will be complete.  Aside from these, the screen is working beautifully! Here are two examples:





Sunday, May 13, 2012

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

Milestone 2 Target is Today

My fears may be coming true. Today was the target completion date for Milestone 2 and I didn't quite make it. The day's not over, but I also have a considerable task list of things to do for my job today, so I'm going to work on Milestone 2 this afternoon and see how far I can get before switching over to work-related tasks this evening.  It was, in fact, my oppressive work load that has keep me from progressing on Team Laser Combat in these last two weeks, so I desperately need to catch up to the project timeline.

There was a huge breakthrough this morning, however.  I spent all day yesterday working on a series of horrible bugs that seemed invincible.  From the time I woke up until the time I went back to bed, it was nothing but troubleshooting (intermixed with taking care of my baby son, of course).  But this morning, I had an epiphany that included multiple solutions to multiple bugs.  I tried the ideas, and they worked on the first try!

Details will follow in the next official progress report, after I get a chance to try my hand at those last remaining requirements in Milestone 2.


Friday, May 4, 2012

Grenades Work!

I'm having a teeny tiny little celebration here because I now have proof that GRENADES WORK!

Look at the screen shot below.  The Blue Team was lucky enough to have a grenade in the troopers' inventory from the initial token draw before the match began.  The Pink Team had not yet moved, so all of their members were standing together in a group.  Trooper Lucien had a clear shot at them, so he launched a grenade over there and voila!  All Pink Team members took damage!

One attack by Trooper Lucien of the Blue Team damaged every member of the Pink Team. Grenades FTW!



Saturday, April 28, 2012

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.

Friday, April 20, 2012

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

Monday, April 16, 2012

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.


Sunday, April 15, 2012

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!

Saturday, April 14, 2012

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.