SOON/OS

Boot Linux, write a game, and run 2D games like Doom and run 3D games like MINECRAFT inside a published Chatforce game.

Comment

Inspiration

We wanted to see how far a Chatforce game could go. The idea became a computer inside a game: boot Linux, open an editor, write a game, and run it in that same machine.

SOON/OS turns a published Chatforce game into a real Linux desktop that visitors can open in their browser.

What it does

The desktop has windows, a terminal, files, and native Linux applications. The demonstration follows a simple progression:

  1. Boot a real Linux desktop.
  2. Open VSCodium, the open-source build of VS Code, edit our Python falling-block game, and run it inside Linux.
  3. Launch Chocolate Doom with the shareware game data.
  4. Explore an experimental Minecraft 1.6.4 demo running through Java and software-rendered OpenGL.

The Linux CPU and memory run locally in each visitor's browser through v86. Chatforce hosts and serves the game and its assets. Visitors do not need our presentation extension or a separate VM server. The optional Chrome extension only adds slides around the live Chatforce demonstration.

Try the published game: https://soon-os.chatforce.com/

How we built it

The outer application is a TypeScript Chatforce game. Inside it, v86 uses WebAssembly to emulate an x86 computer. The guest runs Arch Linux32, a Linux 5.19 kernel, Xorg, and Fluxbox. Its editor, terminal, Python application, Doom, and Java client execute as Linux processes.

We tested the normal upload, source-editing, compile, and publication workflow, then built a packed filesystem transport. Fifteen checksummed packs supply more than 2,500 file slices on demand through the guest's 9p filesystem. This reduced the number of individual asset requests and worked around the practical limits of a large per-file asset index.

The launcher connects browser controls to the guest, handles keyboard capture and focus, and displays the actual emulated framebuffer. Writable guest changes are private to each visitor and currently reset on reload.

Challenges we ran into

Booting the kernel was only the beginning. We had to resolve an emulator constructor mismatch, missing build scaffolding, binary asset delivery, X11 cursor and focus behavior, old application dependencies, and an expensive software-rendered Minecraft menu.

Restoring VM states introduced another subtle problem: saved hardware timers referenced the previous browser document's clock. We aligned the restored timer origin and CPU timestamp counter, and explicitly repainted the full framebuffer so a resumed application would appear immediately.

Large first downloads and software rendering remain important usability limits. Minecraft demonstrates real 3D rendering, but software rendering is currently very slow; this is a technical demo rather than a claim of smooth gameplay.

Accomplishments we're proud of

We published a real Linux desktop as a Chatforce game, edited and ran our own Python game inside the guest, and demonstrated Doom and a Java-based Minecraft demo. The screenshots show actual guest applications, with local validation images labeled accordingly.

We also published a single-VM launcher that swaps between publisher-captured states with each application already open. In a fresh signed-out Chrome session without our extension, the initial Linux/Tetris load took 6.37 seconds, then first switches took 3.01 seconds for Doom, 4.13 seconds for Code, and 4.95 seconds for the loaded Minecraft world. These are measurements on our machine and connection, not a guarantee for every visitor. Switching restores a publisher baseline and discards visitor edits; run edited programs through the build task inside Code.

What we learned

A browser game can host a surprisingly complete computing environment. The difficult work is making storage, clocks, display updates, input, and application compatibility agree across the browser, emulator, and guest operating system. A successful compile is only one step; we tested real guest output, editor behavior, gameplay input, and public delivery separately.

What's next for SOON/OS

Improve first-visit downloads and caching, preserve user work across app switches, and make the desktop comfortable on more devices. The long-term goal is a shareable computing playground where someone can build a game inside a game.

Credits

Built with Chatforce, TypeScript, v86/WebAssembly, Arch Linux32, Xorg/Fluxbox, Python/Tk, VSCodium, Java, and Chocolate Doom. Minecraft is Mojang's demo client. These third-party projects and games retain their respective authorship and licenses. Chatforce's Coder and OpenAI Codex assisted with implementation and debugging.

Built With

Share this project:

Updates

Submission history