I’m happy to release to the public version 1.0 of a project that has been in the works since November of 2024. It started out as a humble C64 BASIC program.
The software is for Windows 10/11 and Linux using wine. For Windows 10, the minimum version is 1809. While the studio and all the features work through wine on Linux, the experience is best on the Windows platform.
This is my labor of love and is not abandonware. I plan on supporting this software for years to come. I will even consider granting access to the private git repositories to other software developers. The software is written in the C# programming language and the engine deploys to Android Mobile, Linux, the Web, and Windows.
I uploaded my TALP 2026 game submission as a project file for use as a reference. Full documentation (137 pages) cab be accessed in the software from the Help→Documentation. I want to thank @Ordon for all the past and present help in actively helping. He is currently editing the in game documentation. The current documentation is my first pass / rough draft. I’m sure he will make it much more user friendly.
Version 1.2 is live. The documentation has been further enhanced to reflect the new generated text properties and reveal exit locations. It has also been updated to show how generating web playable packages can equally be served on a local end users webserver. These are fairly common on all systems.
Built in version control makes sure that any previous version can only play and load up to its current version. New versions, like this one can play all versions that came before. Version control and the file format have been well thought out to serve the singular extension of .mad well into the future.
There is some discussion about how user defined text and movement handling in Arcturus work in the Arcturus thread. I wanted to discuss those points in MCIF. In MCIF rules around movement can be created. When you change locations, there are a sequence of events that can be handled for the different stages of movement. There is a “before” you move event and an “after” you move event. The “before” movement can prevent movement from happening. The “after” movement means the location has changed and you can script logic to play out. Between “before” and “after” there is a “message handler”. Handling this “action” feedback allows an author to display their own custom text, which sounds like Arcturus’s “alter” handler. If you do not choose to handle it then the engine will either generate default generated text or none at all if the global setting for action feedback is disabled. In movement, as well as all other rules, there are location values that can be used. A rule can build on the last location, the current location, the new location (prior to movement occurring), and the target location which is the location when you throw something to or look into an adjacent location. With movement there are also constants for the direction being traveled and the type of passage being traveled through. For throwing these are relative to the type of passage and direction the object is passing through. Because rules can be composited together with chaining, a rule can be very simple and global or very specific. It just depends on what is trying to be achieved. If I wanted to make a rule that prevented me from walking through an open passageway, it would be a simple matter. If I wanted to make a rule where a dog NPC followed me around or played fetch by throwing things, it would be easy to express. With the way MCIF is designed gameplay is emergent which takes away the need for writing 100% scene based logic. In other IF systems, the form of the grammar can feel confining. The parser and the logic are more coupled. In MCIF this is not the case, it is based on semantic slots. It means that a player can enter “from the safe take the diamond” or “take the diamond from the safe” or even “from the safe the diamond take” all do the same thing. I wanted to make the system more forgiving.
This is one of my favorite features of the system and one I spent weeks on, probably at least a month of research and development. It is the ability to import a game made with the studio to the native Android application. This is the process for installing games to the phone. The process of building up a custom game library that plays even when offline. My original target platform was Android. Windows, Web, and Linux didn’t have players yet when I built this function. The APK for the Android application is part of the archive on Itch.
I use my Google Drive as the starting point but any cloud based drive works. Even using Androids ADB program to push files to the phone over a cable works.
The GIF animation shows the process starting from my Home screen. It is a game I work on from time to time called “Canon Alberic’s Scrapbook”
Go to the game file in the “file explorer”
Send it to the MAD Candy application on the Android phone. With Googles Drive it is called “Send a copy” or “Open with”.
Choose the MAD Candy application
The game installs to the main menu and is there to play. Android will launch the application or relaunch it when already running.
I’ve reached a milestone in MAD Candy and an engineering breakthrough. It’s the kind of computer code underneath that gives the feel goods. Not only is the game logic exportable to text file and has a line renumbering feature, but now I’ve got that for objects.
This is a really big deal because it ultimately means that I’ll be able to export and import code and object blocks as reusable components. The system produces a text report for the author to read.
Here is a sample (The UI hides the numbering from you unless you enter it manually):
Object: Old Id: 1 New Id: 3 Name: A Black Velvet Cloak
Object: Old Id: 2 New Id: 4 Name: A Small Brass Hook
Object: Old Id: 3 New Id: 5 Name: A Message
Object: Old Id: 5 New Id: 2 Name: A Chandelier
Object: Old Id: 6 New Id: 1 Name: Hall
Block: The Opera House
Rule: 1
Part: Result
Old: {3}=The message has been carelessly trampled, making it difficult to read. You can just distinguish the words…
New: {5}=The message has been carelessly trampled, making it difficult to read. You can just distinguish the words…
Block: The Opera House
Rule: 3
Part: Result
Old: {3.r12}=0
New: {5.r12}=0
Block: The Opera House
Rule: 4
Part: Operand
Old: 1
New: 3
Block: The Opera House
Rule: 5
Part: Operand
Old: 1
New: 3
Block: The Opera House
Rule: 6
Part: Operand
Old: 3,-2
New: 3,-4
Block: The Opera House
Rule: 8
Part: Operand
Old: 1
New: 3
Block: The Opera House
Rule: 11
Part: Operand
Old: 3
New: 5
Block: The Opera House
Rule: 12
Part: Operand
Old: 3.r12
New: 5.r12
Block: The Opera House
Rule: 13
Part: Operand
Old: 3.r12
New: 5.r12
I’ve started working on the parser adventure game described in the book “How to Design Adventure Games - by Shaun McClure”. It is called “John’s Quest” in the book. I just started in and am really just working on the intro to the game. Here is a sample of “Looking at yourself”. I read that people like to do that so I borrowed an image from the book.
One thing I want to do with this one is use a custom palette that is different from the standard palette shown in the image. The palette may even change during the game. I’m also going to work in some sound effects for the different NPCs and some actions in the game. It is exciting to take a break from the worky-work to do the fun part. Making a system is a lot of work
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.
Source Game - Canon Alberic’s Scrap-book
Cloak of Darkness
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.
