@overcharged-coder

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!