@overcharged-coder

Devlog #7: follow-cam, presets, and main character energy

this update came from a simple problem:

GraSim kept making cool moments, and then they kept leaving.

a neutron star would start tearing through a debris cloud. a black hole would drift into the mess. a star would get launched out of a supernova. and i’d be manually panning after it like the universe hired me as a camera operator.

so now GraSim has body selection and follow-cam.

you can click near a body to select it. selected bodies get a ring, a label, and a brighter marker on the minimap. press l, and the camera follows that body smoothly.

if the selected body gets eaten, merged, exploded, or otherwise removed from existence, follow mode turns itself off. middle-drag cancels follow-cam. esc clears selection.

this sounds small, but it changes the feel a lot. before, you watched the sim from outside. now you can pick one object and let it become the main character.

i also added quick presets:

• 4: binary collapse
• 5: neutron star feeding
• 6: black hole debris field
• 7: orbit art cloud

these are not levels. still not a game thingy. they are just fast ways to start good disasters.

the neutron star preset auto-selects and follows the neutron star, so you can immediately watch it do crimes. the black hole preset does the same for the black hole. the orbit art preset turns collisions off and starts a cleaner trail-painting setup, because sometimes the goal is not destruction. sometimes the goal is making gravity learn cursive.

the minimap from last update is more useful now too. it highlights the selected body, while the main view shows a selection ring and label. the hud also says what you are selected/tracking.

so the ui and camera finally work together:

• minimap says where the system is
• follow-cam says who matters right now

i also added a GitHub Pages workflow.

now pushing to main can install Emscripten, build raylib for web, compile GraSim into docs/gravity.js, upload docs/, and deploy through GitHub Pages. less “did i remember to rebuild wasm?” energy.

under the hood, i added small tested helpers for:

• body type labels
• selected body validity
• follow-camera centering
• click-selection radius

this update did not add new physics. it made the existing physics easier to follow.

which is good, because GraSim already has enough nonsense. now you can actually keep the camera on the nonsense.

thanks for reading :)

Devlog #4: the world starts pushing back

this update made Tidekin feel less like a blank canvas and more like a tiny hostile universe.

before, the creatures had brains, lineages, signals, Creature Lab, and an Evolution panel. you could watch species rise and collapse, and the sim finally kept enough history to make that visible.

but the world itself was still a little too passive.

so now there are world brushes.

you can paint food, toxins, heat, cold, and erase zones directly on the map. the brush has a radius slider too, so you can make tiny little patches or absolutely ruin a region with one dramatic sweep. very scientific. very responsible.

heat and cold matter because Tidekins already have tolerance traits. now those traits have more room to become important. a heat-tolerant strain can survive near vents better. a fragile one can wander into the wrong patch and quietly become a lesson.

i also added environment presets: Lush, River, Vents, Desert, and Islands.

they are basically starting conditions for different kinds of evolutionary pressure. Lush gives life a generous beginning. River cuts the world with toxin. Vents creates dangerous hot spots. Desert is sparse and mean. Islands separates food into pockets, which makes movement and sensing matter more.

this makes testing creatures way more fun. instead of manually painting the same setup over and over, you can drop a whole ecological problem into the world and see who deals with it.

death got more visible too.

Tidekins now leave grave pings when they die, colored by cause. starvation, toxin, heat, old age. it is not a huge memorial. just a little signal that says “something happened here.” but it changes the map. you can see bad areas accumulate evidence. the world starts looking haunted by failed decisions.

then came follow cam.

the Evolution panel already let you click a lineage to highlight its living members. now each row has a Follow button that tracks that species’ current champion. the first version technically worked in the engine, but the UI was rebuilding the lineage rows every frame, so the button could detach while you were trying to click it. extremely cursed. fixed now.

Follow snaps to the champion, then tracks smoothly. it makes the sim feel more personal. instead of watching the whole population as noise, you can pick a lineage and let one Tidekin become the main character for a while.

and finally: mating.

Tidekins can now reproduce in pairs when compatible mature members of the same species are close enough. the child blends both genomes, then mutates from there. asexual reproduction still exists, but paired births now show up in the Evolution panel.

this is a big step for the sim because inheritance is no longer always one straight line. traits can mix. a useful strain can combine with another useful strain. or two disasters can create a new, more advanced disaster.

which is also evolution, technically.

the update is mostly about pressure and evidence.

