I’ll be honest: my biggest disappointment so far in the beta was loading it up and seeing that it uses the same old 62.5 tickrate that OW has. You improved the rendering, polished up the sound engine, but the netcode is the same as ever.
C’mon guys, servers running at 60 something tickrate was ok-but-not-great back in 2016, and now it’s 2022.
What gives?
Consider that the 6v6 → 5v5 format change makes it so every active game server has fewer clients to manage. As a result, each one has to use proportionately less bandwidth to run the game, right?
Valorant and CS:GO both run 5v5 servers at 128 tickrate now.
Would it be unreasonable for you guys to modernize the netcode a little and bump up the tickrate to something closer to 90-100? Even if it just applied for competitive/quickplay games and not for arcade or custom game servers, it would be a big help with the fast-paced feel of the format.
Everything in Overwatch is based entirely on the server-state. Unlike most games, the engine was designed in a way that client only gets to suggest what actions it wanted to make and has to wait and see if the server accepts them.
Calculating and updating the gamestate more times per second increases the precision and responsiveness of interactions in this sort of system. Anything else trying to accomplish the same thing is going to rely on complex predictions, interpolations, or extrapolations, all of which work much better if the server does not control 100% of the simulation state.
Almost (see the prediction models section), and there is a lot of server side stuff you can do. I’ll go though a list.
The first is you can switch to an algebraic geometry model on the server, so rather than doing a check to see if a junkrat mine hits a target each tick, you plot the trajectory of the sphere, and see if it intersects against the hit spheroids. That way if something would hit at a higher tick rate, it still picks up that intersection even though the tick rates are slower.
Basically, rather than do a bunch of spheroid vs spheroid checks, you do a check of spheroid moving along a path vs another spheroid along a path. Weirdly enough the checks are not much more expensive to run, but it emulates an infinite tick rate, and do a recheck if you get an update to movement, from that point on.
So you end up disconnecting “tick rate” from hit box intersection code, it makes a huge difference.
The second part is prediction, which is part of lag compensation.
If you use a better model than “they are going this way, so we expect they will continue to do so”, which takes into account what the player usually does. You can get quite a lot better lag compensation, and better prediction on client as well as the server.
Typically these models also form part of a “player fingerprint” which checks to see if the player is the same between accounts on the same machine as part of smurf detection.
Kinda. Geometric Algebra isn’t all that complex if you build for it, and people are starting to use it for server models already, since it is less processor than running higher tick rate simulations.
And complex prediction models are already starting to be formed for reasons other than just lag compensation, but they work well for doing lag compensation.
The server does have 100% of the canonical simulation state, but yes, using the prediction models, on do also get run on the client, with reconsideration network frames.
I’m been doing some game server work (not for Blizzard), and the state of the art is getting really interesting.
But tick rate isn’t all that, and I suspect you will see some server models disconnect themselves from the idea of a tick rate, and more towards a kind of 4d model of the match. Where the equivalent of tick rate is basically only the “how long do we keep history” for lag reasons, but each input modifies the in memory model.
It is cool as hell, and I am like, super excited to talk specifics if you are interested
A lot of the tech pushing this along is robotics, since they have to check for collisions across multiple systems, all pushing updates at different rates to the central control, and the tech between game engines and robotics control are becoming more closely tied together.
So people are moving back and forward between the industries, each bringing their way of getting this stuff done.
Exciting time to do game Dev. (Sadly, I’m mostly doing big integration and data projects but I get some game industry stuff in between).
I mean, yes, you are right, but yes, the more complex models are happening.
Will Blizzard adopt them? almost certainly not - so I guess higher tick rates are all you can hope for there
I just wanted to point out that tick rate wasn’t the ONLY way to skin that cat.
shouldn’t it be a conic? it’s not a sphere but rather boundary of sphere. it’s an isoperimetric projection of the intersections, so no need to even treat it as a spheroid (which takes at least 2 extra bytes to specify)
That just sounds invasive and rigged.
the dodge bots are winning because of this.
they spoof that directionality assumption.
the thing with geometric algebra is it locks you into that prediction.
i do agree it’s better than blindly upping the tickrate, but so is just about every other ‘better use of math’.
I don’t see how that’s going to be faster than a conic. I suspect this from my geometric measure theory class (which generalizes ‘constructive’ geometric algebra to spectral/stochasic spaces).
The players are (for simplicity) point sources and the spheroids they launch will always be enclosed in a cone. Are you using a single parameter to define the spheroid? i.e. radius + centroid?
I played with DWAVE back in 2011 when my quantum software startup failed. I still toy with quantum categorical semantics because i feel they don’t have good compilers for that stuff. i guess by now you know who my main accnt is bcuz there are very few ppl on these forums who visit those parts of the library.
I honestly think DWave won’t be any faster than classical, but hey, if someone is going to pay me to play with it and matchmaking? I’ll take their money.
I’ve tried all the quantum APIs. MSFT, IBM, Intel, etc. I met with DWAVE people in 2010-2013 era (before my crippling addiction to bot5 OW). But ofc they’re more topological/reservoir model which is great for ‘accelerator type’ work in combinatorial optimization. Their API for toy models (and R&D types like me) was a mess. But it was and still is in python.
The IBM Qiskit is my current fav. But I’m trying to find something in Haskell since I think it will tie into quantum graph databases better.
I could venture a guess on the results for ‘quantum matchmaking’ from quantum game complexity. It will form a kind of contract metagame between parties the way all the other quantum-xyz works. You should be able to get either better matchmaking or faster matchmaking (in the sense of close games and high fidelity labels) through quantum interactions (superimposed initial + entanglement). The representation would have to be a kind of Hilbert CSP.
p.s. these queues are bad. maybe quantum can save 122
Slightly worse but repeated many times to get better approximations in a shorter total time.
If I had to explain it in 10 secs, then pretty much the same way you make a genetic alg (even the most primitive problem like the all 1s). You encode the matchmaking as a binary string and slam the quantum system with XORs or popcounts. There is no backtracking or tabu correction for quantum CSP (at least not on topological types, you need more clever circuit/gate models of quantum compute for proper tree/graph search and the like).
it reminds me of the physics co-processors we had years ago. the early days of gpgpu using a kind of ‘islands model’ where you tried to minimize the communication between the nodes. so you 1 time ask cloud or in this case a quantum coprocessor (that could be simulated by a lot of cloud hardawre) to mulch on one specific well-tailored instance of the problem and return the answer.
it’s great to frame problems this way (that oracle’lize data/memory i/o) but ofc this is hard and has limitations. can’t make use of all the tricks that stockfish does (probably the state of the art in terms of FOSS tree/graph parsing).
do you want the matchmaker to give fair labels or fair matches?
there is no free lunch. if you rig the micro the macro is bad. if you rig the macro the micro is bad.
Seriously, I’m just going for the classic napsack like problem of “find me the group with the closest matching SR, which are possible to put in the same match”
I said it wouldn’t be the best matchmaker out there.
They asked that one existed, not that it was good. You get good if I get longer than 4 months - it will take one just to work out how to talk to this thing.
Hell, I may even take into account ping times to various servers if I get the time.
