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!

The Characters Are Moving!

After days of frustration, my characters are finally moving correctly.  Here's what was goin' on:

First, the characters would move to their new positions, but the map would still hold onto their references in their previous positions.  This caused the pathfinder to incorrectly interpret the characters' previous positions as obstacles because it thought there was still a person standing there.

The problem there was that the characters' positions were only being updated on the local machine and were never being broadcast across the network.  This was causing a problem because the corrective code that removed the old references was in the game client where character updates are processed.

Once this was corrected, another problem emerged. The characters were moving, but they were leaving ghosts rendering in their previous positions.  Basically the same problem as before, except now you could actually see the characters' images in their old positions.

The problem with that one was that the characters weren't clearing their old positions before moving into the new positions.  Once that was corrected, there were no more issues.

There are a couple of things I really want to fix before moving on to the next steps.

1. Get the characters to animate along the paths.  Some code for this is already in place, so I just need to finish it.
2. Remove faulty or unnecessary code that was written for troubleshooting the issues mentioned above.

Speaking of next steps, I have a few possibilities for what the next steps will be.

• The combat token system.  This leads to:
• Token source.
• Token inventory.
• Token selection UI.
• Attack, defend, heal, draw, and teleport actions.
• Attacking leads to implementation of containers.
• Broadcasting and handling the "whose turn" message.  This leads to:
• Implementing action points.
• Creating the "whose turn" UI.
• Adding gameplay intelligence to the AI players
• Random events, including:
• Random injury.
• Random bonus item.
• Finishing the HUD, including:
• Event log display.
• In-game chat component.
• "Whose turn" display.

The Pathfinder is Functional

After a long "dry spell" of being far too busy to touch the project, I'm back with a vengeance.  Finally today I was able to sit down with the project to do some analysis and write some code.  The result: I solved the problem I was having a couple of months ago when I left off -- the pathfinder appears to be functional.

The circles represent all of the places that Trooper Mandy can go.  The filled circle was the one that the mouse pointer was hovering over at the time the screen shot was taken. Valid destinations are determined by the character's equipment and a die roll.

This piece of the puzzle is not finished, however.  There are still several steps remaining in this subsystem, such as:

• A lot more detail on the interface, like...
• Who's selected.
• How many movement points the selected character has.
• Path following behavior.
• And the associated character animations, of course.
• A way to capture and process the selected destination tile.

Requirements Change (Maximum Number of Players)

Those of you who have been close to the project for some time may recall the ongoing struggle that I've had with the performance of the game world initialization routines.  Despite my best attempts at optimization, I have been unable to squeeze more than a few seconds off of the load time for the levels.

Here are the options I have identified for correcting this problem:

• Change the engine's networking modules to use UDP instead of TCP.
• Rejected.  This would almost certainly fix the performance problem, but would also introduce a significant amount of effort in future projects, and require a complete overhaul of much of the existing code in this one.
• Flag each shared data item on the server to indicate when the last update was sent, thereby eliminating redundant broadcasts.
• Rejected.  Again, a tremendous amount of effort and significant change to the existing, functional code.
• Multi-thread the process for synchronizing the clients.
• Accepted.  This was one of the first optimizations I attempted, and it provided a decent speed boost and a more friendly user interface.  However, it wasn't enough.
• Reduce the number of messages sent across the network by consolidating data into larger packets.
• Accepted.  This was a super easy, ten-minute experiment that provided some improvement, but it was fairly trivial.
• Decrease the maximum number of players.
• Accepted.  I changed the MAX_PLAYERS constant from 8 to 4.  All of my previous tests showed that each additional player had a huge negative impact on the initialization times.  Four players, each with large teams, allows the levels to load in an acceptable amount of time.
• Decrease the maximum number of characters per team.
• Postponed.  This change would not only improve the initialization time, but would also impact the game play considerably.  The game would be much more fun if the players had fewer characters to manage, and level design would be far simpler.  I will probably make this change after discussing it with the team.

So far, the change in the maximum number of players has helped tremendously.  More optimization is likely, but for the moment, I'm happy with this improvement.

Progress Report (04/30/2011)

"I live again!"

Woo!  It feels good to be back to the project!  This is the first blog entry in over a month, and I am downright ashamed of the fact.  However, given the intensity of my workload this session, it's no surprise that TLC once again had to take a backseat to more urgent matters.

Last night (actually, early this morning), I got back into the code and picked up where I left off on the Actions menu.  It's not much, but it's more than I've given this project all month.

May I never take this much time away again!

Accomplishments:

• Officially began implementation of the Move command on the Actions menu.
• Created and handled the "Request Movement Points" network message.
• Server now correctly calculates and returns movement points for characters.
• Encountered a serious defect in the path-finding code I wrote last month.  I'm currently in the process of troubleshooting it.

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 color cycle control on the team creation screen throws an exception when there is only one color remaining to choose from.  This is only an issue when setting up a game with eight human players.
• 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:

