Reconsidering TLC's Game Theory (and Other Stuff)

Ever since I used TLC to satisfy my master's degree capstone requirements, I've had one big question on my mind:

Could Team Laser Combat work as a console game?  

I believe it could, but it may require a fundamental change in its game theory elements.  The design, as it stands right now, is based heavily on imperfect information in which there are things about your opponents that you do not know.  However, as a console game, the competitors would sit side-by-side and see all of each other's resources, upgrades, and token selections.  It would be sort of like playing cards with all of the players' hands exposed.

Over the last couple of years, I have been considering ways to change the game rules in such a way to maintain the fundamental aspects of the game while also making it work as a console game.  (Perhaps it could even be a mobile game with a hot-seat mode, but let's not get ahead of ourselves.)

These are the changes that I believe would transform the game from its current design into one that would work in a local multiplayer setting.

Remove the networking functionality.

This is a change that I am quite eager to make as this is the reason why the project "failed".  The unreliable networking code was the thing that made the software so hard to test, and the challenge upon which I got stuck before taking a break from the project.  Local multiplayer, as you would have on a console, eliminates the need for remote communication.  I would probably keep the client/server arrangement, but communication would happen through the MHFramework engine's messaging system rather than broadcast network messages.

Redesign the control scheme to use key presses instead of (or in addition to) mouse clicks.

The OUYA controller, for instance, uses a key listener to respond to buttons pressed on the controller.  One of the first things to do would be to change the current mouse-driven interface to one that uses key presses instead.

Redesign the Actions menu to make it more linear for easy selection by key presses.

Since the Actions menu was designed for mouse clicks, there was no reason not to make it a cool little hexagon that highlighted the current unit and displayed its available actions.  If we change the input device to an OUYA game controller, this layout will no longer be intuitive.  We would need to either change it to a menu from which we could select commands, or just display a controller reference to show which buttons map to which commands.

Here's one possible control scheme, but I'm open to other ideas as well.

Attack	Heal	Draw Token
Move	Select Previous Unit	Select Next Unit

Take away the Auto Attack option and make it the normal behavior.

The real problem with making this a local multiplayer game is the unfortunate necessity to reveal a player's combat tokens to his/her opponent when selecting an attack or a defense.  If I took away the Auto Attack option and just made that the normal behavior of the Attack command, then the mystery would be somewhat preserved.  I would leave Auto Defense as an option like it is now so that players can speed up and simplify the game if they so desire.

Separate the global game options from the player-specific options.

The final major piece that I would be forced to change would be the game options.  Some options would be global, such as the sound options, while others could be set differently for each player, such as the Auto Defense option.

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
Deliverable	Done?
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 project	Yes
Executable build	Yes

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
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	Yes
Executable build	Yes

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

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

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.