I thought it would be interesting to collect some of the decisions I made in the process of creating Trapped in Tucson and issues encountered along the way for future reference and for others who might want a glimpse into my thought process as I created the game.

Objectives for the game

I am very passionate about using technology to address issues related to the UN Sustainable Development Goals and educating people about them. What better way to engage with issues of sustainability than through games? Of course, the issues facing Tucson, Arizona are very serious and can feel overwhelming...especially water shortages and increasing temperatures. I'm trying to strike a difficult balance: make a game that is challenging and impactful without leaving the player with no sense of hope. There are things we can do to address these issues and I want to explore them in this game, while also including a survival and exploration element. We'll see if I succeed.

Creating an inventory system

One challenging aspect of the project has been creating an inventory system that feels organic. I wanted to be able to update the inventory without sending the player to a new passage to manage the inventory and taking the player out of the flow of the story. The solution I ended up with was to use the link macro to execute a run macro that would push the item into the inventory array. This seemed to be pretty robust, at least in terms of adding elements to the inventory reliably; however, I ended up putting in links to passages for each item (and checking to see if the item was already in the inventory to determine which text should be displayed) because the silent addition of items to the inventory didn't provide any feedback, so it was confusing. I'm still not happy with the interactions - especially for the initial inventory (grabbing things from the car). I'll probably return to this later to see about a different approach, like adding a macro to hide the items that have been taken. I'm not sure how to do this without passage transitions in Twine.

I also need to think about what the limits should be for carrying inventory items or if I shouldn't set an arbitrary limit at all (unless, of course, I add larger items later that would be hard to carry without additional conveyance, like a shopping cart). If I don't set a limit, then it might be necessary to expend or lose items. It's very likely that expending or losing items will become part of the game anyhow.

Exposure and health system

The next game component that needs to be figured out (though the inventory system could use some polish, as well), is to calculate the effects of exposure to sun and high heat, limited water availability, and health effects that would result. This also means that it's necessary to track multiple variables: heat exposure in direct sunlight; heat exposure in the shade (which can still be pretty close to direct sun in urban environments); time elapsed without rest, water, or food; the quantity of water consumed per hour; the inability of the human body to recover from heat exposure when nighttime temperatures are too high (generally above 27° C); limited availability of artificial cooling (which would be needed for recovery); tracking day/night cycles; etc. The environmental factors and health effects should be as realistic as possible and I'd like the player to get in-game cues that their health is degrading without a game-like element, like a health bar. This will likely require a silent macro to calculate and track the multiple variables that will cause some passages to be unavailable or be displayed at appropriate times, e.g., when the player is getting delirious from too much heat and not enough water.

After looking into some rather clunky ways of checking the status of various game state variables, including &emdash; I kid you not &emdash; the goto macro, whose use is as inelegant as it sounds like it would be. However, in the notes for goto there is a reference to a new API function added in v2.13 of SugarCube: Config.navigation.override. This function intercepts every passage navigation and checks for a condition (which can include checking one or more state variables) and returns the original destination passage name in the callback if the condition is not met or a new passage name if it is. This is exactly what is needed for checking when the player's health has degraded too much to continue. I would also like to have some conditional events that have a greater probability of happening when some of the state variables increase in value, e.g., the player may be more likely to fall into a trap if the confusion state variable is high; but this will greatly streamline the passage code by avoiding conditional event checks in every passage.

Puzzles

One thing that intrigues me about interactive fiction are good puzzles as part of the story and one thing that frustrates me are extraneous puzzles that don't advance the story line in any way. One of the challenges of Trapped in Tucson (I hope) is finding out how to survive, and possibly even thrive, in the dystopic Tucson of the future. But I also want to have some mini-challenges that will take the form of puzzles. The challenge will be to make them interesting and challenging without being frustrating.

I'm also thinking that events that happen to the protagonist should have an element of randomness to them, so that there is some replay value to the game even if the player follows the same path. This will be a bit challenging, but I think it will be worth it.