Hi there. My friends and I have been battering this question back and forth forever now, so I've decided to do the smart thing now and actually ask about it. (since I have no program yet to test)

How much bandwidth does GS use to auto-synchronize a multiplayer game's entities? I know this is very vague, so here are a few things to keep in mind.
1. It's an RPG with real time combat
2. Player movement using the arrow/w,a,s,d keys (like a first person shooter)
3. Very similar to World of Warcraft gameplay

I'd just like a rough estimate of how much bandwidth is used by each individual player, and by each additional creep.

Thanks!

Well, bandwidth is one of my favorite subjects(latency being the other), so I'll share what I know about it. Here is a quote from the The A6 Client/Server Protocol manual page:

Quote:

---

The protocol is optimized for using as less bandwidth as possible. Only parameters that have changed are sent over the network. Sending a player's changed XYZ coordinate from the server to the client, for instance, needs only 12 bytes (including header). A dead reckoning mechanism is used for extrapolating positions and angles between cycles.

---

If you look through the entire Protocol page, you'll see that it is pretty efficient. Unfortunately I can't give you the exact number per entity, because a lot of it will depend on what you are doing. For example, an entity at rest will send 0 bytes of data for xyz coordinates. An entity in motion will by default send 12 bytes of data 16 times per second, just to update the xyz coordinates. Other things that get updated whenever they change are pan/tilt/roll, animation frames, lighting and color adjustments. But keep in mind these things only get transmitted when they change, and even then only 16 times per second.

There are also things you can do to control the auto-updates. Of course everything is a tradeoff. For example, you can control the time between update cycles with the dplay_entrate, but in doing so, you can introduce excessive lag into the gameplay (or flood the network if you go the wrong way). You can also shut off individual updates, or even all of the updates, but then you'll have to manage the data transmission yourself.

I can tell you from my experience that most likely it will be problems with your script and not the A6 auto updates that will be flooding the network. Usually the bulk of the bandwidth will be used up by your script sending vars, skills, and strings between the server and the clients.

There are lot's of things that you can do to minimize these script issues. Take a look at locoweeds tutorial on Multiplayer. He did an excellent job of keeping the BPS low in his code. The biggest key is to do exactly the same things that the A6 protocol does. Namely, use as few bytes as possible to send your data, only send updates for things that have changed, and if possible try to use things like prediction algorythms and update cycles to minimize the frequency of sending updates.

So... best of luck. I'm sure Locoweed and Fastlane can add some useful info to this thread.

Let me add my two cents worth:

Another issue to consider is that the 3DGS network currently will send updates to everyone on the server... everyone... you cannot natively select who 3DGS auto-updates and who it doesn't (an update "fixing" this is in the works but don't hold your breath for it coming out soon).

So this means that if you are on one side of the map and another person is on the other side of the map, under 3DGS protocol, you EACH still get each others update even though you don't need each others information.

Imagine therefore that 25 clients recieve a 10 byte update. This means each client receives a (25 x 10 = 250B) update, their own and 24 others. Now consider that total bandwidth, that's (25 x 250B =6250B). That's 6.25KB even if you don't need to know what the other 24 people are doing.

Now, you can turn off the auto-update and program the update behavior yourself (this is what I do), but that's pretty advanced stuff.

So if you want to do a small (less than 10 people) MP game, use 3DGS' auto-update. If you want to do something approximating a MMOG, disable auto-update and program you're own routing (keeping in mind what giorgi said).

No comment at this time.

Maby there is a way to track the send packages with a TCP/IP monitor,
to actually check how much data per second the server has to transmit...

Anyways, the way you try to optimize your updates depends on how many clients on average should
join, how much the server should controll, and how often the updates should reach the client.

If you plan to make a shooter-type game with 4 Players over LAN, you can really let 3dGS
handle everything by default, as in LAN it it quick enough.

If you plan to "really" make a RPG with lets say 50 clients joining the server,
dont use the default way 3dGS is handeling the updates.

Get the more complicated way, and disable automatic updates.
Stuff your updates into variable arrays. (Maybe use arrays of different sizes,
to send the smaller arrays, if there are not that many updates)

This way you can even send the arrays to specific clients (var_send_to ....)
The sever needs to calculate then what each client is able to see,
stuff the updatedata into an array, and send it to the specific client.

This way you can manually limit the update packages to the required size.

Also try to use as many local entities on the clients as possible.
Any effects and ambient stuff, that do not affect the gameplay directly should be done on the client.
Also direct movement of client-players is somewhat tricky.
It would be too slow to just send movecommands to the server, and let the server move the player.
And on the other hand it yould be too unsecure to let the client move the player.

You need to find a tricky combination of these 2 methods,
to account for both speed and security.

fastlane, isn't there a plug-in the AUM Resources section that loads only a certain immediate portion of the map activity (you know, the classic "fog of war" effect)?

I'm not aware of it. And it most likley is for Single Player "fog of war", not Multi Player "bandwidth restriction".

I was messing around with something a few months ago that i think i got to work.. (will have to redo it obviously).

What I did was basicly have all entities scan the area around them, and I used var_send_to to send information to specific entities (players). I believed this work fine. However a friend of mine told me that it was working so well simply because the things and players in the area was very limited, eventually it would start making the entire game lag a bit to soon.

Also, i heard internet player should have bandwidth bellow 1k LAN was 10k...
quote from the manual:

Quote:

---

Reduce traffic. Send as less data as possible, and use unreliable data whenever possible. On a LAN, you can send and receive with more than 10,000 bps; however on the internet you should not exceed 1000 bps. Know always how many bytes you're sending per frame or per second. Imagine you had to pay one cent per byte (five cents if you're sending in reliable mode). Send only if a variable has really changed, and even then not every frame. For synchronizing global variables, sending one huge array is faster than sending a lot of single variables.

---

Thank you all for your replies. I think I have a rough idea of what I'm doing now, and a better understanding of the stress on the network. I continue to look forward to anything else anyone has to say concerning bandwidth.