Development log

Devlog

StarLite II is developed solo, as a single-file browser game. Here's the technical behind-the-scenes — netcode, performance, rendering.

Optimizing the rendering of large swarms

Performance · rendering engine

A swarm of 300 moving Zglenglo is the worst case the engine can face. The sprite cache is deliberately bypassed for moving units (to keep the walk animation fluid), so a mobile swarm falls back entirely to procedural vector drawing, frame by frame.

Current work: a walk-pose atlas (pre-computing a handful of discrete walk-cycle frames instead of a fully procedural draw), plus density-aware collision resolution. These are the two next big wins for this specific scenario.

A deterministic lockstep netcode

Multiplayer · networking

Online duels use a deterministic lockstep model: instead of syncing the full game state, both clients exchange only the orders and replay the same simulation, tick by tick. That demands perfect determinism — the same pseudo-random generator, the same resolution order, the same pathfinding math.

A lightweight WebSocket relay routes the ordered commands between peers, and a periodic checksum system detects any simulation divergence between the two machines.

A whole RTS in a single HTML file

Architecture

StarLite II fits in a single HTML file — engine, rendering, AI, netcode and game data included. This choice makes deployment trivial and sharing instant: one page to update. The code is organized into internal modules that reproduce a classic architecture while staying packaged in that single file.