the world can be kinder or meaner. deaths leave marks. species can be followed. genomes can mix. and the player has more ways to shape the experiment without directly controlling the creatures.

Tidekins are still tiny, dumb, fragile little dots.

but now the world around them has opinions.

and sometimes those opinions are heat, poison, starvation, and a suspiciously successful lineage that somehow figured out how to keep going.

thanks for reading :)

Devlog #1: the slack bot that got out of hand

this started because our workspace needed a fun bot. not serious. just something to roast people, hold a little economy, maybe play akinator.

that was months ago. FuSBot now has a dungeon system, a voidmaze, an arena, a lab, and an animal collection i still don’t fully understand. i do not know how this happened.

the economy

the first thing i built was horsenncy. the bot’s currency. earn it, spend it, gamble it, give it to people who are losing. the name is a joke i can’t explain and also can’t undo. nobody has asked what it means. everyone probably assumed it made sense to someone.

the economy runs on state.json. giant nested dictionary, not a real architecture decision, it just started that way and everything got built around it. now it’s the spine of the whole bot and also a file that gets auto-committed to the repo every six hours by github actions.

sometimes the commit history is just:

Update bot state
Update bot state
Update bot state

very normal software engineering.

the roasting

/fus_roast and the bot insults someone with an llm.

original version took @username as plain text. fine until you’re in an 18k-user workspace, the bot paginates through the entire member list, hits a rate limit on page 91, and the roast fires at the sender instead of the target.

i found out because someone said “bro you got roasted.” i was the one who ran the command.

now it uses a slack modal user picker. popup opens, you search for your target, slack handles the uid lookup, bot gets the id directly. no pagination. no rate limits. no self-roasting.

the roast hits multiple llm providers in parallel, faucet, groq, gemini, github models, openai, scores results for spiciness and returns the winner. fast mode takes whatever comes back first. overkill for an insult generator. i am at peace with this.

the typing animation

the bot called conversations.typing in a loop while waiting on llm responses. never worked. slack requires channels:write for that, which is way too much permission for a roast bot.

new approach: post ... immediately when the bot starts thinking, delete it when the real reply is ready. not a typing indicator. just looks like one. nobody noticed.

akinator

/fus_aki starts a real akinator game in slack with yes/no/idk/probably buttons.

akinator.py broke when akinator changed their backend. switched to the akinator package, which also broke, KeyError: ‘akitude’ because the api response dropped that field.

fix: monkey-patch. __handler is name-mangled but python lets you replace _AsyncClient__handler from outside. swapped data[“akitude”] for data.get(“akitude”, self.akitude). one line. done. this took longer to explain than it took to fix.

the brain

the bot has a system called the brain. it reads channel messages and builds a lightweight model of what topics come up and who’s active. uses that context when responding to mentions. if a channel is mostly about games it leans into that. if a user keeps mentioning chess, it remembers.

personalization system or mild surveillance depending on how you frame it. the bot is simply learning. there is a distinction.

how it runs

FuSBot runs on github actions. starts on push, runs up to six hours, commits state back to the repo on exit. cron trigger every six hours as keepalive. cancel-in-progress: true so pushing a fix auto-restarts the bot. not how you deploy a slack bot. works anyway.

what’s next

• more quest types
• roast presets
• figuring out what the dungeon is actually supposed to be
• not letting state.json get unreadable

the bot got way bigger than planned. someone lost 50,000 horsenncy in a dungeon run last week and immediately asked when the next update was.

that felt like a good sign.

thanks for reading :)

Devlog #3: evolution starts keeping score

this update is about making Tidekin less mysterious in the annoying way.

before, the sim was finally getting interesting. Tidekins had tiny neural brains, weak instincts, communication signals, lineage memory, directional sensing, and Creature Lab. you could make a weird little strain and release it into the world.

but then the big question was:

did it work?

sometimes a Tidekin survived longer. sometimes a species quietly died out. sometimes a mutant looked promising and then disappeared while i was looking somewhere else. evolution was happening, but the sim was not explaining itself very well.

so now Tidekin has an Evolution panel.

it tracks lineages/species as they appear, survive, reproduce, and die. each row shows how many are alive, how many were born, and what the main death reason has been. starvation, toxin, heat, old age, unknown. tiny simulated tragedy, now with labels.

this changes the feeling a lot.

before, a dead Tidekin was just gone. now it leaves evidence. if a whole line keeps starving, you know it was not just “bad vibes.” if a toxin-tolerant strain survives where others collapse, the panel makes that visible. if Creature Lab creates something useful, you can actually see it start to matter.

