A Possible Alternative for the Server Upgrade

I had a thought today that I just want to capture here so I don't forget it.  Rather than give the server the complete overhaul that I described in my last blog post, I think I can get by with a better, simpler, more maintainable option.

In the current system, MHServerModule uses MHClientInfo's output stream to send messages to the client. Here's my new idea:

1. Move the send() method from MHServerModule into MHClientInfo.  
2. Extend MHClientInfo into MHLocalClientInfo and override the send() method to talk straight to MHLocalClient.
3. When a client connects to MHServerModule, the method of connection will determine which version of the client info object is instantiated for that client.  If it's a network connection, it will associate an MHClientInfo with that user. Otherwise, it will use MHLocalClientInfo instead.
4. MHServerModule will continue to run the listener thread automatically so the same server can be used for local or networked play without modification or subclassing.

I can't wait to see if this idea is as great as I think it is. Of course I'll continue to post my progress here.

Moving on to the Server Side

OK, the client is working well in its new, more loosely-coupled form.  The only client-side component left to test is the new local client, which can't be properly done until it has a local server to talk to. That means it's time to turn my attention to the server side.

The best habit I've picked up lately is that I always begin a refactoring effort by analyzing and documenting the existing system first.  Here's the server's current form:

And here is a rough idea of what I have in mind for the imminent refactoring:

Check back in a few days to see how it's going.  :)

Client Upgrade in Progress

The refactoring of the engine's client package is working well so far.  I have managed to split apart the code that handles networking from the general client code without affecting the existing functionality of Team Laser Combat.  Here's the new class diagram.

Remaining tasks before the client upgrade is complete:

• Rename MHClientModule to the more appropriate name MHNetworkClient as shown in the class diagram.
• Refactor the server package to add compatibility for MHLocalClient.
• Build a prototype to test both the networked and local versions of the client and server.
• Test the new version of MHGUIChatClient that now depends on MHObservableClient to send notifications of chat messages.
• Add logic to TLC to launch the correct client/server connection based on user role.
• Move the net package into the io package (mhframework.io.net).
• Modify the deployment scripts to accommodate the new package hierarchy.

The New and Improved mhframework.net.client Package

Here's another class diagram of the mhframework.net.client package with several corrections and elaborations.

The heart of the new design is MHAbstractClient.  It will contain some useful constants along with basic implementations of common methods.

Derived from that is MHClientModule -- a class that already exists in an incohesive form. The new version will separate the low-level network communications into a new MHNetworkClient class, and will keep the stuff that's specific to a single client. There's no new functionality here; just a better division of labor.

Another subclass of MHAbstractClient is MHLocalClient.  I'm not sure if the engine itself will have this implementation, but I included it in the diagram anyway to demonstrate what I had in mind. The idea behind it is that situations where the game server is hosted on a player's machine should not require network communication, so a "dummy" class can take the calls and then just update the local data rather than send actual messages across the network...unless, of course, the update must be broadcast, but that can be handled on a case-by-case basis.

Finally, there's MHObservableClient.  This class will take an MHAbstractClient implementation as a parameter to its constructor.  This means that any subclass of MHAbstractClient can be made observable.  It maintains three different lists of listeners:

• MHSystemMessageListener:  A listener for handling messages predefined by the engine.  These messages will be handled by the engine, but notifications can be sent to any class who subscribes to them.
• MHChatMessageListener:  A listener specifically for chat messages.  May also be used to broadcast status messages from the server. The MHGUIChatClient component will implement this interface and provide a method for registering an MHObservableClient object
• MHGameMessageListener:  A listener for handling game-specific messages.  These messages must be handled by the game code.

I haven't implemented this new design yet, but my goal is to have it in place and utilized by TLC by the end of the month.  Stay tuned to see if I can hit that target!

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...

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