Prometheus devlog

The night I deleted my own Forge

2026-11-07T12:00:00.000Z

A little after midnight on Halloween, a routine change to one of my git worktrees deleted most of Forge. Spooky timing. It ended up shaping everything I've done since.

798 files, gone

I keep a lot of worktrees, and they share their dependency folders through Windows junctions, which are links that look like normal folders. Narrowing what one worktree checks out made git follow one of those junctions straight into my main checkout. It took out 798 tracked Forge files, Forge's dependencies, its settings file and the folder holding its keys.

Git brought the tracked files back in seconds. Everything else was harder:

I rebuilt the settings file with new keys.
Forge's sign-in key was gone, so every device had to sign in again.
The key that signs DD-ReForged's licences couldn't be recovered at all. I made a new one, and the desktop app, the phone app and the editor now trust it alongside the old one.

Nothing I'd written was lost, but it was closer than I like. Now a weekly backup copies my untracked secrets, both databases and a verified bundle of every branch and tag, and a quick git-only backup runs before every merge.

Every git write can be undone

A few hours later I was planning the fix. If my own git tool can't protect me from a night like that, it isn't done. DD-ReForged 0.3.16 and 0.3.17 grew a full git toolkit, built around one rule: anything that changes a repo has to be recoverable.

Every write is recorded. Each one saves a journal line and a snapshot of the refs first.
Recovery centre. Browse the reflogs, saved refs and the journal, and undo a ref move. Pruning makes you type a word first.
Lost and found. Dangling commits and dropped stashes can come back.
Destructive commands got softer. clean moves files to quarantine instead of deleting them, and reset --hard and discarding changes both save a copy first.
Backup centre. Verified bundles and mirrors, kept outside any repo.
The junction guard. Removing or repairing a worktree now refuses to reach through a link. That's the exact mistake from Halloween, with tests against real git for a junction at a tracked folder and a junction below a junction.

There's also plenty of everyday git: history search with blame and line history, a commit composer, local-only merges, tags, remotes, a panel for stuck operations and conflicts, and a safe force push. An MCP server lets an AI coding assistant work through the same rules, with the protected-branch override off by default. I've pushed the Prometheus repo through DD-ReForged itself, too.

Repairing my own repo was the real test. It has 22 orphaned pack files, and an early version of the repair would have let any tool's garbage collection delete 446 objects that exist nowhere else. I caught that before it ran. Trying hard to break things before merging also found ways that Send to Forge could lose data, three rounds of them. Passing tests alone would have shipped all of it.

Then I walked every workflow in the desktop app with real clicks against a throwaway Forge. No work was lost, but it found bugs worth fixing, including a leftover lock file that stopped the app from opening and a Create tag button that wrote to Forge's copy while the screen said local.

A new look, and boards that travel

0.3.17 also rearranged the app. Every page now fits in one bar, or a left rail if you'd rather, and Wake and the boards get the whole window. Wake opens from its last known graph and only reads what's new, and the branch list stays fast past 1,000 branches. I know because the Prometheus repo had 1,013 of them, until I cleared out 1,004 merged ones.

Boards and cards now work across your own PC and Forge. Cards can hold attachments, images and safe HTML, and a deleted card or board on Forge sticks around for 30 days in case you want it back. A notifications bell and tabs above the toolbar are merged and waiting for the next build.

The phone

The phone got a branch viewer with a continuous commit graph, plus commit details and making or deleting a branch on origin. It also got line comments, long-press to move a card, formatted Markdown and importing a photo into your avatar. App lock now uses the device's own lock and blanks the preview in your recent apps.

I have to be honest here: the newest of this hasn't reached my Fold yet, and app lock has only been tried on an emulator with a PIN. Fingerprint, face and folding are still to test.

Forge grows up

Forge now keeps an audit log of who did what, when and how, and you can check your own under My activity. Almost every Forge page now works on a phone as well.

It's also getting ready to leave my PC. I've had a hosted Forge running in a Podman pod with MySQL, Caddy and Tailscale, reachable only on my private network. I haven't moved over yet. That comes after the testers' pieces are in place: invites that carry a licence, a list of who may sign up, a page for tracking testers, and a Downloads page that only serves builds to people with a licence.

Back in the editor

The plugin platform moved forward as well. Plugins now say where their panels go, add status items, send notifications and get a say before the app quits. They also declare their permissions, and the editor limits their menus, commands and panels to match.

The editor has a real sign-in screen and a new desktop installer, 0.4.0. Forge can also sign in players from a shipped game now, the first small piece of the game itself touching these tools.

Scene saving got more careful too. A whole-scene save keeps records it wasn't sent, a slow asset listing no longer blocks Load and Save, offline deletes survive a reload, and a half-saved script no longer gets imported.

Tools first

I also made a call that day: no new game content until the tools and every app work properly. I don't want to build a game world on tools I can't trust. The full test suite is past 27,000 tests now, and the game comes next once these pass.

Build 0.3.18 and get the newest app onto my phone. Then the last checks before the first testers: a run as a brand new Windows user, the newer MySQL version, and a real build going through the Downloads page.

Seal: licences for the tools

2026-11-01T12:00:00.000Z

A few days ago I tackled something I'd been putting off: licensing. I've put a lot of time into DD-ReForged and the tools around Prometheus, and I want to protect that before other people start using them. It went from plan to running on my own devices in a single day, and I wanted to think about how to tell you before writing it up.

The plan

The engine will be free once I'm done building my game with it. The custom parts I build for the game, not so much. But there will be a way, with documentation, to build your own plugins and extend the engine to your heart's content.
DD-ReForged has a free version that links up with the engine, at the low, low cost of registering for a free licence. Free never locks. It covers working on your own PC: Drydock, Wake, reviews and boards stored locally, and the VS Code extension. The phone app is free too, for reading.
Pro adds everything that talks to a Forge server: syncing reviews and boards, server worktrees, notifications, and taking action from the phone (comment, approve, merge, move a card). Pro comes with a year of updates, and you keep the app.
Enterprise isn't a thing... yet. More on that below.

Which feature sits in which tier is just data on the licence, so I can move things around later without shipping new code. Payments aren't part of this yet. For now I issue keys by hand.

Why licences at all

Let me be upfront, because "licence" sounds scarier than this is.

No, I won't sell your stuff. Registering is how I find out how many real users I've got, and whether enough support comes my way to keep delivering what I can, when I can. I have a family and a full-time job. I'm a web developer by day and a game developer at night and on weekends, and this is a passion project for me. I love to build stuff, and if I can make a few dollars from Pro, great.

I use all of it myself, every day. I'm the test bed, and the battle testing is done by friends and beta testers. If you want a custom solution for your team, we can talk enterprise, and see what custom features you'd want me to build to help the ecosystem grow and get more robust.

And to be honest, I'm sick of paying an arm and a leg for software. This stuff will basically be free. Pro comes with a year of updates, and you keep the app. Enterprise? Well, that's not a thing... yet. Maybe in my wildest dreams. This is just for funzies, and some cool tools to use for development.

Did I mention it will be almost free? Buy me enough cups of coffee and I won't need to buy my own anymore.

I appreciate you all for your support.

How it works

In keeping with the fire names, the licensing part of Forge is called Seal.

