Zay-es network update time

Hi

Im getting around to creating a client-server structure and want to know if there are ways to tweak how often the entitydata is synchronized from server to client. I know the two methods:

                edHost.setMaxChangeBatchSize(5);
                edHost.setMaxEntityBatchSize(5);

which defaults to 20, but are there other ways? I have 10 entities being moved by a movementservice and at a value of 20 , it already seems to stutter. I tried going to 5 to see if that would improve it and trying 100 went from allright to horrible.

Kind regards,
Asser

Those parameters control how many changes are sent in one message. The updates are otherwise sent as often as your server calls sendUpdates().

…but really, real time networking is a lot more complicated than that and shouldn’t really be handled through regular entity components. For example, you will need to deal with the timeliness of messages, redundancy, interpolation, etc… You will have stuttering with your current approach because it is using TCP to send the messages (because it has to be reliable) and TCP will always have stuttering because of the reliable nature of the protocol.

Real time twitch networking needs an entirely different approach, generally based on UDP.

For additional reading:
https://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization

Thanks for the reply. I figured as much, just thought I’d ask anyways.

I have a friend coming on the project, who will handle networking, so I think I’ll leave my client-server framework (using spidermonkey+zay es net) as it is and move on with implementing the game logic.

Thank you for the links too! :smile:

Note: once you have a real time solution, it’s not too difficult to integrate it with or on top of the entity system. I do this myself in Mythruna, for example.

In my case, I have a component whose existence is controlled by the regular ES updates but it’s internal data is controlled by the real time networking. So an entity may have a PositionBuffer component while the real time networking is making sure that component is populated with the recent position history so that interpolation can be performed in the actual visualization.

I’ve taken the approach you use in MonkeyTrap.

What do you mean by ‘once you have a real time solution’ ?

Monkey Trap isn’t really real-time. It’s more command based.

If you are having problems with stuttering then it is likely because you are trying to do more real-time networking. You mentioned that you have a team member coming on who will take that over and I merely offered that you shouldn’t have to throw away anything you’ve already done. The entity system can play nicely with whatever real-time solutions you might develop.

I think I have a realtime solution :smile: I believe the reason I see stuttering is because I have no interpolation/extrapolation control to make entities move between updates from the server (and the fact that I use TCP at the moment).

Can you describe the approach you’ve taken in Mythruna (or do you by chance already have it described somewhere) ?

It’s… complicated. I may have described it before. At some point I’m going to attempt to make an open source project out of some of the networking but time keeps getting away from me and it may turn out that the compression I use is Mythruna case-specific. Or rather, it may turn out to be difficult to have different zone sizes than what I’ve picked.

But beyond the compression stuff, on the server I collect position (including rotation) updates for moving objects every frame. Every 200 ms or so, I send a batch of these to the clients that are interested in them (based on zone). The client keeps a history buffer per object of the changes received… the buffer depth is based on some guess at server latency. As per those Valve articles, the rendering is actually done slightly back in time (100 ms I think) and so interpolates between known history.

The history buffer of positions is a client-only entity component. So there is a system that updates the position of the Spatials based on interpolating history in these buffers.

With just that, you may get sliding artifacts if packets are missed… and it’s a good idea to keep your UDP messages small. My own scheme includes redundancy but it’s part of the more complicated compression scheme.

The devil is in the details. Networking is very difficult.

1 Like

Thank you. Will be interesting to see where my project goes