A 10 Mbps Booth Line Costs $7,850. Your Trade Show Game Should Not Need One.

A trade show game that depends on hall Wi-Fi will fail at 2pm on day one. Build it offline-first and the venue network stops being a problem you buy around.

Every exhibitor who has run an interactive stand knows the moment. Move-in day, the tablets connect fine, the game loads in four seconds, everyone signs off. Then the doors open, eleven thousand people walk in carrying two radios each, and by mid-afternoon the game that loaded in four seconds is showing a spinner while a prospect stands there deciding whether to wait.

The reflex is to blame the venue and buy more bandwidth. That is the expensive answer to the wrong question. The right answer is to build the thing so it never asks the network for anything during play.

📶 What the Venue Actually Sells You

Start with what is on offer, because the numbers reframe the problem. Trade Show Internet — a connectivity rental firm, so read their figures knowing they sell the alternative — publishes a breakdown of exhibitor connectivity at the Orange County Convention Center, one of the largest halls in North America. The complimentary Wi-Fi runs at 768 Kbps up and down per user, is limited to common areas and lobbies, and in their words "coverage does not extend into the exhibit hall."

So the free tier does not reach your stand. What does:

• Premium shared bandwidth from the in-house provider, Smart City Networks, starting at $1,095, plus $150 per additional device
• A 3 Mbps dedicated line at $3,495
• A 10 Mbps dedicated line at $7,850
• A 24-port switch at $225, floor labour at $125 per hour, and payment due 21 days before the first day of move-in

Read the per-device line again. Shared bandwidth is priced per connected thing. Four tablets on a stand is the base rate plus three device charges before anyone has played anything. Rate cards differ by venue, by show, and by year — the only figures that bind you are the ones on your own show's order form — but the shape holds almost everywhere: the free network does not cover the floor, and the paid one meters devices.

Now price the failure. A dedicated 10 Mbps line at OCCC rates costs more than most exhibitors budget for the interactive content itself. You are being asked to spend four figures on plumbing so that a game which could have run entirely from local storage can phone home between rounds.

🚫 You Cannot Quietly Route Around It

The obvious dodge — bring your own router, tether to a phone, run a MiFi under the counter — is prohibited at a meaningful number of shows, and the prohibition is not decorative. The SC26 network policy is unusually blunt about it:

"Exhibitors, contractors, and attendees may not operate their own IEEE 802.11 (a, g, h, n, ac, ax or other standard) wireless Ethernet access points anywhere within the convention center, including within their own booths."

The same policy extends to "personal hotspots, mifi, or other WiFi-to-cellular bridges," and reserves the entire 2.4 GHz, 5.2 GHz, 6 GHz and 60 GHz spectrum to the show's own network team. Shows enforce this because they have to — a hall full of unmanaged access points degrades into noise, and the organiser is the only party who can prevent that.

Assume, then, three constraints at once: the free network does not reach you, the paid one costs real money and charges per device, and you may not legally bring your own. Any game design that treats connectivity as ambient is designing against all three.

⏱️ The Real Failure Mode Is Not "No Internet"

Total outage is the easy case. You notice it, you apologise, you hand out a business card. The damaging case is the degraded one: the connection that resolves DNS, completes the handshake, serves the first 300 KB of assets, and then crawls.

A game built to stream assets on demand behaves horribly under those conditions. The menu appears. The player taps. The level does not load. There is no error, because nothing has errored — a request is simply outstanding. The player waits four seconds, then eight, then walks. Your stand staff have no idea whether to restart the tablet or keep talking.

That is worse than a hard failure, because a hard failure at least tells you what to do. Intermittency turns a lead-generating asset into a piece of furniture that occasionally works, and it does it precisely during peak floor hours, when the hall's network is under the most load and your prospects are most valuable.

Degraded networks punish the wrong things

Watch what a typical web game touches mid-session and the exposure becomes obvious: a font from a CDN, an analytics beacon, a leaderboard POST, an ad call, a remote config fetch, a sound sprite loaded lazily on first use. Each is small. Each is a blocking dependency on a network you do not control. On a good connection, none of it matters. On a saturated 2.4 GHz band at 3pm, any one of them can hang the first frame.

💾 The Whole Game Fits in the Cache. It Isn't Close.

Here is the part most people get wrong by an order of magnitude. They assume browser storage is tight, so they stream. It is not tight.

MDN's reference on storage quotas and eviction criteria gives the actual ceilings. In Chromium-based browsers, including Chrome and Edge, "an origin can store up to 60% of the total disk size in both persistent and best-effort modes" — their worked example is 600 GiB on a 1 TiB drive. Firefox allows the smaller of 10% of disk or a 10 GiB group limit in best-effort mode, and up to 50% of disk in persistent mode. Safari also lands around 60% of total disk for browser apps.

A polished HTML5 booth game with full audio and high-resolution art is a few tens of megabytes. On a mid-range Android tablet with 64 GB of storage, the browser will hand you gigabytes. You could precache the game, three alternate games, every localisation, and a video loop, and not approach the limit.

The one storage mechanism that genuinely is small is the one people reach for out of habit: Web Storage is "limited to 10 MiB of data maximum on all browsers," roughly 5 MiB each for localStorage and sessionStorage per origin. Fine for a high-score table. Useless for assets. If your build is putting anything substantial in localStorage, that is a bug waiting for the show floor to find.

🧱 What Offline-First Means for a Booth Build

The mechanism is a service worker with an aggressive precache. MDN's PWA caching guide describes the cache-first strategy for exactly this case: resources "the PWA is certain to need, that will not change for this version of the app, and that need to be fetched as quickly as possible." Precache them in the service worker's install event and, as MDN puts it, "the app's UI can be rendered on launch without needing any network requests."

