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.

A sketch of the situation

This sketch implies several things:

• We choose ovals to describe the collision area of beings
• These ovals 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 player control and client-server message list), 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?