This describes how game client works. How it displays data, and what parts of the server code (shared code) is used, an how.

This is sub-layout for documentation pages

Top The game client is thick, meaning that it contains most of the game server logic.

It is difficult to describe all that is on the client side, but easier is to explain what is not there.

Imagining game server and all code needed to run the entire game, the code that is purely on the server consists of:

• Classes that take data from the database or interact with the database
• Server running and server init classes

The code (or game logic) that is on the client side as well is (FOR EXAMPLE) following:

• Game Map and all underlying containers
• Player, Monster, Character, Bosses, GameObject, UseableItem and all that can be in map
• Game logic and mechanics, such as damage computation
• Prototype containers. That are classes containing all Items, all Monsters, all Abilities. When necessary, only clone is created. Like this, server can only send id of monster / ability, and client knows what is being adressed.

In order to display any object (Player / Monster / Chest...), a displayer class is created.
Lets imagine following class diagram:

The diagram xml file can be downloaded here

In the diagram above, there is GameMap, which is contained in shared code. In order to be able to draw the map, but allow acess to all the map public and private methods, inheritance is used to create GameMapClient.
That is because there will not likely be need to create another class on server, which would need to inherit from GameMap.
However, considering ChestMapItemClient class, there is used composition.
The ChestMapItemClient or GameDisplayerBase can be imagined as something, that is given GameObject, and is able to draw it and update it
Moreover, there is animation / texture, and the GameObject contained within the GameDisplayerBase is used to retieve position or some data used for displayment.

Therefore, for any new type of object, there must be specific Diplayer class created and used, which is not nice, but if the game items will be grouped by functionality, you will be most likely left with only following:

• Player
• Monster
• Any specific boss (because the animations for special attack can and will differ, and trying to create general solution for everything would make the things harder here....)
• Door (on client side, this can be drawn as portal, secret passage, glass door, sliding door...) but the functionality stays same
• Useable item that grants something (you use box, and item is dropped, or monster is spawned...)

For any other case, the specific displayer class must be created, but really, number of the cases is very limited, so it is not that bad...