For a consumer web portal, precaching everything is overkill — you are optimising for first-visit weight across thousands of unknown visitors. A booth is the inverse problem. You have four known devices, one venue, one week, and a single load event you fully control during move-in. Precache everything. There is no cold-start cost to protect, because the cold start happens the day before the doors open.

Concretely, a booth build should:

1. Ship every asset in the precache manifest — art, audio, fonts, level data. No lazy loading, no CDN fonts, no runtime asset fetch.
2. Self-host fonts and libraries. A Google Fonts request is a network dependency in the critical path, and it will be the thing that hangs.
3. Make every network call non-blocking and failure-tolerant. Analytics, leaderboards, remote config: fire and forget, never await.
4. Persist state locally and reconcile later. Scores, session counts, captured leads — write to IndexedDB, sync when there is a connection, and never let the sync gate the gameplay.
5. Request persistent storage via the Storage API so the browser deprioritises evicting your data. MDN notes eviction "is a very rare event" in practice, but a show week is not the time to rely on rarity.

The two features that genuinely want a network

Two things resist offline design: a live leaderboard across multiple stations, and lead capture that feeds your CRM in real time. Both are solvable without a venue line.

For the leaderboard, run it on the local network segment or accept per-device boards and merge them at end of day. Most exhibitors discover the cross-station live board mattered less than they thought — the prospect cares about their own score and whether they beat the person next to them, which is a same-device or same-tablet-pair problem.

For lead capture, queue locally and sync in batches. Records written to IndexedDB and flushed over a phone tether in the coffee break are indistinguishable, at the CRM end, from records posted live — and they survive the four hours when the hall network does not. This also removes the worst outcome in the category: a lead form that submits, fails silently on a hung request, and loses the contact you just earned.

🔌 Test It the Way the Hall Will Break It

Almost nobody tests a booth game under the conditions that will actually kill it. The office Wi-Fi is fast and empty; the hall is neither. Run these before you sign off:

• Airplane-mode cold boot. Load the game once, kill the browser, disable all radios, reboot the tablet, open the game. If it does not reach a playable state, you do not have an offline build.
• Throttled, not severed. Use browser devtools to simulate a slow connection with high latency rather than toggling the network off. This is the condition that surfaces hanging awaits.
• The eight-hour run. Leave it looping through attract mode and gameplay for a full show day. Memory leaks that are invisible in a five-minute demo will crash a tablet by hour six.
• Thermal and battery. A tablet charging while running a WebGL game all day gets hot and throttles. Test at temperature, not from a cold start.
• Kiosk lockdown. Lock devices to the single app — Guided Access on iPadOS, screen pinning or a managed kiosk configuration on Android — so a curious attendee cannot exit into the browser, the camera roll, or your email.

❌ The Anti-Patterns, Named

Five decisions that reliably produce a dead stand:

• Treating the venue line as insurance. Buying a dedicated 3 Mbps connection does not make a streaming game safe; it makes an unsafe design expensive. Fix the build, then decide whether you still need the line.
• Demoing the live production site. Your marketing site's game embed pulls tag managers, consent banners and ad scripts. That is a hostile payload on a bad connection. Ship a stripped standalone build.
• Discovering the AP rules at move-in. Read the exhibitor manual's network section when you book the stand, not the night before. If the show is a no-hotspot show, your offline plan is not optional.
• One tablet. Two people playing is a queue; a queue is a reason to stop walking. One device is also a single point of failure with no spare.
• No offline fallback for the prize mechanic. If the draw, the voucher code, or the reward reveal requires a server, it will fail in front of someone you were trying to impress.

🎯 What to Ask a Supplier Before You Commission Anything

Whether you are licensing an existing title or commissioning a custom build, the questions are the same, and they are answerable in a sentence each:

1. Does the build register a service worker that precaches all assets at install?
2. What is the total precache size, and what is the list?
3. Which requests happen after first load, and what does the game do when each one fails?
4. Can it be handed over as a folder that runs from a local web server with no internet at all?
5. What happens to captured data if the device never reconnects during the show?

Point four matters more than it looks. "Runs from a folder" is the cleanest test of genuine offline capability, and it also gives you a deployment path that does not touch the hall network in any way: a small local server on the stand, four tablets on an isolated wired switch, nothing routed to the outside world. No per-device charges, no shared bandwidth, no rate card.

🎪 Where This Fits

Forestry Games has licensed HTML5 games since 2017 and builds custom titles for stands and events, so we see the same constraint from both ends: the catalogue side, where a licensed game has to be handed over as files an exhibitor can host anywhere, and the custom side, where the build spec has to survive a venue nobody has visited yet. Our trade show games and games for events pages cover the formats that suit a stand, and the broader HTML5 catalogue is where most exhibitors start when they want something playable without a bespoke production timeline. If the game is doing double duty in a campaign as well as on the floor, the marketing games side is the same asset with different instrumentation.

Do This Before Your Next Show

Take whatever interactive content you already have booked, put it on the tablet you plan to use, and put that tablet in airplane mode. That single test — five minutes, no budget — tells you whether you are exposed. If the game does not run, you have two choices: rebuild it offline-first, or pre-authorise four figures of venue connectivity and hope the hall's network holds up at 3pm on day two.

The first choice is cheaper, and it is the only one that is actually under your control. The venue owns the spectrum, sets the prices, and writes the rules about what you may plug in. What runs on your own tablets is the one part of the stand you can guarantee. Guarantee it.