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.

Designing the Token Display

The combat token system is a fairly complex thing, so it demands a fairly complex user interface...at least by this game's standards.

I've gone back and forth on this design for months, sketching layouts, making changes, considering trade-offs, and refusing to settle until I felt that the design was "just right". Well, I think I have a design that's "just right" now.

Below is a rough mock-up of what I have in mind.

This is what is going to happen when the user clicks the Tokens button on the button bar.

The three buttons at the top will allow the user to choose the unit type for whom he/she wishes to view the inventory of tokens.  For example, if the Captain button is clicked, the captain's tokens will be displayed.

Just below the buttons are the counts of how many Heal Tokens and Grenade Tokens are in this unit type's inventory.  Only Troopers have grenades, so this value should always be 0 for Captains and Officers.

Next is the Combat Tokens area. Regular Combat Tokens are stackable with counters, and will be displayed with their attack values in red, their defense values in blue, and the count in the lower right corner.  The Attack and Defense buttons will cause the tokens to be sorted by their attack and defense values respectively.

Below the Combat Tokens is the Power Tokens area.  If the display is sorted by attack, then only the aggressive Power Tokens will be displayed.  If sorted by defense, then only the defensive tokens will appear.

Right under the Power Tokens is a text area that will marquee-scroll the descriptions of the Power Tokens' effects when the mouse hovers over a Power Token.

So this is my plan. Hopefully by the end of the month we'll see it in action...and see how closely the final product ends up matching this low-fidelity prototype.

Redesigning the Engine's Network Client

Perhaps a good place to start the refactoring process would be in the engine itself.  How's this look for a redesign of the mhframework.net.client package?

Corrections to be made to this diagram:

• Declare sendMessage() in MHAbstractClient superclass.
• Remove sendToAll() -- that's a server function.
• Consider making MHLocalClient observable.  Or make an observable subclass of it.
• MHObservableClient needs separate lists of observers for system messages vs. game messages.

More to come...

Rethinking Single-Player Mode

As I mentioned in my last rant -- I mean, "blog post" -- the game needs to be refactored before I go any further.  So I'm starting with the change that will do the most good:  removing all networking code from the single-player game mode.

What's the Problem?

Since the game was primarily intended to be a multiplayer game, the single-player mode has been treated almost like an afterthought.  Basically, it's just the multiplayer game configured to have just one human player.  Seemed like a good idea at the time.  Unfortunately, this means that I'm not only troubleshooting data issues and gameplay logic, but I'm also at the mercy of the underlying network even when the only client is on the same machine as the server.

What's the Plan?

The plan, therefore, is to remove all networking functionality from the single player mode.  The question is "how?"  Well, I've got an idea.

The current chain of responsibility goes like this:

• TLCScreenBase is the base class from which all game screens are derived.  When a screen needs to update data, it calls out to TLCDataFacade.
• TLCDataFacade is the single point of contact for all data updates and retrievals for the entire system.  If the data to be updated must also be shared with the server or other players, the data facade hands it off to TLCGameClient.
• TLCGameClient is the intermediary between the local game instance and the network.  It takes responsibility for sending, receiving, and processing application-specific network messages, the actual transmission of which is handled at a slightly lower level by the engine's MHClientModule class.

