--- title: Best Practices for Web Games on AirConsole slug: best-practices-for-web-games-on-airconsole docTags: createdAt: 2025-09-17T11:47:59.091Z --- This guide provides developers with essential **guidelines and standards** for building performant and reliable WebGL games for AirConsole. The document applies to **desktop, mobile, and automotive** devices. Games are expected to **scale automatically** across platforms β€” there are no separate versions. *** ## 🎯 Goals - Ensure compliance with [AirConsole Checklist](docId\:IEdkpmfJl8JQS3UOIFhmg). - Provide **performance and resource usage best practices**. - Deliver games that are **robust, safe, and enjoyable** everywhere. *** ## βœ… Technical Requirements ### General Requirements - **Compatibility:** Game must run correctly on **Chrome 61+** (baseline automotive embedded Chromium). - **Loading Performance:** Main menu loads in ≀30s under 20mbit up/down with 100ms latency. - **Frame Rate:** Game must achieve **β‰₯30 FPS** consistently across all supported platforms. - **Error Handling:** No uncaught exceptions in console during normal play. :::hint{type="success"} Always validate performance under throttled conditions, not just on your development machine. ::: *** ## πŸš€ General Performance Best Practices ### Rendering β€” Lights, Shaders & Materials Automotive graphics chip are heavily pixel throughput limited (up to 20x lower than current generation mobiles) - **Prefer baked lighting** for static geometry; reserve **1–2 realtime dynamic lights** for hero objects only. Use **lightmaps** (directional if supported) or **spherical harmonics light probes** for dynamic objects. - **Shadow strategy:** If shadows are required, use **single sun/dir light shadows** with **resolution ≀1024** and **cascade count ≀2**; disable soft shadows on low-end. Avoid per-pixel point/spot shadows. - **Shader precision:** Default to `mediump` in fragment shaders; use `highp` **only** where artifacts are visible (normals/IBL). In vertex shaders, `highp` is generally fine. - **Branching & loops:** Avoid dynamic branching and unbounded loops in fragment shaders; prefer **static **`#define`**-based variants** and precomputed LUTs (BRDF, fog, tone map curves). - **Material variants:** Limit material permutations; prefer a **single uber-shader** with compile-time feature flags, or a **small set** of well-curated variants. - **Specular/IBL:** Use **image-based lighting** with prefiltered environment maps (mip chain as roughness levels). Keep environment cubemap at **≀256 px face** (≀128 on low-end / automotive). - **Normals & tangents:** Use **octahedral/BC5**-style normal encodings when possible; otherwise compress normals to two channels. Recompute tangents offline. - **PBR pragmatism:** Avoid it unless it provides significant value. If used, use **metalness/roughness** workflow; clamp roughness to **\[0.04, 0.96]** to avoid fireflies. - **Tone mapping & gamma:** Avoid HDR and tonemapping unless it provides significant value. If used work in **linear space** with sRGB textures; apply **ACES (approx)** or filmic tone mapping **once** at the end of the pipeline. - **Transparency:** Sort back-to-front; minimize overdraw. Prefer **alpha test / dithered cutout** over expensive blended layers when possible. - **Post-processing budget:** Keep to **≀1–2 passes**. Prefer **FXAA** over MSAA; - Ensure mobile optimised shaders are used when running on cars - **Instancing & batching:** Batch small meshes and **GPU-instance** repeated props to keep draw calls **\< 200**. - **Overdraw control:** Keep fill rate low; avoid full-screen particles and parallax layers. Use **depth pre-pass only if profiling proves a net win**. - **Texture sampling:** Prefer **trilinear with mipmaps**; add **anisotropy 2–4x** for ground textures. Avoid manual LOD biasing unless necessary. - **Texture lookups:** For wide support try to have \<= 4 texture l - **Skinned meshes:** Limit bones per draw (≀50); update skinning on GPU where available; pool and reuse skeletons. - **GL Extensions**: The available GL extensions vary widely between platforms, in particular in cars -> Ensure you only use features that are provded by the GL extensions - If that is technically not feasible -> Ensure that you support WebGL1 :::hint{type="success"} Baked/global lighting + minimal dynamic lights yields the biggest visual/performance win for WebGL across all devices. ::: ### Assets β€” Formats, Sizes & Streaming - **Texture formats:** Ship GPU-compressed textures: **ASTC** (best), **ETC2** (fallback AndroidTV) and **DXT** for desktop. - Where available use ** Basis** or **KTX2** which are optimal for automotive and desktop. - **Texture sizes:** Target **max 2048Β²** (automotive) / 4096Β² (desktop high). Generate full mip chains; avoid NPOT when possible to keep mips efficient. - **Atlasing:** Use **sprite/texture atlases** to reduce binds; group by sampler/state. - **Streaming:** Stream large assets (music, video) and **lazy-load** level content; gate heavy loads behind user interactions. - **Audio:** Stream BGM; keep SFX short and pooled. Avoid decoding large audio during gameplay. ### Memory Management - Cap texture memory per platform (\~256MB for low-end & automotive, higher for desktop). - Implement **lazy asset loading**: load resources only when needed. - Use **asset eviction strategies**: unload unused textures/models/audio. - Monitor garbage collection behavior; avoid excessive object churn in critical loops. :::hint{type="warning"} Run memory profiling sessions at least once per major milestone β€” many issues only appear under long play sessions. ::: ### Particles & VFX - Keep particle systems **GPU-cheap**: billboard quads, batched draws, avoid complex fragment work. - Prefer **CPU-updated, GPU-drawn** pools - Avoid allocating particle and VFX systems during gameplay - Cull off-screen particle and VFX systems early. - For smoke/fire, use [flipbook textures / texture sheets](https://vfxdoc.readthedocs.io/en/latest/textures/flipbooks/) at half/quarter-res - Limit additive blending areas using tight sprite meshes where possible ### Input & Responsiveness - Ensure **input latency \<100ms** under normal conditions. - Support **AirConsole's input integration** only. - Design for **scalable UI layouts** β€” support resizing and different aspect ratios. - **If your game's input is time sensitive: **Use lag compensation approaches and timestamps for controller -> screen messages for the best game experience. ### Audio - Use **compressed audio formats** (AAC low, OGG) for background music. - Keep audio memory low by streaming long tracks. - Ensure to implement onPause/onShowAd -> onResume/onAdComplete to pause and resume audio. ### Power & Battery - Minimize unnecessary background work. - Pause heavy animations or physics simulations when not visible. - Use **frame skipping** or **dynamic resolution scaling** if hardware struggles. *** ## πŸš— Automotive-Specific Considerations While games must scale automatically across all platforms, **automotive environments** require additional care: - Avoid distracting animations or high-contrast flashing elements. - Handle **OS memory pressure** β†’ free unused textures/models. - Implement **crash recovery**: auto-return to safe menu state. - Test readability under glare and low-light conditions. *** ## πŸ§ͺ Testing & Certification ### Mandatory Test Scenarios - Chrome DevTools Network Throttling (20mbit/100ms latency). - FPS measurement with Chrome Performance tab. - Memory profiling vs platform budgets. - Long play session stability (β‰₯1 hour). - AirConsole simulator and real-device tests (incl. automotive hardware where possible). ### Recommended Tooling - Chrome DevTools (Performance, Memory, Network tabs). - WebGL Inspector / Spector.js for GPU analysis. - For automotive, test using the [Xiaomi Pad 6 WLAN](https://www.gsmarena.com/xiaomi_pad_6-12237.php) - **For web:** To test your game in a similar performance setup as many cars, use Chrome to load [https://airconsole.com](https://airconsole.com) as Desktop Site and connect the Chrome Dev tools with video stream active. This gives a somewhat similar experience and performance profile. - **Android native games:** Work like normal but ensure to not add your game to Xiaomi's Game Space! This would enable optimisations that impact performance and behaviour considerably. *** ## βš–οΈ Do’s and Don’ts | Do βœ… | Don’t ❌ | | ------------------------------------------------------ | ----------------------------------------- | | Use compressed textures and atlases. | Ship raw PNGs or too many small textures. | | Profile with Chrome DevTools and Spector.js. | Assume desktop performance = automotive. | | Implement adaptive quality (LOD, texture scaling). | Hardcode high-quality settings. | | Test input latency on real devices (incl. automotive). | Only test on desktop Chrome. | | Stream large assets (audio/video). | Load everything eagerly at startup. | *** ## πŸ“Œ Summary - Meet **technical requirements** across all platforms. - Follow **general performance best practices**: rendering, networking, memory, input, audio, and power. - Apply **automotive-specific safety considerations** when needed. - Use robust **testing workflows and profiling tools** to ensure consistent quality. By following this guide, developers can deliver games that are performant, efficient, and enjoyable across all environments on AirConsole.