I would so love the color images from the book. I took that picture with my phone and ran it through a paint.net sepia filter. I want to use the “map of the realm” and different sections to show maps ala images. Like a map of the realm.
edit - The making of this game is going to be the example/sample game that goes in my documentation. I’ll be uploading the project file in complete form and then the individual parts used to build the game along with the documentation. I’m excited to use the export, import, renumber, and recode functions in the system to demonstrate how to make and use reusable code and objects.
I’m wrapping up a very powerful feature set. It is the ability to write reusable code and objects. My example exports code and objects from one game and imports them to another, Cloak of Darkness.
The code and object are complex. The object is a book. The book has 73 lines of custom game logic. The logic allows reading the book in the game. A menu presents the chapters of the book and these can be selected to read. Each chapter has multiple pages of text, 3-4, which are paginated through. Finishing a chapter returns the logic back to the main book menu. Pressing enter exits the menu.
The first image shows the context of the book in its own game and editor. The second image shows it in Cloak of Darkness.
What can I do with this specific reuse? I can create a library location with hundreds of readable books. The clue I want can be hidden in any of those texts and become the key to the puzzle. That is just one small example that I can think up on the spot.
Objects in the game have unique id’s. These are exposed through UI lists that keep you from having to do manual entry. Manual entry is still available. Having an ID and “Line” numbered based system makes renumbering and recoding a data-management problem. Code and objects are exported in a readable, predictable, and deterministic text format which is then used for import. In the source game the book is object 12. In Cloak of Darkness it recodes to object 4, the first open object in the object table for CoD. Code starts on line 59 originally. Code starts on Line 31 of CoD. Chained rules now reference the new code range. I deleted line 59 from the import because it was a rule that prevented the book from being picked up for anyone noticing. Renumber CoD afterwards then created the code starting at 31. Before the renumber it imported to line 32.
I’d show the UI of the process but it is not complete. This is the main use case with many others needing UI to express.
The best part of making a custom system is being able to create processes like this. I subscribe to OOO, and work like this just expresses how OOO can be leveraged for reuse. It is also very rewarding. I’m always impressed by what people are making that plays and makes games for the historical systems. What makes this system nice is it gets to live in a different space in the ecosystem. This will be released in v1.3.2
I’m happy to announce version 1.3.3 of the MAD Candy Interactive Fiction system. Most of the new functionality lands in the Studio, but there are a few notable improvements to the engine as well. Documentation is current and reflects the new functionality. This has been an intense few to three weeks of work and I’m glad to move back to making John’s Quest. I’m going to be using one of the new functions in the game to toggle location awareness based on certain map locations. John, the hero, will only know the land around his village and thus when the exit directions are listed he will know the name of the location. When he crosses the river he must discover the location before its name shows up. It will only be referred to as a compass direction. I think this kind of usage answers for me the debate of if I should use or not use location names. It is up to the back story of the player and what they know. When they strike off into uncharted territory the locations must be discovered before being named.
Studio: Modular Code & Object Reuse: The Studio now supports code and object reuse between project files. Any project’s rules can be exported, either in full or selectively, and imported into another project. This enables sharing modularized functionality across games. Objects participate in this process too. When rules are imported, they are renumbered starting at the next available rule ID in the target project. For objects, you now have two choices: Create a new object using the imported object’s name and properties. Recode to an existing object in the target project. Recoding is especially useful when you’re incrementally bringing in functionality. You can create the object fresh on the first import, then recode to it on subsequent imports. That’s a major use case, though not the only one.
Engine: Unified Text & Reveal‑Location Display Settings. On the engine side, the display settings for unified text and reveal locations are now part of the update display outcome. Documentation has been updated to show how to use these features. A practical example from a game I’m working on for the forthcoming documentation: Part of the map is familiar to the player, and part is unexplored territory. When the player moves from known areas into new territory, reveal‑locations‑on‑discovery is toggled on. When they return to familiar ground, it toggles off.
What this means in practice: In known territory: “You can go north to the desert, south to the desert, and west to the bazaar.”
In unknown territory: “You can go north, south, and west.”
The name of the destination is only revealed once the player has discovered it.
Cloak of Darkness has been redeployed and updated on Itch. I renumbered it and did the bar / darkness logic in a much cleaner way. All the screens for how it is built reflect the new deployment. It took all of a minute to renumber, enable unified text, and deploy. It took more time updating Itch. Download the project file and run it yourself in debug mode to watch the moving parts.
I’m really enjoying “How to Design Adventure Games” by Shaun McClure. The design metaphors translate cleanly to MCIF. It is still an up hill climb because I’ve tasked myself with not only building the game in the book but doing it incrementally for documentation.
I’m having a lot of fun with experimenting with environmental actions like SMELL and LISTEN. They are going to be driven by world state. In the game there are two realities. The village before the evil wizard destroys it and afterwards. Before when you SMELL or LISTEN it is going to be pleasant and reflecting. Afterwards it will be the smell of the smoke, or something burnt to ashes. The sounds of something burning. I’m also using the RNG to roll me random numbers between 0 and 9 which are used in the “case” statement for different modifiers to the location text. The book talks about doing small things like this to make the world feel lived in.
For John’s Quest, I’m aiming for a retro palette. Here is what I’ve setup so far. This is how it looks when being played in the native android application on my Pixel 7. It is easy to configure all the colors in the system. There is one central place in the IDE for this. The game engine has well defined colors. The prompt, descriptive text, exit directions, open/close/lock state, etc… all have colors but they can all easily be made uniform. I really like this palette and I need to add a way to the system to save off color schemes for reuse. The colors can also be changed by game logic during play to achieve different effects.
I’m happy to announce version 1.4.0 of the MAD Candy Interactive Fiction Studio and Text Engine. This version bumps the version to 1.4.0 for a new feature of the studio and the engine. This is “Look Text”. What is “Look Text”? It is the text that you get when you look into an adjacent location when it is possible. Adjacent locations are listed as an exit direction in the location. They are open passages, open doors, and windows. Windows are unique in that they can be looked through when open, closed, or locked. Game logic can prevent any of these actions using the rule system that targets the portal information. When “Look Text” is checked, the editor lets you fill in the text that will be presented when looking at the location from another location. If you wanted to lock a window but put something in the location it locks off as a necessary item, then looking through the window gives the look text and the rooms noticeable items. You can even use the existing rule logic to prevent looking through the window. You may want to say that the window is dirty and can’t be looked through. Game rules can do this and even be granular enough that they only trigger on the window when it is closed. An open window can’t be dirty so it can be looked through. The rule system is granular enough to write these kinds of game governing rules.
“Look Text” was always available but the system generated it from the actual location text. Now you can supply it. If you don’t supply it, then it still works the way it always did. With “Look Text” there is more flexibility in describing standing in your location and not worrying about strange location text that implies you are in the adjacent location when you looked into it.
John’s Quest is coming along very nicely. I’ve settled on a color scheme and some images. I bought the Kindle version of the book “How To Design Adventure Games” which means I’ve bought it twice. I’m able to screen grab images out of the book for the game. I combined some to make the welcome screen image and opening.
Just from an accessibility standpoint, you might want to adjust your colors, either by darkening the background or setting the text color to black.
Using Adobe’s color contrast analyzer (there are many such tools but Adobe’s is good) here are results for your current colors. Ideally you want at least a 5:1 contrast.
edit - I will probably make multiple versions of the same game just sitting in the game main menu that differ by palette. I may even make a cray version that randomizes all the colors before playing for fun. I got clobbered over my previous color choices for other things but hey, I liked them…
MAD Candy IF Studio Engine 1.4.1 is now available that lets anyone add images and sounds to the welcome screen like in my previous post.
Here’s an alternative color that is more forest themed. I redid the photo. I think it needs to be edited to size better. This is how is it looks from the main menu on the phone app.
One of the most challenging parts of working on a text engine is handling disambiguation gracefully. Disambiguation can occur when the objects in the parser command don’t cleanly have a 1:1 mapping. The engine has always supported object disambiguation but now I am wrapping up portal disambiguation. In the contrived example there are 9 rooms labeled 1 to 11. Room 5 is the center and it has both door and window exits to all rooms in a cardinal manner, including up and down. In this contrived example I want to test opening doors and windows, looking through them, and throwing an object through them but causing disambiguation to trigger. In the example, in location 5 are 10 closed doors and 10 closed windows. By just commanding it to open a door, it asks me which one, the same with windows, the same with looking and throwing. In the case of throwing, I am hold 2 kinds of rocks. The disambiguation system needs to activate for this as well. Doors and Windows can be aliased and do not need to be named as their cardinal location on the map. I’ve done this with one of the windows for other tests that I do with this testing project. Have a look at the screen. At any time had I just added the full name of the door, disambiguation is not needed. It is probably one of the most challenging aspects of a game engine to do in a way that is generic and works for verb actions that take a directional component like looking, throwing, or opening/closing/locking/unlocking. What is even more challenging is when verb classes share the same verb for different things. In the example, it is not demonstrated but one of the rocks is defined as a lever. One of the levers verbs is “throw”. So you can throw a rock and throw a lever. That is part of the dimension of this test.
I needed to build in disambiguation in general and also for John’s Quest. In John’s Quest, his shack has a back and front door. When in the shack if you opened just the door before disambiguation it just chooses the first one always. So while open door opened the back door, open front door was needed to open the front door. Being the detail oriented person I am I wanted open door to give you the choice of front or back door.
edit - The goal of the text game engine was to really focus on modeling mechanical items and actions. I’m mostly interested in making things with rich mechanics. It has many curated object types and actions. Part of the fun for me was to make something I could make the kind of visual puzzles I experienced in the last of us, far cry, and Indiana Jones games but in a text manner. I try to make these actions and rules as low hanging and accessible as possible.
One of the things that I got clobbered on, with a text adventure, early on was something that didn’t think was a big deal at all. That was wall, door, and window details. In my text engine, doors and windows are portals. They can be locked, unlocked, etc. After playing other games in game jams I saw how details for doors and windows could matter. In John’s Quest they don’t but the book calls for echoing that when you look at one. The location text editor has been massively extended to cover adding door, window, and wall text to any location, and also aliasing the locations so that “north door”, or “west window”, “or east wall” don’t necessarily need to be commanded. This effort has also been combined with disambiguation so if I command something on a door or window without being specific and there is more than one, disambiguation happens. Here is a sample from John’s Quest, the spec driven adventure that I am working on and that will become the documentation reference for how to make a text adventure in the studio. Shown is the game play and the location editor for door as it exists from the village center. It is also set inside the shack with the same text which is not entirely necessary. These new pieces of text are also mutable during game play by the game rules. If there was some detail in the description that needed changing, it can be changed to accurately reflect the game state. None of this text is necessary and defaults like the one in the game when I look at the other door will occur.
edit - None of these changes have been released yet as I’m still in unit and acceptance testing. I can’t seem to ever underestimate or underrate how much benefit there is in making real games with a game engine. Duh… I guess the proper term is dogfooding, as distasteful as that word is. Nothing has found more rough edges, corner cases, bugs, and other gotchas than making something with the tool that makes something. When this slog is over, is it ever, almost 2 years running now, I’m going to have to relearn how to take a proper holiday.
Sometimes I feel like a proud parent when the game engine works just as intended. In John’s Quest you have many “Shack’s”. “The Woodcutter’s Shack”, the west face of that building which carries “Shack” as an alias. And the “Shack Door” which is the alias for the west door into the shack. In the screen the commands all properly funnel to the correct action. The parser also would understand “Look at the west wall” or “Look at the west door” and “Look West”. They all do the same thing but it seems strange to make a player think cardinally unless something good is about to happen. Any doors, windows, and surfaces automatically can be looked at and if text has not been set then the default responses come back.
You might be interested to know that Inform 6 has the ability to examine all walls by default (e.g. EXAMINE WEST => “You see nothing special about the west wall.”) but it’s removed in Inform 7 because if the author doesn’t override it it’s too often misleading or flat-out wrong (if the player is outdoors, say).
The way I handled that in my parser in progress was to make all walls examinable by opt-in rather than opt-out, so it’s up to the author to enable them as needed. I also made it possible for the author to set non-present walls to return a customized “there’s no _ wall here” message in case they want to use it for hinting or to restate the available exits or whatever.
This example has three possibilities. It will either look west of the current location or at the west surface. If the adjacent location has “look text” defined it is displayed, otherwise it generates it from the location text. In the case of the surface or no adjacent location it will respond with a more generic message that doesn’t include the word wall. “You don’t see anything that way” which is the generic response for no adjacent location. Generic responses can be handled or altered with custom rules which can be globally applied or individually on a case by case basis. Because all these things are done in a WYSIWYG editor it becomes a pretty simple affair to add, change, or remove text. Doing text linkage directly in script is usually more work.
This example uses a prior game jam game that was made before the feature and the look text is generated from the location text. If I ever republish the game I would probably go in and add look text to each location for when this command happens.
In that situation you would need to go out of your way to “engage the surface” and do this which is somewhat nonsensical of the player but still expected really to someone who is figuring out how parser games work. For this game, I might go back and make a global rule to say something, or just put look text that says something more appropriate
I would characterize the engine as working this way. None of what I’ve been showing has been released yet. I’m still working through it as I build John’s Quest from the book.
In general the game engine parser subscribes to a rather heathen methodology. The code is designed with the assumption that people gravitate towards typing commands which look correct to them. Behind the curtain a lot of the text can be ignored. I really tried to get away from starting the parser from the roots of a proper sentence diagram state machine with proper grammar enforcement. I studied a 9th grade English grammar book looking at all the parts of the sentence and decided I didn’t want to go that route. I used myself as the test case and decided that more cavemanlike approaches work better from a playability standpoint.
I think I’ve settled on this as the welcome screen once John’s Quest starts. These are combined from the images of the book it comes from. I’ll be sure to make the author the games co-author and credit the book and all. Does anyone think it is too liberal to use these images?
I think that Inform 7 uses something else now for this. I also have the concept of a scenery object though it is just a generic object. It is a word in a master list of objects that are recognized. The only difference from a synonym to an object and a generic object is the linkage. Generics aren’t linked to other objects in the object table. I use them in JQ for the sky. I don’t want to call the “up” wall the sky for every location and alias it as the sky. That would be a lot of work. Looking at the sky is handled by rules that are global and state driven. If it is before the Wizard attacks the sky is perfect and it is a perfect day. After the attack, the sky is filled with smoke and ash.
