Client-server communication

What is a client?

 

A client (in this project) is a graphical component representing a specific aspect of the game. What you see above is two different Clients. To the left is a property client and to the right is an event client. The property client displays all visible properties of Weezy the orc, and the event client reports all events that I detect.

A Main client is made up of several client put together. There are different types of Main clients, depending on what you are doing. If you are a player controlling a character in the world, you might see the following:

This is an instance of PlayerClient, which is a specific type of MainClient. As you can see, it includes a property client (to the left) and an event client (bottom right). The little text field on the top right is an action client which allows the player to describe the actions he wants to carry out. The client in the middle is an AreaClient (ie a client that displays the contents of an area).

The player can initiate actions in other ways than typing them into the action client - he can also use drag and drop techniques, arrow keys to move around, and other direct manipulation techniques.

Here are some definitions. They are not "real" definitions - only definitions in terms of this project.

Clients & Agents

Each client has an independent connection to an Agent that resides on the server side. The agent can answer requests from the client and will send updates when necessary. The agent will keep track of the world from its client's point of view, and knows how to operate upon the objects in the world if the client so desires. The result is an architecture like this:

So although there is only one world, there will be one main agent and one main client per player connected to the server. Each of these will in turn contain a set of clients and agents.

Object references - minimizing the net traffic

All objects displayed in the client are initially shown as either an icon or a textual name. The server does not really need to send any more information than that, until the player actually desires more information about that particular object (by for example clicking on it).

For this purpose I have defined a class called ItemHeader. This represents just enough information about an object to:

  1. Uniquely identify the object in the world (by means of an ID)
  2. Tell the client the name of the object and it's icon
  3. Tell the client which operations can be performed on the object.
It can therefore be seen as an object reference. It is the agent's duty to keep track of which object an ItemHeader really represents.

Example

Let's say the user of the client program picks up the potatoe icon (with his mouse), drags it over to the sack icon, and drops it there. The client decides that this means the player want to place the potatoe in the sack. The potatoe and the sack are really just ItemHeaders. The client can verify that the sack allows the "add child" operation, since this is included in the ItemHeader. Now the client will tell the agent that the potatoe should be placed in the sack.

The client will give the agent the two ItemHeaders, and the agent will look up the "real" objects that these headers refer to. When that is done, it can finally create the Action and place it in the clock's action queue (see the action document for details).

How is it really done?

OK, for you Java people, the clients and agents use RMI (Remote method invocation) that is included with JDK1.1. Each client and agent that can accept calls implements the Remote interface and provides a stub and a skeleton, which is sent over the net as a remote reference. In practice this means each client and agent uses it's own socket.

Henrik Kniberg

Last updated: