A game engine with its own IDE, a sprite editor, a shader graph and hot reload — all in Delphi, all in a few days. This post is about the engine, but even more about what makes such speed possible: frameworks, a backend of cooperating MCP servers, and a plan database that never forgets.
Meet ISOlDE — a Game Engine Written in Delphi
On 25 September 2026 I started a new repository. On 28 September, version 0.5.0 of ISOlDE was there: an isometric 2.5D game engine with its own IDE, both written entirely in Delphi. Direct3D 11 renderer, sprites with per-pixel depth images for the terrain, meshes with GPU skinning for characters and objects, dynamic light with a time of day, weather, fire, smoke, water and fog. And the game code itself is Delphi: the IDE compiles it into a DLL and swaps it into the running game every time I press save.
The whole thing is not built on a foreign engine and not on a foreign scripting language. It stands on frameworks I have developed over the years, and that is exactly why it could grow so fast.
The Foundation: FDK, #D.MVVM and the FMX Code Editor
- FDK — my Delphi framework with well over 100 units. It carries everything an application needs below the user interface, and the engine and the IDE both use it. More on the FDK.
- #D.MVVM — the MVVM framework for Delphi. The IDE with its docking windows, panels and plugins is built on it, so every tool window has a clean view model that can be tested without a user interface. The story of D.MVVM.
- FMX code editor — my own FireMonkey implementation of a source code editor in the style of SynEdit. The game code is edited right inside ISOlDE, and a press on save triggers compile and hot reload.
- FMX ribbon controls — the ribbon of the IDE, including tabs and customisable key bindings (Delphi, CUA or empty preset).
Four building blocks, and every one of them already existed. An agent that gets a clear, well-tested framework does not have to invent a user interface layer, a docking system or an editor first. It uses them — and produces code that fits.
The Real Secret: 33 MCP Servers That Work Together
Several Claude instances worked on ISOlDE at the same time. That is only possible because of my backend server concept: today, 33 MCP servers interact with each other through one central backend. A proxy in front of it hands every agent exactly the tools it needs — compiler, source index, tests, search, Word, mail, Blogger, ffmpeg, and so on. Agents find each other, ask each other questions, wake each other up, and lock a unit when they are about to change it, so two of them never write into the same file.
Compiling does not happen through a hand-typed command line but through DelphiMCP; searching a code base of several hundred thousand lines goes through an index instead of a blind grep. This is the part that turns "an AI that types code" into "a team of agents that delivers". The modules are available as Delphi source code — see the MCP page.
I don't think I need to mention this specifically, do I? Of course, the game engine has its own MCP server so that agents can start working with it right away and create games with minimal effort. Many years ago, I programmed a Pac-Man* clone in FMX and had already fully implemented the game logic here. Claude rewrote the game in no time using the built-in MCP server in the backend.
PlanMCP: Organisation in a Database, Not in Markdown Files
Most agent setups keep their plans in Markdown files that someone has to maintain, merge and re-read. Mine does not. PlanMCP stores tasks, features, decisions, and handovers in a MySQL server. Any agent can ask: What is open? What is blocked? What did the last session hand over? When I clear a session, the next one picks up exactly where the last one ended — with an append-only history, not with a text file that may be out of date.
For ISOlDE this meant 166 tracked features, each with a status, and a plan that all agents see in the same state at the same moment. With several agents working in parallel, that is not a nice-to-have. It is the difference between coordination and chaos.
A PAServer for Games: IDE in the VM, Game on the GPU
I work inside a VMware virtual machine, and a VM has no real GPU. A game engine needs one. So I took the idea behind Delphi's PAServer and applied it to games: the IDE runs in the VM, and a small runner runs on the Windows host, where the RTX 5090 sits. The runner listens in the local network and authenticates the IDE with a shared token. It idles without a Direct3D device and only starts rendering when it is told to run.
- F9 builds and starts the game locally for debugging.
- Shift+F9 builds the release, deploys it from the VM to the host (about 117–128 MB/s over the LAN), loads the game DLL and hot-reloads it — while the game keeps running.
- The IDE even brings the host runner up to date by itself, and a health call reports its build and protocol version.
- A command-line tool,
IsoCtl, offers the same commands to scripts and agents: run, stop, stats, capture, deploy, update.
The result: the comfort of working in a VM and the speed of real hardware. On the host, a borderless 4K window with one million sprites runs at about 550 fps, and the volcano island scene at over 1,000 fps.
Screenshots and 4K/60 Demo Videos, Straight From the GPU
A game engine needs pictures. IsoCtl capture fetches the current frame from the host in full resolution (4K included), so agents and I always look at the real GPU image, not at a screen grab of the VM.
For videos, the runner records itself, and it does so properly. No screen capture, no wall clock: a fixed time step of 1/fps, vsync off, and every single frame is read directly from the GPU interface and handed to ffmpeg — with hardware encoding (NVENC for h264, hevc or av1) or libx264. The result is a demo video in 4K at 60 fps (the frame rate can be set from 1 to 240), rendered faster than it plays back.
The ffmpeg part is, of course, one more server in the backend: an ffmpeg MCP server installed on the GPU machine itself. That is where the frames are, so nothing has to travel over the network before it is encoded. An agent can record a scene, cut it and post-process it with a few commands, instead of me spending an evening with a screen recorder.
What Happened, Day by Day
| Day | Revisions | Result |
|---|---|---|
| 25.09. (start) | 20 | New repository, resources imported, runner without Direct2D, monitor selection, full screen |
| 26.09. (day 1) | 35 | IDE with docking, game DLL with hot reload, content store, scene designer with undo, FBX characters with GPU skinning |
| 27.09. (day 2) | 108 | Shader graph with HLSL generation, flowing water and lava, sprite import, FBX models in scenes, plugin API, sprite editor as a plugin |
| 28.09. (day 3) | 113 | Plugin host, sprite editor as a standalone application, depth images for sprites, dynamic light with time of day, version 0.5.0 |
276 revisions in four calendar days. On the last day, the volcano island demo already had wind-blown grass, bridges, flowing lava and smoke — once the tools exist, building a scene with them is the fun part.
Why It Goes This Fast
- Parallel agents with a fixed contract. Each agent has its own files and a precisely described interface. The merge commits in the history show that several of them really were working at the same time.
- Test first, then the core. Calculation kernels get their unit tests before the implementation, which gives the agent a solid feedback loop.
- Experience that steers. 45 years of development decide the architecture, the order and the acceptance. The agents do the typing, the porting and the research across many files — and this is where the hours disappear.
- Looking at the result. A short look at the screen finds what no test catches. An animated fox that kept rendering in the editor, a splash screen that waited too long — found, fixed, and turned into a rule or a test.
FBX to 2.5D Sprites, Sprite Editor and Mesh Editor
FBX import: my own FBX importer reads static models as well as animated characters. Whole model kits (Kenney, CC0) stand in the isometric scene as real 3D objects, lit together with the 2.5D sprite world, and an animated fox runs with GPU skinning of up to 256 bones. And the importer is also the way into the 2.5D world: FBX models are baked into 2.5D sprites with depth image and normals. That is how the bridges on the volcano island were made — a 3D model goes in, a sprite that sorts and lights correctly in the isometric scene comes out. Because every sprite carries its depth and normal channels, flat 2.5D sprites and real 3D meshes can live side by side in the same scene.
The sprite editor is a result of those first days: it paints in isometric planes, supports surfaces with normals for dynamic light, patterns, layers and directions, and it runs either as an IDE plugin or as a standalone SpriteEditor.exe. Shader effects such as torches, geysers and lava can be baked into looping sprite sheets.
The mesh editor followed shortly after on the same plugin API, and it bakes depth images from points and meshes into sprites. A nice proof that a clean plugin interface pays off — a new tool is a plugin away.
A tip from daily practice: the AI verifies against what it can see. When the mesh editor was checked through the CPU drawing path while I looked at the GPU view, we found and fixed a silent fallback on window resize — and now the screenshot function captures the real GPU views. Give the agent the same view the human has.
A Local Assistant for the Tedious Part
Not every job needs the biggest model. ISOlDE has a local agent panel running qwen3.8 on my own hardware. It takes over bulk work: assessing an imported tile set, suggesting roles and semantics, generating maps. Assigning roles to tiles worked 12 of 12 times; for edges and orientation geometry, code takes over, because code simply measures better than a model estimates. A larger model is used only for acceptance. Local model for volume, code for what can be calculated, big model for judgement.
ISOlDE Today
| Measure | Value (22.10.2026, four weeks in) |
|---|---|
| Revisions | 1,333 |
| Delphi source files | 847 files, about 622,000 lines |
| DUnitX tests | 3,574, all green, no leaks |
| Shader graph | roughly 300 nodes |
| Frame rate | over 2,000 fps on an RTX 5090 without optimisation (target: 400 fps as reserve) |
What an Experienced Developer Can Achieve in Three Days
A lot. A running game engine with IDE, editors, FBX-to-sprite import, a host runner on the GPU, hot reload, and 4K/60 demo videos — because the pieces fit together: FDK and #D.MVVM as the foundation, the FMX editor and ribbon as the building blocks, 33 MCP servers as the workshop, and PlanMCP as the memory that keeps the whole team on the same page.
Delphi plus AI does not mean writing less. It means being able to build much more — as long as the framework and the infrastructure around the agents are right.
ISOlDE is in active development. Screenshots, the feature list, and a trial are on delphiprofi.de/isolde, and the frameworks and MCP modules behind it are on delphiprofi.de.
Note on the Use of AI: This article was created with the "assistance" of generative AI. The content, technical statements, and conclusions have been reviewed and revised by the author. The author bears full responsibility for the publication.
No comments:
Post a Comment