//Technical — Engine, Tooling & Platform Stack

This section covers the technical stack, engine architecture, performance targets, networking, and the supporting systems behind nu-Eden: Sundered Skies.

For the interview build, the previously separate programming-language and nu-Edenian GDD tracks are condensed here as one supporting technical article. They matter to the project, but they serve the larger game case study rather than needing equal billing on the main GDD surface.

▸Engine Stack

Architecture Philosophy

nu-Engine is a bespoke web-first engine built around the browser's native rendering and media stack, purpose-built for nu-Eden's unique gameplay systems and visual style. It is not built on top of Godot, Unity, Unreal, or any existing game engine — it is a custom solution from the ground up.

The game is designed PC-first, but the prototype remains playable in a browser and distributable as a desktop application. The frontend stack combines React and TypeScript for the prototype surface with native TypeScript/ReScript, WebAssembly, WebGL/WebGPU, the browser's HTML/CSS/JS/SVG engine, and WebAudio for the final game runtime, while Tauri and a Rust backend provide the desktop shell and native services.

This architecture keeps the project rooted in web technology without assuming the player only experiences it as a website. The decision to build bespoke was driven by nu-Eden's specific requirements:

• ▪Cel-shaded rendering pipeline with volumetric lighting that no off-the-shelf engine handles correctly — inspired by TWEWY's visual language married with Control's volumetric atmosphere
• ▪Vertical level streaming optimised for nu-Eden's layered city architecture — standard engines assume horizontal worlds (open fields, corridors); nu-Eden needs seamless vertical transitions between layers
• ▪Orbital rhythm subsystem integrated directly into the rendering pipeline for hacking arenas — heliocus depends on frame-perfect timing, angular motion, and low-latency cursor tracking in the same loop
• ▪Dynamic audio system that requires frame-level synchronisation with gameplay state — Doom Eternal's adaptive music system demonstrated that audio must be a first-class rendering concern
• ▪Web-native systems embedded at every layer — from gameplay logic to player-facing loadout customisation. No off-the-shelf engine gives the same level of control over browser rendering, desktop packaging, and native host integration without significant compromise

Why Not Unity/Godot/Unreal?

The engine choice is deliberate and architectural, not ideological:

▸Platform Integration

The stack prioritizes iteration speed, deployment flexibility, platform reach, and fine-grained control over adopting a monolithic engine.

In-Game Role

The technology stack serves two purposes:

1. ▪Engine-side: Gameplay systems run inside a custom web runtime built with TypeScript/ReScript, WebAssembly, WebGL/WebGPU, and browser-native APIs
2. ▪Distribution-side: The same frontend can run in-browser for the prototype and inside a Tauri desktop shell with Rust handling native services

"The project is built entirely on web technology, but it is not designed as a browser toy. It targets PC first, with browser delivery and desktop packaging as parallel deployment modes."

Sample Code

let pickLoadoutPreset = threatLevel => {
  var presets = {
    low: 'stealth',
    mid: 'balanced',
    high: 'heavy',
    boss: 'boss_killer',
  }

  return presets[threatLevel] || 'balanced'
}

▸Modular System Design

All major systems are hot-swappable modules communicating via well-defined interfaces:

Modules can be added or replaced independently without affecting the overall system.

▸Performance Targets

Optimization Strategies

• ▪LOD scaling — dynamic model/texture/effect LOD based on distance and performance budget
• ▪Occlusion culling — aggressive culling of unseen objects
• ▪Async loading — background asset streaming to minimize hitching during traversal
• ▪Optimized shaders — custom shaders for efficiency across hardware range
• ▪Multi-threading — parallel processing of AI, physics, and rendering
• ▪Memory management — careful allocation/deallocation to prevent leaks and fragmentation
• ▪Adaptive quality — automatic graphics adjustment based on hardware capabilities

Performance is a first-class citizen — treated as a design constraint, not a post-process.

▸Networking & Online Features

SunSkies is primarily a solo experience with asynchronous and opt-in online elements:

All online components are non-intrusive and can be disabled entirely. No competitive PvP at launch.

▸Security

