Finding your way around the Stendhal Client Code

Issues

• The client side of current stendhal implementation lacks of thread handling even graphic code like draw is done in main.
• The login window is never released until end of game.

• All handling of changes is done by polling rather than be pushing.

The information already given by the way marauroa handles changes is ignored and the values are retrieved from the updated underlying object.

A different way of reacting to changes in rpobject is shown in the refactored BuddyPanel.

• The client code is a big monolith (same with server)

• To have all the client code restructured on client side, we need to tear down every single line of code and replace it.

• There are way to few tests for client side.

GUI

If we want to stay with the First screen and all those popup windows or if we want to find a way to integrate it into one is still to be decided.

We would then have one Gui for Login and one for inGame.

InGameGui

We have already agreed to achieve a InGameGUI like this:

http://img530.imageshack.us/img530/2669/ingamguijp0.png

• ground is where the game happens
• chatwindow contains chat, but could also contain a tabbed window so we could divide chat and support maybe an own guild chatwindow.
• Settings contains minimap , bag i.e. all those windows that now scatter the ground window.

(currently the file you want to read/change is j2Dclient. )

Base Client

The base client ([ideally] free of any specific UI) is StendhalClient. It is responsible for interacting with the server, maintaining private user information/state, and dispatching object events.

Threading model for the inGameGui

http://img101.imageshack.us/img101/5932/threadsbb3.png

The model part in the above image contains more than the pure model. It also contains the controller part.

What we want to achieve is a really dumb gui that listens to the model changes and only knows how to paint things. We want a model that holds the state of the game.

and we want a controller that holds the logic, how to handle the messages from network/Server.

if we want to have a MVC (Model-View-Controller) or a HMVC (Hierarchical-MVC) is still to be decided. Both need a high discipline until installed. The latter has the advantage to keep things together that belong together, higher modularity and probably higher maintainability, but would request the restructuring of the whole client. ( Which we intend to do anyway )

to be continued....

Entities

Entities are created using EntityFactory.createEntity(). In this method, the appropriate implementation class is created, and initialized.

Example:

RPObject object = ...

Entity entity = EntityFactory.createEntity(object);

// Force the view to be created
entity.getView();

  ...

// Done with entity - free up resources
entity.release();

The design is being changed to a Model-View-Controller (MVC) like framework. This will allow different visual implementations (like 2D, 3D, 4D?) to be plugged in with minimal (or no) changes of the model class.

Model/Controller

This contains all logical entity data, and is responsible for tracking all entity specific attribute changes in the RPObject that it wraps. Currently this also handles some of the UI controller functions.

The initialize() method is called with the RPObject that it will represent. This method is called after the constructor returns, but before anything else is [externally] called. When the client no longer needs the entity, it should call release(), which should handle any cleanup, where garbage collection only would be insufficient.

The class gets notified of object changes via the RPObjectChangeListener interface that it implements. This will be called for all changes to its object (and immediate slot objects).

Methods

• getArea()

This returns the "ground" area that the entity occupies, as it is in the server (with real-time motion adjustments made by the client).

• update(delta)

This is called periodically so that the entity can update any active state. It is passed the number of milliseconds since the last call.

View

The current view implementation is Entity2DView. This is responsible for rendering an entity in a 2D view.

Sound System

TBW...

UI

The user interface (UI) is responsible for bringing together the base client and user interaction. The base class is StendhalUI, and is extended by an appropriate implementation (currently j2DClient).