Module 7 · The present (2018–26)

Cloud and streaming

Cloud gaming is a "future" that has been arriving for ten years as a feature, not a product. It is held in check by physics (latency you cannot hide with prediction) and economics (a GPU for every player), which is why Stadia died and Game Pass streaming survived — not as a good, but as a way of delivering content.

~16 min☁ infra + 💰 business model

The gist in 30 seconds

Cloud gaming: render on a GPU in a data center → encode video → stream to a thin client → input back. Technically it runs into two walls. Latency: the cloud adds a round trip (input→server→render→codec→network→decode→screen) on top of the game's own delay, and — unlike netcode — it cannot be hidden with prediction (the client renders nothing, it has nothing to extrapolate from). Economics: a dedicated/shared GPU per concurrent player — you pay for compute every hour of play, not once per copy. So the cloud survives only as a feature of something else: Stadia (a separate store where you buy games in order to stream them) died in 2023 — it had no reason to exist; Game Pass (a content subscription where streaming is one delivery method) and GeForce Now (a neutral pipe to games you already own, ~21% of the market) survived. And the business shifted: success is no longer "we sold 5M copies" but "100M hours in a week" — an engagement metric, not a sales one.

The mechanism: the cloud's two walls

Latency you cannot hide

A local game renders on your machine, and client prediction hides network delay by extrapolating. The cloud cannot do that: the client renders nothing, it only shows the video it is sent — there is nothing to predict. The full delay chain:

t_{cloud} = t_{render} + t_{RTT} + t_{enc} + t_{dec}

Even with an edge data center (network <20 ms), encoding + decoding + network add ~40–80 ms on top of the game's own delay (~50 ms) → a total of ~100–130 ms input-to-photon against ~50 ms locally. For slow games (RPGs, strategy, turn-based) that is fine; for twitch games (shooters, fighters) it is a ceiling physics will not break: you cannot cheat the speed of light plus the codec pipeline, and network jitter makes the delay inconsistent on top of that.

The economics of a GPU per player

Selling a game is one-off revenue. Streaming a game is a continuous compute cost: every concurrent player needs a GPU in a data center (dedicated or shared) plus bandwidth (35 Mbps for 4K). An hour of play is an hour of GPU rental. That inverts the unit economics: the more successful a streamed game is (more hours), the more it costs you. Which is why a pure streaming product does not add up — something has to subsidize it.

Why Stadia died and Game Pass survived

The key takeaway of the era: cloud gaming is a feature, not a product.

Stadia (Google, †2023) — a tech-first separate store: you buy games at full price in order to stream them from Google's servers. No reason to exist: you pay twice (for the game and for the dependency on the cloud), there is no content moat, and the whole thing rests on "the technology is cool". Dead.
Game Pass (Xbox Cloud) — a content-first subscription: the product is "Netflix for games", and streaming is merely one delivery method that widens the funnel (play on a phone/TV without a console). Streaming is a feature of the catalogue, not the good being sold.
GeForce Now — a neutral pipe to games you already own (Steam/Epic): you do not rebuy anything, it is simply "rented hardware" at a distance. ~21% of the market, 2000+ titles.

Two models survived — the content funnel and the neutral pipe; the third died — the separate store-with-streaming. In 2026 you can see it in the pricing too: Game Pass Ultimate jumped to $29.99 (Oct 2025) and rolled back to $22.99 (Apr 2026) after the backlash — Microsoft is looking for a balance, giving the cloud away as "top of funnel" rather than selling it as a good.

The shift in the business metric

Subscriptions redefined success. Before: "we sold 5M copies × $60". Now: the game launches day one on Game Pass and the revenue is unknown — it depends on engagement (how many hours, how many subscribers it converts/retains). Success is "100M hours in the first week". Designers optimize engagement curves (DAU/time-in-game) rather than "was the player happy with the ending" — with the risk of crushing single-player. The paradox that refutes it: Elden Ring (pure single-player, zero live service) became a generational hit — engagement ≠ necessarily live service.

🕹 What to try — and what to notice

You feel the cloud's walls in your body within a couple of minutes — compare fast against slow, local against cloud.

GeForce Now the neutral pipe · twitch vs slow game

The "rented hardware" survivor: you stream games from your own Steam library. The perfect test bench for feeling the latency ceiling across genres.

🎮 Try: run a slow game (strategy/RPG) and a twitch game (shooter/fighter) through GeForce Now. In the first the lag is unnoticeable; in the second the crosshair "swims" and the input lags behind. That is the latency wall: the cloud is fine for one class of game and agonizing for another, and no upgrade fixes it.

Xbox Cloud Gaming / Game Pass streaming as a subscription feature

