Wednesday, July 22, 2015

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.


Draw Token

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.