Originally published: https://blog.prototypr.io/12in12-adventures-in-text-ec034dfab7eb

January’s side project was an about turn from the end of last year: going from experiments in handcrafted animation to exploring interactive fiction. In particular, how do you create a compelling narrative and interactive experience with only text? Time to find out.

Or why read when you can play the side project for yourself: What’s That Scratching at Your Sarcophagus?

The Project: Adventures in Text

Or maybe that should be hieroglyphics? What started out as a project to explore interactive fiction and text adventures became a desire to write at least one functioning game that led to building a one room interactive fiction to test this which quickly spiralled into the project for the month, What’s That Scratching at Your Sarcophagus, a micro sandbox where you play as a ghostly pharaoh and find weird and wild ways to drive off the tomb robber who dared disturb your slumber.

Try it for yourself: What’s That Scratching at Your Sarcophagus?

The Checklist:

• Created a complete and functioning (at least so far) micro interactive fiction with multiple endings (at least 5 distinct + some of those with various paths and variants).
• Whacked up a webpage and played around with code for the first time in a while.
• Taught myself Inform (amongst much gnashing of teeth) and stuck it through to fix the issues even when I thought half the endings were broken.

The Undone:

• Sadly could not make it to the 2019 Global Game Jam. But there’s always next year!

Creating What’s That Scratching at Your Sarcophagus was fun but also one of my biggest challenges yet. To go from nothing to a complete, playable project using a medium (Interactive Fiction) I’d never designed for using a system (Inform) I had no knowledge of was a bigger chunk to bite off than I originally anticipated. With not many free hours over the month and health issues eating into even more of that time for a week, the project became as much about learning to manage my time & efforts as exploring text adventures. I had to set aside some of my more overly ambitious notions and outline what I needed for a MVP and build from there as time allowed. Overall, something of a roller coaster but I’m happy with the results and look forward to dabbling in more micro gaming experiences in future.

Highlights of the Month:

Side Project:

• Making a game! Like a real game you can play on your computer or phone and it kinda, sorta, mostly works! I’ve written a good smattering of tabletop games but this is my first digital game and required a different approach compared to writing a rulebook.
• I’m now officially halfway through the Side Project Project! 6 project down, 6 to go.
• Oh and Net Magazine happened:

At Work:

• First pull request + merge into production! Okay so I literally just created some sizing conventions but it was still fun to officially contribute and go through the process and production checks of contributing to a company repo that aren’t a thing when I’m working alone on my own projects.
• Half another notebook full already! Two sizeable systems in the works means lots of meaty problem to think through and interesting design challenges to face.
• The cross-continent UX team has regular (virtual) meet ups to catch up but for 2019 things are shaking up and those are now becoming virtual critique sessions to show off work, get feedback, raise awareness of what’s going on across the product portfolio, and of course our usual chitchat and ribbing. So far it’s working like a charm and been great to see everyone’s work and the iterations between sessions.

Lessons Learnt:

Distinguish users’ language and actions from the system’s

Learning on the job:

…and address each in the appropriate way. From the copy on a single button or the words used to describe each step, the seemingly smallest details can make a huge difference. Not only that, asking if this is really how the user would see it or whether this is actually an implementation feature and unnecessary distraction on the way to their goal has a massive impact on how you approach the design.

Applying on the side project:

Inform lets you program in simple English. On the one hand that’s really neat, on the other hand it can extremely frustrating because it raises your expectations because you expect actual understanding of English (which it does not do. And actually is an interesting concept from the UX perspective because it should feel nicer and easier but actually becomes an alternative syntax which can sometimes make you expect more from it because it doesn’t have the obvious, machine-like quality of other syntaxes in coding). Layer on top of that the fact that designing game involved writing nearly 5,000 words and what you call an object might not be what the player calls an object and there were a lot of language considerations to work through. This became an area where I dedicated a lot of time over the project.

What assumptions are you making?

Learning at work:

When you think you’re done, stop and ask ‘what assumptions are we making?’. Same when you’re stuck. Take a moment and zoom out. Why are we doing that here? What are we really trying to achieve? Etc.

Better yet, start with the high-level timeline and try to stay think at a high level and holistically for as long as possible. It can be tempting to dive down a level when you think you’ve got the high stuff sorted but chances are you’re missing an extra layer of refinement which can only be done at the top conceptual architectural level.

Applying on the side project:

It was easy to get carried away working on a particular puzzle or item, especially if I dove straight into Inform, but that can be counterproductive when crafting a one room sandbox where different items need to have multiple layers of interaction and usage. To start with, I sketched out a high level flow of how the ‘light puzzles’ played out and interacted. Then came the skeleton text, and only then diving into programming it (which would reveal new potential or raise questions, making it easy to circle back and reevaluate the thought process at each level as necessary).

“If we think the model we’re applying is complex, how is it going to be for the user?”

Learning at work:

This was the wakeup call in a discussion with lead UX maestro for the product, Rick Monro. It was a passing comment and after refining the system we were working on was boiled down to be simple enough but it stuck with me.

Whenever things are getting too complicated: stop. Step back. Reevaluate. You’re probably missing something. Perhaps the situation isn’t actually as complicated as it sounds (that’s when I find a workflow or simple list on paper is the biggest and easiest sanity check) but maybe it is. If it’s too complex for you then it’s likely going to be complex to make and definitely too complex for the user.

Applying on the side project:

Puzzles are a key component of classic interactive fiction. For What’s That Scratching at Your Sarcophagus the idea was not to craft intricate, complex puzzles but more intriguing, interactive items the player can try combining in whacky ways. However, how those items are combined needs to follow a logic or the player will never figure it out (or worse, the game logic will run counter to player logic and frustrate instead of delight). When planning out the steps necessary to reach each ending, I stopped each time to review to make sure each did not feel too complex or convoluted because if it was to me who planned all the hints, how is it going to be for a player coming in fresh?

Always ask ‘what happens if I…?’

Learning on the side project:

What happens when if you throw the mummified cat? But what if I open it? So many considerations as soon as you start considering each element as interactive. Suddenly dropping in a vague note about snakes in a description becomes another element in the environment.

At work:

It’s easy to become focused in on particular steps or handwave over how two flows link up (especially in what I’m working on at the moment where most flows have multiple entry points and I have to constantly remind myself to forget what I know is coming up and consider what information the user actually has at this point). Whenever I think a flow is all sorted out, asking “what happens if I click that?” or “what happens when I X…?” is what reveals if that’s actually the case or not.

Be relentless in showing

Learning on the side project:

The easiest way to always be seeking feedback and evaluating your work is to design in the open keep showing it off no matter how rough. In this case, I started by posting in a gaming forum and messaging friends I know with experience in interactive fiction for feedback (which even turned into a code review in one awesome case). Work in process content was posted first to the forum and resulted in amazing suggestions as well as some playtesting.

Best of all, it helped me press on and not settle for ‘it can’t be done’. Feedback helps figure out what needs to be done and whatever is worth doing is also worth persevering for.

Applying at work:

The new UX team work sessions have been perfect for this, providing a means to show and review work. But it doesn’t have to stop there. Who says you only ask design questions to designers? Get engineering involved as soon as possible and keep showing it off as you iterate.

Next Time

February will be keeping with the ‘why not go and learn something I have zero clue about’ theme of January’s side project but this time it’s less about writing and more about reading. Or maybe a bit of both? Either way, it’s going to be groovy hint hint

To find out more about The Side Project Project, read the full recap of the year: A Year in Side Projects