A licence is a signed statement. Forge signs something like "this account has Pro, these features, up to 3 devices, updates until next October". Every app carries Forge's public key, so it can check the signature without going online. Nobody can turn Free into Pro without Forge's private key, and that never leaves the server.
A key is how you claim it. You sign in, open Settings → Licence, and enter a key like DDRF-XXXX-XXXX-XXXX-XXXX once.
Each device gets its own pass. Every install makes its own device key and keeps it in the operating system's secure store. Activating sends Forge the public half, and Forge sends back a pass that only works on that device. Copying it to another machine gets you nothing.
A daily check-in keeps it fresh. Once a day the app checks in and gets a pass that's good for another 14 days. If you're offline, everything keeps working until the 14 days run out. A licence that's been revoked stops at the next check-in.
Up to 3 devices. You can release one yourself, from the desktop or the phone, to free its slot.

When a feature isn't in your licence, it doesn't vanish. It shows as locked, says which tier unlocks it, and everything else keeps working.

As usual, I drew all of these screens in Figma before building them: activating a key, the licence page, locked features, a failed check-in, the end of the offline grace, the device limit, and Forge's page for issuing and revoking keys.

Being honest about protection

Anything checked only inside an app can be cracked by someone determined enough. Desktop apps and Android apps can both be unpacked and patched. So I put the real protection where it can't be patched out: on the server. The paid features that matter run on Forge, and Forge checks the licence before it does anything. A patched app that skips its own check just gets turned away.

On top of that, the desktop app refuses to start if its files have been modified, and code signing is on my list so a tampered build can't pass as mine. What I deliberately didn't do is heavy obfuscation and anti-debugging. They slow honest debugging down more than they slow down anyone cracking it.

Working end to end

By that evening Seal was running on my Forge. I issued myself a licence and activated it on my PC and my phone. Then I switched on Forge's rule that refuses paid features without a licence, and tried it for real: I commented on a card from my phone, and the comment showed up in DD-ReForged on the PC.

The first real use found a bug, as usual. The Activate button on the PC was greyed out. The app asked for the licence details when I signed in, but at start-up the sign-in arrived before the licence part had finished starting, so the request was dropped. Now it loads the licence when it starts, waits properly for a sign-in that arrives early, and shows "Loading the licence…" until Forge answers.

Build 0.3.11 has Forge's public licence key built in, so it only trusts licences my Forge has signed.

Getting it to testers

What comes next is putting DD-ReForged in front of a few testers. They'll reach my Forge over Tailscale, a private network that also gives Forge a proper https address, and each tester gets a Pro key that expires when the beta ends. Later, Forge moves off my PC into a hosted setup on that same private network.

Plugins

I also settled the ground rules for the engine's plugin platform:

For now, only my own trusted plugins.
Plugins that only affect the editor can be switched on and off while it's running.
Every plugin carries a licence, and the ones that ship with the engine get a free one.

Hand out the first beta keys once the last checks pass, and keep building the plugin platform, which is the next big step for the engine.

A real phone, and scene saving done

2026-10-29T12:00:00.000Z

Last time the phone app had only ever run on an emulator, and scene saving had a few gaps left. This week the app went onto my own phone, the gaps are closed, and DD-ReForged is built as far as I can take it on my own.

On a real phone

My phone is a Galaxy Z Fold 7, so I got two screens to test on: the big inner one and the tall, narrow cover screen. I installed the app over Wi-Fi straight from my PC, then pointed it at Personal Forge on my home network.

The very first sign-in failed, and it was a good failure to find. To sign in, Forge gives the phone a short code and the address of a page to approve it on. Forge hadn't been told its own home-network address, so it handed the phone localhost, which on a phone means the phone itself. The app was right to refuse to open that, but then it gave up without showing the code, so I had no way to approve it from the PC either. Now, if the app can't safely open the approval page, it still shows the code and tells you to approve it on your PC. I also gave Forge its proper home-network address.

After that, everything I tried worked: the inbox, the repos, the branches, the boards and a card's discussion. Two more things turned up:

Settings → Notifications had nothing on Forge's side to talk to. Forge now keeps notification preferences for each person, and the phone reads them from there.
The cover screen. On the narrow screen, the "Edit server" button grew two rows tall whenever the connection test result appeared next to it. The result now sits on its own row under the buttons, the way the design always had it.

Forge's branch list also has a time limit now, so a slow repo can't leave the phone waiting forever.

The fixed build went onto the phone as an update, so I didn't have to sign in again. One mystery is still open: for about five minutes one afternoon, the phone couldn't reach my PC at all, then it recovered on its own. I've noted it and I'm keeping an eye out.

Scene saving, finished

