You posted some screenshots a couple of days ago that implied you had a playable test game, but your docs suggest that work on the runtime still hasn’t started. What’s the deal with that?
The phrasing would seem to confirm my suspicion that an LLM wrote them, with little or no human supervision. I am not at all sure that you are right.
It’s still a long way off. If you feed the urd.json output of the compiler into an LLM and point it at urd.dev website, it will produce a working ‘game’. Claude does it in a single shot.
In fact, I simply told Claude to create a universal runtime to what it knew about urd.json and it loads whatever get compiled at the moment. It’s obviously throw-away stuff, but the important learning from it was whether this type of format works for the LLM. Both in terms of documentation, and json artefact.
Edit: Let me quickly give the robot the instruction to make a self contained runtime and i will share it
So do you have any evidence that your urd.json files are actually useful output for creating a playable game? Not LLM assurances but actual human-verified evidence? Saying that Claude can cobble something together doesn’t carry much weight because for simple examples like this, Claude could probably take a guess at how the game is meant to work just based on a vague description anyway.
Here you go:
https://claude.ai/public/artifacts/687c38cd-156f-4010-9ec5-5ce151b4549d
Explanation: This is not the way it’s supposed to work. A runtime engine like this would only be allowed to interface with the Urd world through the Wyrd API that is highly restricted and limited.
Also, these are not games but unit tests for the compiler test suite. What you are effectively looking at is a state machine explorer that Claude built directly on top of the definition. The ‘runtime’ has no concept of a winning condition. So reaching the ‘end’ is just that. It keeps going because that state has been set but nothing is done with it.
Is it proof, no? Is it an indication that the urd.json can have the wyrd layer on top, probably yes.
Would you build anything useful right now with the stack for an end-user? Absolutely not.
PS: This runtime only consumes urd compiler 0.1.2 output. The current 0.1.4 feature set would not be supported.
Edit: Monty Hall is my favourite. However, please note that the world is always the same. There is no seeding of location of the goats and car behind doors. That would be done through Wyrd using constraints defined in Urd
I tried pasting the Monty Hall example that you shared upthread into the playground (world.urd.md first and then monty-hall.urd.md). I hoped that I could paste the output JSON into the prototype player you just linked, but it doesn’t compile, just gives a bunch of “unresolved entity reference @door_1” errors. How do we get the Monty Hall example into a format where the playground will compile it?
It’s a bit clunky because the playground allows only a single file. Urd allows to either import the world as a separate file or as frontmatter inline.
All examples are in package/compiler/tests/fixtures on github.
It’s all a bit in flux because the compiler is getting bumped almost daily. That’s why it’s not even in pre-alpha :D. I am spending a lot of time syncing the docs on the site and defining the home stretch for v1 + manual testing.
The biggest single test is this one. It contains the most recent additions to the compiler.(check the raw or you will only copy/paste the world definition):
Here is a static exploration of the sunken citadel: https://claude.ai/public/artifacts/d3c268e0-8699-464d-8a62-e7c7a15fd724
For convenience, try this for Monty Hall in the playground:
---
world:
name: monty-hall
start: stage
types:
Door [interactable]:
~prize: enum(goat, car)
revealed: bool = false
entities:
@door_1: Door { prize: "goat" }
@door_2: Door { prize: "goat" }
@door_3: Door { prize: "car" }
@host: Door
---
# Stage
[@door_1, @door_2, @door_3]
## The Game
### Choose
* Pick a door -> any Door
### Reveal (auto)
rule monty_reveals:
actor: @host action reveal
selects door from [@door_1, @door_2, @door_3]
where door.prize == goat
> reveal door.prize
### Switch
== switch
* Switch doors -> any Door
? @door_1.revealed == false
* Stay with your choice
Hi all
This will probably be my last update here for a while as I don’t want to seem like I am artificially bumping up this thread. My sense is that this forum is more focused on authoring tools and runtime behaviour, which makes sense, and what I have been working on recently is much more on the compiler side.
One of the comments earlier in the thread about database driven approaches not working for interactive fiction stuck with me and influenced the direction quite a bit.
The main shift is this: the compiler now produces, alongside the runtime JSON, a second artefact which is a structured set of facts about the world. This includes things like which choices read which properties, which effects write them, how locations are connected, and how sections link together. (It’s called a FactSet)
So instead of trying to execute from a database, or pushing complexity into the runtime, the system keeps execution simple and moves reasoning into the compiler. The result is something you can query and inspect without walking the AST or simulating play.
Practically, it means questions like:
-
which conditions depend on this property
-
which effects can change it
-
why a choice is available or unreachable
-
or WARNING**:** You gave the player a key, but no door in your entire game ever asks for it.
-
or ERROR**:** Exit to “Hallway” requires
Door.is_locked == false, but I found 0 instances ofDoor.is_lockedbeing set tofalsein any file. This exit is physically impossible to use.
can all be answered directly from the compiled output.
This is loosely inspired by Datalog and Soufflé style thinking, but without introducing an inference engine. The compiler just creates the base relations. Anything more complex can be built on top of that.
It is quite a technical direction and probably not a great fit for this thread, which is why I won’t go into details. But since it came directly out of the discussion here, I wanted to share it before stepping back.
In case you are the type of person looking forward to an IDE that is more like Houdini or Softimage XSI, you will be in for a treat 
In case you read this far, you might enjoy this read with more information: The Experiment Becomes a System · Urd
Thanks again for the feedback, it genuinely helped shape this part of the design.
The below is live in the Playground on the site. The compiler keeps being bumped every day, so expect dragons.
You’re welcome to continue posting here, to be clear; repeatedly bumping threads isn’t really a taboo on this forum. (In fact, we generally prefer it over making a dozen new threads!) I’m just not sure you’ll find much more feedback until you have some way to play and test the compiled output.
6 Likes
Definitely keep posting please. I’m particularly interested in semantic networks and rule based systems. As far as I know, Inform is the only system that uses a semantic network and rules. If there are others, I’d like to hear about them.
I’m also working on an authoring system that is based on a semantic network + a rule system. However, I’m handcrafting my code. I guess we’ll see which development methodology is faster.
1 Like
My robots started work on this yesterday evening. I will push them harder this weekend.
I am not satisfied enough with a fully working compiler, mcp server, semantic layer, custom UI framework, rust backed and mixing the best of blender splits and vscode docks + a runtime simulation and analysis tools.
I need MORE panels! More spreadsheets, more canvases, more 3D, more workspaces.
The brief is here: Urd Forge · Urd
Did i mention scriptable, docks, command palette and unified keybind manager?
Maybe ‘Smorgasbord’ is a better codename for the IDE
—-
This is my favourite part:
1 Like
That looks like enough for a NASA flight mission.
2 Likes
The most complicated enterprise level ‘hello world’ application
1 Like
At this point it’s just seeing how many silly things you can get Claude to make, no? 
3 Likes
Yes, it’s so good that you might as well throw the kitchen sink at it and then sort it by good, average, not so good. The iterative process this enables boggles the mind.
What I love about it is that while the agents are coding, you can still brainstorm in parallel about the next steps and have it update the documentation and site. All at the same time.
Here’s a paper by Donald Knuth describing Claude’s solution to an open problem he’d been working on for several weeks.
It seems that I’ll have to revise my opinions about “generative AI” one of these days. What a joy it is to learn not only that my conjecture has a nice solution but also to celebrate this dramatic advance in automatic deduction and creative problem solving.
4 Likes
Thanks for sharing that! From a skim of the paper, it looks like Claude was able to devise an algorithm for solving the problem and implement it as a C program, but it was down to Knuth himself to formally prove that Claude’s algorithm always produced a correct solution?