Devlog #1: MysteryOS v0

first version of MysteryOS! a mystery-themed web OS that runs entirely in your browser, built in c++ and compiled to webassembly.

you boot into what looks like a completely normal desktop. there’s a taskbar, a file explorer, a text editor, a terminal. it feels like a real OS, just a little dated. the kind of computer you might find in an office that nobody has touched in years. and then you start actually reading the files.

a memo from the admin telling staff not to open the archive folder. a deleted note in the recycle bin that someone clearly wanted gone. a system log that gets cut off mid-sentence. a config file so corrupted you can barely read it, but one line is still visible: overwritten=true. the more you look around, the less sense it makes. something happened here.

the whole thing is built on dear imgui, which is a lightweight immediate-mode UI library mostly used for game tooling and debug interfaces. it handles draggable resizable windows completely out of the box, which is what makes it work so well for faking a desktop environment. SDL2 takes care of windowing and input, OpenGL ES 3 handles rendering, and emscripten compiles everything to webassembly so it runs straight in the browser with no install needed.

the file system is entirely data-driven. every folder, every file, every locked directory and corrupted text file is defined in a JSON file that gets loaded at startup. same with the mystery itself. each stage of the story is just data: what password unlocks it, what files get injected into the file system when it does, which folders get revealed, how much the visual glitching ramps up. the actual narrative of the OS is just a text file, which makes it incredibly easy to write and iterate on without touching any c++ at all.

the apps are all separate modules that plug into a central kernel. the file explorer lets you browse and open files. the text editor displays their contents. the terminal does… terminal things. the password dialog is how you submit what you find. they all share access to the same file system and puzzle state through the kernel, and the kernel calls render() on each open window every frame. keeping them isolated like that made everything much cleaner.

deploying to github pages hit one genuinely annoying snag. emscripten normally packages your preloaded data files into a separate .data file that the browser fetches when the page loads. this worked fine locally but on the actual CDN the fetch was silently failing, leaving the entire file system empty with no error anywhere. the fix was switching from --preload-file to --embed-file in the build config, which bakes the data directly into the webassembly binary itself. slightly larger download, but it just works.

the OS gets progressively more corrupted and glitched the deeper you go into the mystery. right now it’s subtle, background noise and a few visual artifacts. but by the final stage the idea is that the desktop feels genuinely wrong. like something in the OS itself doesn’t want you to keep looking.

i have a rough idea of where the story is going but i want it to feel like a real discovery, not a puzzle game. more like finding something on an old computer that you weren’t supposed to find.