MMOItem updates too big in size ?

Post here your questions about SFS2X. Here we discuss all server-side matters. For client API questions see the dedicated forums.

Moderators: Lapo, Bax

genar
Posts: 137
Joined: 13 Jul 2017, 11:49

MMOItem updates too big in size ?

Postby genar » 29 Mar 2021, 20:31

Im currently running into an little issue with my MMOitem useage. Im using MMOitems to represent stuff like Bullets, Enemys and several other "Entities". They are easy to use and i like to work with them.

Theres one big issue im running into. Their update packet size and the garbage it creates. I ran a test where 180 enemys were spawned next to the player. All in his AOI.

Each enemy has the following attributes : "id (long), type (string), x(float), y(float), rx(float), ry(float), hp(float), maxHP(float)". I update all the enemys with a server tic of 30. So the server runs at 30 fps and i only send enemy attributes which changed. Most of the enemys are walking around, which changes their "x,y,rx,ry" value every frame. So im forced to update those four MMO-Variables every single tick. And it seems like MMOItems cant handle floats, just doubles. Which doubles the packet size.

Sending these amounts of updates and packets is no problem for the server... but for the client receiving them. Those huge blue spikes are caused by smartfoxServer.ProcessEvents(); ( Aka. ConnectionManager.Update() ) on the client where i receive the packets.
Screenshot_4.png
(93.72 KiB) Not downloaded yet

Image

As you can see... this creates about 250KB of incoming updates every 0.032 seconds ( 30 tick ). Which is a lot for unitys gc alloc and makes the game stuttering. But the worst is the packet size itself. We are updating 4 variables ( mentioned above ) each frame. Those are handled as ( i assume ) doubles, which results in an update size of "4*16 ( Boxed Double) = 64 Bytes" per entity and in total "64 * 180 = 11520 Bytes (11,52KB)".

Probably my calculation is wrong... but i should never, ever receive packets in such a huge size. Where do the other ~240KB coming from ?

This is my code which produces those high amounts of data, if someone is interessted on how i "update" my MMOItems. I see nothing wrong here, its actually highly optimized because i only update MMOitems which changed.

Code: Select all

    /**
     * Gets called every 0.032 ms for updating MMOItems on the client
     * @param i entity
     */
    @Override
    protected void process(int i) {

        var identity = identities.get(i);
        var transform = transforms.get(i);
        var moving = movings.has(i);
        var mmo = mmos.get(i);

        // Check which variables require an update
        for(var tuple : mmo.variables){

            if(mmo.item != null) {

                var variable = mmo.item.getVariable(tuple.key);
                if (variable != null && Utils.sameValue(tuple.value, variable.getValue())) continue;
            }

            // Update requires
            vars.add(new MMOItemVariable(tuple.key, tuple.value));
        }

        // Create and update variables
        if (mmo.item == null) mmo.item = createMMOItem(identity, transform, vars);
        else if(!vars.isEmpty()) mmoApi.setMMOItemVariables(mmo.item, vars, !playerQuery.getEntities().isEmpty());

        // Update position of the item
        if(moving)
            mmoApi.setMMOItemPosition(mmo.item, new Vec3D(transform.position.x, transform.position.y, 0), room);

        // Dispose
        vars.clear();
        mmo.variables.clear();
    }


Im glad for any help on this topic ! Thanks !
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: MMOItem updates too big in size ?

Postby Lapo » 30 Mar 2021, 08:15

Theres one big issue im running into. Their update packet size and the garbage it creates. I ran a test where 180 enemys were spawned next to the player. All in his AOI.

The first question I'd ask is ... is it realistic to run 180 enemies in the AoI for your game?
That does sound like too much. Normally the AoI is used exactly to avoid these kinds of situations, i.e. cramming too many players in the same place to the point that it becomes unmanageable.

How is the client going to handle 180 players sending updates to each others?
Even with a small 50 bytes update you would be generating 30 * 50 * 180 = 270KB/s of data that must be broadcast to the other 180 players. It's not realistic.

Thanks
Lapo
--
gotoAndPlay()
...addicted to flash games
genar
Posts: 137
Joined: 13 Jul 2017, 11:49

Re: MMOItem updates too big in size ?

Postby genar » 30 Mar 2021, 08:42

Lapo wrote:
Theres one big issue im running into. Their update packet size and the garbage it creates. I ran a test where 180 enemys were spawned next to the player. All in his AOI.

The first question I'd ask is ... is it realistic to run 180 enemies in the AoI for your game?
That does sound like too much. Normally the AoI is used exactly to avoid these kinds of situations, i.e. cramming too many players in the same place to the point that it becomes unmanageable.

