Built in codemode is rather nice. Its the feature i like the most from OMP which is Pi + lots of plugins.
1,160 karma · joined December 17, 2020
We found this massively outperforms any kind of agent like this and the official unreal MCP systems. Its similar to the Blender MCP which also just exposes scripting + very minimal api to claude code/others.
This is a field that changes significantly every few months, so using 1 year old models essentially invalidates the entire report, as they are 2 model generations behind and the newer generation models are heavily RL-d around their harness. For example they put a lot of emphasis on context management but that kind of context management isnt done anymore because many models now have 250k or 1M context and inferencing the models heavily rewards cache hits so you should never touch the context until you decide to compact. They comment on plan mode, which is something that Claude decided to remove from their client because they dont consider it needed at all anymore.
Opengl meanwhile is significantly easier, and will give them the important terminology and math required to do graphics. Once the student has learned opengl and wrote a small renderer with a few basic techniques, moving to vulkan or DX12 will happen far more smoothly.
In particular, learnopengl explains a lot of basics like transformation coordinates, what a mesh is, and other similar "basic knowledge", while all vulkan and dx12 tutorials skip through that because they are meant for a much more experienced audience.
So, for example, i ported stb_image from C to Jai (you can think of Jai as similar to Zig, another c-style lang).
To do that, i built my own agent scheduling/swarm system, because there is nothing out there that works, its all slop. First i used normal claudecode and the likes to build a set of translation rules, documentation about the project, and set up the context for all. Then the first stage of the swarm was to use claude to split the 7000 line library into chunks of about 500 lines each, a few functions/structs at a time. Then each deepseek bot had a task of translating that snippet of code from C to Jai. Next, i had a system merge it all back together. This was done with just a single claudecode running over time. It had to be agentic and not a script because the bots often would duplicate definitions and things like that.
Then, i had a system where it would try to compile the project, get an error list, parse the error list, and split that error list across multiple fixer agents.
Doing multiple fixers because Jai can give you a large error list across a bunch of functions, so this speeds it up. If your project rules/setup/etc is better you can improve this step to have less errors to begin with. The more tools you can have to prevent errors instantly on a feedback loop of each sub-task, the better it goes.
After the fixer step, the code was ported, but with some mistakes. I ran a wide pass of having 2 agents look at each struct/function, and validate if the translation was done well. 2 of them because if both agree the function is fine, the function probably is actually fine.
Next, i began iterating the test suite. The library had a decent enough test suite, so splitting the work between testing + fixing tests across the different parts of the library was doable. for example i would run fixes on png format and jpeg format at once couse their code doesnt overlap.
After the tests were 100% green, the next stage was to implement a literal exploit finding swarm to fuzz it all, which actually found a couple errors on the original library and found a bunch of more obscure bugs in the port.
After that, now i have my own version of this image loading library, more hardened than the original, on a pet lenguage i wanted to do it for.
Here is the result https://github.com/vblanco20-1/stb_image_jai
Note that the better the AI you have, the less error the process has, and the larger chunking you can use. Mythos can likely do this same port much easier, but deepseek flash did it in about 3 bucks of tokens including the trial runs and experiments.
I later use this tooling to build a translator agent swarm for my videogame that can do english to anything translation for 7000 strings that can be menu buttons, tooltips, small fluff text, and others.
That article is paid for by the lobbysts and completely incorrect and wrong.
I did port stb_image from C to Jai which i was able to fully verify and harden and that one ill give more use. Im also using the same workflow system to perform agentic translation of a game i work with from english to various other languages, the results are far better than the commercial "human" translation services we tested. And i also use it to fix OCR issues on PDF books im ocr-ing for a data pipeline. This kind of workflow/wide agent swarm system is rather useful for many things where you want to "apply" the same prompts across a whole codebase or just in parallel.
I did find it uses tokens like crazy, i migrated Pixel Dungeon (java) to C# as a experiment, and it used almost 2 billion tokens. It was just 20 bucks due to deepseek flash, but i shudder thinking of how much money this uses when run on the real claude API pricing.
The world is being generated at startup for a 50-50 kilometer play area through multiple steps of generation that includes city placement, roads, and various biomes.
Has 3 months of dev time right now
Godot whole engine is text based. This means you can just let claude rip through the assets and files just fine. It basically just works.
The thing that is critical is to make some documentation about the axis systems and core classes (the one on OP project is pretty good, ive grabbed it) and then you set your claude.md to point at the godot source code so that the bot can doublecheck things.
Ive been playing with multiple engines, and godot is by far the best one to use with the AI. Unreal engine is too heavy on binary files that coding tools cant parse, and Unity is closed source which leaves the bot with no reliable documentation or way to check what the game apis are doing. Godot is small enough that the bot can understand it and works fine for games that arent too complicated.
Im using it to build a spiritual remake of daggerfall as a procedural open world rpg, right now its at 60.000 lines of code, quite advanced. I got it running on a steamdeck at 60 fps even with 4 kilometers of draw distance with thousands of trees and procedural terrain thanks to doing tons of custom shaders and a few engine edits.