In the last post, the engine learned to hold on to anything in a scene it can't load and save it back untouched. This week I finished the part you can see. When a scene has held items, the editor shows a banner and gives them their own Held group in the Hierarchy. Each one is marked as either missing (its plugin isn't in this build) or unavailable (its plugin is there but couldn't load it).

Selecting one shows exactly what was saved, read-only. You can delete it, but only after a confirm that spells out what you're losing.

None of this ever shows up for players; the markers only exist in the editor.

To prove it all works, I ran the full loop against a real backend and editor: open a scene with held items, save it, load a later save back from the database rather than the browser's copy, delete one with the confirm, and reload. All 20 checks passed.

That run turned up one more mismatch. The editor and the game disagreed about physics that had been switched off: in one case the editor still built a physics body the game wouldn't, and in another it was the other way round. They now agree. The editor's list of avatars and the server's catalogue also now always give the same entry for the same name.

With that, scene saving is done, and it's safe for a plugin to be switched off without taking anyone's work with it.

DD-ReForged: built as far as I can take it

I went through DD-ReForged again against everything I want it to do, and every piece I can build is built. What's left is on my side: a code-signing certificate so Windows stops warning about the installer, a real Linux desktop to check the tray on, and handing the team build to the people who'll use it.

Builds 0.3.9 and 0.3.10 went onto my PC in place, with backups first. Two smaller fixes made it in:

If a save fails because of a database error partway through, DD-ReForged now says so plainly and logs it, instead of failing with a vague message.
If you open Forge's approve-a-device page while you're signed out, signing in now brings you back to that page instead of dropping you on the home page.

The engine, for real this time. Scenes are safe now, so the next step is either the plugin platform itself or the export targets for phone and Steam builds.

Forge in my pocket, and scenes that forget nothing

2026-10-25T12:00:00.000Z

Two days ago the phone app was nineteen drawings in Figma. Last night it signed in to my Forge, read a pull request, left a comment, approved it and merged it, all on an Android emulator. Along the way Forge learned to push updates as they happen, and I spent part of the day on something less flashy that matters more for the game: making sure a scene can't quietly lose data.

The phone app is real

The app is a small React project wrapped with Capacitor, so it shares DD-ReForged's colours and components with the desktop app instead of copying them. It does what the drawings said it would:

Sign in. Personal Forge signs in with a code, like the desktop apps. The phone shows a short code, you approve it on Forge, and you're in.
Inbox. Review requests, comments, approvals, merges and card changes, each one tapping through to what it's about.
Pull requests. The list, the details, the changed files and each diff, plus comment, approve and merge.
Branches. The remote branches, and merging one branch into another on the server.
Boards. View a board, move a card, comment on it. Docs are read-only for now.
Settings. Accounts, an app lock, and the avatar editor.

The first Android build ran on a headless emulator. Then I ran the whole thing end to end against a scratch Forge: sign in, read the inbox, open a board, move a card, comment, open a pull request, read the diff, approve and merge. Forge's own records agreed with what the phone said had happened.

Personal Forge lives on my PC at home, so the phone talks to it over the home network. I decided plain http is fine there for now. Forge only listens on the network if you turn that on, and it can also be reached through Tailscale when I'm away. Proper HTTPS on the home network is a later job.

Forge talks back

Until now everything that showed Forge's data had to keep asking whether anything had changed. Forge now has a live event stream instead. When a review gets a comment or a card moves, Forge sends a small hint saying what changed, never the content itself. Each person only gets hints about things they're allowed to see.

Forge's web pages refresh themselves from it, and DD-ReForged on the desktop refreshes and shows a notification. Each person also has their own notification list now, with read and unread, and that's what feeds the phone's inbox.

Forge's web pages work on a phone now too: the menu, the boards and the reviews all fit at 360 pixels wide. Forge also fetches every repo it knows about on its own, every 15 minutes, and there's an Open in DD-ReForged button for jumping from a review in the browser straight into the desktop app.

Who sees which repos, done

The rule from the last two posts is finished. A teammate on my Forge only sees the repos their own GitHub account can reach, and the boards, cards and docs that belong to those repos. I also went after the sneaky ways a hidden repo could still give itself away: a name in a list, a parent folder, a path, or even the wording of an error. A member now learns nothing about something hidden from any of those. Before turning it on, I checked that my GitHub token could only read, not write.

DD-ReForged keeps going

Reviews go both ways. Reviews on my PC and on Forge now sync in both directions. DD-ReForged brings in Forge's reviews and keeps them current, and sends back new reviews, threads and decisions made locally.
VS Code. It now sees Forge through the desktop app's sign-in. It also has a Sync down now command and shows the sync state in the status bar.
Safer secrets. The Forge API key moved out of a plain file into the operating system's encrypted store, backups included.
Self-healing. If the background agent crashes, it restarts by itself once the old process is completely gone. A restart I ask for doesn't count against the crash limit.
The tray shows which GitHub account you're signed in as, with its avatar.
Linux. I checked the install on Linux for the first time, with both the .deb and the AppImage in a throwaway Linux setup. It caught a real bug: the app made its profile folder with the wrong permissions and then refused to start. That's fixed.

I also chased down the flaky tests that failed only when the machine was busy, and fixed each one at its cause instead of just giving it more time. My favourite find: one of Forge's web tests had been quietly sending 77 real requests to my actual Forge server every time it ran. The tests can't reach a real server any more.

Builds 0.3.6, 0.3.7 and 0.3.8 each went onto my own PC in place, with a backup first.

Scenes that forget nothing

This is the one that matters most for the game. The rebuild turns big parts of the engine into plugins, and plugins can be turned off. That raised an ugly question. If a scene uses lights from a plugin that isn't loaded, and you open the scene and save it, what happens to the lights?

Until now, the honest answer was that they could vanish. The loader skipped anything it didn't recognise, and saving wrote back only what it had loaded. Nothing was being lost yet, because nothing could be unloaded yet. But it would have been the first thing to bite once plugins arrived, so I fixed it before building any of them.

Now, when the engine finds something in a scene it can't load, it holds on to it exactly as written, keeping its id and its place in the order, and saves it back untouched. Held items show up in the editor, read-only, so you can see they're there. Deleting one asks you to confirm. Lights, emitters, physics settings and avatars all keep their authored values, even if their part of the engine fails to start. An avatar whose model is missing is held instead of dropped. The server carries along anything it doesn't recognise too, and a deletion made while offline still reaches the server and doesn't come back.

To prove it, I built a round-trip test harness: load a scene, save it, load it again, and check that the document comes out the same. That harness found more than one way data could slip through, and each one is fixed.

A few more gaps in scene saving to close before any plugin is allowed to unload. After that, back to the engine itself: either the plugin platform or the export targets.

A team of more than one

2026-10-23T12:00:00.000Z

Yesterday Forge got a front door. Since then I've been getting the rest of the house ready for guests: Forge knows who is on the team, the engine knows who is editing, and DD-ReForged can talk to GitHub without borrowing anyone's token.

Forge has a team

Forge now has a Team page that only Admins and the Super User can see. It lists everyone who can sign in, their role and when they last signed in. If someone needs to go, I can disable them without wiping their history.

Adding someone starts with an invite. I pick a role, Forge gives me a link, and that link works once and expires after a week. Whoever opens it sees who invited them and what the role lets them do, then joins with GitHub or sets a password.

Roles are a grid: one row per permission, one column per role. The built-in ones (admin, dev, member, player) sit next to any I make myself. The Super User has every key and isn't a role at all, so nobody can edit their way into it.

There are service tokens for scripts too. A token is shown once, can be revoked, and can never do more than the person who made it. That's the rule everywhere on this page: you can only hand out what you already have. I found one spot where a change skipped that check, so now every kind of change has its own test for it.

The engine knows who you are

Until now the engine trusted one shared key, the same mistake Forge used to make. Now it accepts a Forge sign-in, both on its regular API and on the live connection the editor uses. A session can only be picked back up by the person who started it. Every edit, version and session records who made it, so when two people bump into each other the editor tells you who, not just "conflict". Settings are per person now, and asset downloads use short-lived tickets tied to one session.

The editor's side is in as well. It signs in and keeps the session fresh in the background. Until the editor learns to use those asset tickets, a signed-in session opens scenes read-only, so you can't make edits the engine would just refuse. Last night the signed-in live connection went in too: if it drops, your edits wait a moment and go through once when it comes back.

None of this is switched on for my own setup yet. That's on me: swap out the default key it shipped with and point the engine at Forge.

I tested all of this hard before it went in, and it paid off. One bug was a password reset code that could be used twice if two requests landed at the same moment. Now using the code and setting the new password happen together in one step, so the second request gets nothing.

Who sees which repos

Yesterday I said a teammate should only ever see the repos their own GitHub account can reach. That now has a plan, and I've made the calls it needed. Teammates won't be able to push, merge or open pull requests through my GitHub token in Forge; they'll do that from DD-ReForged with their own login. Repos show up only for people who are collaborators on them, even public ones, and anything on GitHub that Forge doesn't track stays hidden. Building it starts with a read-only check of the token, before anything can write.

DD-ReForged connects to GitHub itself

DD-ReForged can now connect to GitHub on your own PC through Git Credential Manager, the same sign-in git already uses, or with a pasted token. That turns on GitHub features that were already built but had no way to reach GitHub, including a pull request sweep that had been sitting there unused.

Also new in DD-ReForged:

It can join a Forge from an invite link, and its screens follow what your role on that Forge allows.
VS Code shows who you're signed in to Forge as.
In Wake, clicking a file in a commit opens its diff right there, and the sidebar folds away into a drawer.

Before starting on those, I went through the whole tool against what I want it to do, checking the actual code and not just my task list. What's left on the DD side comes to roughly 80 to 110 hours. It also turned out about 45 tasks were done and just never closed.

Review build 0.3.5 went out tonight in two versions, mine and the team's. The first attempt failed its own smoke test, because the new sign-in check stopped it at the door. I taught the smoke test about the check, and both versions pass now.

A phone app, drawn first

DD-ReForged is getting a phone app for reviewing and merging pull requests and moving cards around. Same rule as the editor: Figma before code. I've drawn nineteen screens in both themes, from sign-in to the inbox, a diff, the merge sheet and the boards, all built from DD's own theme and components.

The interesting part is Personal Forge. It runs on my PC at home, so until it's hosted somewhere the phone can only reach it on the home Wi-Fi. The app is upfront about that: it shows the last thing it read and tells you why.

Repo visibility on Forge, a live event stream from Forge, and the rest of that list. Once that's done, DD-ReForged is in good enough shape that I can get back to the engine.

The shell, the engine and a front door

2026-10-22T12:00:00.000Z

Yesterday the code for the rebuild started. Today three pieces of it came together, and the team got a new build of the git tool.

The shell is built

The frame from the design round is now the real editor: a title bar with the menus, the scene switcher, the mode switch and the transport (play, pause, stop) in the middle, and a command palette on the right. Press the search box and you can run any command the editor or a plugin offers.

The bigger change is how panels dock. The Hierarchy sits in a zone on the left and the Inspector in a zone on the right. Tool windows can dock into a zone as tabs or float, and a bottom zone holds wide panels.

Jobs, the server-side job list, now lives there. When the window gets small the left zone folds into a flyout and the bottom zone shrinks, while the right zone holds on longest. If a panel would not fit anywhere, the editor tells you instead of quietly hiding it. A fresh install opens with the Hierarchy left and the Inspector right, and Reset layout in Settings puts you back there in one click. Splitters work from the keyboard too.

Before any of this was called done, I ran the whole shell against my real scene in the browser, read-only. It passed, and it also found two real bugs: the editor could open on a theme that had been retired, and Space on a focused switch did nothing. Both were fixed the same night.

The desktop editor runs its own engine

The desktop editor used to need a backend started by hand. Now Settings has an Engine section: point it at the engine's folder, press Start, and the editor checks that the folder is the right one, that nothing already answers, and that the database is up, and only then starts the engine as a child process.

I ran it for real, against the real engine and database: about 6.6 seconds from pressing Start to "Running", and about 3 seconds from Stop to "Stopped" with the engine confirming it had flushed its scenes. Quitting the editor takes the engine with it.

There is an option to keep the engine running after the editor quits, and it had a Windows quirk worth a paragraph. A program started from another inherits every inheritable handle its parent holds, not only the three it was meant to get. A kept engine was therefore quietly holding on to the editor's own debugging socket after the editor had gone, so the next launch couldn't use it. The fix is a tiny launcher that starts the engine and passes it only the handful of pipes it needs. After the editor dies, it no longer owns anything.

Forge has a front door

Forge, the git manager, used to trust one shared key, so anyone who reached it was effectively me. That was fine for one person and wrong for a team. Forge now has people.

You can sign in with an email and password, or with GitHub. A new account gets a one-time password that must be changed on first use. Wrong passwords and unknown emails get the same answer, and repeated failures are rate-limited. The card shows when a key is still the shipped default, and refuses to run until it is changed.

GitHub here means identity, not git access. When you sign in, Forge reads your GitHub id and your primary verified email, then throws the token away. It is never stored and never logged. That matches the rule I'm building toward for the team: a teammate should only ever see the repos their own GitHub account can reach, never mine through my token, and nothing of theirs should sit on my server. The sign-in half is done; the repo-visibility half is still ahead.

Desktop apps have no browser cookie, so DD-ReForged and the editor use a device flow. The app asks Forge for a short code and shows it, you open Forge in your browser, type the code and approve.

The code is never put in a link, so a phishing message can't carry it. The page names the app and where the request came from, and the shared key cannot approve a device. Only a signed-in person can.

DD-ReForged 0.3.2, for the team

The review build for the team is 0.3.2, with a matching VS Code extension. It stops Settings saves from restarting the local agent unless a setting the agent actually reads has changed, makes a restart wait up to 30 seconds for a busy agent, and keeps a redacted log per profile. Building it found that the agent change had broken the packaged app in a way the tests hadn't caught, so that was fixed and guarded before it went out.

The repo-visibility rule for the team, then the desktop editor's remaining slices.

The rebuild starts: a desktop app and its first plugin

2026-10-21T12:00:00.000Z

A day after round one of the designs was approved, the code started. Four pieces landed today.

A desktop app

The editor now runs as its own desktop app on Windows, built with Electron, with its own installer. The browser version keeps working alongside it.

The interesting part was closing it. The editor saves your work a moment after each edit, so closing the window has to save the last edit first. The plan assumed that a page closing itself from a script would raise the same "about to close" event as clicking the X. It doesn't. In Electron the window simply goes, with no close event at all. So now every way out (the X, quitting, Windows shutting down) waits up to a second while the last draft is written, and the page saves its own work on the one event that still fires on its way out.

The new title bar

The first slice of the new shell is in: the frame, the title bar with the menus and the transport in the middle, the Forge and Blue themes, and the dock layout underneath. It's checked against the Figma frames screenshot by screenshot. The scene switcher, the modes and command search come in the next slices.

Plugins, for real

The plugin host is in. Plugins can add commands, menu entries, windows and settings pages, and a Plugins manager lists them and turns them on and off. The test plugin above has an unsaved draft, so the manager won't turn it off until that draft is dealt with. That's the close guard from the designs, working.

Jobs, the first plugin

The Jobs window, which follows imports, sprite bakes and exports on the server, is now the first plugin that ships with the editor. Turn it off and its window, its menu entry and its status item all disappear. Turn it back on and it comes back exactly where it was.

Every review found something

Every piece is reviewed before it's merged, and every review found something real. My favourite: the editor used the Space bar for Play and Pause everywhere, so pressing Space on a focused button in any tool window started the simulation instead of pressing the button. Buttons get their Space bar back now.

More of the shell (the activity bar, dock tabs and the command palette), then the rest of the tools move into plugins one at a time. Round three of the designs is drawn and waiting for review.

Round two: play, previews and Frieze

2026-10-21T12:00:00.000Z

Round two of the editor designs was approved today. Round one was the frame and the everyday tools. Round two is everything you do in the editor besides building.

Play mode

Pressing Play switches to a Play layout instead of just setting the viewport running. The inspector becomes a live readout of the selected character: its position and velocity, which behaviour-tree node it's running and what's on its blackboard. Values update live, but edits wait until Stop, so nothing you poke at while playing quietly ends up saved. Dialogue and scripted sequences get their own panel, with Play, Cancel and Replay.

Frieze as a plugin

Frieze, the sprite maker, moves out of a floating window and into a document tab of its own. Models and drawings sit on the left, the live preview and the whole sheet in the middle, and the sheet's settings on the right: cell size, eight directions, palette, rig, animation states, and frame events such as which frames of the walk play a footstep. Batch re-bakes run as server jobs in the panel underneath.

Seeing it on a phone

The game ships to phones and Steam, so the editor will preview it on them: an iPhone, a Galaxy Fold, a Steam Deck or a desktop screen, in portrait or landscape, with the safe area drawn in and the touch controls where a thumb would land. There's even a fake language that makes every string 40% longer, to check the HUD text still fits before a real translation finds out the hard way. A banner says plainly that a preview is an estimate, not a measurement, and a real run on the device is one command away.

And the rest

Round two also covers a 3D dev tools mode for performance work, with a benchmark that flies the demo camera and a warning when a scene goes over a phone's budget. And it has a first run for brand-new world builders: a short setup, a starter level, a tour, and a choice between a simpler World builder layout and the full editor. As the screen puts it: your helpers can each pick their own.

Design first: drawing the new editor

2026-10-20T12:00:00.000Z

The rebuild has started, and the first tool I picked up wasn't a code editor. The new Prometheus editor is being designed in Figma first, approved screen by screen, and only then built. The rule for the whole rebuild: the design comes first, changes go into the design, and then the code changes to match.

The shell

This is the frame everything else plugs into. It's drawn as the desktop app, with a browser version kept alongside.

The title bar holds the menus, a scene switcher, the modes (Build, Play and 3D dev tools), command search, and the Play, Pause, Stop and Delve controls, right up in the title bar where they're always in reach.
The dock zones on the left, right and bottom take tabs, and the middle holds documents, so a scene and the tools I'm using open side by side, like files in a code editor.
The status bar shows the engine connection, whether my changes are saved, notifications, frame stats and the device budget.

A plugin can only add UI through a small set of slots, and every slot on every frame is drawn with its way in: a menu path, an icon, a command or a shortcut. If you can't find a feature, it might as well not exist.

Everyday editing

The everyday loop is select, move, edit, undo, save. Plugins show up where you'd look for them. Here a Lightning plugin adds "Strike from this light" to the right-click menu and its own section to the inspector, with a small badge saying which plugin it came from.

Turning a plugin off

The plugin manager lists what's installed, what each plugin adds and where to find it, what it needs and what needs it. Core plugins are always on.

The interesting part is turning one off. If the Lightning plugin owns three things in the scene, the editor doesn't delete them or pretend they're gone. It holds them, shows them locked and keeps saving them, so turning the plugin back on brings everything back. That's the save that deleted things, designed out from the first sketch.

Round one, approved

Round one is six screens: the shell, scene editing, the plugin manager, settings with a page per plugin, the Jobs panel as the first real plugin, and the project's git tools living inside the editor. Each one is drawn in two themes, Forge and Blue, along with every state it can be in: loading, offline, a plugin failing at start-up, a version conflict while two people edit the same scene, a script with a compile error. I approved them today.

Round two is next: Play mode, 3D dev tools mode, Frieze as a plugin, a first run for brand-new world builders, and previews of the game on a phone and on Steam from inside the editor.

On the calendar

To be honest about time: with a full rewrite in front of it, the first vertical slice now looks more like mid to late 2027 than the end of this year. The roadmap has the details.

A plugin-shaped future

2026-10-18T12:00:00.000Z

The catching-up post ended with development pausing for a rebuild. Here's the thinking behind it.

The problem

Today, adding something to Prometheus means editing the core in a dozen places: the list of entity kinds, the component registry, the inspector, the menus, the tool windows, the frame loop, the save system, the event catalogue, script commands, the exporter and the server's validators. Nothing can be switched off without deleting code, and nothing outside the core can add to the engine.

Plugins, widgets and modes

The rebuild turns each of those places into a socket.

A plugin is a package that adds capabilities: new kinds of entity, components, simulation systems, script commands, importers, server jobs.
A widget is a piece of UI a plugin brings with it: a tool window, an inspector section, a menu item.
A mode is a named bundle of plugins.

Modes are the part I'm most excited about. The same engine could be a game, a simulation or a 3D development tool depending on which mode you load, even one that renders apps or websites in 3D and lets you take them apart.

What stays in the core

Not everything becomes optional. The core keeps what every project needs: scene formats, edits and undo, saving and recovery, and the renderer and simulation lifecycle. The everyday tools, like the hierarchy, inspectors, scene browser and asset browser, ship as built-in plugins that are on by default. Specialist tools become optional plugins: sprite tools, retargeting, behaviour-tree authoring, generation labs, and git and review tools.

The rule it can't break

Unloading a plugin never loses data. A scene that uses a plugin you don't have loaded must still open, save, restore and export with that plugin's data intact, held exactly as it was. It's the save that deleted things, grown up: missing isn't the same as unavailable, so hold, don't drop.

The desktop and beyond

The editor is moving into a desktop app built on Electron, and it will keep running in a browser too. Further out there are two ideas: a faster backend, possibly in Rust, that can still run the TypeScript plugins, and a Figma connection for managing models and their updates. Those are plans, not promises.

The order is: settle the plugin contracts, build a minimal desktop editor, then move the first tool out of the core and into a plugin. After that the rest follow, one at a time.

Catching up: two months of Prometheus

2026-10-18T12:00:00.000Z

Two months and a little over 1,800 commits in, this is where Prometheus stands, with links to the posts that go deeper. It ends with why development is pausing for a rebuild.

Quick reminder of the goal: Prometheus is a custom 2.5D engine with a browser-based editor. The world is fully 3D; the characters and props in it are 2D pixel-art sprites. Everything is being built toward Forgotten Memories, Endless Abyss, an online MMO set in an endless dungeon that reshapes itself around how its players behave. The game itself is still a future milestone. Right now the work is the engine and the tools.

The editor and the server

The editor is a remote session into a backend that owns the simulation. The browser renders locally and trades state snapshots with the server rather than streaming video. In September that hit its first real milestone: two browser tabs editing the same scene at once, with undo carrying across them and nothing lost when a tab refreshes mid-edit. The same simulation package runs on the server in the editor and locally in an exported game, so what you test is what ships. More in The server owns the world.

On top of that there's now most of what you'd expect from a scene editor: a hierarchy and inspector, a four-pane quad view, lights and shadows, materials, post-processing, particle effects (campfires with flames, smoke and embers, wall torches, lightning), Rapier physics, and camera rails for fly-throughs. Scenes keep a version history you can preview and roll back, and the editor recovers unsaved edits after a crash.

Every feature that lands also goes into one showcase scene, Re-Forged, which has a guided tour that walks through the engine feature by feature. It's the scene in the screenshot above, and it's how I check that new work actually reaches the screen and doesn't just pass its tests.

Frieze: from 3D models to pixel sprites

Every sprite in the game starts life as a real 3D model. Frieze imports the model, borrows animation clips from a shared library and retargets them to the model's rig, then captures it from several angles and bakes the result into pixel-art sprite sheets. It has its own palettes, a pixel editor for touch-ups, and batch re-baking when a source changes. More in Frieze: pixel art from 3D models.

The sprites also bake a normal map, so a flat sprite catches light from the 3D scene around it: a torch on its left lights its left side. The whole route, from importing a model to baking it, publishing it and placing it in a scene, is now one workflow with a readable report at each step.

Walking around: Delve

Delve is the first mode where you actually walk around: a third-person camera at a 35° tilt following a sprite character, with the billboards turning to face the camera and switching animation frames as they move. The first stress test put fifty animated billboards in a scene and held a mean of 12.7 ms per frame on my desktop. That's a dev machine, not a phone, so it's a baseline, not a verdict. More in First steps in Delve.

The gameplay foundation

None of this is gameplay yet, but most of what gameplay will stand on now exists (more in Teaching sprites to think):

Input: keyboard, mouse and gamepad, with rebinding.
UI: widgets and HUD panels with anchoring, focus and keyboard/gamepad navigation.
Scripting: script files edited in your own editor and watched from disk, with type checking, readable errors and shared scripts.
AI: behaviour trees with a shared blackboard, sensing and perception, navigation, and crowds that send a couple of hundred agents to one goal along a shared flow field.
Systems: physics queries and collision layers, an event bus, a game clock, sprite animation states, dialogue, localisation, entity pooling and a component model.

Built for phones

The game is aimed at mobile, so the editor measures every scene against a device budget: triangles, draw calls, texture memory, sprite sheets and entity counts, each checked against mobile, browser and desktop limits. The world is split into regions that load and unload around the camera, so distant areas give their memory back and come back intact when you return. A scene can also be exported as a static build that runs with no backend at all. More, including the first numbers from real phones, in Will it run on a phone?

What's next: a pause to rebuild

Two decisions have changed the plan. The editor is moving into a desktop app built on Electron, and the platform is becoming plugin-based, so features plug into a core rather than being built into it. Together those mean a full rewrite. So development is on pause while I rework: new designs in Figma, and the platform redesigned from the plugin perspective from the ground up. More in A plugin-shaped future.

The engine work is more or less done. What it needs now is more thought about how to make the rest of the game a reality on top of it. The biggest piece of that thinking is the living world. The dungeon won't be a complete map hidden under fog; ground that nobody has reached doesn't exist yet. Terrain is generated as players, and monsters, actually travel into it. A monster wandering off on its own extends the world along the path it walks, without revealing that ground to anyone. What each player has discovered stays private to them, while the terrain itself is shared by everyone. More in A world that isn't there yet.

Three stores, one launch

Beyond the editor, the game still needs a mobile version for the App Store and Google Play, and a Steam version for PC. All three will release at the same time. That's a substantial undertaking for a solo developer.

Not entirely solo

My teenagers are studying engineering and will, I hope, help me design and build the game world. A few friends are taking on the music and ambience, playing the first vertical slice as they write for it. That slice is the next real milestone: maybe later this year, maybe early 2027, we'll have something to show for all the hard work. There's a lot to do until then, so stand by.

The tools behind the tools

2026-10-17T12:00:00.000Z

Prometheus has a sibling: Forge, a set of project tools that lives in the same repository and runs beside the editor. It started life as tools I'd built for earlier projects, got ported in under new names, and has grown since.

What's in it

The names follow the rule from the start of the project: tools that build the game get fire and forging names, and systems inside the game get abyss and memory names.

Anvil handles repositories, branches, git operations, code review and pull requests.
Ember is Anvil's commit graph.
Bench has the boards and cards, a burndown chart and a roadmap.
Kiln is the documentation library. Every project document is versioned and has a review queue: propose a change, approve it or send it back, and the approved version is written to disk.

The file is the truth

Work is tracked as plain Markdown files, one per issue, numbered, with a status line at the top. The board cards are a mirror of those files, not the other way round. As of this week the mirroring is automatic: change a file and its card updates within seconds, and Forge syncs everything once when it starts.

Why files? Because they live in git with the code. An issue's history sits next to the commits that closed it, nothing is locked inside a database, and the whole plan for the game is something I can search.

Stocking the shelves

2026-10-10T12:00:00.000Z

A sprite generator is only as good as what you feed it, so this week went into the pantry.

Animations

About 2,400 animation files, sorted by what they do (locomotion, idles, gestures, unarmed combat and so on) and by which skeleton they were made for. Clips made for one skeleton don't fit another without retargeting, so that sorting matters more than it sounds. A search finds what you need. "Zombie" turns up 44 files, which is more zombie than I expected to own.

Every original file is fingerprinted, so I can prove nothing has been changed or lost. Twelve exact duplicates are kept on purpose. I've learned not to delete things on a hunch.

Models

For the world itself: 409 models from two of Kenney's free CC0 packs, the Nature Kit with 329 models and the Survival Kit with 80. Trees, rocks, cliffs, fences, logs and barrels.

They're split into 13 import batches by category, at most 80 to a folder, each with its licence and source kept alongside. Next stop for them is Frieze, to come out the other side as pixel-art sprites. Thanks to Kenney for making these free for everyone.

Will it run on a phone?

2026-10-09T12:00:00.000Z

The game is meant for phones first, so this week was about finding out how far the engine is from that, with real numbers instead of hopes.

A budget you can see

The editor now measures a scene against a device budget (triangles, draw calls, texture memory, sprite sheets and entity counts) with separate limits for mobile, browser and desktop. The first time I pointed it at the showcase scene, it said texture memory was 78% over the mobile budget.

That turned out to be the meter: it was counting shared textures more than once. Counted properly, the scene was under budget all along. Phones still shouldn't download desktop-sized textures, though, so a new asset pipeline publishes a separate version of each texture per device, with phone textures capped at 512 pixels. On the showcase scene that takes texture memory from 131.9 MiB to 83.9 MiB on mobile, well inside the 192 MB budget.

Draw calls are the open problem. The showcase scene makes 178 of them, and the mobile limit is 100.

Streaming the world in

The world is split into regions. As the camera moves, nearby regions stay loaded, the next ones wait warm, and distant ones give back their memory, then come back intact when you return.

Exporting a game

A scene can now be exported as a static build: plain files that run in a browser with no server behind them, with the simulation running on the device. That's the shape a shipped game will take.

Real phones

Then the real test. A profiling page runs a fixed workload on the phone itself and records the results. I ran it on a Galaxy Z Fold7, folded and unfolded, and on an iPhone 14 Pro, against a hall of about 60 sprites.

The median frame came in right on 60 fps on the Fold7 (16.6 to 16.7 ms) and a little slower on the iPhone (19 to 21 ms). The slowest frames ran past the 60 fps budget on both. Treat these as early samples rather than benchmarks, but the verdict is clear enough: close, not there yet, and now it's something I can measure instead of guess.

Teaching sprites to think

2026-10-06T12:00:00.000Z

The last few weeks went into the systems game logic will be written on. The last pieces of a first set landed today, so here's a tour.

Scripts are files

Game scripts are ordinary files, so I write them in VS Code instead of a text box in the editor. With file watching on, saving in VS Code reloads the script in the running editor. Scripts are type-checked, errors show up where I can see them, and a script that throws no longer drags the frame down with it.

Behaviour trees

Characters run behaviour trees: small graphs of decisions like "if you can see the player, approach; otherwise wander". Trees share a blackboard, a set of named values characters can read and write, which is how two characters can hold a conversation or a group can coordinate.

Seeing and hearing

A character can have a view cone, a hearing range and a memory, and its behaviour tree reads them. In the editor I can show the cone and the hearing ring and tune them live.

Getting around, together

Characters find routes across the navigation grid. Crowds go one better. When many characters head for the same goal, the engine builds one flow field, a grid of arrows pointing the way, and they all read it instead of each searching for its own route. In a test with 200 characters heading for one goal, that meant zero route searches per second and at most one field build.

Talking

There's a dialogue system too: lines, choices and branches, with the camera able to move to whoever is speaking. The first test conversation in the showcase scene goes: "You found the stairs. Most people forget them." Choose "I remember." and the reply is "Then the abyss remembers you too."

And the rest

Gamepads and rebindable controls, UI widgets and HUD panels, an event bus, a game clock, localisation, collision layers, physics queries for AI, and entity pooling so a burst of spawns doesn't stall a frame. None of it is a game yet. It's the toolbox the game will be built with.

A guided tour of every feature

2026-10-05T12:00:00.000Z

Every feature that lands goes into one showcase scene, Re-Forged. By this month it had become a pile: lights, particles, sprites, widgets and physics props all fighting over the same patch of floor. So I rebuilt it as a tour.

Ten stations

It's now a hall 40 metres wide and 140 long, with numbered stations down its length, each with a sign: a welcome, then sprites and paths, behaviour trees, scripting, physics, lighting, particles, UI widgets, shared simulation, and a wall of materials. A saved camera flight weaves between them, so the whole tour plays as a fly-through.

The dry run caught three mistakes

I didn't build the new layout straight into the saved scene. A script built the proposed version as a private copy, flew a camera to each station and took a picture, without saving anything. Those pictures caught three problems:

Invisible signs. They stood outside the camera's view from the walking line, so nobody would ever have read them. They moved five metres in.
A moonlit wall. The three spotlights on the brick wall were 30 candela each, eight metres away. That works out to roughly the light of two full moons. Atmospheric, but not what a showcase wall needs. They went up to 140.
A distracted camera. The fly-through was pointing at the wrong places, and now looks at the stations.

At the physics station the spawner dropped four balls while the scene played, and none were left after Stop, so stopping really does put the world back. Then the layout was saved, and the same camera run against the saved scene gave the same pictures.

A world that isn't there yet

2026-09-22T12:00:00.000Z

This week I pinned down one of the most important rules of the game world, and it changes what the engine has to do.

Ground that nobody has reached does not exist. It isn't hidden or fogged over; it hasn't been generated. The dungeon is endless, so it gets built as it's explored.

Monsters explore too

Monsters don't idle in rooms waiting for a player to show up. They wander, head home, follow routes, and keep doing it when no player is anywhere near. When a monster walks toward the edge of the known world, terrain is generated for its path, and only its path. It learns the ground it has actually walked, not a circle of everything around it, and none of that reveals anything to players.

Terrain is shared: once it exists, it exists for everyone. Maps aren't. What each player has discovered is theirs alone by default.

The rules that hold it together

A few engine rules fall out of that:

Nothing walks on nothing. Before any actor, player or monster, moves into new ground, that ground is generated and committed, with its collision and navigation. Nobody crosses a blank region, a guessed bridge or a floor that doesn't exist yet.
First come, first fixed. Once ground exists, it stays. Otherwise a monster could head home to its den and find a lake there, because a player's arrival had regenerated the area. A player who turns up later finds the same trails, dens and residents the monster left.
Budgets. An endlessly wandering monster could otherwise generate an endless world with nobody in it. Generation distance, active populations and simulation time all have limits, and when one runs out a monster waits at the edge rather than inventing ground.
Reproducible from history. A seed alone can't rebuild a world shaped by what happened in it, so the engine keeps the seed, the generator version, the behaviour that shaped the world and everything that was committed.
Not flat. Hills, valleys, cliffs, gaps and water. One spot on the map can hold a bridge above a cave, so a single height per point isn't enough.

Where it starts

None of this is gameplay yet. These are engine requirements, and the first building block arrived the same day: navigation. The editor can now bake a grid that says where an agent of a given size fits, and find a route across it.

Today that works on flat floors in scenes I've built by hand. Terrain that generates itself as monsters walk into it is the long road from here.

First steps in Delve

2026-09-18T12:00:00.000Z

Until this week, Prometheus was something you looked at. Now you can walk around in it.

Delve is the engine's first walking mode. A third-person camera tilted at 35° follows a sprite character, and every billboard in the scene turns to face the camera, picking the right direction and animation frame as it moves. It runs inside the editor, so I can step into a scene I'm building, walk around it, and step back out to carry on editing.

Input that isn't tied to a keyboard

Delve brought the input system with it. Game code never asks "is W pressed?". It asks for actions like move and turn, and whatever the player is holding supplies them. On a keyboard that's the usual keys. On a touchscreen a virtual stick appears bottom-left, with turn buttons on the right:

Hide the editor around it and what's left is what a player would see:

How heavy is a crowd of sprites?

Every billboard has to be turned, framed and positioned every frame, so I measured that early. Fifty animated billboards held a mean of 12.7 ms per frame on my desktop while I walked around them, about 79 frames a second. That's a development machine, not a phone, so it's a baseline to measure later work against rather than a verdict.

Frieze: pixel art from 3D models

2026-09-15T12:00:00.000Z

Every character and prop in Prometheus is a 2D pixel-art sprite standing in a 3D world. Drawing all of those by hand, from eight directions, for every animation, isn't something a solo developer can do. So the engine makes them. The tool is called Frieze.

Models in, sprite sheets out

Frieze takes a 3D model, poses it with animation clips, captures it from several angles and bakes each frame into pixel art at a fixed size, then packs the frames into a sprite sheet. Clips can come with the model or be borrowed from a shared library and retargeted to the model's skeleton, so one walk cycle can serve many characters.

It also works from 2D art. A drawing can be given joints and animated with the same library clips. For testing that I used a free character turnaround from OpenGameArt:

Palettes

A sheet can be indexed, so each colour belongs to a palette slot. Change a slot and the character changes colour everywhere it appears, with no new bake. The green-trousered character here is the same artwork as the blue one, with four of its thirteen palette slots changed:

Touching up by hand

Automatic isn't always right, so Frieze has a pixel editor built in, with onion skinning across frames. A bad frame can be fixed in place without leaving the tool or re-baking the sheet.

Sprites that catch the light

Each bake also produces a normal map, so a flat sprite reacts to the 3D lights around it: a campfire on its left lights its left side.

That led to my favourite bug so far. Seen from behind at a low angle, a character's shoes glowed white-hot, as if lit from inside:

The cause was in the sprite material. A tweak that softens how light wraps around a sprite was also being applied to its reflections, and at grazing angles that amplified the reflection enormously, even on a completely rough surface. Limiting the softening to diffuse light fixed it:

The server owns the world

2026-09-12T12:00:00.000Z

The editor passed its first real milestone today, so it's a good moment to explain the decision underneath it.

Two ways to put a game in a browser

The Prometheus editor runs in a web browser, but the scene lives on a server. There were two ways to build that.

Pixel streaming renders every frame on the server and streams video to the browser, the way cloud gaming does; the browser is a remote monitor. That costs a GPU video encoder per viewer, tens of megabits a second, text and thin lines softened by video compression, and input lag on every click.

State streaming keeps the renderer in the browser. The server runs the authoritative simulation (physics, behaviour, game rules) and sends compact updates about what changed; the browser draws them locally and sends edits back. The research I did put that at a few hundred times less bandwidth than video, with no server GPU per viewer and a UI that responds at local speed.

Prometheus streams state.

One simulation, two homes

The simulation is a standalone TypeScript package with no browser or server dependencies. In the editor it runs on the server, which is the authority. In a shipped game there's no editor server, so the same package runs on the player's device.

Writing it once and hosting it twice is why the backend is TypeScript rather than something like Rust: the code that ships to players is the code I test in the editor.

The milestone

Today two fresh browser tabs edited the same scene on the server at once. One tab was refreshed mid-edit and lost nothing, and undo worked across both tabs. Then I pressed Play in one tab and watched the simulation from the other, through a full stop and restart of the backend.

It doesn't look like much in a screenshot, but everything else stands on it: the editor is a window onto a world the server owns, and that world survives the window closing.

A scene for every feature

Every feature also goes into one scene, Re-Forged, so new work can be seen rather than read about. This is how it looked in its first week: a handful of lights, shiny materials, particle fire and smoke, and a camera rail for fly-throughs. It will grow with everything that lands.

Six times faster type checking

2026-09-11T12:00:00.000Z

Prometheus is TypeScript across three workspaces: the editor, the engine backend and Forge, my project tools. Type checking the lot took about 19 seconds. Today I switched to TypeScript 7, the native rewrite of the compiler, and it takes under 7.

What	TypeScript 5.9	TypeScript 7	Faster
The editor, whole program	6.6 s	0.84 s	7.9×
All three workspaces, compiler only	15.8 s	2.5 s	6.3×
All three workspaces, full typecheck scripts	19.3 s	6.6 s	2.9×

The full-script number improves less because some of that time isn't the compiler at all, like building the shared libraries first.

Two catches

No language service. TypeScript 7 doesn't ship tsserver, the part a code editor talks to for autocomplete and red squiggles. Upgrading in place would have quietly broken my editor. So the new compiler is installed under an alias beside the old one: TypeScript 7 does the checking and building, and 5.9 keeps the code editor happy.

Two programs, one name. Both versions install a command called tsc, and whichever installs last wins. Installing the alias really did repoint tsc at the new compiler; I checked rather than assumed. So no script in the project says a bare tsc any more. Every one names its compiler by its full path.

The save that deleted things

2026-09-10T12:00:00.000Z

This week I found four bugs that could permanently lose work. They looked unrelated. They turned out to be the same bug wearing four hats.

Four ways to lose a scene

A save that quietly dropped the scene's camera fly-through.
A loader that gave up waiting a moment too early on a cold start, and threw away every rail that objects were riding along.
An auto-save guard that pressing Pause switched off, so a running simulation, mid-tumble, could be saved over the scene you'd actually built.
An object whose model couldn't be found was skipped when the scene loaded, and the next auto-save, sixty seconds later, wrote the scene without it. Opening a scene while the backend was restarting was enough. No edit required.

The shape

Every one went the same way. Something failed to load, for a reason that wasn't its own fault: the server was restarting, a cache was cold, a load was still in flight. So it never made it into the live scene. Then a save came along, looked at the live scene, and wrote down what it saw.

To a save, something that failed to load looks exactly like something you deleted on purpose. Nothing complains on either side. The load logs a warning and carries on, and the save looks perfectly normal. You find out when the thing is gone.

Three rules

Missing isn't the same as unavailable. "This doesn't exist" and "I couldn't reach it just now" are different answers, and only the first is allowed to remove anything. A comment in the code puts it best: collapsing the two is what let "a backend that was merely restarting look like a mass deletion."
Hold, don't drop. If something can't be loaded, keep its saved record and write it back out unchanged. It's missing from the screen, which is honest. It isn't missing from the file.
Teach the guard you already have. There was already a check that stops a half-loaded scene being saved over a full one. Teaching it about these cases beat bolting a second guard on beside it.

All four bugs are fixed. The rules stay: anything new that saves data gets asked what the next save writes when its load goes wrong.

The game behind the engine

2026-09-04T12:00:00.000Z

Before the engine posts start, here's what all of it is for.

Forgotten Memories, Endless Abyss is an online MMO built around one shared goal: dive as deep and as far as possible. Humanity has found a dungeon that seems to have no bottom. It's so vast that towns have sprung up just to keep adventurers supplied, and everyone is chasing the same questions. Does it end? Why does it exist? Is there a story beneath it all?

The name has some history. Forgotten Memories was a game idea of mine from college, and it still has a Steam page from back then. Once there's a game to talk about, that page will be carrying this one.

A dungeon that reads its players

The dungeon isn't just procedurally generated; it's behaviourally generated. It watches what its players do, in aggregate, and reshapes its landscapes, difficulty and monsters to match. Every layer sits somewhere between order and anarchy.

Order comes from cooperation, guild work and players policing each other. Monster pressure eases, towns grow, and blighted ground heals into livable land.
Anarchy comes from player-killing and hostility. Spawns get nastier, the terrain degrades toward a hellscape, and town defences can be overrun.

Anarchy spreads like a sickness: one pocket, then many, then faster and faster. A layer that flips blocks fast travel through it and creeps back up toward the shallower layers, so griefing on a deep floor becomes everyone's emergency. Nothing is permanently solved. A paradise left alone can fall again.

You can't die, but you can forget

There's no permadeath. Every revival costs you something instead: fragments of memory. Abilities you've earned can weaken with each revival until they're gone, becoming Forgotten Memories. You feel yourself slipping before anything is lost outright.

The way to get them back is to go deeper. Clearing the dungeon and discovering new layers recovers what death took, so loss pushes you forward rather than back toward safety. That's the title: the endless abyss is the dungeon, and Forgotten Memories are what it costs you, and what it repays.

Holding the line

Roughly every ten layers a raid boss blocks the way. Beat it and travel to that depth unlocks for everyone. But bosses come back. As one nears its return, monsters surge until the layer breaks out in a stampede, and an ignored break loses that layer, then the ones above it, one by one. The frontier and the homeland are the same responsibility.

Towns need supplying too. Players haul materials to keep them running, and an under-supplied town dries up and loses its services. Guilds form around defence, expansion, exploration or policing, and a big enough guild can hold a layer, for a while.

There's more under the surface than this, and some of it is meant to be discovered by players rather than read in a devlog, so I'll leave it there.

Why build an engine for it

A world like this needs things an off-the-shelf engine doesn't hand you: a server that owns the simulation for everyone, the same simulation running on the player's device in a shipped game, and a pipeline that turns 3D models into the pixel-art sprites that live in its 3D dungeon. It also has to run well on phones.

So I'm building Prometheus, a custom 2.5D engine and editor on an all-open-source stack with no vendor royalties. The next posts are about that.

Reforged from the ashes

2026-07-20T12:00:00.000Z

Prometheus didn't start from nothing. It started from the ashes of something else.

For about a year before this, a friend and I built an avatar project: animated 3D characters in the browser, with an editor for building the scenes they lived in. He did a lot of the animation system and a good share of the engine work. As a product it didn't work out, but a lot of what we built was good.

So rather than throw it away, I went through it for anything worth saving, and there was plenty: the entity system, the editor's interface, the renderer and the animation work. The parts that no longer fit, like the chat layer that let the avatars talk back, were cut out. What was left is the starting point for something new.

A new shape

The old project ran everything in the browser. The new one splits it in two: a server owns the world and runs the simulation, and the browser becomes a window onto it, using the editor and renderer we already had. The game all this is for is an MMO, so the server has to be in charge anyway.

Why the fire names

Everything rebuilt on top of the old project is named for fire and forging:

Prometheus, who stole fire for humanity, is the engine.
Forge is the project tools, with Anvil, Ember, Bench and Kiln inside it.
Re-Forged is the showcase scene, where every rebuilt feature goes to prove it works.

The old project was melted down, and this is what gets hammered out of it.

From here on it's just me. I'm grateful for the year of work that got it this far. This is where the devlog picks up.