Maybe, but I want to point out that even the lesser models are capable of hunting this stuff down. The most important thing is that you provide a decent path for them to follow.
It's mathematically provable in most cases because the engine is deterministic from the ground up and I refused to ever compromise on that one detail. For example, nearly all of the VM and maths code functions have been validated for ALL possible 32-bit inputs and extensively fuzz tested in the 64-bit range. Even the more complicated sections of the code like the emulators have batteries of third party tests that ensure a certain level of compliance. The fact that you can play commerical ROMs to completion, including esoteric titles that require third party peripheral/MBC code, is quite solid proof too!
A form of recursion is also doing a lot of heavy lifting because the emulators are their own separate deterministic engines that are dynamically plumbed into the primary loop. This not only allows us to embed diegetic devices (as in, you can literally pick up a glowing brick in the world, hold it to your face, and play it), but also validates that the primary loop is coded accurately because the outer loop runs at X Hz while humble bricks must run at ~59.7275 Hz. Pacing inaccuracies in the main loop cause us to fail the brick suites that we test against. This concept of having features reinforce one another is applied as often as possible.
The obsession with determinism goes so far that both the DirectX and Vulkan backends are validated against each other for pixel level differences. If they differ more than the expected maximum then code is refactored until the drift is back within acceptable range.
Frankly, there's no "good" starting off point for a human right now, and that's why I'm not at all comfortable claiming this has actually shipped. It's very much a WIP where only a select few namespaces have actually had a chance to settle.
That said, the maths library might just be the best thing to start with because it's mostly stable, relatively simple, and virtually every other part of the project depends on it in some way. If graphics are more your jam then maybe check out the SDF VM project and associated documents. All rendering goes through a single instruction set that is implemented via a shader pipeline that allows arbitrary scenes to be defined without shader recompilation. The project is essentially multiple compilers wearing a trench coat so there's a little bit of something for everyone... like two fully implemented emulators of the brick variety, including peripherals.
If you're adventurous and want to have your favorite LLM give the project a review in a sandbox then I think that'd be neat! Especially considering that they would have absolutely no problem driving everything themselves through STDIN. Though I totally understand if that's not something you're keen on doing considering the state of things today. Either way, cheers!
I get the skepticism, I really do, but my hope is that your own AI(s) confirm exactly what I'm claiming within these comments. Like I've told others, there's no need to take my word for it... the entire point of the project is that anyone can execute/prove the same things I claim using their own hardware via a Doom-replay type format. If I was one of those influencer types, then I would've simply led with "it's an agentic first engine!!! how amazeballz is this?!" or some other nonsense. On the extremely off chance that I'm actually working on some sort of ridiculous ARG, consider this post a canonical part of it.
The most wonderful feature of the project is that there are almost zero new ideas contained within. I'm standing on the shoulders of many giants, proudly.
This is an addon that I wrote for WoW, well before having access to any sort of AI, that blatantly copies the crossbar layout popularized in FFXIV. Playing an MMO with a controller in that game was a mind-blowing experience for me because I never imagined it could work! So, I spent a winter break reimplementing the entire thing in my own unique way.
Some of us aren't just slopping it up like @theo and all the other AI influencers are, as I developed nearly every single line of this by hand over the span of the past decade. Agents recently became capable of factchecking it and helped find bugs that my other unit testing never caught. Software engineering has never been more alive!
This is a snippet I wrote years ago to help me study different formulations of the equation ((1 + √5) / 2). There was this thing I could "see" in there that would allow me index into these sequences, and whole families of others, in O(1) time. The problem is that I still don't know enough maths to derive the exact object that I want from the nonsense that I have.
This is the reformulation of that snippet into a proper object, distilled using Fable and Sol. Unlike BinaryIntegerFunctions, I didn't write a line of this and I'm quite happy with that. It's been a slog for so long... being able to let these agents toil away at all the off-by-one type noise is just nice. I get to focus on an actual product for once instead of manufacturing every single nut and bolt myself.
Did you actually try to read what I wrote, or are you just stopping at the very first thing you can parse? I'm engaging in good faith with you here, it would be nice if you even remotely attempted to do the same. You can literally walk around in a world, pick up an in-world device, turn it on, and watch/hear the device play an actual ROM. Furthermore, you could edit that ROM while you're playing it. Recursion and determinism all the way down. Again, that's just one of the many possible things you could do... call it slop all you want; I'll still believe that it's coolest thing I've ever worked on.
It has so many words precisely because it isn't a slop game engine. You could indeed build a game out of it, and that's what I'm personally doing, but that isn't what it is. In a nutshell: it's just a really fancy compositor. We can take arbitrary feeds from different input sources and composite them in pretty much whatever way we want to. Obvious basic things like four-player split screen is possible but you could also choose to embed a fifth player screen within the game world itself, sculpted and riding on top of actual geometry. We can do this with a webcam, a program, the entire desktop, or even the built-in emulation engines; all editable and composable in real-time via a data-driven document. That's just scratching the surface...
The README is, the project absolutely isn't and you don't have to take my word for it. I figure I'm speaking to a technically advanced audience who is perfectly capable of pulling down the repository if they're at all curious. I also provided a non-slop link elsewhere in the thread if that's more your bag. If not, oh well...
Yes, it would probably be better to have something like that if you're struggling to plan and decide. In my particular case this has been a project that I have dreamt about and tinkered with for at least 15 years now. Most of the work I'm doing is just refinement of existing ideas what were already codified in other projects I've built.
Why don't I do this in place? The amount of churn is utterly incredible as ideas are refined and taken to the limit. These agents are getting quite good, but they regularly make the silliest of mistakes. You actually have to be extremely cautious about what you document because it often has a way of becoming "doctrine" to the agents. In fact, one of the most difficult parts of working on this project has been that the foundational properties cause the agents to lock down behavior WAY too early.
Sort of? The bots almost insist on making sure one exists because that's one of the many patterns they trained on and they do their best to be human-like, but we all know that just doesn't pan out. They're also a side-effect of your long-term interactions with the agents, very much like being in a tight clique where most of your conversations sound like gibberish to outsiders because of all the jargon.
'Cause I don't have any quality user-facing documentation yet; that README is for bots. None of the interfaces have had a chance to settle, so any time spent accurately and humanely documenting what the project is capable of right now is an investment I cannot afford. I figured most people would just give it over to their favorite LLM with whatever instructions they prefer for translation because that's what I would've done...
That's fair critique, the README itself is indeed slop explicitly written by bots for bots. What it actually does and how it works is actually pretty neat if you care to look.
It's not a full game yet, but the substrate on which I am building one. It implements a completely deterministic SDF VM rendering engine that allows edits in real-time at acceptable performance levels. The engine is essentially folded in on itself as the editor is the game; assuming that an editor mode was actually defined in the world document. It's a lot...
As a kid who grew up absolutely loving their GameCube, this is a perfect computer to me. Yes, I already built my own LAN cube ~2 years ago that fits in my carry-on and is significantly more powerful for a comparable price point... but the Steam Machine is WAY smaller! I can fit it in my backpack and still have room for a monitor, work laptop, peripherals, Steam Deck, and clothing. It's just not possible to build a DIY machine of this size + quality without resorting to extremes as a consumer.