Archive:Being movement system

This article contains information for Programmers working or interested in working for The Mana World

Introduction

The point of this article is to bring communication and several mechanism related issues together. Currently some loose suggestions about certain specific problems exist in other articles, which should be linked from here. This article should become a replacing coherent piece, readying us for implementation of the system in both server and client.

Articles currently replaced by this article:

• Player control
• Client-server message list

A sketch of the situation

This sketch implies several things:

• Pixel coordinates are used instead of tile coordinates
• We choose ovals to describe the collision area of beings, which are 4:3 to accomodate for a camera which in theory watches the scene at a 45 degree angle
• Map obstacle layer definition doesn't change
• Pathfinding could still be based on map coordinates + being collisions (but would be nicer if more smooth)

Important is to think about how this connects to the incoming and outgoing messages about being movement (see below) and how hit and collision checking is done (see pixel based players in a tile based world and realtime action combat protocol).

Finally we need of course to determine what the server will do each tick. Specifically how will we manage to keep down being movement related CPU usage while still having smooth and responsive being movement on the clients? Some things discussed:

• Like eAthena, we will not take dynamic collisions with other beings into account on the server. This keeps down complexity, while at the same time solving problems with getting stuck because of a monster that is in the way or because of an annoying mob of players.
• The server will only do tile-based pathfinding and collision detection. This should be enough to verify the player move and to estimate the position.

Communication

Client-server

From client to server, we've so far been agreeing on sending the target coordinates and some flags about how to get there (walk, run, jump, ...). This will be sufficient for both mouse and keyboard player control. However, two things I want to note about using this message:

• A change in only direction cannot be communicated. I suggest we use a separate message for it, because I do think it is relevant.
• No being ID is communicated, so this message assumes the client is in control over a single being (the player character). When we want to allow clients to control multiple beings (like a herd or a player's pets), we'll need to introduce a new message for this. I think this is ok.

The following message definitions follow the naming convention used in defines.h in the tmwserv module. The last two are a proposal for later and don't have to be implemented now.

0x0260 - PGMSG_PLAYER_MOVE         { W x, W y, B flags }
0x0270 - PGMSG_PLAYER_CHANGE_DIR   { B new_dir }

0x0280 - PGMSG_BEING_MOVE          { D beingId, W x, W y, B flags }
0x0290 - PGMSG_BEING_CHANGE_DIR    { D beingId, B new_dir }

The W stands for a word and is a 16-bits integer. The maximum pixel coordinates are thus 65535, which makes 2048 tiles our maximum map dimension. A 2048x2048 map takes 16 MB per layer, so this seems like a reasonable limit.

Server-client

Many beings are moving around on the map and it has been suggested to pack these updates in a single message towards the client in order to save on overhead. Also, we keep relying on pathfinding at the client in order to keep traffic low.

0x0202 - GPMSG_BEINGS_MOVE         { [ D beingId, W cx, W cy, W tx, W ty, B flags ] * }

The number of being updates in the message can be determined by the message length, since a single being update has a fixed size. For each being it gives the ID, the current coordinates, the target coordinates and the flags about how the being is moving.

Use case: client -> server -> clients

• The client initiates a move, either by keyboard or mouse. The above PGMSG_PLAYER_MOVE is sent to the server with the target coordinates. The player will start moving along a locally calculated path instantly.
• The server verifies the move by calculating a path from the current player coordinates to the target coordinates. The path will be calculated based on the tile grid and only takes into account map collisions, and the start and end will be adjusted to the pixel coordinates. The sole purpose of this is so that the server can verify that the move is possible, how long it takes and estimate where the player should be with reasonable accuracy.
• When a valid move, the server communicates it to all clients that are near in its original form (with the same target coordinates that it received itself). This happens as part of a GPMSG_BEINGS_MOVE message.
• The clients receiving this message will calculate a detailed path to the target coordinates and start moving the being along it. When the original position included in the message is too different from the current position of the being on the client, a quick correction is done before calculating the path.