Bjørn: I would propose using less different messages, and also to send the beingId with the message because I'd like to keep the option open for multiple beings to be controlled from one client. Also, to make sure the client and server stay synchronized in the direct way of control, the x and y coordinates of where the change happened will need to be sent I think. It's easy for the server to be mistaken one or two tiles, in such a case I guess the client will need to try to get the server to walk to where he wants the player to be, instead of the server correcting the client position which could be rather annoying and should only be used for larger distances. Of course I would prefer scrapping the "Walk update" kind of messaging entirely, but ah well.
0x0001 - WALK_UPDATE { L beingId, S x, S y, B direction (none,n,ne,e,se,w,sw,nw) }
0x0002 - WALK_TO_TARGET { L beingId, S x, S y }
Kyokai: When I created this list, I assumed we could (and would want to) reduce all traffic from the client into the single message ID, without passing any extra parameters. If you want to pass parameters as well, then it is simple to just make one walk message with a short 0-7 as direction, and to use the same message passing an 8 to stop. If we can turn all traffic into a simple series of commands, rather than adding parameters, I think it will save us alot of extra message data. Of course, doing this would require us to make the walk AI a client-side convention, rather than calculating it server side, but I believe the benefits of this are better than the costs of creating a larger message system.
On another point, I don't understand why you would ever want to run more than one being from the same client. You run into the sort of difficulties where one client needs double player updates, players are forced to work within the same screen constraint (extra walk possibility detection relative to another being's position will be expensive), and, as you said, we have to increase the size of every downstream packet by 32 bits. All this comes together to make a messy, expensive, and rarely used option for players. It worked in SoM, where you couldn't link systems together, but it seems like a step backward by today's standards, when multiple machines are readily available. I'm saying this from an objective point, that the costs of muliple being clients far outweigh any gameplay benefit.
Even if we are just trying to control a secondary character, like a pet or summoned monster, that can all be boiled down to a series of 16 bit word commands that translate to things like "help me", "fight defensively", or "run away". This indirect control makes a lot more sense for non-player characters that are still controlled by the player.
Bjørn: I have reconsidered the idea of controlling multiple characters from the same client. Whenever we'd want to add that later we can always introduce a separate set of messages for that, and also in some cases running an extra client to do so would be an option.
I have also thought a bit more about out-of-sync issues with sending only messages about in which direction you want to walk, and it occured to me that you could just send a single WALK_TO_TARGET message every few seconds so that the server knows again where exactly you expect to be, and scrapping coordinates from WALK_UPDATE message again. Because I still prefer using one byte more for the message, than splitting up the message in 8, this is the result:
0x0001 - WALK_UPDATE { B direction (none,n,ne,e,se,w,sw,nw) }
0x0002 - WALK_TO_TARGET { S x, S y }