Given moddable systems and sandbox elements (especially Zaia Koruzana's debug mode), security focuses on containment rather than restriction:

• ▪Sandbox and debug tools are sandboxed at runtime
• ▪Online components validate state transitions server-side
• ▪Anti-tamper systems protect narrative flags and progression data
• ▪Modding is encouraged but online features require a "clean state"

Cheating is treated as a single-player concern, not a moral failure.

▸AI & NPC Behavior

▸Rendering Pipeline

The visual stack is purpose-built for nu-Eden's hybrid aesthetic:

The pipeline is designed to scale — cel-shading is computationally cheap, volumetrics are the main performance cost and can be dynamically adjusted.

Rendering Design Rationale

▸Language Systems & Tooling

The web runtime, nu-Edenian, and KAGE are not side hobbies bolted onto the project. They are technical support systems that shape how the game communicates logic, world identity, and player expression.

Why Combine Them Here

For portfolio purposes, these systems answer the same question from different directions:

• ▪The web stack explains how the project thinks about implementation, deployment, and player-facing systems
• ▪nu-Edenian + KAGE explain how the world handles language, signage, and procedurally rendered text without reducing them to decorative flavor

Grouped together, they read as one article about tooling in service of game feel and world coherence.

Web Stack — Runtime & Delivery Layer

The implementation stack is intentionally split so each layer handles what the web is best at. Its design priorities are:

1. ▪PC-first delivery — keyboard, controller, and high-fidelity rendering are the baseline target
2. ▪Browser accessibility — the prototype remains playable without installing a native build
3. ▪Desktop packaging — Tauri enables desktop distribution without abandoning the web runtime
4. ▪Performance scaling — WebAssembly and GPU APIs cover hot paths where plain DOM scripting is insufficient

The stack serves two distinct audiences:

That dual role is the real design point. The same web foundation supports rapid prototyping, presentation, and eventual desktop delivery.

Runtime Pipeline

React + TypeScript Prototype Surface
    ↓
Native TypeScript/ReScript Gameplay Layer
    ↓
Web APIs → HTML / CSS / JS / SVG / WebAudio
    ↓
GPU / Native Acceleration → WebGL / WebGPU / WebAssembly
    ↓
Desktop Packaging → Tauri Shell
    ↓
Native Services → Rust Backend

Sample: Loadout Configuration Logic

let handleZoneEntry = zone => {
  var preset = pickLoadoutPreset(zone.threatLevel)
  equipPreset(preset)

  zone.threatLevel == 'boss' && notify('Boss preset activated')
}

let handlePartySwap = ({previous, next}) => {
  var synergies = getSynergies(previous, next)
  synergies.bonus > 0.2 && applyAugmentaSet(synergies.recommended)
}

nu-Edenian — World Language System

nu-Edenian exists as both a worldbuilding layer and a systems problem. It carries social hierarchy, historical pressure, and geographic identity, but it also has to function as something the game can actually render and reuse.

Its main design goals are:

1. ▪Multi-script authenticity — a layered script system that feels internally motivated rather than ornamental
2. ▪Sociolinguistic depth — language varieties that imply class, district, and history
3. ▪Procedural generation — reproducible glyph construction from a seed rather than hand-authoring every sign
4. ▪Typological range — a system broad enough to support logographic, syllabic, and featural behaviors

The important portfolio point is that nu-Edenian is not there only to look impressive. It is part of how the world signals culture, status, and infrastructure.

KAGE — Glyph Pipeline

The KAGE engine handles the rendering side of that language system. It transforms stroke definitions into SVG polygon outlines so the project can treat written language as a procedural asset pipeline instead of a static art dump.

This matters because the language system becomes technically legible: signage, UI fragments, and world text can all come from the same underlying rules.

Why These Systems Matter To The Game

Taken together, the web stack and nu-Edenian solve different parts of the same design problem.

• ▪The web stack supports implementation, presentation, and distribution
• ▪nu-Edenian supports world identity and readable cultural texture
• ▪KAGE turns that identity into a usable rendering pipeline

They are supporting technologies, but they also demonstrate the kind of end-to-end thinking this project is trying to showcase.

▸Save System Architecture

Narrative State Complexity

The save system must track an unusually large state space due to the branching narrative:

• ▪7 Director fate states (deposed / turned / allied / preserved)
• ▪6 nERF internal wing reputation values
• ▪10+ faction reputation tracks (-100 to +100)
• ▪Named NPC relationship values (hundreds of NPCs)
• ▪Key conversation flags (hundreds of binary flags)
• ▪Conrad's temporal decay counter
• ▪Act-specific divergence point decisions

All of this is serialised efficiently using a custom binary format rather than JSON to minimise save file size.

▸Platform Targets

The project is built entirely on the web, so browser deployment is native to the architecture. Tauri provides the desktop distribution path, while Rust handles native-side capabilities that do not belong in the frontend.