Play in the Browser
JaiScript running in this page: write a program in the sandbox, or play three of the example games. The engine is compiled to WebAssembly and runs the same scripts the standalone runner runs, so what you play here is the game the runner plays: same frames, same seeds, same state hashes.
Write JaiScript and run it here: the strict checker reads the whole program first, then the VM runs it. The program below is a small game, already running: click its output and the arrow keys or WASD walk the gator. It runs live: change a setting in the code and the running game takes it. Run starts a program over.
What runs here
The page downloads the engine (the library and the runner's console builtins, built with Emscripten), and for a game its .jai files, then runs the game's drag-drop shim, the file you would drop onto the runner. The VM compiles the scripts in the page; nothing is precompiled and nothing runs on a server. A small terminal screen draws the game's escape codes, and your keys reach the script's key_down and read_key.
The sandbox has the standard library, with a file system that lasts until the page closes and the runner's console builtins (key_down, read_key, term_cols, term_rows). A program that runs 20 seconds without a sleep is stopped, and Stop ends one at once. A program that declares bool frame() runs live: live.jai calls it frame after frame and imports the editor's text again as it changes, which reloads the functions and classes in place, gives a variable with an initializer its new value and keeps one declared without. An edit that does not check is named under the output and the program runs on with the code it had. The guide has a runnable sample in every chapter; paste one in.
The engine runs in a worker, where a script's sleep() sleeps as it does in the runner. A page that cannot share memory with the worker (one served over plain http, or a browser without that support) runs a stepped build in the worker instead, where every sleep() hands control back to the worker between frames; it is slower, and the page stays responsive either way. Sound plays through the page: GLOOM's effects as its script synthesizes them, and the demo reel's score, which the script writes as MIDI, through a small synthesizer in the page; the speaker button mutes it. In the worker the engine has WebAssembly threads too, so a script's parallel_for and parallel_transform spread over your cores as they do natively. WebAssembly still runs the VM slower than a native Release build: GLOOM and GRUBWELL keep their frame rate, and the demo reel, which draws every pixel of every scene, plays its heavier scenes slower than in a terminal.