Engine Works
Under the hood of Alteryx: tips, tricks and how-tos.
This article is part of the Alteryx Obscura Blog series. Alteryx Obscura is the Inspire session dedicated to all things non-analytics, highlighting what the software “can” do rather than what it’s “supposed” to do.
I was basking in the glory of completing a decidedly complex project I built with @Jeff_Neklason, which I covered in my blog “Dynamic Hard Coding – Chained App Sorcery”, and Jeff was congratulating me on my genius and charisma when a conversation suddenly gave rise to the kernel of an idea.
“McEleavey, you perspicacious superman, are there any other use-cases for this?” wondered Jeff. My grey matter already firing, I had an idea that I could use this to build something. Something different. Something…odd.
Despite my boyish good looks, I am actually a child of the 80s, and during this time, I would spend many an hour deeply engrossed in the video games of the day: Books. For those of you born this millennium, these are bits of trees glued together with writing on which you can read to evoke images in your brain.
Source: reactiongifs.us
It was during this eye-bruising time of spandex and TV commercials prompting parents to wonder where their children were that a visionary decided to take the humble book and turn it into something completely different. How about an interactive book, where the reader chooses the next step in the story? Rather than being a passive medium where the reader is taken along for the ride, we were now able to enjoy books with the added dimensions of frustration and self-loathing.
Introducing the Choose Your Own Adventure, and specifically the Fighting Fantasy books. My hero in this genre was Sir Ian Livingstone, who wrote my favorite of these books: Deathtrap Dungeon.
Deathtrap Dungeon (Source: wikimedia.org)
To give an overview of how this works, I’ve snaffled a short section from the Fighting Fantasy Wikipedia page:
“The main text of each gamebook does not progress in a linear fashion but rather is divided into a series of numbered [Sections]. Beginning at the first section, the reader typically must pick one of a series of options provided by the text, each option being detailed at a separate non-sequential numbered section (e.g. the reader may be presented with a choice to turn from section 1 directly to either section 83 or section 180) which in turn provides an outcome for the option chosen. The book continues in this fashion until their character is killed in combat, is stopped by the story, or completes the story.”
And in the words of the legend himself:
"Fighting Fantasy gamebooks empower the reader, who felt the anxiety or joy of being fantasy heroes themselves – they lived or died by their decisions. And if at first you don’t succeed, try and try again." - Sir Ian Livingstone.
Source: GIPHY
So, can I build Deathtrap Dungeon in Alteryx?
Before I begin, I must warn you that this will involve some extremely nerdy discussions around Chained Apps. If you are not familiar with Chained Apps, then this will make about as much sense as “carrot on a broccoli engine”, so I strongly advise you to go and read up on those before subjecting yourself to any more of this.
With that said, to do this, I had to take the principles outlined in the blog linked in the introduction and somehow build a series of chained apps that would allow each app to be completely different based on the choices of the player.
Each app would have a different narrative section, different choices, different impacts on key stats that must proliferate throughout the game, and completely different outcomes.
For example, one app would have the following narrative and choices:
As you can see, the narrative is specific to the “section” on which the player has landed, and there are two choices that are mutually exclusive. Depending on the choice made by the player, the subsequent app will either reflect the choice to open the box or the choice to ignore it and move on. This would mean the subsequent chained app will be completely different depending on the choice.
As you know, it is not possible to chain to a different app based on choice or logic, as this is hard-coded within the Interface Designer of Alteryx.
With this in mind, the two primary challenges I needed to conquer to be able to do this were:
- How to chain to the next app when I don’t know what that app is until the decision is made.
- Avoid having to develop potentially thousands of apps to cater to all eventualities of each decision. Embrace laziness.
Building the Foundation
This was baking my noodle, so I did what any great thinker throughout the ages did. I decided to have a little drink.
Upon making bail, I returned to the challenge with renewed vigour, and I thought the best approach was to build the parts that I knew how to do relatively easily, and so build the framework of the project before tackling the engineering problems.
I began by collating the 400 base sections of the book into a spreadsheet, including the information I would need to determine certain outcomes.
The first tab included all text from each section (redacted in the image below), and what template this would be. More on templates later:
Then came the Options and Actions tab:
This would allow me to determine the impact of decisions offset by one app in the chain, and the impact upon statistics, and whether or not a dice roll is required.
Without giving too much away, I had to build libraries for the following:
- Combat
- Inventory
- Knowledge
- Death Conditions
- Item Knowledge Conditions
- Luck Checks
These are all required to determine the impact of every section with every possible combination of conditions.
In addition to this, I also built a list of templates along with the description. As mentioned above, templates are required for the central core functionality of the game. More on templates later, calm down.
As you can see, each of these tabs formed a tabular input which could be joined together using the ID field, so any app on which the player lands would be able to draw all associated information from this repository.
Once I had the resource libraries in place, this allowed me to ingest these and determine the narrative text, the ongoing inventory, the requirements for a luck check, damage, which items I would/could receive, etc. All these are subject to the “section” on which I’d landed.
For example, if I landed on a section (App) which was triggering a trap which fired a squirrel into my face for a -2 Stamina impact, that would be determined when the conditions arose to bring me to that app.
Of course, I still hadn’t figured out how to bring about said app.
I tried many different methods, including snaffling the XML to build different sections of each app independently, and meshing them together so I could determine the number and type of selections to be made. However, I couldn’t get it working, and although I had limited success, I was frustrated in my efforts.
I had the game built, but I was struggling with chaining to a template that must be hard-coded, but is different every time. Going back to my Dynamic Hardcoding blog, can’t I just use this functionality and change the XML? The answer is: sort of, you know-it-all.
The problem here is that you can’t change the number of selections, or the type of selection particularly easily, and it would take a lot of XML wizardry to get that working. You see, chaining to an app that has three radio buttons is very different than chaining to an app that has a populated dropdown, and trying to figure this out is why I have grey hair and a general disdain for everyone around me. Not you, though. You’re adorable.
Creating App Templates
Now that the framework was in place and the basic structure was built, I decided to get a fresh pair of eyes on it, so I waited outside the local bingo parlor and found @TheOC leaving the premises with a spring in his step.
TheOC (Source: GIPHY)
After a few hours of bouncing ideas around, we came up with a great idea. Given I had identified the different types of Apps we would need, we could take the approach of building each app “type,” then writing the information from the data repository built earlier to that App.
To explain, the vast majority of the apps used radio buttons as selectors, and there were between 2 and 6 radio buttons, depending on how many selections a player could make. In addition to this, there were apps that simply required a continue where no selection was required, and there were those that resulted in a player death and those that resulted in combat. Therefore, I only needed to build 8 apps, which included all these options, assign this app “Type” to each section, and then allow the app to open with those selection options in place, the narratives could be simply changed by using Dynamic Hard Coding.
The trick is that although we can only chain to the same hard-coded app each time, we can overwrite what that app is each time before we chain to it. How? By using templates.
Source: imgflip.com
This means we can associate a template type to each decision made, so we can define the type of app we will chain to when a selection is made:
Providing an App ID means we can determine through logic in the workflow an app that will be loaded in, amended, and saved as the next app in the chain before chaining to it.
Put simply:
We begin with App 1, and we bring in the Sections Library, which defines everything that will be written to the next app. It also takes the selections made by the player and determines the template to which we will chain.
As you can see in the (simplified) flow diagram above, once the template is determined, it is pulled from the template library, overwritten with the elements determined by the Sections Library (selections, narrative etc.), and then saved as App 2. This becomes the next app to which we will chain.
Once we have this in place, we repeat the next step from App 2 to App 1, so we only ever need to use two apps.
Furthermore, once we had the templates in place and ensured they covered every eventuality, I snaffled the XML from each template and included them in the workflow, so no external files were loaded in, and rather the XML itself was then used to simply create the following app.
Source: gifdb.com
Conclusion
This is the basic overview of how Project Asparagus functions, and essentially means you can now chain to any number of apps based on logic or human selection, as you are simply overwriting the next app to be whatever you want.
None of this would have been possible without Sir Ian Livingstone himself allowing me to use his work and indeed going the extra mile, recording a video introducing Obscura on stage in Las Vegas in 2023. It was a huge honor to have one of my childhood heroes take time out of his day to do that, and I would like to extend my genuine thanks to him for that.
I may host this as a playable event in the future (depending on appetite), and until then, go and buy his books and his other works, and as the great man himself always says:
“May your stamina never fail.”
