The engine

The engine is a private product, which I have not published. It is a Rust codebase, compiled to WebAssembly for the browser, on which my games, my learning applications and my sites rest. It targets the web, the native desktop and the terminal, and the applications that use it each pin a tagged version. It is in development, and I am porting my games onto it one by one, starting with Atlas and Le repère.

A game’s code is a set of ECS systems in Rust, and its interface is declared once, in Rust, as a view model. On the web, Solid displays it in the DOM, and on the desktop a wgpu renderer takes its place. Rendering goes through WebGPU, with WebGL2 as a fallback. Four threads of execution share memory, so the main thread does only DOM work and a layout never blocks a frame.

Each application declares in its manifest the pairs of setting and device class that it promises to hold, such as the “pupil workstation” or “phone” class. CI checks the weight of each version and the computing time of each frame for these pairs, with zero allocation in the frame loop. A scripted reference scene per type of application decides that a piece of work is finished.

I wanted a learning tool to be as smooth and as polished as a good game. Hence weight and speed budgets held by CI rather than promised, and services common to all applications (signed saves, French and English, accessibility), so that a game ported to the engine does not have to rewrite them.

The classroom sets the floor: the school’s pupil workstation, on Linux with an integrated graphics processor, is one of the device classes on which the budgets are measured. Behaviour specific to the class stays in each application and in the deployment on the workstations, never in the engine.