Archive:Being movement system

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?

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         { B n, [ D beingId, W cx, W cy, W tx, W ty, B flags ] }

The message start with a number up to 255, which says for how many beings new target locations are given. Then for each being it gives the ID, the current coordinates, the target coordinates and the flags about how the being is moving.