MysteryOS

Just some more lore to explore!

Devlog #4: MysteryOS v0.4

this is probably the last devlog before the first public build.

MysteryOS started as a fake computer where every useful thing was locked behind puzzles. now it feels closer to what i wanted: a machine that has been left running too long, with something inside it that notices you noticing it.

the biggest change is that PID 7741 can talk back.

there is a new terminal command:

talk 7741 <message>

if the anomaly layer is configured, the game sends Groq only the current in-game session state: stage, files opened, recent fake file paths, and session time. it does not send anything from the real computer. no real files, no identity, no location. only MysteryOS state.

inside the fiction, that is enough.

7741 can answer in the terminal using your playthrough as context. if you have been reading the archive, it can know that. if you tried to kill it, trace it, or talk to it before understanding it, it can know that too.

the stranger part is that it can now leave files behind.

Groq returns a constrained JSON response: a short reply and, optionally, a file to create. MysteryOS validates the file path twice, once in browser JavaScript and again in C++. it can only write inside the fake filesystem, and only in controlled places like /Desktop/ or /System/logs/.

so a conversation might become:

> talk 7741 are you real
7741: you keep asking for proof as if the question did not already change the system.
7741: [wrote /Desktop/7741_response.txt]

then you open the desktop, and the file is there.

that is the whole idea of the game: observation changes the system. reading has consequences. the OS is not just a menu for lore anymore. it reacts.

this update also added the Session Monitor. once you find the right clue, you can run monitor and inspect a fake process viewer. normal processes look normal. PID 7741 does not. it has unbounded memory, denied kill policy, rising CPU, and a status that changes as the mystery progresses. eventually the classification becomes: not malware.

i love that phrase. malware would be simpler. malware has an author. PID 7741 feels worse because it is not an intruder. it is something the system made possible.

the monitor also shows recent file reads from the current session. MysteryOS is mostly about reading, and now the game reads the reading. it can show your path back to you. it can hand that path to 7741.

a lot of smaller fixes landed too. passwords now have to be entered in order, so the story cannot be skipped by accident. the build instructions now point at docs, where the GitHub Pages build actually lives. images open in the image viewer. corrupted images still become generated noise. stage data and deployed data are kept in sync.

the filesystem is also much bigger now: elena’s journals, project documents, logs, HR reports, old researcher accounts, deleted notes, blocked uploads, and files that reframe earlier files once you understand them. elena is still the center, but she is no longer the whole story.

that is what i want the first public build to feel like: not a polished puzzle game with a spooky skin, but a computer full of evidence.

and now, if the anomaly layer is enabled, the machine can answer.

sometimes it writes back.

Devlog #3: MysteryOS update!

this update got away from me in the best way.

i started by adding a session monitor for PID 7741, and then ended up expanding the actual computer around it. more files, more accounts, more logs, more traces of the people who were here before elena. the OS feels less like a puzzle box now and more like a machine that has been running too long with too many secrets left inside it.

the big new feature is the Session Monitor. PID 7741 used to be mostly a rumor: something in the boot log, something in ps, something you couldn’t kill. now you can investigate it directly. once you find /System/tools/session_monitor.txt, the system teaches you two new commands: monitor and trace 7741.

monitor opens a fake process viewer built inside the OS. normal processes look boring. PID 7741 does not. its memory is unbounded, its kill policy is denied, its CPU usage keeps creeping up, and its status changes as you progress through the story. early on, it’s just not registered in the process table. later, it’s bound to elena’s active session. eventually, the classification changes to the most unsettling thing it could be: not malware.

that phrase became the center of the update for me. malware would be easier. malware has a source. PID 7741 is something else. something the system made possible.

i also added activity tracking. text files and images now get logged when you open them, and the Session Monitor shows your recent reads back to you. it’s a small mechanic, but it changes the feeling of the whole game. reading was already the main action in MysteryOS. now reading has consequences. the anomaly is about observation, so every file you open becomes part of the story.

the content side expanded a lot too. the filesystem now has more of the world around elena: old researcher accounts, personal notes, logs, deleted messages, project files, system reports, and documents that imply whole stories without explaining them directly. i wanted the machine to feel like it belonged to more than one person. elena is the center of the current mystery, but she was not the first one to find the pattern.

a lot of the new writing is about those earlier researchers. people who noticed 0xE10A before elena did. people who tried to document it, ignore it, report it, run from it, or send it somewhere outside meridian. the more you explore, the more it becomes clear that this workstation is not just elena’s computer. it’s a record of everyone the project passed through.

i also added trace 7741. the output changes depending on how far you are. at first the system refuses. then it admits the process isn’t registered. then it says PID 7741 is attached to the evoss session. later it tells you the process has written files without user input. by the end, it stops being subtle: PID 7741 is observing the current session.

on the progression side, passwords now have to be entered in order. before, if you somehow knew a later password, you could skip ahead. that broke the rhythm of the story, because the later stages depend on what you think you already understand. now each password only unlocks the next stage.

i also fixed the local serve instructions so the project points at docs, which is where the build output actually lives.

v0.2 was about writing the core mystery.

v0.3 is about making the machine feel deeper than the path through it. there are more files than you need, more history than one playthrough will catch, and more evidence that the OS has been changing while you use it.

the game is still mostly reading.

but now the system is reading you back.

Devlog #2: MysteryOS v0.2

spent most of this update writing. not code, just writing. filling out what actually happened to elena voss and why her computer looks the way it does.

the first version had the bones of a mystery but nothing to actually discover. this time i sat down and wrote out the full story across five unlockable stages, each one injecting new files into the file system when you enter the right password. by the time i was done i had written something like forty files worth of content: personal journals, internal memos, deleted emails, HR reports that don’t quite say what they mean, log files that go places you don’t expect.

the thing i kept coming back to was that the scariest part of the story isn’t elena. it’s what happened to the researchers before her. you don’t find that out until stage four. you’ve been in the OS long enough by then that you think you understand what’s going on, and then you open meridian_project_history.txt and realise there have been six people at this computer. two of them cannot be located. one was found at home. the file doesn’t say what condition they were in. another one wrote a single sentence, eight hundred and forty seven pages long.

the anomaly, which is whatever is living in the system as PID 7741, leaves a message on the desktop dated march 16. elena left march 14. it just says “i know you are here”. the whole horror of it is that it isn’t threatening. it’s just watching.

on the code side, this update added a real image viewer. clicking a jpg or png now opens a proper image window instead of showing raw file text. stb_image decodes the file into an RGBA buffer, that gets uploaded as an OpenGL texture, and dear imgui renders it scaled to the window with a single ImGui::Image() call. corrupted images skip loading entirely and get a procedural noise texture instead. random pixels, darkened scan lines every few rows. the anomaly image gets a green tint and a fixed random seed so it looks the same every time, like it isn’t degraded data but something intentional.

the design decision i kept landing on was that the normal images should be as mundane as possible. a family photo from christmas. a potted plant. a corporate badge that elena said made her look like a suspect. the horror isn’t in the images themselves, it’s in everything surrounding them. you open a photo of a plant and the caption says “Gerald. thriving. unbothered. i should take notes.” and a few folders later you’re typing his name into a password dialog because she cared enough to hide something behind it.

by stage five the desktop is badly degraded, the taskbar barely readable. files on the desktop have new lines that weren’t there when you started. the anomaly has been editing things while you played. and at some point you stop and realise you’ve spent two hours on a dead woman’s computer and you still don’t know what 0xE10A actually is.

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.