Saturday, September 17, 2011

Don't Get All GUI On Me

It's been pointed out that the client-side class diagram that I posted last night doesn't include anything for the user interface.  I have two things to say about that.

First, it was intentional. If you look at the project plan that I posted about a month ago, you see that "Token Source" and "Token Inventory" come before "Draw Token Action" and "Token Display GUI".  The Token Source is handled by the server, and the Token Inventory resides on the client.  The next two steps require user interaction, but the back-end support needs to be there first.

Second, it's not entirely true.  The diagram shows that TLCToken inherits from MHActor, which promotes and simplifies the rendering of animated graphics in the engine.  Also, the diagram mentions methods like sortByAttackValue() and sortByDefenseValue(), which will provide sorted lists to be displayed and selected from in the Attack command and the Defend interface.  The properties of the token stacks are also values that will appear on the token inventory display.  So there's a lot of stuff that will support the UI, even if it's not explicitly represented in this diagram.

Satisfied?  Is everybody happy now?  :)

Friday, September 16, 2011

The Client's View of the Token System

As promised earlier, here is a fairly high-level view of the client side of the token system.  You may notice some classes in common with the server side.  Code reuse is just good software engineering, of course.  :)


The Server's View of the Token System

The process of implementing the token system has begun!  The core gameplay revolves around random chance factors combined with how the player uses the resources that his/her team has available.  These resources come in the form of tokens -- combat tokens, heal tokens, power tokens, and grenade tokens.

Here's the class diagram of the system's server-side components.  I will follow up later with the client side.



Sunday, September 11, 2011

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!