So basically, a client slows down checking if it’s character is in 100 different parts using my rotated region service of choice at 60 FPS because that’s 6000 intensive calculations per second.
But what if the server checks 100 players in one part at 60FPS? That’s 6000 calculations. Will it impede the server at all?
This is abstract, I don’t have numbers besides going from 60FPS to 47, but your response need not be any more numeral than my question! I simply want to know how strong is the server relative to the average client in terms of operations per second?
1 Like
Clients are stronger than the server by a longshot in my experience. If your client slows down by checking if the character is in 100 different parts in 60 frames (or even worse, in one passage of Heartbeat), yes your server will die a harder death and affect other systems as well.
Compared to the client, the server isn’t that strong. That isn’t telling you to underestimate the server’s power but many things have to be taken into account both sides. Clients are as powerful as their device, the server is also dependent on its own specs. Server region can also play a major part here: a server further away from you means longer trips for network-based systems (includes remotes).
This is usually why you want a nice balance for tasks on the server and the client and sometimes you have to breach the model of “don’t trust the client” where applicable. Clients can handle all that heavy work while the server focuses on more critical tasks, chiefly (sometimes solely) replication.
I don’t know what your implementation is like but as an example of where you can strike balance, the client can check often where it is between said 100 parts and the server can check as in when it needs to perform a security check. Client can tell the server what parts its in, server verifies.
Is cutting down an option for you as well? Depending on how large your regions are, you should switch from iterating across all of them to just checking very specific regions near the character. A small and enclosed map with not many regions, sure, check across all of them, it’s not computationally expensive. On the other hand, a larger map with complex and/or nested regions may need to look at other solutions that cut down how many things you need to iterate over.
1 Like
Thank you, what if I had the client do their thing at the full rate I’ve optimized it to handle, and just had the server occasionally verify? Like if substantial gameplay relies on this, is this a viable option? What I’m doing is lowering health, temperature, or other stats (or raising them) based on location, sometimes rapidly, where hz have an amplified effect.
If you’ve worked on anything or know anyone who has pertaining this, examples would totally help as well.
Without 60hz updates on the client, you could imagine some extreme enviroments with rapid effects would be noticeably out of sync when users entered/exited, like some radiation beam (killing regions) during a rampant boss fight.
Am I a fool for even wanting truly smooth health lowering, when the bar could just lerp or tween to the newest health, though? I want to implement it only more because I can’t, and I figure I might just have to deal and bend to the constraints?
It just seems icky, I never wanted any gameplay to be caused by anything other than the actions the player took themselves.
That’s also an ideal solution. The rule of thumb I have for the server is not to do things frequently and only involve it when it’s actually needed at different points in the game. The server can handle a lot but it just isn’t wise to spend its resources on a frequent task with many intermediate steps.
In terms of depleting stats, you can probably still do that from the server since all it’ll be expected to do is increment a few numbers (health especially, will need to replicate), just don’t expect it to be clocking at a very fast rate like the client would.
The only real example that immediately comes to mind is A Pirate’s Tale by Aurek Team, which has a “Frostlands” and “Ashlands”, a cold and warm area respectively. You lose health over time in these regions without having consumed temperature immunity drinks. The health loss isn’t fast but it’s compensated by each step of health loss being large.
Health will probably require some kind of compensation from the server’s end as you need to handle it from there anyway. Likewise, temperature stats won’t be visible to anyone but the client so you might want to have it predict where the bar should be according to if its losing or gaining temperature; and if you handle the temperature value from the server, then take temperature away at larger chunks periodically. Essentially: the server will infrequently in/decrement stats while the client predicts to match.
I wouldn’t say you’re a fool necessarily for wanting to smooth health lowering but it’s not the wisest choice. Most often that’ll be the first go-to when trying to create bars for stats, thinking that you actually have to smoothly change stats. Once you’re more familiar with creating systems, you’ll realise that you can just use prediction to where a bar should go and the backend can quietly modify stats. May not necessarily be in sync because it is prediction, but we try to be as accurate as possible so prediction is only guessing intermediate steps between the old and new value of a stat.