How do I split data up into regions(Multiplayer plugin)

I was reading the getting started articles this morning and i came across

[quote:23tdrunx]10 players = 16 x 10 x 10 = 1600 bytes per update

20 players = 16 x 20 x 20 = 6400 bytes per update

30 players = 16 x 30 x 30 = 14400 bytes per update

100 players = 16 x 100 x 100 = 160000 bytes per update

I also came across http://www.dynetisgames.com/2017/04/05/interest-management-mog/, My question is, Is it possible to implement something like that into c2 and use it with the multiplayer plugin, And How would I even begin

Not possible yet! A feature request for C3 is up on the idea board, which might solve this issue: https://construct3.ideas.aha.io/ideas/C3-I-319

Yaay!

You can, but you'll have to build your own sync algorithm via messages rather than use the built in sync.

You can, but you'll have to build your own sync algorithm via messages rather than use the built in sync.

Yeah but this is highly unrecommended. Messages are sent as strings, and it costs you 1 byte per standard character. So for anything other than a turn-based game that doesn't need to be transferring data every few milliseconds this would be horrible.

Agreed it isn't recommended, but it is possibly workable. Most MMO's were hardly truly real time anyway, there was a lot of fudging going on.

You can still get 6 states out of a single byte character rather than 8 with little work. The overhead of messages will always be a problem though, so you still have to weigh what data to transfer carefully.

Anyways it would basically be pretty far outside the scope of a beginner, considering a normal multiplayer game is difficult enough to make properly as it is. Just throwing some ideas out as possible workarounds in case anyone really wants to do this with the capabilities we currently have. The general feeling I got was that there would be no more work done in terms of the multiplayer plugin, regardless of a new runtime in C3, so I'm not holding my breath.

I also had some crazy ideas involving separate zones/hosts with agents dedicated to popping in and out of each server in succession to pass low priority data.