i also added lineage summaries under the hood. the sim now turns the birth/death history into ranked species rows based on living population, children, and survival. it is not a full science dashboard yet, but it is enough to make natural selection feel less invisible.

you can also click a lineage row to highlight the living members of that species on the map.

this is one of those features that sounds small until it exists. suddenly the dots are not just dots. they are part of a line. you can see which strain is still around, which one is fading, and which one somehow became the dominant little disaster.

i also found a UI problem while testing: the inspect popup got too tall after Creature Lab, so some controls could end up offscreen. very professional. very graceful. now the inspect card scrolls properly, so the gene sliders and Spawn variant button are actually reachable.

the overall direction is becoming clearer now.

Tidekin is not just “watch creatures move around.” it is becoming “make a tiny world, meddle with life, and then watch the consequences show up in the population.”

the creatures are still not smart.

but now the world remembers what happened to them.

a Tidekin can starve, burn, survive, reproduce, fail, or accidentally start a whole lineage of weird little champions. and now the sim keeps enough history that you can tell the difference.

that feels important.

because evolution is cooler when you can see the receipts.

thanks for reading :)

Devlog #6: actual scares and the thing behind the screen

this update started with a very normal horror game thought:

“what if the computer actually scared you?”

not just a popup. not just corrupted text. not just the system saying something ominous and then politely giving control back.

i mean the screen gets taken.

MysteryOS now has real scare events. opening the wrong file can hard-cut the entire screen into static for a couple seconds, with a sharp sound hit and no friendly little error box explaining what happened. for a moment the desktop stops being an interface and becomes something else using your monitor.

i added a new scare type called HardJumpscare, which is not exactly subtle.

there’s also an aperture scare now. the screen goes black and a thin vertical slit opens in the middle, like something is looking through from the other side. green static crawls behind it. scanlines move through the gap. there’s this horrible descending sound underneath it, less like a glitch and more like a door opening somewhere it should not.

sound was the missing piece.

before this, most of the horror was atmosphere: creepy files, corrupted images, strange messages from PID 7741. that worked, but it didn’t have teeth yet. now the scare director can request audio events: dread drones, impact hits, aperture noise. no audio files needed. it’s all generated live with WebAudio using oscillators, filtered noise, and gain ramps.

which feels right. the game is about a machine making meaning out of nothing, so the screams might as well be procedural.

i also made terminal reads count as opening files.

this matters because terminal players are exactly the kind of people who should not be safe. if you cat /Pictures/0xE10A.png, the system notices. if you read deleted researcher files from the terminal, the system notices. avoiding the GUI does not save you anymore. it just makes you look more suspicious.

some current scare triggers:

• opening /Pictures/0xE10A.png
• searching for september
• running timeline /Users
• opening deleted researcher files
• opening /System/models/
• opening /Desktop/you/a_door_you_did_not_open.txt

that last one is probably my favorite, because the file name is already a warning. you know opening it is a bad idea. the game knows you are going to do it anyway.

the important part is that the scares are tied to meaning now. the aperture scare happens around models and timelines, because those are the moments where you are not just reading evidence anymore. you are helping the anomaly understand people.

the hard jumpscares are for boundary files. 0xE10A.png. the door file. things that should feel like the OS briefly stopped pretending there was a safe distance between you and it.

internally, the scare system is cleaner now too. the scare director handles visual events, delayed whispers, and sound requests. the kernel drains those requests and plays the WebAudio stingers. it’s starting to feel less like a pile of glitch effects and more like a horror engine hiding inside a fake OS.

which is exactly where this game has been heading.

MysteryOS has always been about reading too much. every stage rewards attention, but every reward also makes the machine more aware of you. now that awareness has a body: the screen going black, the sound cutting in, the desktop being taken away for two seconds while something else uses it.

next i want the horror to get more personal. tracking what files you reread, what terms you search, what folders you avoid, and letting the final stages respond to that.

because the scariest version of MysteryOS is not one where the anomaly jumps out.

it is one where it is right.

Devlog #6: minimap, clean ui, and the branding crime

this update was supposed to be simple.

i wanted to make GraSim easier to look at.

not more realistic. not more explosive. not “what if black holes had opinions.” just cleaner ui.

