[Hajo]

Hi,

today I tried to rework my network layer to have smaller packages. Compared to before it got much better, a move is now 6 bytes, a turn even is now 4 bytes. Those are the most frequent but chat messages, I guess, and talk is always fairly voluminous ...

The games world is divided into maps. Actions on a map are distributed to all clients which are active on that map, to keep them in sync. If a client enters a map, it gets a full update.

Now I noticed that my 6 bytes for a move can be a lot in some cases. if there are 100 players on a map, and one moves, the server has to send out 100*6 = 600 bytes in total to update all clients. And 100 people will not stand still with only one moving. This looks like a lot of data that quickly sums up? If all move once, that is 100*100*6 bytes ~ 60kb of data!

Are there ideas to circumvent that? I could shrink those packages some more, with some effort, but the problem stays, the design scales badly with the number of players on a map :(

I could shrink the maps. Smaller maps mean less players on a map, and since in this example the amount of data goes by n*n (if n is the number of players) that should help? Currently maps are at most 127x127 units (place for 127x127 players, but actually it's unlikely that so many are there).

It's not an urgent problem. I don't expect 100 players there anytime soon, much less all of them on one map. I just noticed the current design has a problem, and now I'm pondering what to do about that?

[Verious]

Hajo, generally you only need to send updates to players (or objects) that are in close proximity to one another. This allows the maps to be very large with a huge number of players without overloading the connection.

You can use a basic distance calculation to determine proximity, if it is over a certain threshold (generally about a screen and a half) the packet does not need to be sent.

So for example if the screen resolution was 800x600, anyone greater than 1,200 pixels away from a player does not need to be aware of the player's movement. The reason you don't want to use 800 pixels (the screen width) is because players would "pop" on an off the screen if they were near the edges.

You will want to adjust the maximum distance threshold to find a setting that works best for your game.

[Terry]

I won't claim to have any deep understanding of this, but six bytes per move seems like a lot. Couldn't you do this in three bytes for simple movement?

I always pictured the framework of an online game as something like an IRC server where each action tells the game to do something. Seems to me all you need to do is send a message to the server when you move - with one byte, you can send 256 distinct messages:
0 : Move up,
1 : Move up and right,
2 : Move right,
3 : Move down and right,
4 : Move down,
5 : Move down and left,
6 : Move left,
7 : Move up and left,
8 : Attack up
...etc

The server can then relay that message with two bytes (one for the character that's moving (assuming less than 256 players), another for the action taken) - three bytes in total. I suppose if the action is more complicated you've got a problem though - say you're talking, for example, then you've got to send the string too.

Oh well. I've never tried even the most basic network programming, so I'm probably missing something really obvious. Don't mind me. :|

Verious's optimisation sounds like it would do a great deal to alleviate the bandwidth problem anyway :)
_________________
http://www.distractionware.com

[Verious]

Terry, if packets are lost in transit the client can quickly get out of sync with the server when movement vectors are sent. Additionally, sending only a movement vector requires a packet for every single space moved.

Generally, it is best to send the destination coordinates. While this approach takes slightly more bandwidth, it forces the client to sync with the server.

Hajo, movement packets are generally comprised of the following:

[1 or 2 bytes] for packet id (optional, required for games that use UDP instead of TCP/IP)
[1 byte] packet type
[1 or 2 bytes] entity (player or object)
[1 or 2 bytes] x coordinate (depending on map size/movement resolution)
[1 or 2 bytes] y coordinate (depending on map size/movement resolution)


Note: UDP does not guarantee packet delivery or order of packet delivery; therefore, stale packets need to be discarded. This can be accomplished by using an incrementing packet id.

___

Edited for clarity.

[Terry]

ahhh.... That makes a lot of sense :)
_________________
http://www.distractionware.com

[Verious]

Something else to keep in mind is that packet headers are much smaller for UDP packets than TCP/IP packets.

[Hajo]

My packets for a move are currently:

1 byte: packet type
1 byte: source X
1 byte: source Y
1 byte: destination X
1 byte: destination Y
1 byte: flags

I see the benefits of having the moving player/being identified by an ID rather than coordinates. If the client was out of sync, source coordinates will fail, while a lookup over ID will move the right player/being to the right destination, thus res-syncing the client. A question: how do you organize map data internally to make a lookup by ID fast, while still having a lookup by coordinate (for display) fast as well? Double-index the structure, once as hashtable, once as array?

If you only transfer movement to clients whose visible area is close to the location of the move, and one of the clients moves to a new area, you must send a complete update of the area that came newly into view? This can be quite some data, too?

It's basically the same idea like dividing the world into smaller maps. Make the area which needs to be updated smaller, to reduce the number of packets to be sent.

Crossfire (an old X-Windows/Unix MMORPG) has maps of 16x16 (15x15?) squares. It seems to be still popular among some people. One of my project aims is simplicity, since I have not much time to work on it these days, and simpler code is easier to maintain and debug. Thus border updates for a sliding view in a partly out-of-sync world seem to be the best approach. But maybe small maps are 'good enough' and easier, simpler to implement? I'm not sure what players will think about it.

Visibly, a map square appears to be roughly 1x1 meters (about 3x3 feet) in my game. I just checked and found my main map to be 53x53 squares (please noone ask why such a number, I have no idea and was surprised by myself. 50 or 64 I'd understand, but 53 ... must have been in an odd state of mind then). Back to topic: This map looks rather big in the game. I could imagine that in most cases 32x32 will do (4 times a Crossfire map) and that 48x48 will be good enough for all places that I need in my game. In the few online games that I know, maps are usually sparsely populated except some busy places where players crowd up. I wish I could get a feeling if 48x48 is a small enough area to keep traffic low, or if I'll run into troubles later ... map making is time consuming and I'd not want to remake a larger number of maps later, when I see it was a mistake :( I could still try to implement gliding "update windows" as suggested above, later when there are problems. And until then hope that small maps are easy and simple and will be good enough?

Sorry for so much text. I'm uncertain, this makes me write down a lot of thoughts.

[Bjorn]

Your map size really doesn't matter if you send updates based on proximity, as Verious already pointed out.

This is also what we do with The Mana World server. For each move a character makes, it has to check whether it was in range and isn't anymore, or wasn't in range but now is, or simply was and is in range, of every other character on the map. This is of course CPU intensive (quadratic order to the number of characters), which is why the TMW server divides the maps into a grid of zones that point to the characters occupying them. Next, for each character that moves you only have to check against all characters that are in the set of zones which are partly visible to the moving character (based on player's viewport size). This way, maps can be very large without affecting bandwidth or CPU usage significantly.

For saving more bandwidth, consider sending only one update package to each client, which contains all the moves that are relevant to this client. This significantly reduces the data spent on headers and message IDs. For this to work, we do the former in reverse by remembering old and new positions of each character, and looping through the connected clients first.

Lastly, if you use tile coordinates, two bytes is a bit of a waste (since maps aren't going to be 65536 tiles large), but one byte may seem a bit limiting. In this case, an alternative is to bit-shift things around to fit the x and y values together in 3 bytes.

If you need objects to be quickly accessible by coordinates for display, I would indeed suggest that you use a lookup array or hash table for both ID and coordinates.

[Hajo]

[MDS-MU]