Roadmap

Loft is under active development. Everything documented on the language pages works today. This page describes where the project is headed.

The project goal is browser games that anyone can play via a shared link. Native OpenGL is supported for desktop enthusiasts. Server and multiplayer features come after the single-player browser experience works.

Current release — 0.8.4: Awesome Brick Buster

0.8.4 turns Brick Buster from a tech demo into a game someone would actually want to share with a friend, and makes sharing trivial via single-file HTML export.

Game polish

• Hand-designed levels — five themed layouts dispatched by level_brick(lv, r, c), with a procedural fallback for deeper runs.
• Cel-shaded sprite atlas — outlined icons, a round ball with velocity-directional squash, hearts for lives, balloon projectiles, fireball after-images.
• Roman-numeral level display and persistent high score (.loft/brickbuster_score.txt).
• Chiptune soundtrack — three early-Capcom-style tracks (Heroic / Determined / Calm) that play once per level with silences between, plus brick/paddle/wall/pickup/life sound effects.
• Screen shake on brick breaks and life lost; pause menu; title and game-over screens.

Single-file HTML export

Compile any loft program to a self-contained .html file that runs in any browser — no install, no server.

$ loft --html app.loft

The game's WebAssembly, textures, and audio are all embedded. Host the file anywhere, send someone the URL, they play.

Infrastructure

• Audio — rodio-backed playback on desktop; WebAudio bridge in the browser.
• Store-leak fixes — per-frame idiomatic struct APIs now work without workarounds (P122 + P117–P131 resolved).
• CLI hardening — script-level arguments, file-scope constants, and release-mode coroutine-iterator fixes (P126, P128, P131, P132).
• Bytecode cache — .loftc files are invalidated on interpreter rebuild via the embedded git commit hash.

Next — 0.8.5: Working Moros editor

The Moros hex RPG scene editor runs end-to-end in the browser: load a map, paint hexes, place walls and items, see a live 3D preview, export to GLB. Web only — multiplayer comes in 1.0.0.

• Map model — Hex, Chunk, Map with material/wall/item palettes and spawn/NPC routines, serialised as JSON.
• 2D scene canvas — hex coordinate math, pan/zoom/hit-test, layered rendering.
• Editor shell — toolbar, palettes, Paint / Height / Wall / Item tools, undo/redo, localStorage autosave.
• 3D renderer — hex surface geometry (flat and slope), wall slabs, stairs, camera orbit, hex picking, GLB export.
• Live 3D preview alongside the 2D editor, powered by the loft graphics library compiled to WASM.

0.9.0 — Fully working loft language

The language itself becomes feature-complete, well-documented, and tooling-friendly. No "appears fixed but unverified" bugs. Anyone can write loft code in their preferred editor with syntax highlighting, decent error messages, and a REPL for experimentation.

Language polish

• Error recovery — the parser continues after a token-level failure and reports multiple errors in a single pass.
• REPL — running loft with no arguments starts an interactive session; definitions persist across lines.
• Developer warnings — Clippy-inspired lints for common mistakes.
• AOT library compilation — automatically compile libraries to native shared libs for faster startup.
• Stdlib hygiene — name-clash warnings and a std:: prefix for shadowed builtins; library enums in match arms without qualification.

Compilation cache

Bytecode cache (.loftc) and the shared constant store are already implemented. Remaining work — mmap-based native cache loading, serialised Data definitions, pre-compiled stdlib for WASM — lands in 0.9.0.

Developer experience

• TextMate grammar for .loft syntax highlighting.
• VS Code extension with snippets and a run task.
• Quick-start examples/ directory.
• CI covering package tests and native codegen.

Packaging and FFI

• Lock file (loft.lock) for reproducible builds.
• Generic FFI marshaller — zero-boilerplate native functions from a #native signature; generic cdylib loader scans exports into a hash map.

1.0.0 — Totally sure everything works

The stability contract. Anyone can write, run, and share a program — terminal or browser — and trust that it will keep working.

Web IDE

A browser-based IDE running the full loft interpreter as WebAssembly — no installation, no server.

• Editor shell with CodeMirror 6 and a loft grammar.
• Symbol navigation (go-to-definition, find-usages).
• Multi-file projects stored locally (IndexedDB).
• Documentation and examples browser built in.
• Export/import ZIP; PWA offline mode.

Scene scripting

The Moros scene editor gains a loft scripting panel with in-browser compile and hot reload. Scene scripts are sandboxed, travel with the scene JSON, and can be shared alongside the map.

Multiplayer

• Server library — plain HTTP routing, HTTPS with static certs or automatic ACME, WebSockets, JWT / session / API-key auth, CORS, rate limiting, static file serving.
• Game loop primitives — WebSocket polling, broadcast, connection registry.
• Game client library — GameEnvelope protocol, lobby + matchmaking, fixed-timestep loop, client-side prediction and reconciliation, WASM script loading with Ed25519 verification.
• Moros multiplayer — DM and players share a live scene hosted on a loft server.

Stability contract

Version 1.0 means: any program that works on 1.0 will compile and run identically on all future 1.x releases. The language syntax, type system, standard library, and command-line flags are frozen. Until then, breaking changes are possible between minor versions.

Tagging 1.0 requires every stability gate to be satisfied without shortcuts: zero open high-severity bugs, valgrind-clean debug builds of the full Brick Buster and tuple tests, green CI on Linux, macOS Intel, macOS ARM, and Windows, pre-built binaries on the GitHub release, and the reference + PDF linked from the release page.

1.1 and beyond

Post-1.0 items include route decorators (@get / @post / @ws), WASM Web Worker pools for browser-side par(), iterator protocol (for msg in ws), interface factory methods, lazy work-variable initialisation, stack raw-pointer cache, spatial index operations, and additional native codegen optimisations.

Following progress

Development is tracked in the GitHub repository. The full internal roadmap with effort estimates, dependencies, and design pointers is in the repository's doc/claude/ROADMAP.md.