How is the client going to handle 180 players sending updates to each others?
Even with a small 50 bytes update you would be generating 30 * 50 * 180 = 270KB/s of data that must be broadcast to the other 180 players. It's not realistic.

Thanks


Thanks, but it is nessecary. We arent talking about 180 players here... 180 mmoitems. Imagine a bullet hell game, such amounts of mmoitems are quite easy to reach.

Besides that... Whats up with the packet size i mentioned above ? Does the profile log looks realistic too you ? And how can i calculate the packet size each mmoitem update generates ?

What are possible improvements to simulate 180 entities in the players aoi without running into such iusses ? Any advanced mechanics ? I heard of stuff like delta compression, a technique where we only send bits that changed instead of the whole primitive. Dooes sfs already uses this ?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: MMOItem updates too big in size ?

Postby Lapo » 30 Mar 2021, 10:25

From your description it sounded like it was 180 players because you said:
I ran a test where 180 enemys were spawned next to the player. All in his AOI.


If it's bullets, why do you have to update each bullet's position on every frame? Aren't bullets flying at a fixed or at least predictable speed?
If so you can optimize the updates to a much lower rate and save a ton of updates.

What are possible improvements to simulate 180 entities in the players aoi without running into such iusses ? Any advanced mechanics ? I heard of stuff like delta compression, a technique where we only send bits that changed instead of the whole primitive. Dooes sfs already uses this ?

We have demoed a similar type of game with tons of players and bullets flying around with our SpaceWar game demo:
https://www.youtube.com/watch?v=iPM_JPwl6T0&t=5s
You can take a look at the relative tutorial (and code) here:
http://docs2x.smartfoxserver.com/ExamplesUnity/spacewar

Cheers
Lapo

--

gotoAndPlay()

...addicted to flash games
genar
Posts: 137
Joined: 13 Jul 2017, 11:49

Re: MMOItem updates too big in size ?

Postby genar » 30 Mar 2021, 10:55

Lapo wrote:From your description it sounded like it was 180 players because you said:
I ran a test where 180 enemys were spawned next to the player. All in his AOI.


If it's bullets, why do you have to update each bullet's position on every frame? Aren't bullets flying at a fixed or at least predictable speed?
If so you can optimize the updates to a much lower rate and save a ton of updates.

What are possible improvements to simulate 180 entities in the players aoi without running into such iusses ? Any advanced mechanics ? I heard of stuff like delta compression, a technique where we only send bits that changed instead of the whole primitive. Dooes sfs already uses this ?

We have demoed a similar type of game with tons of players and bullets flying around with our SpaceWar game demo:
https://www.youtube.com/watch?v=iPM_JPwl6T0&t=5s
You can take a look at the relative tutorial (and code) here:
http://docs2x.smartfoxserver.com/ExamplesUnity/spacewar

Cheers


Them im sorry ^^ I was talking about 180 MMOitems, not players. 180 MMOitems inside the players AOI. The bullets were only an example, to symbolize the need of such high amounts of MMOitems. In my case there 180 Monsters moving around near the player. Its some kind of hack and slash game.

So lets just say there 180 MMOitems ( Monsters ) getting updated every frame and i wanna optimize this ok ? No dodging here ;) So i cant use the bullet optimization trick. What else could i do to optimize those updates ? Does SFS already uses delta encoding/compression to minimize the packet size ?

And could you please take a look at my attached profiler picture regarding the GC allocs produced by SFS ? Does that amount of GC is realistic for 180 MMOitems getting updated by 4 MMOItemVariables of doubles ? And how do i calculate the packet size of such an update ? Is there any formula ?
User avatar
Lapo
Site Admin
Posts: 23008
Joined: 21 Mar 2005, 09:50
Location: Italy

Re: MMOItem updates too big in size ?

Postby Lapo » 30 Mar 2021, 14:04

So lets just say there 180 MMOitems ( Monsters ) getting updated every frame and i wanna optimize this ok ?

I would not recommend using MMOItems that way. Sorry. This is not the way or the use case they were designed for.
If these entities require per-frame updates (which is still very questionable since there should be ways to optimize this aspect and reduce the amount of updates/sec, especially in a game that aims at running hundreds of these entities) then I would code this using Extensions and custom code, so that you can optimize packet size, packet rate and maybe even use UDP instead of TCP where applicable.

Cheers
Lapo

--

gotoAndPlay()

...addicted to flash games

Return to “SFS2X Questions”

Who is online

Users browsing this forum: No registered users and 56 guests