Streaming here is not the good being sold but a way to deliver the catalogue: play from a phone/TV without a console, with state carried between devices (suspend/resume).

🎮 Try: start a Game Pass game in the cloud on your phone, then continue on another device — notice the instant state transfer. That is the cloud's real value: ubiquity (play anywhere), not the image quality. Streaming sells "anywhere", and what you pay for is a content subscription.

Stadia †2023 · the tech-first that died

An instructive corpse: it worked technically, but it was a separate store where you had to rebuy games in order to stream them. No content moat, no reason to choose it — Google shut it down in 2023 and refunded everyone.

🎮 Read: a post-mortem of Stadia's death. Notice that what killed it was not the technology (the streaming worked) but the business model: a product that should not have existed. Compare it with Game Pass/GeForce Now — the same technology, but as a feature rather than a good. The diagnosis is about the model, not the engineering.

Deep end · infra: the codec pipeline, edge, and why prediction does not save youskippable

The delay pipeline

The full path: poll input → send to server → render frame → real-time GPU encoding (H.265/VP9, low-latency profile) → network → decoding on the client → display. Every link costs milliseconds: encoding/decoding per frame (even with GPU encoders, tens of ms for buffering and compression), the network is RTT plus jitter. Edge data centers (servers closer to the player) only cut the network part to <20 ms; the codec pipeline stays.

Why client prediction does not work

