Hello guys, I have been working on a Co-op rpg for quite a while now

I've setup a server and client which synchronizes position and rotation very well, using a quad tree to optimize performance.

And now I have tackled a design dilema which I'm not sure which solution would be “better” to solve the problem:

The design issue I have is how to synchronize skill-result across the network.

In my scenario each skillEffect can have a unique implementation of what the effect can do, no generic constraints whatsoever, and those skillEffects are stored in a dictionary which is accessible for both the server and the client.

When a player/character casts a skill, I send a skill-cast-accept packet to nearby players, and they visually cast the skill (though they do not mutate their state), once the skill's effect has taken place it generates a skill result which would be sent to nearby clients on the next tick.

And now I wonder what schema a skillResult should look like.

I have 2 options that are possible to implement,

the 1st is having the skillResult contain the casterId, effectId, and nearby characters and let the client perform the same skilleffect as well in order to mutate the state - This method is better in terms of bye economy though it lets the client the ability to mutate their state, with possibly non-synced data, which could later cause de-sync with the server.

Option 2 that I thought of - is having each skillEffect return a specific skillResult which is unique to that skill, the skillResult will contain all of the mutations performed through the skill effect – This method could be far more pricey in terms of bye economy though it will be safer to use since there is 1 and only 1 variation of the skill result, and the client will not count on a falsey state.

I'd love to hear your opinion about this, and also if you are familiar with other networking forums please share them ?

@hplus0603 Hey again ?

I'm less worried of clients hacking their game (as the model I'm going for is authoritative server), and I'm more worried about players getting de-synced from the server state.

The flow that I had in mind is similar to your suggestion, the client casts a skill and receives immediate visual feedback, during this time he sends a cast request to the server whom can either accept or decline this request, the server will then notify the other clients to play along and visually display the skill cast.

The focus of the issue I'm having is how to sync the state mutation (not visual effect, for example stats change, damage over time the juicy stuff) between the client and server, since each skill in my game can do a lot of stuff and isn't coupled to a limited amount of effects, a skill can do many mutation operations with different values that are extracted through the caster's state when he first cast that skill.

Would you suggest assuming that the client has a valid state (a partitioned state that equals to the server partition of that area), and that previous commands which alter the state have successfully arrived, and as such let the client get the skill's formula and just calculate the changes.

Or take a stricter approach in which the server sends to the client the exact changes, which requires no calculation on the client side, and simply assign those changes.

Thanks for the help

@hplus0603

hplus0603 said:
If your main goal is to use the least possible bandwidth for the most possible units, like an RTS game, then assuming that the client is already correct might be worth it.

I think this solution would be the most suitable in terms of performance, to counter a possible a client desync, I can send every X (probably 60) ticks an entire State update (of only surrounding objects) - is that also a common thing to do in these types of games?

And a general question for this type of networking, letting the client the freedom to perform calculation operations that are triggered by the server is an acceptable method?

hplus0603 said:
If you want to support cross-platform play (JavaScript, ARM, x86, others) then you may also want to use server-sends-state, because the details of under-specified parts of math (signed overflow, floating point rounding, and so on) will vary between compilers and CPUs.

My target environments are Widnows/Mac/Linux, all floated variables in my games are round to 2 points after the decimal.

what exactly did you mean by “server-sends-state”?

Thanks again

@hplus0603

hplus0603 said:
If you “baseline” (send the full state every X ticks) then why not send the full state when there's a somewhat-rare event, too? You already budgeted for sending full state updates.

Well the RPG type of game I'm aiming for is similar to the Diablo (though mine is a 3D not topdown), so I guess the optimizations I have to do on each packet are more crucial so that the gameplay won't be clunky, I expect that during combat many mutations will be going on - I'm unsure whether or not it will cause major FPS drops during combat (which is rare, but not that rare).

hplus0603 said:
And, yes, sending deltas with occasional “baselines” is pretty common, because it saves some throughput compared to only sending full states, yet it avoids spending too much time with a de-synced client. However, in this mode, you still have to be prepared to be de-synced and hide the corrections, or players will notice “snapping.”

That's an interesting solution, is this model considered to be an optimized solution?

What would be an example of said “snapping” correction? (I guess you refer to non-position related data but rather game data like health and such?)

In your experience which solution would you recommend using, in a scenario where there is a lot of action going on?

Thanks

@hplus0603 Thanks for the informative answer,

hplus0603 said:
“snapping” can happen both for position (he was there, and then he warps to that other place!) and for state like hitpoints (I had a full hitpoint bar, and suddenly it's at 15%!)

That makes sense, I currently handle these cases with lerping the visualization of the values and behind the scenes I immediately set the actual value to the snap value.

hplus0603 said:
Practically speaking, I think baselining is the best trade-off.

In this scenario the 5 seconds “area state” will suffice?

hplus0603 said:
Regarding frame rate, networking will never affect your frame rate. Graphics rendering and physics simulation and AI (especially pathfinding) may, but networking is so little data each second, there's really no way you could make that, in itself, consume enough CPU to be a problem. The only concern, really, about “minimizing network usage,” is that users have limited amounts of bandwidth. Someone may have a 10 Mbps DSL connection, which is shared with their whole household. Someone might be playing over mobile internet. Someone has a ISP with a 200 GB / month cap. Sending 20 packets of 400 bytes each per second, or sending 60 packets of 20 kBytes each per second, is a big difference! (The latter would likely not actually fit on a 10 Mbps connection in practice.)

This makes sense, though I recently played league of legends, and I noticed that when my latency goes over 340 ms +- the whole frame freezes, which I assume this happened because they block the game loop of running until a snapshot arrives (if a long time has passed)