4 ms·
The conceit here is that rendering happens server-side, so visible game-state latency is replaced by input latency.
by Inityx 6y ago
The conceit here is that rendering happens server-side, so visible game-state latency is replaced by input latency.
- ColFrancis 6y agoMany RTS games have already done this in a traditional client rendered setup with deterministic lockstep (e.g. [1]). The basic idea is to have an input at time t which has a fixed delay until t + x. During [t, t+x] everyone syncs what actions they will take, and so everyone renders the exact same state. Of course, if this sync fails then the game will stutter for everyone, unlike in the stadia case, and it has pros and cons for various types of game. It was largely rejected for action games in the past. The trick is you need to specify the minimum latency that everyone must get under for it to run smooth. In the server-rendering case you would be locked to the renderer's region and would have people with better internet having a strong advantage. If you're interesting in this sort of thing, check out [2] which goes into depth on how to synchronise game simulations in a bunch of different ways. [1] https://www.gamasutra.com/view/feature/131503/1500_archers_on_a_288_network_.php https://www.gamasutra.com/view/feature/131503/1500_archers_o... [2] https://www.youtube.com/watch?v=Z9X4lysFr64 https://www.youtube.com/watch?v=Z9X4lysFr64