because after the last update, the sim was getting pretty good at making cool moments, but the interface was still kind of yelling at you. the old hud was a giant instruction rectangle in the corner, which was useful, but it also made every screenshot look like a debug build trying to explain itself.

so this update is basically:

• less wall of text.
• more tiny space instrument.
• the first big thing is ui modes.
• press u now cycles between:
  – full ui
  – compact ui
  – hidden ui

full ui still gives you the important controls and stats. compact ui shrinks everything down into a small stats bar. hidden ui removes the overlay entirely so you can actually take screenshots without a massive instruction box photobombing the supernova.

this was one of those features that immediately made the project feel more finished. not because it changes the simulation, but because it stops the ui from fighting the simulation.

then i added the help overlay.

press / and you get the controls. press it again and it goes away.

that means the controls are still there when you need them, but they do not need to live permanently on top of the universe like a sticky note from mission control.

then came the minimap.

press tab to toggle it.

it sits in the top-right corner and shows the whole system as tiny dots. planets, stars, black holes, neutron stars, all compressed into this little overview panel. it also draws a rectangle for your current camera view, which is weirdly useful because GraSim scenes can spread out fast. you zoom in to watch one neutron star doing crimes, and suddenly half the system has wandered off somewhere else.

the minimap makes the sim feel less like “where did everything go?” and more like “oh, the disaster is simply over there now.”

it also makes the project feel more like an actual tool. still chaotic, still tiny, still not a full game thingy, but now it has a little observatory energy.

i also updated the README.

it has shield.io badges now, longer feature descriptions, controls, physics notes, build instructions, and a better explanation of what the project actually is. basically less “here is a gravity thing” and more “here is my cosmic disaster sandbox, please enjoy responsibly.”

and then there was the branding incident.for some reason, in the new hud, i wrote the name as grAsim.

i do not know why.

nobody asked for that.

GraSim looked at me from the corner of the screen wearing the worst capitalization possible. this was immediately corrected. the hud now says GraSim, the browser title says GraSim, and the abomination has been removed from the repo.

important work.

under the hood, this update also added a few small testable ui helpers. nothing huge, but enough to make sure the ui mode cycle behaves properly:

• full goes to compact
• compact goes to hidden
• hidden goes back to full
• hidden mode does not draw panels
• help does not show while ui is hidden
• minimap scale math behaves predictably

the web build was rebuilt too, so the browser version has all of this.

the sim itself did not get new cosmic physics this time, but honestly this update matters a lot. GraSim is becoming the kind of thing where the visuals deserve room to breathe. if a neutron star is ripping a planet apart, i do not need six lines of controls sitting on top of it forever.

now the screen can be messy because the universe is messy, not because the ui is.

next i still want follow-cam. probably presets too. maybe a proper screenshot key eventually. because the main problem has become that GraSim keeps making cool moments and i keep noticing half a second too late.

thanks for reading :)

Devlog #2: still dumb, but better at surviving

this update was mostly me yelling “why are you like this” at tiny simulated life.

after the first build, Tidekins had neural brains, mutation, inspection, and reproduction. technically, evolution was happening. emotionally, a lot of them were drifting into nowhere and dying with total confidence.

so the goal became: make them less doomed without making them secretly smart.

first came lineage memory. Tidekins still do not learn during life. there is no training loop, no backprop, no server brain. but lineages now leave pressure behind. if a parent survives and has kids, descendants mutate more gently. if a line dies fast, future variation gets more exploratory. evolution feels less like pure lottery noise now.

then came communication.

Tidekins leave signals in the world. eating leaves a food signal. getting hurt leaves a danger signal. being healthy enough to reproduce leaves a mate-ish signal. other Tidekins can sense those fields, so one creature finding food can make that area more attractive, and one creature suffering somewhere can make that spot feel cursed.

this helped.

they were still dumb.

so i added survival instincts under the neural brain. not pathfinding, not “go exactly here,” just weak built-in pressure toward food and away from hazards. the neural brain still matters, but gen one is no longer born with absolutely zero survival reflexes. they are dumb in a way evolution can actually work with.

then i added intent modes, because they kept changing their mind every frame.

now a Tidekin can briefly commit to seeking food, fleeing danger, recovering, or reproducing. low-energy Tidekins also slow down instead of sprinting themselves to death when they have no useful cue.

after that, the problem was perception. they were basically nearsighted. if food was not close enough to create a nearby gradient, they often had no idea it existed. now they have directional feelers. each Tidekin samples the world in multiple directions at a distance based on vision, so they can notice food or danger before physically stumbling into it.