My plan is to have TLCGameClient implement a version of the strategy pattern so that, upon instantiation, it will either create a true network client (as it's doing now) or it will create a simple object that "fakes" the network communication.  So in single-player mode (and perhaps even multiplayer hosting mode), the data will simply be communicated to the game server via method calls rather than being sent out on the network.  The server will implement a similar mechanism for communicating to local clients.

With this new system, the instantiation rule for each user role might be like this:

• Single-Player:  Local client
• AI Player:  Local client
• Host LAN:  Local client
• Join LAN:  Network client
• Spectator:  Network client

What Could Go Wrong?

• TLCDataFacade.  It currently contains a very complex mechanism for tracking individual data for multiple users.  This will not be necessary once the refactoring is complete, and should itself be refactored once the single player mode is separated from the networking functionality.  It should probably no longer be a singleton.
• TLCGameServer. Since the local clients won't be using network communication to talk to the server, then the server should not use it to talk back to the clients.  A protocol must be established for the server to know how it should be communicating with each client type.  (My first thought on this:  Keep a list of network connected clients only, and then broadcast to them whenever a change is made.  Local clients will simply share the data with the server.)

Candidates for Refactoring

It's official; Team Laser Combat is in serious need of a refactoring.  Because some elements of the original technical design were carelessly lost during implementation, the project has reached the a point where adding even simple pieces is becoming unnecessarily difficult.

The highest priority refactorings, as I see them, are these:

1. There is no reason whatsoever to have single player mode use network messages to communicate between the client and server.  The proxy pattern prescribed in the original tech design would solve a number of current frailties and intermittent failures, as well as improve performance..
2. The network modules really need to operate on a publish/subscribe model.  The observer pattern would greatly simplify the message handling code (which is a huge chunk of the system), eliminate some recurring errors, improve the functionality of the user interface, and go a long way to clean up the overall architecture of the client.
3. I may do away with the authoritative, standalone game server.  Not sure about this yet.  I fear that the added simplicity of the game client would come at the cost of testability.

So much to do, so little time!

Lessons Learned, Part 1

It's never too early to start a project's postmortem, and I've had a lot of thoughts floating around in my head of things I really want to remember for my next project.  I think I can keep these thoughts from becoming regrets if I record them and learn from them, so here's my first list of lessons learned in this project.

This is not to say that the project is over, of course.  It's far from it.  I just don't want to lose these valuable lessons in the meantime.

• First and most importantly, make all games data-driven from the start, even if they're only single-player.
• Along these lines, all objects in the game should have ID values of some sort that allow easier serialization, database storage, and network communication.
• Don't use networking code for single-player mode. Use the remote proxy pattern.  My original technical design specified this, but that detail was somehow lost once implementation began.
• This type of information loss is a crime! I must not let it happen again.
• Dynamic and finely-placed objects should not be part of game map structure.  The engine's map rendering algorithm uses coarse object placement as a matter of necessity, which makes it impossible for an object to lie randomly on the ground, or for a character to walk smoothly from one map cell to another.
• Network modules that receive messages should use the observer pattern.  This will enable different UI components to respond immediately to high-priority messages coming in without waiting for the rest of the messages to dequeue, and allow messages of different types to be sorted upon arrival.  (System messages versus chat messages versus character movement commands, etc.)
• Model-View-Controller principles are always relevant.  ALWAYS! Even beyond the basics of the Single Responsibility Principle.  Perhaps the high-level architecture should always begin this way and then evolve to fit the individual needs of each project. This may be worth further consideration.
• An unrelated discovery: sliding doors can be animated in real time by generating the image and cropping it. This is a profoundly good idea.
• Audio spatialization is crucial, especially when the entire game world doesn't fit on one screen. This shortcoming of the engine must be implemented before development of Beltzhian Marauders can begin.

There are sure to be more to come.  I know this doesn't cover them all!

Progress Report (08/20/2011)

The slim chance of finishing my degree earlier than anticipated has raised the priority of reaching the alpha stage on this project, so I've been forcing it into any free moment I can find lately!

Accomplishments:

• The players take turns correctly now.  That bug is dead and gone.
• Investigated the bug with the actions menu, but the problem still remains.  Something is keeping the human players' characters from performing two actions back-to-back unless the actions menu is artificially refreshed.  
• I put over three hours into troubleshooting this problem and still haven't found a solution.  Fortunately, as I mentioned in my previous post, there is an easy workaround by either trying again or refreshing the menu.
• Discovered a bug that's only possible when you have multiple characters on your team.  As long as you leave one of your characters stationary, then your other characters can move an unlimited number of times until you move your stationary character and use up his action points.  Should be an easy fix, but I haven't tackled that one yet.
• Gave the design doc an overhaul to update it with the recent requirement changes and fill in some of the "to do" items.  The new game design document is version 2.3.

Known Issues:

• Something is keeping the human players' characters from performing two actions back-to-back unless the actions menu is artificially refreshed.  
• The game gets stuck in the lobby if the host is a spectator rather than a player.
• As long as you leave one of your characters stationary, then your other characters can move an unlimited number of times until you move your stationary character and use up his action points.
• Sometimes network errors will cause an AI to be disconnected immediately after it connects.
• 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 in multiplayer mode doesn't turn control over to the player until the host has signaled ready.
• Chat messages get lost when a user in multiplayer mode switches 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:

• Fix the action menu bugs mentioned above.
• Create the token factory.
• Create the token inventory system.
• Create the token display GUI.
• Implement the Draw Token action.

Medium Priority:

• Sometimes network errors will cause an AI to be disconnected immediately after it connects.  This causes the lobby screen to wait indefinitely for a player who will never arrive.  The server should detect this and try again to create the AI player.
• Solution: Refactor the engine's networking modules to use the Observer Pattern. This will also correct the "Known Issue" mentioned above with abandoned team data.
• Investigate ways to dynamically color the team uniforms.  Experiment on the placeholders.
• If this works, add the ability to dynamically color MHFont objects too.
• Create the in-game chat component.
• But first, fix the issue with the lost messages by making the data structure static.
• Create the HUD's event log display.
• Finish the level design guide.
• Finish asset lists for current set of level designs.

Low Priority:

• Implement the Heal action.
• Implement the Attack 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.
• Make the AI players taunt each other in the lobby chat, just for fun.
• Design the web site.
• Get coin display graphics from the 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.

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

Progress Report (07/16/2011)

Again, my job has kept me from doing much with the project, but I have been paying some attention to it in the few moments that time has allowed.  Really, there's just one thing that has been drawing my attention:  the refusal of the AI characters to move when it's their turn.

Based on the accomplishments listed in the last report, the priorities of some tasks have been rearranged.

Accomplishments:

• Nothing quite...but efforts are underway to get the AI players to acknowledge their turns.

Known Issues:

• 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 in multiplayer mode doesn't turn control over to the player until the host has signaled ready.
• Chat messages get lost when a user in multiplayer mode switches 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 AI characters move when it's their turn.
• Formalize the flowchart for the AI logic.
• Create the token factory and displays.
• Implement the Draw Token action.

Medium Priority:

• Sometimes network errors will cause an AI to be disconnected immediately after it connects.  This causes the lobby screen to wait indefinitely for a player who will never arrive.  The server should detect this and try again to create the AI player.
• Solution: Refactor the engine's networking modules to use the Observer Pattern. This will also correct the "Known Issue" mentioned above with abandoned team data.
• Investigate ways to dynamically color the team uniforms.  Experiment on the placeholders.
• If this works, add the ability to dynamically color MHFont objects too.
• Create the in-game chat component.
• But first, fix the issue with the lost messages by making the data structure static.
• Create the HUD's event log display.
• Finish the level design guide.
• Finish asset lists for current set of level designs.

Low Priority:

• Implement the Heal action.
• Implement the Attack 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.
• Make the AI players taunt each other in the lobby chat, just for fun.
• Design the web site.
• Get coin display graphics from the 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.

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

Progress Report (07/02/2011)

I'm posting a progress report because I've actually made some progress...and also because it's been a while.

Accomplishments:

• Movement for the host's characters is working beautifully.
• Movement for the other players works sometimes, but...
• ...the path following animation doesn't happen on remote machines.
• ...sometimes the characters are getting duplicated on the guest machines.
• ...sometimes the team status display throws an exception.  This is a complete mystery at the moment.
• ...the lobby doesn't let the guest players in until the host signals ready.  This will be a high-priority fix when I turn my attention to multiplayer mode.
• Created a primitive version of the "whose turn" display.  Good enough for now, but not really what I want for the final version.
• Drew a couple more level designs better suited to the new "maximum players" requirement.

Known Issues:

• 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 in multiplayer mode doesn't turn control over to the player until the host has signaled ready.
• Chat messages get lost when a user in multiplayer mode switches 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 AI characters move when it's their turn.
• Finish the level design guide.
• Create the "whose turn" display.

Medium Priority:

• Sometimes network errors will cause an AI to be disconnected immediately after it connects.  This causes the lobby screen to wait indefinitely for a player who will never arrive.  The server should detect this and try again to create the AI player.
• Solution: Refactor the engine's networking modules to use the Observer Pattern. This will also correct the "Known Issue" mentioned above with abandoned team data.
• Investigate ways to dynamically color the team uniforms.  Experiment on the placeholders.
• If this works, add the ability to dynamically color MHFont objects too.
• Create the in-game chat component.
• But first, fix the issue with the lost messages by making the data structure static.
• Create the HUD's event log display.
• Finish voice scripts for narration.
• Finish asset lists for current set of level designs.
• Formalize the flowchart for the AI logic.

Low Priority:

• Create the token factory and displays.
• Implement the Draw Token action.
• Implement the Heal action.
• Implement the Attack action.
• 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.
• Make the AI players taunt each other in the lobby chat, just for fun.
• Design the web site.
• Get coin display graphics from the 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.

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