81–90 of 169 posts
Earlier quoted context omitted.
You can't really do prediction if you are not rendering the game locally, so all you can do is have a lot of servers all over the world and rely on most customers having a low latency fiber link.
The servers could predict what the user does in the next 100ms. Not the same kind of CSP, but fits well into "powered by AI" marketing...
Carmack's dotplans are always interesting history to read. If you weren't a gamer (or alive) at the time when quakeworld came around, you might not appreciate how amazing it was for multiplayer games on the internet. On dial-up, you were lucky to have 150ms latency. Before client-side-prediction, that latency applied to every action you took in game, including player movements. Hit the up-arrow, and you wait 150-300m…
You can't really do prediction if you are not rendering the game locally, so all you can do is have a lot of servers all over the world and rely on most customers having a low latency fiber link.
Theoretically the server could speculatively render and transmit a number of different "potential future frames", and the client throws the wrongly predicted frames away.
That's a nice way to burn even more energy and bandwidth though ;)
Earlier quoted context omitted.
You can't really do prediction if you are not rendering the game locally, so all you can do is have a lot of servers all over the world and rely on most customers having a low latency fiber link.
The servers could predict what the user does in the next 100ms. Not the same kind of CSP, but fits well into "powered by AI" marketing...
And those types of game are the ones that are suffering most from input latency.
Earlier quoted context omitted.
You can't really do prediction if you are not rendering the game locally, so all you can do is have a lot of servers all over the world and rely on most customers having a low latency fiber link.
The servers could predict what the user does in the next 100ms. Not the same kind of CSP, but fits well into "powered by AI" marketing...
I'm also skeptical about the ability for a model to generate predictions without having too many mispredictions to make it viable.
Earlier quoted context omitted.
TIL Ken Silverman was 18 freaking years old when he started working on Build.
I feel a bit mean to all involved in linking this but at the same time it's an extremely interesting piece of history; check out GEORGE.TXT, found in a leaked alpha version of Blood (another Build engine game): https://tcrf.net/Proto:Blood/Alpha_Demo#GEORGE.TXT
Carmack's dotplans are always interesting history to read. If you weren't a gamer (or alive) at the time when quakeworld came around, you might not appreciate how amazing it was for multiplayer games on the internet. On dial-up, you were lucky to have 150ms latency. Before client-side-prediction, that latency applied to every action you took in game, including player movements. Hit the up-arrow, and you wait 150-300m…
I'm not sure if it's funny or sad that there's more key press latency typing into most local Electron apps than connecting to a Quake 3 server 200 miles away back when I had 56k dial-up in 2000.
If you want to fast forward to today's internet, with an average internet connection it takes around 150ms to ping a server in the Netherlands from California. That's over 5,000 miles (8,000 kilometers). Somehow a local key press has the same latency with certain code editors. What have we gotten ourselves into.
Earlier quoted context omitted.
You can't really do prediction if you are not rendering the game locally, so all you can do is have a lot of servers all over the world and rely on most customers having a low latency fiber link.
For the camera alone one could do a few tricks on the client like VR's timewarp/reprojection, but that doesn't work for gameplay actions (like pressing the fire/jump button). Theoretically the server could speculatively render and transmit a number of different "potential future frames", and the client throws the wrongly predicted frames away. That's a nice way to burn even more energy and bandwidth though ;)
Carmack's dotplans are always interesting history to read. If you weren't a gamer (or alive) at the time when quakeworld came around, you might not appreciate how amazing it was for multiplayer games on the internet. On dial-up, you were lucky to have 150ms latency. Before client-side-prediction, that latency applied to every action you took in game, including player movements. Hit the up-arrow, and you wait 150-300m…
Sadly we live in a world today where some local code editors could really benefit from CSP because they add 100-200ms of latency to every character you press. I'm not sure if it's funny or sad that there's more key press latency typing into most local Electron apps than connecting to a Quake 3 server 200 miles away back when I had 56k dial-up in 2000. If you want to fast forward to today's internet, with an average i…