This describes how client and server interact, in order to for example allow player to pick up item, equip item and so on. This also involves changing the html on the cient side according to the event received from server

This is sub-layout for documentation pages

Top

All of the following tasks (or actions) are executed by client always, when relevant packet with data arrives, regardless the situation (since server is master). Client can fulfill (not only) the following tasks:

• When item is dropped on the ground
• Add item with itemGameWorldID and itemSqlID to world position X, Y
• Remove item with itemGameWorldID from world


• When item is in inventory (or put to inventory)
• Add item with itemInventoryID and itemSqlID to inventory of invID to position X, Y
• Remove item with itemInventoryID from inventory of invID


• When item is equipped / unequipped
• Add item with itemSqlID to equipmment window to slot equipmentSlotID
• Remove item from equipmment window slot equipmentSlotID


• Add (static / dynamic) data to currently displayed map (by erasing all current (static / dynamic) data in currently displayed map)
• Add a player to map (along with skull, name, and data), (also visually ofcourse)
• Remove player of player ID from map (also visually ofcourse)


• Play death animation for player with player ID on map, then remove him from map

2.1 Picking up dropped item to the inventory

The situation is illustrated by following activity diagram:

2.2 Equipping item to target equipment slot

The situation is illustrated by following activity diagram:

2.3 Attacking another character

When client clicks on an NPC or another player, command to the server is sent, that player should attack another charactter.
The mechanics is illustrated by following activity diagram:

2.4 Combat settings (autoCast/auto retaliate/attack style/spell cast/special attack...)

For any of these settings, if user clicks on some button, message is sent to server with that info.
Server then validates, if that setup is possible, and if so, overwrites the setup in Player's combat class instance.
That info is later used whenever player attacks (for example).
Below is a use case diagram, showing the combat settings use cases:

3.1 Definition

Buff or debuff in any effect put on target character(s). Such an effect modifies the character (health, of stats....) for some (usually finite) amount of time, or until removed.

3.2 Representation

Buff or debuff is represented by AuraAbility
When you add effect to character (maybe lower the stats, or damage over time), you need the AuraAbility.
The AuraAbility structure is added as effect to the character.
This gives flexibility, where whatever buff you want to create, you just add a new ability (which can be unavailable to players to be used as ability) to game.

3.3 The usage (diagram)

The usage in game is illustrated by following activity diagram:
Note: in green are displayed sub-activities

When command from server is received, client adds a new player to the map, and will be displaying the player, until removed.

Along with the command from server, complete info for player must be sent aswell (for example: object ID, player name, player level, position, current health, max health, skull ... )

However, once this is done, server can address such a player using ID, and send only updates.

The interaction is displayed by following activity diagram:

5.1 Definition

Player is dead \(\iff\) his health reaches \(0\) or is below \(0\)

5.2 Implementation of interaction

As this is complicated operation, it is atomized to easier operations, which are already implemeted.
Suppose, that player dies (which is evaluated on server side). Then:

• Send to client command to kill player of player ID
• Send to client command to add player of player ID to map (this is sent to only these players that are in such a map...)

Situation is best described by following activity diagram:

Please notice, that in following diagram is an activity displayed in red. That means that it can be found somewhere else

6.1 Introduction

When player clicks on door (or cave entrance), it would take him to different map.
That is called the map transition (=change current map).
This describes, how it is implemented

6.2 The idea

The idea is to assebmle this operation from operations described above. Here is what generally what happens (understanding, that comunication is done through network and packets, so diagram is simplified alot):

On server side, this is easy, we just remove player from current map, and add him to the other map (GameMap instance).
This will result in following network data to be sent:

• [Player left] message to all clients in the map
• [Player joined] message to all clients in the other map
• Message telling the owner of transitioned character, that the map was changed to [map ID]
• Dynamic data for the map to which player transitioned

Ofcourse, other messages, such as player position is sent, but that is not the case of discussion here...

It is important that messages above 3 and 4 are sent eighter together, or one after another, but dynamic data shall never be sent before map transition information, to avoid logical errors

6.3 When client receives info about map transition

When client receives information about map transition, he will also retrieve the dynamic data for the map. There is no way to optimize this (apart from difference data sending, which would be extremelly complex), as dynamic data in map can change at any time...

• On client side, system looks up, whether static data for that map is cached
• If no such data is cached, client requests static data from server
• Upon receiving data, the map transition is finally complete
• If the data is cached, the map transition is finally complete

6.4 Triggering the map transition

The map transition event can be triggered by, for example, using door.
However, implementation is not that trivial, and it shows that it is actually very tricky to get this done correctly...

6.4.1 Buggy solution example

Here is example solution, which might seem like correct one after first look, but is in fact incorrect, and can result in undefined behavior, which would be tormendously difficult to resolve (=to find why is game crashing...)
Imagine, that upon receiving request from client, action is added to the action queue of player:

Then, as the server update loop will run, the following would happen:
Note: The class names / interations might NOT exactly reflect the server itself, as the code is changing alot, but the diagram is more about the idea of what could have happened...

6.4.2 Correct solution

In the packet creation phase, before we add data to the packet, we check, whether player has transitioned between maps (this update). If so, then we will not add some data to packets / add different, relevant data