Web JS vs Unity — Engine Feasibility Investigation¶
Date: 2026-07-13 · Status: investigation complete, decision pending Question investigated: can Shadow Raiders drop Unity and be developed/shipped purely as a web JS game — at the same visual quality, and with the analytics / ads / platform SDKs we need?
1. Executive summary¶
| Question | Answer |
|---|---|
| Can a web JS engine reach the Unity build's visual quality? | Yes. Nothing in our visual stack is Unity-exclusive. Estimated 4–8 weeks to rebuild the render layer (WebGL via e.g. Pixi.js). |
| Can it run our SDK stack? | No — not for our current publisher. TinySauce (Voodoo) has no web runtime. Analytics itself is trivially replaceable; the publisher SDK is not. |
| So is dropping Unity a good idea? | Not while we ship with a Unity-exclusive publisher. The engine question is really a distribution question: mobile stores via Voodoo → Unity; web portals / instant games → web JS would actually fit better. |
| Are there hybrid options? | Yes, two real ones (§6). One is publisher-risky (WebView shell), one is publisher-invisible but only pays off if a web SKU is on the roadmap (JS logic inside Unity). |
Recommendation (§7): stay on Unity as the shipping shell for the Voodoo track; treat web JS as a proven-feasible option that activates only if distribution strategy changes; ask the publisher one clarifying question (§7.1) before any hybrid work.
2. Background & method¶
The game exists twice today:
- Web prototype (
game.js, HTML5 Canvas, frozen) — the mechanics/tuning source of truth. All visuals are procedural vector shapes and emoji; zero image assets. It proved the readability layer (fog of war, vision cones, telegraphs, floaters) in a browser, but never tested real sprite art on the web. - Unity port (Unity 6000.0 LTS, URP) — the shipping target. Real sprite pipeline, biome tilesets, character/weapon rigs, shader-based fog of war, publisher SDK embedded.
This investigation audited three areas of the repository: (a) every visual system in the Unity build, (b) the full SDK/platform surface (TinySauce, analytics, ads hooks, haptics, build pipeline), (c) what the web prototype's renderer already achieves. Findings below.
3. What the Unity build's visuals actually consist of¶
Despite being "in Unity", the game barely uses Unity's high-level features — it is a 2.5D billboard game with a fixed orthographic camera, and most systems are custom code:
| System | Mechanism | Unity-specific? |
|---|---|---|
| Map tiles / biomes | Custom chunked mesh builder (NOT Unity Tilemap); per-biome/zone TileSet assets (sprite variants + tints); walls = extruded cubes or pre-tilted cards |
Only the batching machinery |
| Characters | Runtime-built sprite billboards; no Animator — all animation is code tweens (step hop, attack lean, recoil, hit flash); flip via rig mirror; pivot convention chars y=0.5 / props y=0 | No |
| Weapons on characters | Sprite child with per-item grip offset/size (ItemDef), procedural stab/swing/recoil |
No |
| Shadows | Plain blob sprites at the feet (real Unity shadows disabled everywhere) | No |
| Fog of war | LOS fan mesh → hidden mask camera → RenderTexture → temporal-smoothing shader → sampled by custom terrain shader (Fogged.shader, also does wall glow + bush wind sway) |
Yes — multi-pass GPU pipeline |
| Draw order | Manual RenderQueue + ZTest ladder (ground decals occluded by walls; HUD cues drawn through walls) | Yes — depends on depth buffer |
| Vector overlays (bars, reticles, cones, telegraphs) | Shapes (paid asset) components | Asset-specific, easily redrawn |
| Particles (deaths, impacts) | Pooled Epic Toon FX prefabs (paid asset) | Asset-specific, needs re-authoring |
| In-world text (floaters, labels) | Screen-space UGUI + TextMeshPro projected from world anchors | No (browsers do text natively, better) |
| Menus / screens | UGUI + custom Figma→Unity import pipeline | No (Figma→HTML is a better-trodden path) |
Key insight: the project's own architecture (procedural animation, config-driven everything, no Tilemap/Animator dependence) makes it unusually portable. The only genuinely hard pieces to reproduce are the fog-of-war GPU pipeline and the depth-buffer layering tricks.
4. Web JS parity assessment¶
Target stack for parity would be WebGL via Pixi.js (or Phaser) — not plain Canvas2D — for sprite batching, custom shaders, and render textures.
| System | Effort on web | Notes |
|---|---|---|
| Tile map + biome tilesets | Easy | Pixi batches sprites natively; variant-hash logic ports verbatim |
| Camera, characters, weapons, shadows | Easy | Already pure procedural code; ports 1:1 |
| Draw-order ladder | Medium | No depth buffer in a 2D scene graph → rebuild as explicit layers + painter's Y-sort (the web prototype already did this) |
| Fog of war | Medium — hardest piece | Standard WebGL pattern: visibility fan → offscreen render texture → temporal-lerp shader → fullscreen filter. Prototype's polygon fog is a proven cheap fallback |
| Custom shaders (hit flash, cutout, fog) | Easy–medium | Four small HLSL shaders → GLSL rewrites of a few dozen lines each |
| Vector overlays | Easy | Pixi Graphics / Canvas paths; sheds the paid Shapes dependency |
| Particles | Medium (art cost, not tech) | Epic Toon FX prefabs don't port; effects must be re-authored |
| Text, minimap, character preview, UI screens | Easy | Browser-native text/emoji; offscreen canvas bakes; DOM+CSS beats UGUI for menus; Figma→HTML easier than our custom Figma→UGUI pipeline |
| Performance | Fine | Hundreds of sprites + one fog pass is comfortable mobile-WebGL territory |
Estimate: ~4–8 weeks for one experienced engineer to rebuild the render layer at current Unity visual quality — because game logic already exists in JS (game.js) and all tuning is data-driven. This is a view-layer rewrite, not a game rewrite.
What we would gain on web: instant reload and shareable builds, live tuning, no Unity version/gradle maintenance (we recently had to downgrade Unity 6000.3 → 6000.0 LTS for TinySauce compatibility and hand-patch its gradle templates, which revert on re-import), smaller team-tooling surface.
5. SDK & platform compatibility — the actual blocker¶
5.1 Publisher SDK (TinySauce / Voodoo)¶
- TinySauce 8.2.0 is mobile-only: the consent flow (Voodoo GDPR API), VoodooAnalytics, and Adjust ship as native Android/iOS binaries. Only the embedded GameAnalytics SDK has a WebGL backend; the TinySauce init/consent layer itself has none.
- A pure web build cannot run the publisher's required SDK. With a Unity-exclusive publisher this alone settles the question.
5.2 Analytics (replaceable in a day)¶
The game calls the SDK through a single seam (Analytics.cs) and sends only two events: game started / game finished. GameAnalytics has an official JS SDK; Adjust and Facebook have web SDKs (web attribution is inherently weaker — no device IDs). Analytics is not a reason to keep or leave Unity.
5.3 Ads (nothing integrated yet — future options differ sharply)¶
| Distribution | Ads story on web |
|---|---|
| Web portals (Poki, CrazyGames, GameDistribution) | First-class JS SDKs with rewarded/interstitial built in — easiest option of all |
| Own website | Google Ad Placement API only — weak monetization |
| Mobile stores via a native wrapper | Possible (native ad SDK + JS bridge) but re-inherits the entire native toolchain we'd be leaving Unity to escape |
5.4 Haptics (real loss on pure web)¶
Our ~30 semantic haptic events route through NiceVibrations native bridges. On web: navigator.vibrate() works on Android Chrome only (crude), and iOS Safari has no vibration API at all.
6. If the publisher is Unity-exclusive: hybrid options¶
| Option | What it is | Verdict |
|---|---|---|
| A. WebView shell — Unity app hosts the JS game in a fullscreen WebView; a JS↔C# bridge forwards analytics/haptics/ad triggers to TinySauce | Technically workable (our bridge traffic is 2 analytics events + haptic pings; native ads overlay fine) | High risk. Low-end Android WebView performance is exactly what publisher CPI tests stress; two runtimes in memory; a tech review will see the game isn't really Unity — many publishers reject webview games outright. Also fixes none of our Unity maintenance pain — we'd keep all of it and add browser quirks. Ask the publisher before writing any code. |
| B. JS logic inside Unity — embed a JS engine (Jint / puerts / QuickJS); game logic runs in JS, Unity renders natively and hosts all SDKs | Publisher-invisible: the shipped app is a fully normal Unity build. Buys a single JS logic codebase that could later drive a pure-web SKU (portals, playables) with a different renderer | Only worth it if a web SKU is genuinely on the roadmap. Costs a permanent binding layer, harder debugging, interpreter overhead. As a way to "escape Unity" it escapes nothing. |
| C. Just ask the publisher | "Unity exclusively" sometimes means "our SDK ships for Unity", not an engine mandate; some publishers maintain native iOS/Android SDK variants | One email. Should precede any hybrid investment. |
7. Recommendation¶
- Keep Unity as the shipping shell while the Voodoo/mobile-store track is the plan. The investigation confirms web JS could match our visuals, but the publisher SDK constraint is decisive, and no rendering benefit outweighs breaking the publishing requirement.
- Do not pursue the WebView-shell hybrid unless the publisher explicitly approves it in writing first — the acceptance risk is high and it compounds our maintenance burden rather than reducing it.
- Revisit web JS the moment distribution strategy changes (web portals, instant games, playable ads). For that world, this investigation shows the port is a bounded ~4–8 week view-layer task, not a rewrite — and the SDK story on web portals is simpler than what we run today.
- Option B (JS logic in Unity) is the only hybrid worth keeping on the shelf, and only as an enabler for a deliberate two-SKU strategy (mobile + web from one logic codebase).
7.1 Open questions for management / publisher¶
- Does the publisher require the Unity engine specifically, or only that their SDK is embedded? Do they offer a native (non-Unity) SDK variant?
- Is web distribution (portals / instant games / playables) on the product roadmap at all? This is the switch that changes the recommendation.
- Which ad formats are planned (rewarded / interstitial / banner)? All are Unity-native packages on the Voodoo track — further reinforcing point 1.
Appendix: evidence pointers (repo)¶
- Unity visual systems:
unity/raiders/Assets/Scripts/World/MapGenerator.cs(custom chunked tile meshes),EntityView.cs/WeaponView.cs(procedural billboard rigs),FogOfWar.cs+Assets/Shaders/Fogged.shader(fog pipeline),Assets/Scripts/Presentation/*(Shapes overlays, floaters, pooled VFX). - SDK surface:
unity/raiders/Assets/VoodooPackages/TinySauce/(v8.2.0; providers, native binaries, privacy flow),Assets/Scripts/Meta/Analytics.cs(the single SDK seam — game start/finish only),Assets/ExternalAssets/Feel/NiceVibrations(haptics natives), custom gradle templates inAssets/Plugins/Android/. - Web prototype renderer:
game.jsRENDER section (~lines 3487–4790) — Canvas2D, procedural shapes/emoji only, raycast fog polygon, offscreen floor/minimap caching.