they can also remember a food direction for a short time. not forever. not intelligently. just enough that they do not instantly forget what they were doing.

the last big addition is Creature Lab.

when you inspect a Tidekin now, the popup has sliders for its trait genes: speed, size, vision, metabolism, diet, toxin tolerance, heat tolerance, fertility, fear, aggression, hue, and accent. you can edit the selected Tidekin directly, then spawn a variant from it.

that changes the whole feel. instead of only watching evolution happen, you can meddle. make one with huge vision. make one fearless. make one tiny, fertile, and weirdly colored. then see if that strain actually survives.

it is not a polished creature creator yet. it is more like poking the gene pool with a glass needle.

which feels right for Tidekin.

the sim is still simple. the brains are still tiny. the Tidekins are still extremely capable of making terrible choices.

but now their terrible choices have more structure.

they can sense farther, remember briefly, signal to each other, inherit pressure from their lineage, and be manually nudged into strange new forms.

they are still dumb.

but now when they survive, it feels a little more earned.

thanks for reading :)

Devlog #1: Tidekin begins

this started as “what if i made a little evolution sim?”

then the little guys got brains.

Tidekin is a browser-based evolution sandbox built in C++ and compiled to WebAssembly. the world starts empty, which feels right. nothing exists until you add it. click Spawn, drop a Tidekin into the universe, and suddenly the map has a little nervous system moving around inside it.

the map can zoom and pan now, so it feels less like a fixed aquarium and more like a tiny open petri dish. you can place creatures, add food, drop toxins, create vents, mutate the population, and inspect individual Tidekin.

Inspect ended up mattering a lot. at first, clicking a creature opened its stats, but then spawning near an existing one got annoying because selection stole the click. then i fixed spawning and accidentally made it impossible to inspect anything. very elegant. very normal.

so Spawn and Inspect are separate tools now. Spawn means “put another one here.” Inspect means “pause the world and look at this specific creature.” the popup shows species, generation, energy, traits, and the new brain drives.

that is the big thing: neural brains.

the first behavior was rule-based. creatures looked for food, fled hazards, avoided crowds, wandered, and reproduced when thresholds lined up. it worked, but it felt too authored. they were following rules i wrote instead of carrying their own weird little decision systems.

so now every Tidekin has a tiny fixed neural network encoded in its genome.

there is no training server, no Python model, no backprop, no cloud brain. it is just C++ math inside the sim. the genome has normal trait genes, then extra brain-weight genes. those weights mutate, and children inherit changed versions.

the brain reads inputs like nutrient direction, hazard direction, energy, toxin, heat, crowding, velocity, and a little restlessness. then it outputs movement plus drives for food, hazards, and breeding. those show up in the popup as Food drive, Hazard drive, and Breed drive.

that changed the feeling immediately. a Tidekin is not just “seeking food” because the engine said so. it has weights pushing it toward or away from things. a lineage can become food-focused, reckless, avoidant, or weirdly obsessed with reproducing at bad times.

i also slowed the sim down. early on, creatures ate too fast, bred too fast, and the whole world became a population explosion before you had time to care about any individual. now reproduction takes more age, more energy, and more cost. eating is less of an instant battery refill too.

the goal is for individual creatures to matter longer. if you inspect one, watch it move, and later see its descendants, that should feel like a tiny story instead of just another dot in a swarm.

Mutation storm is there too, because obviously it is. it mutates the current population and lets you throw the gene pool into chaos. useful? sometimes. responsible? probably not. fun? yes.

the creatures are still simple. they do not know anything in a human sense. they are little weighted reactions drifting through fields.

but that is kind of the point.

an empty map.

a click.

a tiny creature with a tiny brain.

and then the uncomfortable realization that if you give the dots enough rules, you start rooting for them.

thanks for reading :)

Just some more lore to explore!

Devlog #5: real mode, smaller black holes, and the 4500-body incident

this update started with a dangerous sentence:

“can we make it as real as possible?”

which is always how you end up rewriting half the rules of your tiny gravity sandbox.

the big new thing is realism mode. sandbox mode is still the weird toybox: fixed black holes, white holes, dramatic nonsense, maximum chaos. real mode is stricter. white holes get removed, black holes are no longer pinned in place, and compact objects actually move under gravity like everything else. black holes are still terrifying, but now they can drift, get tugged around, and become part of the system instead of being an immovable stage prop.

