Since the last release, I started in with some big aspirations for the next version. I've been working tirelessly on this version. It has both a laundry and grocery list of items. The laundry list was more attuned to internal architectural consistency. All the curated actions now disambiguate the exact same way. Before some would disambiguate starting with the noun, others the direct object. They are now all disambiguating the same way. This was a really important thing that needed closure because of how it affects the verbs. Many curated actions like switches, levers, and generic objects can share verbs. I can throw a light switch, throw a lever, and throw a rock all by using the throw verb. Proper disambiguation of the objects in the text command were necessary to keep this working correctly. To the grocery list was something that I'm very excited to release for use in a text game. In the last release I added "look text" for providing custom text when an adjacent location is looked at. This may be from looking through an open door, passage, a closed window, or even in a compass direction. This was really just the tip of the iceberg and a bare minimum of what was needed. What was really needed was the ability to define text for the different surfaces of a location in the world. Any location can have all of doors, windows, and other surfaces like walls. Those surfaces should be able to be looked at and also mutable with the rule system. Now they can be. Do you want a string on your door that indicates a trap. Put it in the description for the door. Does it need to change, then change it with a rule after something happens. The same with window and other surface text. Doors and Windows are opt-in by default and react to their default name along with their alias name. Walls are opt-out by default and can be defined and given multiple aliases, comma separated, for any surface. The north wall can be the "cliff face" and looking at the cliff face brings back the text. Like Doors and Windows, the wall category can be given a broad name, like wall, or yard, or whatever is appropriate to the location, or nothing at all. In the game I'm building, there is a location that is in a back yard. The word yard is assigned to the wall surfaces of the location, the north wall or "yard" is aliased with "fence, gap". The down direction is aliased with "ground, dirt", and the south location is aliased as "shack" because the southerly direction takes you inside a shack in the game. Looking at the yard will then provide a menu to pick one of the fence, the ground, or the shack. Looking at the fence brings it back directly. It is a very powerful and intuitive way to provide textual context to a location. Because directional actions are a big part of the game, the other actions like throwing, got this ability as well. I added this feature to a new feature as of the last release. This is the action for "listening" or "hearing" something. You can now "listen to the north door" and it will carry out the command. With the right rules, this can be turned into a neat puzzle. Maybe it won't work until you are carrying the empty glass. It is up to you and the rule system can completely and simply make rules like this. The portal constants are part of rule building since the beginning and new rules based on constant values make it even easier than ever.

The next thing that is coming is a full reference game that shows the entire process from beginning to end of making a playable text adventure. It is using a specification from a "how to make a text adventure" book and I have played another's PunyInform implementation of the game in a recent 2026 game jam. It was an enjoyable classic text adventure. My favorite kind. I'm excited to make it a show piece for the system. I'm trying to show off as many things as possible in the game for other authors who may want to try their hand at the game making process.

Why does this matter? It matters because from the very beginning, the design goal has been to model spatial awareness and its mechanical ability. The ability to do mechanical things, out of the box, has always been an important facet of the system. Now directional awareness has a bigger role than ever.

Coming soon, very soon. I'm using an internal build of the forthcoming release to build the game and test out the system. I don't know whether to call it 1.4.3 or 1.5.0. A good problem to have. 1.4.3 works well because there is always undoubtedly a patch release after which makes it 1.4.4. 1.5.0 turns into 1.5.1.

The internal build is very solid and I'm very happy with how it handles surface/scenery, door, window, and adjacent location examination. One of the aha moments was in how these actions have evolved. Looking and throwing objects towards a compass direction or adjacent location have always been part of the system. The evolution of looking was in the addition of separate look text and when it is defined it is used over the body of the location text. The location text has always been constructed from the intro, title, and body and even the game display mode controls how these display. The ability to have different display modes, like book, cinematic, modern, and classic affect how locations are described. Now with additional look text and door, window, and surface text, the expressiveness has really evolved. Being mutable with rules makes it even more dynamic to have evolving locations based on your world state. With the addition of listening in a direction that makes for really interesting possibilities. An aha moment was with the button object and mechanic. The button mechanic is a verb strata that was initially designed for the pressable object. The aha moment was extending the press verb to additionally act on compass directions, ala Zork III. Now the forthcoming version supports the button mechanic on doors, windows, and surfaces like walls. Being able to write rules that trigger when you "PRESS THE EAST WALL" is now 100% doable and quite simple to express. It becomes utilizing the Before or After Push event then rules that narrow the scope and finally checking the Portal Type and/or the Portal Value. Portal Type tells you if the action happened on a passage, door, window, or surface. Portal Value tells you the direction of the action. Because of the complete mutability of the entire world with rules, constructing or removing passageways is just a matter of using rule outcomes to update the door or window state. The door state can create open passages or doors in any of the open, closed, or locked states. The window state allows creating windows or changing one to open, closed, or locked. I'm already working with this in my reference game and will be happy to show it off and demonstrate how easy it is to do this. Combine all this with room lighting, listening, smelling, and throwing, some seriously interesting puzzles can be constructed that just utilize the mechanics of the engine and objects. So exciting; I can't wait to release this build.

A small but extremely meaningful refinement to the menu handling and rendering system has been introduced to the upcoming release. This improvement will make proof of concepts like Road of Darkness even easier to create and manage. Menu stacking and pressing enter to return to a previous menu are now easier to do thanks to this refinement. Road of Darkness still functions perfectly the way it is created but will be able to be simplified. I'm looking forward to posting an update to the game along with the game file. Another new action, help, has also been introduced. Help is a first class verb and can be used to return helpful hints or be used in the games context. I'm internally on build 1.4.4 as I work through the updated system and fine tune everything. I made an administrative change with the meta commands. Commands for saving and loading a game have undergone a slight revision. Now save and load do not need to be followed by the word game; they are stand alone commands now. The internal help system is working very well. The bonus with it is that not only can it be leveraged in rules to give a player a bit of help but it can also be used as a verb in a game. The help system does not have to just return helpful text; it can be an action used along with a NPC. So excited. The reference game is coming along very well. The reference specification leaves a lot to interpretation and since I'm trying to show off as many of the systems as possible, it has multiple possible solutions, some bonuses, and a small combat system using the RNG. I'm still on the fence if I want to make that part of the game be menu driven, parser driven, or a hybrid. Good design problems to have and my goal is to show off the aspect that I think an author would want to use for their own game.