• Finish the level design guide.
• Broadcast and handle the "whose turn" message..
• Create the "whose turn" display to show it.
• Implement the Move action.  This will involve:
1. Decoupling the characters from the map structure.
2. Implementing network messages for the Move command.
3. Implementing the UI for selecting a destination.
4. Done:  Implementing a pathfinding algorithm.
5. Implementing path following behavior.

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.
• Fix the team color selection for the eighth human player.
• 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:

• I have a plan for optimizing the AI character initialization routine by consolidating some of the network messages.  I've got to try that.
• 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!

Progress Report (03/26/2011)

The best news of the week: Kristen is not permanently leaving us! She's only stepping away from the project while she's working on her internship, but she'll be back. This makes me very, very happy!

Aside from a few coincidental things, this was not a week of productivity for this project. My birthday, my annual tax appointment, a fantastic business deal, an Epsilon Delta Pi honor society event, and my ongoing struggle to catch up on work took all the free time that I had. Therefore, this week's report doesn't have much to say. So let's get it over with.

Accomplishments:

• Started working on the level design guide.  Will continue to refine it throughout the course of the project's implementation.  I plan to bundle LIME with the game along with instructions to tell players how to create their own arenas.
• While I was stuck without a computer for a few hours, I drew four new arena designs that, as of right now, are unnamed.
• Did a little research and talked to some of the appropriate people about setting up an official game development studio under which to develop and publish this project and many more after it.

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 color cycle control on the team creation screen throws an exception when there is only one color remaining to choose from.  This is only an issue when setting up a game with eight human players.
• 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:

• Finish the level design guide.
• Broadcast and handle the "whose turn" message..
• Create the "whose turn" display to show it.
• Implement the Move action.  This will involve:
1. Decoupling the characters from the map structure.
2. Implementing network messages for the Move command.
3. Implementing the UI for selecting a destination.
4. Done:  Implementing a pathfinding algorithm.
5. Implementing path following behavior.

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.
• Fix the team color selection for the eighth human player.
• 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:

• I have a plan for optimizing the AI character initialization routine by consolidating some of the network messages.  I've got to try that.
• 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!

Chris Taylor's Common Questions

Master game designer Chris Taylor (of Dungeon Siege fame, among other things) created a game design document template that is among the most thorough I've ever seen.  Much of Team Laser Combat's design document was based on Taylor's template.  Although I have found the template to be a bit unwieldy for TLC, there are some parts that I have found to be particularly useful for capturing some of the subtle details in the game's design.  One such section is Taylor's "Common Questions".  Here are Team Laser Combat's answers.


What is the game?
A multiplayer “board game” where players recruit teams of laser tag athletes, equip and train them, then guide them through a series of matches against other teams.  At each turn, players order their characters to perform various actions such as move, attack, heal, or draw a combat token which provides characters with the ability to attack or defend.

Why create this game?
To satisfy those players who want a fun and rewarding turn-based strategy experience without the complex rules, intricate resource management, or unforgiving constraints of staged tactical scenarios.  I would like this game to be viewed as a LAN party game, where new players can have an exciting experience right alongside experienced gamers.

Where does the game take place?
In a future where laser tag is a popular professional sport, arenas are popping up everywhere.  Amateurs and enthusiasts practice wherever there’s an open space with sufficient protective obstacles (parking lots, wooded areas, cemeteries, etc.), and professionals play in grand arenas in front of boisterous crowds and television cameras.

What do I control?
As the owner, manager, and coach, you make all of the decisions for your team. You command your soldiers where to move, how to defend themselves, and who, when, and how to attack.

How many characters do I control?
Your team consists of one to ten characters, depending on how you choose to build and configure your team.

What is the main focus?
The main focus of each round is to eliminate all of your opponents’ characters while keeping yours in the game.  The round is over when only one team or alliance remains in play.  The long-term goal of the game is to be the top-ranked team when the game is over.  The criteria used for ranking is selected by a game configuration option.

What’s different?
To answer this question, I will have to perform a competitive analysis, and I’m not sure what existing products to compare it with.  Laser Squad Nemesis?  Dokapon Kingdom?  Perhaps I can compare it to the tabletop board games that inspired it – Epic Duels, Hero Quest, Fireball Island, etc.

Tile Image File Naming Conventions

This post is for primarily for reference. Level designers need to know what to do with the files created by the FTT and WTT (Floor Tile Transformer and Wall Tile Transformer, respectively). Specifically, they'll need to know how to rename the files so that they'll be picked up by LIME when creating the maps for the various levels in the game. That is the purpose of this reference.

Here's a reference explaining the format and meaning of the tile image file names.

Elements:	Layer	Tile Set Number	Tile Number	Animation Frame Number	File Extension
Valid Values:	F, L, I, O, W, D, C	00-99	000-999	00-99	.png, .gif
Notes:	F = Floor, L = Floor Detail, I = Item, O = Obstacle, W = Wall, D = Wall Detail, C = Ceiling	2 digits	3 digits	2 digits

