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.