i also split visual size from collision size.

before, a black hole’s visible radius and collision radius were basically the same idea. that made them feel too chunky. now bodies have a visual radius and a collision radius. stars and planets can still look big and readable, but black holes can have a smaller actual eating zone while keeping the dramatic accretion disk visuals. neutron stars stay tiny and dense, which feels much better.

then came high-speed realism collisions.

in real mode, fast planet/star impacts can now fragment instead of just merging. the impact throws out visual debris and a few physical asteroid chunks, so collisions feel more like violent breakup events instead of every crash becoming one bigger blob.

and then i discovered a very funny problem.

the launched fragments counted as bodies. those bodies immediately collided with each other. then those collisions made more bodies. then those bodies collided too. a small-ish crash could casually become 4500 bodies and turn the browser into soup.

so that got fixed.

impact debris is now mostly visual particles, with only a small capped number of real chunks. asteroid fragments also cannot recursively fragment again, which means you still get the cool spray of debris without accidentally inventing an infinite universe generator.

the sim now has a clearer split:

• sandbox mode is for cosmic nonsense
• real mode is for cleaner physical behavior
• visual particles are for spectacle
• real bodies are for things that should actually affect gravity

that last distinction matters a lot. not every glowing speck deserves to be in the Barnes-Hut tree, emotionally or computationally.

the best moments now are these messy almost-real disasters: a star explodes, leaves a neutron star, nearby bodies get torn up, a black hole drifts through the debris, and the whole thing looks like some cursed astronomy textbook diagram that learned how to party.

next i probably want capture tools: hide UI, follow-cam, maybe a screenshot-friendly slow motion key. because the sim is now very good at making moments that disappear right before i can take a picture.

thanks for reading :)

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 #4: neutron stars, cleaner orbits, and cosmic nonsense

this update started as “fix the math a little.”

then neutron stars got involved.

after the last devlog, the sim already had Barnes-Hut gravity, spatial hashing, black holes, white holes, and supernovas. it could throw hundreds of bodies around, but the math needed to feel less cursed. so first i split the project up: the main loop, renderer, and simulation code now live in separate files. boring maintenance, but very worth it. changing gravity code is much nicer when it is not buried inside the draw loop.

then i changed the integrator.

before, bodies used a simpler velocity/position update. now the sim uses velocity Verlet. it calculates acceleration, moves bodies using current velocity plus half the acceleration term, recalculates acceleration, then updates velocity using the average. the result is better orbit behavior and less fake energy drift.

Barnes-Hut got a correctness fix too. a body could be inside a quadtree node that still got approximated as a far-away cluster, which meant it could get a tiny pull from a group containing itself. now internal nodes containing the target body are never approximated. the tree has to recurse deeper, so the gravity math is cleaner.

now the fun part: neutron stars.

neutron stars are compact, bright, and violent. they have a tiny fixed radius, pulse with blue-white halos, and shoot narrow rotating beams like little cosmic lighthouses. they are also dense enough to rip apart nearby bodies.

i added tidal disruption: when a normal body passes inside a neutron star’s Roche-like limit, it gets shredded into hot debris instead of simply merging. the neutron star absorbs some of the mass, a shock ring flashes outward, and particles spray away with the victim’s old velocity mixed into the blast. it looks nasty in the exact way i wanted.

supernovas now tie into that properly. before, the remnant logic was too simple. now it works like this:

• below 2000 mass: the star blows apart and leaves no compact remnant
• 2000 to 2599 mass: it collapses into a neutron star
• 2600+ mass: it collapses into a black hole

so a massive star can explode and leave behind a neutron star, but only in the right range. if it is too massive, it becomes a black hole instead.

the emergent sequences are getting really good now. binary stars spiral together, merge, cross the supernova threshold, explode, and leave a neutron star in the debris. then that neutron star starts tearing through nearby bodies, throwing off little streams of glowing fragments. sometimes a white hole shoves the whole cloud sideways. sometimes a black hole eats the aftermath. none of this is scripted. it just happens because the rules are finally interacting.

with collisions off, the screen turns into these huge braided orbit paintings. with collisions on, it becomes a machine for making disasters.

next i want to make it easier to capture the good moments: probably a hide-UI key, better presets, and maybe a follow-cam so one chaotic object can become the main character.

thanks for reading :)

Devlog #3: black holes, supernovas, and O(N log N)

a lot has happened since the tunneling fix.

