How to make proximity updates not send updates for some items

[Zenith]

Hi,
Currently, my proximity list updates end updates for all MMO items that come in the area of interest of the user.

I want it to not send updates for a particular type of objects. But I do want to find it by using find proximity items.
So is there a option so I can make it not send proximity updates but still setting mmoApi positions.

[Lapo]

Hi,
no it's not possible to do that. The server will send updates about all items in the AoI, then you can filter them out on the client side (maybe by their variables) and decide which one you want to show/render on screen etc...


Cheers

[Zenith]

Hi,
no it's not possible to do that. The server will send updates about all items in the AoI, then you can filter them out on the client side (maybe by their variables) and decide which one you want to show/render on screen etc...


Cheers

That would mean a lot of data getting synced though right? Even though I am not using that.
hmm. Could this be considered as a feature request for upcoming versions maybe?

[Lapo]

You should define "a lot of data"
By using an AoI you're already highly optimizing the rate of sync updates by reducing them to only where they are necessary. If you design your game smartly and use a reasonable AoI size you should always be able to keep the updates to an acceptable size/frequency.

Could this be considered as a feature request for upcoming versions maybe?

Off the top of my head it looks like a too complex feature to implement, where every client can customize a filter on the data the it should receive with the AoI system. In terms of server side performance it would be pretty resource intensive to apply such filtering on a per-user basis.

It seems like a feature that could be implemented in a server specifically designed for a certain types of game, but not in one that attempts to support a wide variety of scenarios (as SFS2X does).

We'll investigate the possibility though, maybe it's doable.

Cheers

[Zenith]

You should define "a lot of data"
Off the top of my head it looks like a too complex feature to implement, where every client can customize a filter on the data the it should receive with the AoI system. In terms of server side performance it would be pretty resource intensive to apply such filtering on a per-user basis.
It seems like a feature that could be implemented in a server specifically designed for a certain types of game, but not in one that attempts to support a wide variety of scenarios (as SFS2X does).
We'll investigate the possibility though, maybe it's doable.
Cheers

Here is what my problem was!

As used in Spacewar tutorial the bullets are the mmoitems. Now to make the bullets appear instantly after the player fires them , I would have to keep proximity update rate to something low like 50ms.
While my rest of scenery should have no problem in loading even at like once or twice every second.

So what I needed was a server side option to keep bullets as mmoitems but not send there proximity updates.
I would then have handled bullet proximity updates by server response to nearby users instantly which I would get from room.proximityList .

So a server side option if viable would have been very nice in my case.

Now I have instead taken bullets completely out of the mmoapi and not made them as mmoitems. This is working fine as of now but I cannot obviously use now getProximityItems near to users and find any bullets around them.
But I am able to keep my scene objects (tree , stones, gold mine) etc to a 500 ms update!

Hope I could explain. If there is some tricky approach coming to your mind ..throw it my way!

[Lapo]

Okay, that makes sense.
I am still a bit unclear on how these bullets you have implemented work...

Having an MMORoom with items that update very fast (as bullets) and items that don't shouldn't be an issue, in fact the MMOApi keep a list of objects that have been changed between proximityUpdates and doesn't have to rebuild the whole list of items every time.

This is to say that running the MMORoom update at 50ms instead of 500ms is not that big of a deal. At the end of the day the system is already optimized to work only with what changes between update intervals and to send deltas.

Surely a 50ms interval adds a bit extra work for the server, but so does implementing your own system that separates "slow" items from "fast" ones. I am not sure the extra work to implement this is worth the difference in performance (if any exists).

Cheers

[Zenith]

Okay, that makes sense.
I am still a bit unclear on how these bullets you have implemented work...

Having an MMORoom with items that update very fast (as bullets) and items that don't shouldn't be an issue, in fact the MMOApi keep a list of objects that have been changed between proximityUpdates and doesn't have to rebuild the whole list of items every time.

This is to say that running the MMORoom update at 50ms instead of 500ms is not that big of a deal. At the end of the day the system is already optimized to work only with what changes between update intervals and to send deltas.

Surely a 50ms interval adds a bit extra work for the server, but so does implement your own system that separates "slow" items from "fast" ones. I am not sure the extra work to implement this is worth the difference in performance (if any exists).

Cheers

Okay.

My implementation-->

1. My bullets are NOT mmoitems but a list of objects which every frame for which they are alive, would check with proximity to find any nearby
Trees (mmoItems),buildings (mmoItems), AI Units (mmoItems) and Players . Then they hurt them and bullet is destroyed by itself.
Since the game has large number of Buildings and AI units so it already made sense to make bullets the bottleneck instead of iterating over all zombies and Buildings each frame and finding bullets in their proximity !

2. The bullets when produced would send an update to nearby players about bullet position and velocity who would then render it themselves.

3. Anything dead would also send a notification to players nearby.

It is working fine other than a few issues which I got to fix.
I wished for a mmoitem update be slower because I already run a 50ms update loop for clients for position sync. So I fear data exchange as I am building for webgl.
give me any tips you might have.

[Lapo]

[quote="Zenith"
1. My bullets are NOT mmoitems but a list of objects which every frame for which they are alive, would check with proximity to find any nearby
Trees (mmoItems),buildings (mmoItems), AI Units (mmoItems) and Players . Then they hurt them and bullet is destroyed by itself.
Since the game has large number of Buildings and AI units so it already made sense to make bullets the bottleneck instead of iterating over all zombies and Buildings each frame and finding bullets in their proximity ![/quote]
I am not sure what you mean by "bottleneck", but yes you need to iterate on each bullet to check it's collisions with the world, not the other way around.

2. The bullets when produced would send an update to nearby players about bullet position and velocity who would then render it themselves.

Okay

3. Anything dead would also send a notification to players nearby.

It is working fine other than a few issues which I got to fix.
I wished for a mmoitem update be slower because I already run a 50ms update loop for clients for position sync.

You're not forced to run at 50ms if it's not necessary. You can experiment with settings between 50 and 100 and see which is the best compromise between fast updates and good enough approximations.

20 updates/sec over websocket is usually doable, but maybe 15 is the sweet spot (although it really depends on the game).

cheers