Parked Cars, Long-Haul Cabins and Living Rooms: The Captive-Screen Case for HTML5 Games

HTML5 games run on parked cars, aircraft cabins, smart TVs and kiosks — captive screens that have dead time, a web runtime, and almost no competition for them. Nobody is bidding for these surfaces the way they bid for the phone, and the reason is not that they are small. It is that most catalogues are built and licensed as if a touchscreen in a hand were the only place a game can land.

The interesting thing about these screens is not that they exist. It is that they share a shape. Each one has a player who cannot leave, a block of time defined by something other than the game, and a browser engine sitting under the interface. That combination is unusual and it is worth designing for deliberately, because the design constraints are nothing like mobile's.

🚗 A Parked Car Is a Games Console With a Bad Controller

The clearest working example is BMW's. BMW Group has partnered with AirConsole since 2022, and on 21 August 2024 it pushed UNO Car Party! over the air to more than 500,000 BMW and MINI vehicles. Up to four people play. Their phones are the controllers, connected by scanning a code on the centre display. Each player sees their private hand on their own phone while the shared board sits on the car's screen. The car has to be parked.

Read that architecture again, because it is the whole point. A display running a web view, phones acting as inputs over a local connection, no app installed on the controllers, content delivered over the air rather than through a store. That is an HTML5 deployment pattern. It is the same pattern a browser-based party game has used for a decade, moved onto a dashboard.

The dead time is real and measurable. A 2023 study from Purdue University's Joint Transportation Research Program, Evaluation of Electric Vehicle Charging Usage and Driver Activity, found median charge times between 28 and 36 minutes across charger types, and — more usefully for anyone building for the surface — that roughly 43 to 45% of drivers stayed in the vehicle for the duration rather than walking to a shop. That is a large minority of charging sessions where a person is sitting in a seat, facing a screen, for half an hour, with nothing scheduled.

Keep the scale honest. Half a million vehicles is not half a billion handsets, the games only run stationary, and the install base grows at the speed of car sales and OTA updates rather than app downloads. This is not a replacement for mobile distribution. It is a surface where a well-suited title has very few competitors, which is a different and sometimes better thing.

✈️ The Cabin Just Got Bandwidth It Never Had

In-flight gaming has been technically possible and practically miserable for years, because the connectivity underneath it was metered, slow and expensive. That premise is being dismantled right now.

Southwest's own announcement says its first Starlink-equipped aircraft enters service in summer 2026, with more than 300 aircraft by the end of the year, and the Wi-Fi is free for Rapid Rewards members. The activities the airline lists explicitly include playing games. Separately, AeroTime reported in 2026 that International Airlines Group will fit Starlink to more than 500 aircraft across Aer Lingus, British Airways, Iberia, LEVEL and Vueling, starting early in the year — against a fleet IAG put at 601 aircraft as of December 2024. American and Frontier have announced their own Starlink programmes.

Two things follow, and only one of them is obvious.

The obvious one: bring-your-own-device gaming in a cabin stops being a joke. A passenger with a phone, four hours, and a connection that does not time out is about as captive as an audience gets.

The non-obvious one: this is a retrofit, not a switch. For years the same aircraft type will fly with three different connectivity generations depending on which airframe you boarded, and the advertised aircraft-level speed is shared across every passenger on board. A game that assumes the marketing number is the number it gets will feel broken in the seat. Design for the worst cabin in the fleet and the best one will be pleasant. This is one of the surfaces where our airline games category exists precisely because the constraint set differs from a normal web build.

📺 A Smart TV App Is Already an HTML5 App

The living room is the surface people most often assume is closed to them, and it is the one that is most open. Samsung's Tizen and LG's webOS are web-first platforms: apps are HTML, CSS and JavaScript. LG steers developers toward Enact, its React-based UI framework tuned for a remote-driven interface, and packaging happens through the webOS TV SDK; Samsung's route is Tizen Studio or its VS Code extension. You are not rewriting a game in a foreign language. You are repackaging a web build and rebuilding the input layer.

On how much audience that reaches, the honest answer is that published estimates disagree badly. Surveys of the global installed base in 2025 and 2026 put Android TV and Google TV somewhere around 35–40%, Samsung's Tizen anywhere from roughly 14% to 23%, LG's webOS from roughly 9% to 25%, and Roku around 10–11%. Those are not small discrepancies — the webOS range spans a factor of nearly three — and they come from different methodologies counting different things: units shipped in a year versus televisions actively in use, global versus regional. The regional split is sharper still: in US broadband homes, Roku leads.

Do not build a business case on any single one of those figures. Build it on the structural fact underneath them, which nobody disputes: the two biggest TV-maker platforms both run web applications, and a catalogue that is already HTML5 is already most of the way onto them.

🕹️ Input Is the Part That Breaks

Everything above is easy compared with this. Captive screens have four input models and none of them is a finger on glass:

• A TV remote. Four directions and a confirm button. No pointer, no hover state, no drag.
• A car's controller or centre display. A rotary dial, a few hard keys, sometimes touch, all designed for menu navigation rather than play.
• A phone acting as a gamepad. Real inputs, but with network latency between the press and the pixel, and a screen the player is not looking at.
• A public kiosk. Touch, but standing, in daylight, possibly with a queue behind and gloves on.

