Network

This is the network architecture of the system:

It is nothing more than an ordinary server with clients running on separate threads.

Controller

The server controller is implemented by the Controller class, which manages two aspect of the server itself:

• By means of ProtocolController interface, it acts as a protocol controller, managing a basic request-reply mechanism (synchronous semantics),
• By means of the IntercomListener interface, it is able of being connected to the other clients' controllers, thus implementing inter-client communication (asynchronous semantics).

Model

The model has no precise architecture, yet. It is rather a "flat" aggregation of classes, notably:

• Mobile, which has (also) a set of Items, each on a separate Layer,
• Item.

I plan to add classes and interfaces as they become needed. One important characteristic of the model is that it is completely oblivious of the controller and the other layers, which, in turn, depend on the model to implement their concerns (e.g., the controller uses Mobile to notify clients of approaching characters).

Short-term objectives

Add these features:

• Improve the dragging & dropping of items:
  • Now it works only to and from the ground,
  • Do it also to and from any container (e.g. your backpack),
  • Enable the drag & drop between characters.

• Notify clients also on login when necessary (by now they're notified only when moving the characters),
  • Implement a complete (though simple) combat scenario (this is more a user story),
• Introduce scripts. They will designed according to the active-object pattern, meaning the scripts will run in the core's thread.
• Implements LOS (line of sight).

Long-term objectives

They include, most important first:

• Add persistence (I'd like not to use a relational DB, but we'll see...) and read mobiles, items, accounts, etc from the chosen persistent store,
• Improve inter-clients notifications - is the current pattern suitable for the task? By now a simple observer is employed, but as simple as it is there are already signs of its being unfit, because these different semantics are needed:
  • Point-to-point (when having to notify a single client),
  • Topic-like, when a character must be visible to a group of other characters.

  Maybe the observer pattern is not the best for this, because it forces the controller to add checks like (point-to-point):

  @Override
  public void onEnteredRange(Mobile entered, Mobile target) throws IntercomException {
      if (!target.equals( mobile )) {
          return; // Point-to-point semantics
      }
      ...
  }

  or (topic):

  @Override
  public void onOtherMobileMovement(Mobile moving) throws IntercomException {
      if (moving.equals( mobile )) {
          return; // Ignore self-notifying messages
      }
      ....
  }

  I'd much more like it if it this filtering was done declaratively, rather than imperatively (I've done something like this using Prolog, so I could just use it).

  Also, the Intercom class is used statically, which is not so cool.

• Implement system notifications (i.e., messages on the lower part of the client's screen),
• Add a CLI (command line interface) acting like another sort of client,

.. all of this while not putting in any custom policy about skills and so on: I want to keep as abstract and simple as possible.