Example: F0100400.gif

Progress Report (03/19/2011)

Once again, I've surprised myself by accomplishing several things by just working for a few minutes at a time. I haven't had longer than about thirty minutes at any one time to work on this project, and yet those scattered little moments throughout the week have enabled several small steps to be taken. There are lessons to be learned in this! It's unfortunate that so many of the tasks in this project are far too large and complex to be completed in such a tight space.

Still, even small accomplishments bring great hope. At the very least, they keep hope alive.

Here's the game in one of the new widescreen modes.  The old mode is still available, of course, but now there are three more from which to choose your optimal experience.

Accomplishments:

• Fixed the team config, character config, and character recruitment screens so they display correctly at all supported resolutions.  (If I'd known it was going to be that quick and easy, I would have done it last week!)
• Corrected an issue with the MHFramework Wall Tile Transformer utility so the right-facing walls have no gaps and line up properly with the left-facing walls.
• Created some new maps just for testing.  
• Also created a basic blocked-out version of the Mansion level.
• Pseudocoded some classes for decoupling the characters, laser beams, and other dynamic actors from the map.  
• Really, really, really wanted to have time to implement the code, but no luck there.
• Spent too much time considering a complete redesign of the user interface for player commands to make it more intuitive and help it flow better.  
• After prototyping it through a few different scenarios on paper, I decided against it because there would be too much ambiguity, which could make it prone to errors and frustrate the players. I won't completely abandon the idea until I bounce if off of some brilliant game designers that I know, but for now, I'm going to stick with the original design.
• Readjusted some of the priorities in the project plan to postpone some of the art-related tasks.  Since I can't be sure who will be doing my art, those tasks need to be put on hold while I do what I can from a functionality perspective.
• However, just to help me visualize the player command UI, I started designing buttons for selecting a firing direction when attacking. Probably gonna throw them out when I finally have another UI artist.

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 color cycle control on the team creation screen throws an exception when there is only one color remaining to choose from.  This is only an issue when setting up a game with eight human players.
• 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:

• Broadcast and handle the "whose turn" message..
• Create the "whose turn" display to show it.
• Implement the Move action.  This will involve:
1. Decoupling the characters from the map structure.
2. Implementing network messages for the Move command.
3. Implementing the UI for selecting a destination.
4. Done:  Implementing a pathfinding algorithm.
5. Implementing path following behavior.

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.
• 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.
• Fix the team color selection for the eighth human player.
• 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:

• I have a plan for optimizing the AI character initialization routine.  Gotta try it.
• 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.
• Finish the level design guide.
• 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 (03/12/2011)

Once again, I missed last week's update.  I assure you, though, that it was for a good reason!  GDC week put me pretty far behind, and I'm still not caught up.  To make matters worse, I'm spending this weekend to take the final exam in the worst class of my entire graduate school career.  I'm mostly done with it, but I won't have it finished in time to work on TLC again this week, so I may as well post this now and hope for better opportunities in the week to come.

There is also some happy/sad news to report.  The Team Laser Combat development team is losing a highly valued member.  The magnificent Kristen Miguel is leaving us to pursue a wonderful opportunity as an intern designing educational games.  So...yay for Kristen!  (And boo for us.)  We should all keep our eyes on the career of this amazing young woman.  She will be missed.

Alas, the show must go on, so here's the latest.

Accomplishments:

• Fixed the floor detail layer problem mentioned in the last report. 
• Rebuilt some of the test maps to make sure.
• Added a display resolution selector to the launcher dialog so users can select a higher, more appropriate resolution for their particular monitor.
• This may seem like a misplaced priority at this point, but it aids in testing.
• Tested all screens with the new resolutions.  
• Found only three that require corrections: team config, character config, and character recruitment.

Known Issues:

• The team config, character config, and character recruitment screens need to be fixed so they display correctly at resolutions other than the default.
• 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 color cycle control on the team creation screen throws an exception when there is only one color remaining to choose from.  This is only an issue when setting up a game with eight human players.
• 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:

• Correct the team config, character config, and character recruitment display problems.
• Investigate ways to dynamically color the team uniforms.  Experiment on the placeholders.
• If this works, add the ability to dynamically color MHFont objects too.
• Broadcast and handle the "whose turn" message..
• Create the "whose turn" display to show it.
• Implement the Move action.  This will involve:
1. Decoupling the characters from the map structure.
2. Implementing network messages for the Move command.
3. Implementing the UI for selecting a destination.
4. Implementing a pathfinding algorithm. (Done.)
5. Implementing path following behavior.

Medium Priority:

• Create the in-game chat component.
• But first, fix the issue with the lost messages by making the data structure static.
• Fix the team color selection for the eighth human player.
• 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.
• Finish the level design guide.
• 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!