The practical test is blunt: if a title can be completed with four directions and one confirm, it ports. If it needs pixel-accurate dragging, precise multi-touch, or a swipe gesture, it does not port — it needs redesigning, and redesigning a licensed title is a different commercial conversation from deploying one.

The secondary problems all trace back to the same root. Focus management has to be explicit, because there is no cursor to fall back on. Hit targets and typography have to work at a distance the designer never sat at. Hover states are dead weight. Any interaction that assumes a keyboard — entering a player name, say — becomes a genuinely painful on-screen picker unless you design around it.

⏱️ Someone Else's Clock Sets the Session Length

On mobile, a session ends when the player decides it ends. On a captive screen, it ends when the charge completes, the seatbelt sign comes on, or the person's coffee is ready. The player has no say and neither do you.

So the session lengths are effectively fixed per surface, and they are wildly different: a couple of minutes at a signage or retail kiosk, half an hour at a charger going by the Purdue medians, several hours in a long-haul cabin. A single game rarely spans that range well. Match the round structure to the clock instead of shipping one build everywhere.

It also kills a whole class of mechanics. Daily rewards, streaks, energy timers and anything else that assumes a returning player are worthless on a screen the player will never sit in front of again. Worse than worthless — they occupy the first thirty seconds of a session that only has ninety. Progress that survives a hard interruption matters more than progress that accumulates across days. The same discipline applies to trade show and event games, where the clock is set by the queue rather than the charger.

📶 The Connectivity Assumption Inverts

Web games mostly assume the network is there. On these surfaces it frequently is not, and the failure is invisible until it is embarrassing — a kiosk in a basement retail unit, an aircraft mid-retrofit, a vehicle whose data plan the owner never activated, a hotel with a captive portal in the way.

The rules that follow are unglamorous and non-negotiable. Cache the entire playable build, not just the shell. Make zero blocking calls at runtime — no font fetched from a CDN on first frame, no leaderboard request the game waits on, no analytics beacon in the critical path. Let ad calls fail silently rather than stalling the round. Assume the clock may be wrong and the storage may be wiped between sessions.

This is the same engineering discipline that makes a title work in a low-connectivity market, which is a useful thing to notice: the work you do for a cabin is the work you would have done for a portal in a market on patchy 4G. It ports both ways.

🚫 Five Ways Operators Waste the Opportunity

1. Shipping the mobile build with bigger buttons. Scaling a touch UI does not create a focus model. It creates a game that looks fine in a screenshot and cannot be played with a remote.
2. Assuming the licence already covers it. Licence scope is written by platform and territory. A right to publish on your website is not automatically a right to embed in an in-flight system, preload on a head unit, or ship inside a TV app. Establish the scope in writing before the integration work, not after a legal review kills it.
3. Bringing a monetization model the surface cannot serve. Rewarded video needs ad demand that reaches that inventory. In-app purchase needs a payment path the player can actually complete in the seat. On several of these screens neither exists, and the commercial model has to be sponsorship, a platform fee, or a licence — decided up front, not discovered at launch.
4. Sizing the surface like mobile. These are hundreds of thousands to low millions of devices, not billions. That is fine if the acquisition cost is a partnership rather than a media buy. It is not fine if the plan needs mobile-scale volume to break even.
5. Treating one integration as a platform strategy. Getting a title onto one TV OS teaches you the packaging. It does not give you the input abstraction, the offline layer or the session model that make the next five integrations cheap. Build those once, deliberately, or pay full price every time.

🎮 Where a Licensed Catalogue Fits

Forestry Games has licensed games since 2017 and maintains a catalogue of 1,049 titles spanning HTML5 and Android APK builds, with titles also published on Google Play and the App Store. We develop HTML5 games in-house, work with branded IP, and hold brand partnerships including Disney, Nickelodeon, Cartoon Network and Warner Bros.

For captive screens specifically, the useful part of a catalogue is not its size. It is having enough breadth to find the handful of titles that genuinely survive a four-direction controller and a fixed clock — puzzle, card, quiz, arcade and board formats tend to, twitch and precision-drag formats tend not to — and having a licence written for the surface you are deploying to rather than a generic web grant. Browse the full catalogue or the HTML5 games section if you want to see what the format spread looks like in practice.

🧭 What To Do Next

Pick one surface. Not four. The input model, session length and connectivity profile differ enough between a car, a cabin and a television that trying to serve all three at once produces a build that serves none of them.

Then do this, in order. Choose three titles from your existing catalogue that pass the four-directions-and-a-confirm test. Get the actual hardware — a real remote, a real head unit, a real kiosk enclosure — and play them on it, because every problem in this article is invisible on a development laptop and obvious within ninety seconds on the device. Establish in writing that your licence covers the platform before anyone writes integration code. Decide how the deployment makes money before you decide what it looks like.

That sequence costs a couple of weeks. The alternative, which the industry keeps choosing, is a six-month port that ships onto a screen the licence never covered, monetised by a format the surface cannot serve, controlled by an input the game was never designed for.