In a local networked game the client renders the world itself and extrapolates against your input, hiding the RTT (prediction + reconciliation). In the cloud the client is a "dumb display": it does not know the game logic and cannot draw a reaction to a keypress on its own, only wait for video from the server. There is nothing to hide — the latency is visible in full. Partial hacks (speculative client-side rendering, Stadia's negative-latency experiments) stayed marketing.

Designing for streaming

Games built for streaming have to support instant state serialization (suspend/resume across devices) and tolerate variable latency and quality. "Watchable" games (co-op, emergent chaos) also win at algorithmic discovery, but that is about marketing, not rendering.

Deep end · economics: why streaming has to be a feature rather than a productskippable

The unit economics of a pure streaming product diverge by construction.

Cost scales with success

Selling a copy: revenue is one-off, the cost of delivery is ≈ zero (downloaded once). Streaming: every concurrent player needs a GPU slot, an encoder and bandwidth — that is a marginal cost per hour of play. The more people play, the more you pay. For ordinary software "one more user" is nearly free; for cloud gaming it costs hardware. Which is why you cannot "sell streaming" cheaply: success ruins you.

Hence — subsidy only

The model only adds up if streaming subsidizes something with better margins: a subscription (Game Pass: you pay for the catalogue, streaming is bonus delivery, and plenty of subscribers rarely stream at all), or hardware/an ecosystem (NVIDIA: GeForce Now sells loyalty to a GPU brand and upsells a subscription). A standalone store-with-streaming (Stadia) has nothing to subsidize the GPU hours with — and dies. The conclusion: cloud gaming is a delivery channel with bad economics of its own, valuable only as a feature of a product with good ones.

Analogy

Cloud gaming is renting a gaming PC in another city and watching it over a video call while you send it commands. Brilliant when you have no PC of your own and the game is slow — but you feel the video-call lag, and the owner needs a whole PC for every viewer. It is a feature ("play anywhere") bolted onto something you wanted anyway (a catalogue of games), not a thing you would buy on its own. Stadia tried to sell the "video call to a rented PC" itself as a good — and nobody wanted to rebuy their games in order to watch them through a laggy call.

Why it matters

The cloud is the second case after VR of "a cool technology ≠ a product". For ten years the "future of gaming" has arrived as a delivery feature rather than a replacement for local hardware, because it runs into physics (latency you cannot hide with prediction) and economics (a GPU per player). So it lives only as a channel for a content subscription (Game Pass) or as a neutral pipe (GeForce Now) — and dies as a standalone good (Stadia). Understanding what a technology can be (a feature) and what it cannot (a product) is the same engineering judgment as "VR is not always the answer" and "ML is not always the answer".

🔁 Beyond games — where this transfers

The lesson is "cloud vs local" and "feature vs product": latency, the unit economics of compute, and business-model fit.

ML / AI (your domain): cloud gaming is cloud inference vs on-device almost word for word (exactly as in LLM NPCs): a cloud model adds latency (network + inference) and costs a GPU per user per request — the same economics as "a GPU per player per hour of streaming", and the same reason on-device, quantization and batching matter. The latency stack $t_{net} + t_{enc} + t_{dec}$ ⇄ the inference time budget. And "the cloud is a feature, not a product" = "LLMs/AI are a feature, not a product": the argument about GPT wrappers and AI-as-a-feature versus standalone is the same Stadia death (the better technology loses to the better business-model fit and distribution). Read where a technology actually fits (channel/feature) against where it is hype (a standalone good).

Infra / SaaS: thin client plus server-side compute = terminals/VDI/edge; marginal cost per user-hour versus "one more user is free" decides the whole unit economics of a product.

Strategy / product: the better technology ≠ the better business; content moat and distribution beat engineering; a feature subsidized by a high-margin product versus an unviable standalone.

Principle: ask not "does the technology work" but "do its unit economics add up and what subsidizes them". What cannot survive as a product is often valuable as a feature.

🔧 Run it and poke at it — on your home machine

What to play is above (🕹). Here — measuring the cloud's walls.

🔧 Tinker (latency) ~40 min, GeForce Now / Xbox Cloud

Run one game locally and through the cloud and feel the difference in input-to-photon (best on a twitch game). Turn on the latency/network overlay if there is one; catch the jitter when the network is loaded. Estimate the budget: how much the network, the codec and the decode each add — and why prediction is powerless here (the client renders nothing).

🧪 Test (business model) ~15 min

For three cloud services (Game Pass, GeForce Now, the late Stadia), answer: what here is the product and what is the feature? What subsidizes the GPU hours? Then design a viable cloud service from scratch — and notice that it inevitably turns out to be a feature of something with margins.

Checklist: felt the latency difference local/cloud on a twitch game; explained why prediction does not save you; classified 3 services as product/feature; found the source of the GPU-hour subsidy.

Connections

foundation

A taxonomy of netcode — why the cloud cannot hide latency with prediction: the client renders nothing.

contrast

The VR/AR reality — a neighbor on the "cool ≠ needed" theme: VR hit physiology, the cloud hit latency and GPU economics.

adjacent

LLM NPCs — the same cloud-inference vs on-device choice: latency plus a GPU per user.

The economics of the industry — consolidation around subscriptions (Game Pass) is part of a larger shift in platform power.

Questions worth asking

Why did Stadia die and Game Pass streaming survive — it is the same technology?

The difference is not the technology but the business model. Stadia was a separate store: you buy games at full price in order to stream them from Google's servers — you pay twice, there is no content moat, and no reason to choose it. Game Pass is a catalogue subscription where streaming is just one delivery method (play without a console); the product is content, streaming is a feature that widens the funnel. GeForce Now is a neutral pipe to games you already own (no rebuying). The survivors are the ones whose streaming is subsidized by a high-margin product (subscription/hardware); the one that died tried to sell the streaming itself. The diagnosis is about the model, not the engineering.

Why can't cloud latency be hidden the way ordinary netcode hides it?

Because client prediction requires the client to render the world itself and extrapolate the reaction to your input locally (see prediction + reconciliation). In the cloud the client is a "dumb display": it knows neither the game logic nor the physics, and has no world state to predict anything from. Press a button and all you can do is wait while the server renders, encodes and sends video. There is nothing to hide: the whole delay (network + codec + decode) is directly visible. That is the fundamental difference between a "thick" client (renders, predicts) and a "thin" one (only displays).

Why are the cloud's unit economics so bad — it is "just servers"?

Because the cost is marginal per hour of play rather than one-off. Sell a copy and the revenue is fixed while delivery is nearly free (downloaded once). Stream it and every concurrent player needs a GPU slot, an encoder and bandwidth — every hour of play costs hardware. In ordinary SaaS "one more user" ≈ free; in cloud gaming it costs a GPU. The paradox: the more successful a streamed game is (more hours), the more it costs you. So pure streaming cannot be sold at a profit — it has to be subsidized by a subscription or by hardware sales. These are not "just servers", they are expensive servers for every active player.

So is cloud gaming a dead end, a "future that will never arrive"?

No — it is simply a feature, not a revolution. As a delivery channel for a content subscription (Game Pass) or as remote hardware for your own library (GeForce Now) it is genuinely valuable and growing: it gives ubiquity (play from a phone/TV, without an expensive console) and instant state transfer. What it will not do is replace local hardware for twitch games (latency) or become a profitable standalone product (GPU economics). The "future" is arriving, but in the shape of a feature, not in the shape of "everyone plays in the cloud instead of on consoles". Just like VR: a real niche instead of the promised revolution.

When is cloud gaming genuinely good?

When three conditions line up: a slow game (latency is not critical — RPGs, strategy, story-driven), no powerful hardware (a phone, a weak laptop, a TV — the cloud gives you AAA without a $500 console) and value in ubiquity (started on the TV, continued on the subway). Then the "play anywhere, no hardware" feature outweighs the lag. And the reverse — competitive twitch play on a good PC: here the cloud only adds delay and costs money for nothing. Knowing that fitness profile ("what this is a feature for and what it is not") is exactly engineering maturity toward a technology.