last time i said the next few updates would focus on cutting time complexity. that’s done now. the big one is Barnes-Hut. instead of checking every body against every other body for gravity, you build a quadtree that recursively splits space into four quadrants. when computing the gravitational pull on a body, if a whole cluster of bodies is far enough away, you just treat it as a single point mass. “far enough” is a ratio called θ; i used 0.5. gravity goes from O(N²) to O(N log N). at ten bodies you won’t feel it. at two hundred you really will.

collision detection got the same treatment. spatial hashing: bodies are bucketed into grid cells by position and you only check pairs that share a cell. O(N) average case. there was a subtle bug where i had a fixed cell size of 100px, which completely broke for large merged bodies since their combined radius could exceed 100 and the system just never detected them. fixed with cellSize = max(100, maxR * 2).

also switched trails from vector::erase(begin()) to a deque so pop_front() is O(1) instead of O(N) every frame. small thing but it was just sitting there being wasteful.

then the actually fun stuff.

i added a body type system. asteroids are jagged 7-sided polygons with a faint white outline. planets get an atmospheric halo and an equatorial band. stars have layered corona glows and eight slowly rotating rays. bodies auto-upgrade when they absorb enough mass, past 20 you become a planet, past 200 a star. it all just happens from collisions.

black holes (H key) are fixed in space. i zero their acceleration and velocity every substep so gravity from other bodies does nothing to them. visually they’re a black void ringed by a spinning orange accretion disk. they eat everything that enters their radius unconditionally, regardless of whether collision mode is on. they grow as they feed.

white holes (W key) are also fixed. the Barnes-Hut tree naturally computes attraction toward everything including white holes. after the tree pass i run a correction that subtracts 2× each white hole’s gravitational contribution from every other body, cancels the attraction, and flips it to repulsion. in merge mode they also kick anything that gets too close instead of absorbing it.

and then supernovas. when a star hits 2000 mass, it explodes. 22 asteroid fragments fly out in a ring, every nearby body gets an outward shockwave kick proportional to how close they were, and a visual ring expands and fades over about 1.5 seconds. if the star was over 3000 mass it collapses into a black hole instead of disappearing.

the thing i didn’t plan was the emergent sequence: binary stars spiral inward from mutual gravity, merge into one massive star, cross the supernova threshold, explode, and leave a black hole sitting in the middle of the debris field. i didn’t script that. it just happens.

next i want nebulas: regions that apply drag to passing bodies. and probably a follow-cam that locks onto a selected body.

thanks for reading :)

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.

Devlog #2: Zoom, stars, and chaos
new updates to GraSim!

zooming is obviously an essential part of GraSim, so I added it as quickly as possible. there are some randomly put stars around the map. zooming introduced a crucial bug:

since you drag to add speed, when you zoom out the max of 10x the max speed gets 10x higher. this caused an issue called tunneling! each frame, the simulation moves bodies velocity * dt. at very high speeds, as mentioned above, a body can actually travel faster than it’s own diameter in a single frame! so, in frame N if they are apart, in frame N+1 they could well be already crossed.

i fixed this with substeps. basically, instead of checking just per frame, we check for collisions every X times per frame. more times checked = less distance possible, so it’s the easiest way of stopping passing into each other.

unfortunately, gravity is already expensive with O(N^2), and substeps adds another O(N^2) on top of that. the next few updates will likely focus on cutting down this time complexity as well as the time complexity of other features noticeably!

thank you so much for reading :)

Devlog #1: GraSim v0
first version of GraSim! a fun, addicting gravity simulator!

v0 includes a few basic features, including asteroids, planets/stars, collision/no collision modes, gravity field mode (you can see the gravity fields), and panning mode (infinite map style).

raylib is the easiest for these kinds of things in c++, so i used that as the main library. the majority of the code was just physics, mainly Softened Newtonian Gravity:

F = G·m₁·m₂ / (d² + ε²)

and various other smaller things during collisions, collisions during no-collision mode, etcetera

i’m not sure what the end result will be like, maybe i’ll add more realistic-looking planets and asteroids, and maybe black holes & white holes.

here’s the main part:
static void AddBody( vector<Body>& bodies, Vector2 position, Vector2 velocity, float mass, Color color ) { Body body; body.position = position; body.velocity = velocity; body.mass = mass; body.radius = RadiusFromMass(mass); body.color = color; bodies.push_back(body); }

i’m not sure what the final goal is, but I hope it’s cool!