10:04in productionCh. 1 · It’s video, not code/ 10:04 · ceiling 15 min
Systems · Internet culture
Cloud gaming
Cloud gaming moves the game out of your machine — but puts your reflexes at the mercy of your ISP.
Cloud gaming is a remote execution system that streams video and audio while relaying inputs. It depends entirely on network quality — not hardware — and fails where latency exceeds ~50ms. It was first demonstrated by G-cluster at E3 2000 and released around 2003.
Games run remotely, not locally — the screen shows a video feed, not native rendering.
2:43
Two-way streaming
Inputs go up; outputs come down — and some services even let you install games inside a virtual PC.
4:26
The physics problem
Latency isn’t a bug — it’s the defining constraint. Fast games fail first.
6:19
Band-aids on the pipe
Caching helps, but it doesn’t fix the speed of light or your ISP’s traffic shaping.
Worth your time?
Yes. Study the whole thing.
2.5/ 5
What works
streaming video output
relaying inputs over stable connections
virtualised Windows game installation
What does not
eliminate network dependency
support competitive first-person shooters reliably
function under data caps or congestion
Study it if
users with fibre broadband and zero data limits
players prioritising library access over responsiveness
Skip it if
mobile users on cellular networks
competitive players
rural users with asymmetric DSL
The written brief1 min read
What it is and the problem it solves
Cloud gaming solves the problem of running demanding games on underpowered devices. It does so by offloading execution to remote servers and streaming output. It does not eliminate the need for capable networks — it relocates the bottleneck.
How it works
Cloud gaming runs games on remote servers. It streams video and audio output to the user’s device. Client software captures player inputs and sends them back to the server for execution. Some services use virtualised Windows environments to let users install games as if locally.
What works
Streaming video and audio output works reliably where bandwidth and latency are sufficient. Input relay via client software works. Virtualised Windows environments enable familiar installation workflows. Caching reduces latency in predictable, repeatable request patterns.
What does not
Latency cannot be eliminated. Input delay breaks precision-dependent gameplay. Traffic congestion and ISP data caps break regular usability. Caching helps but does not solve the core physics of network round-trip time.
What it changes
It shifts compute from the endpoint to the data centre. It replaces local hardware ownership with subscription-based access to remote infrastructure. It makes game libraries contingent on provider uptime and network policy — not device capability.
Is it worth your time
It is worth your time only if you have a stable, low-latency, high-bandwidth connection with no data cap — and only for games that tolerate input delay. For fast-paced titles, it remains functionally impaired.
