Sunday, 5 June 2016

Writing Salon Week 6: Program the Room Description

This post is for the June 5-11 writing event of the 2016 AIF Writing Salon.

Add the room description to your game so that players can look around.

If you are using Twine, you can emulate the feel of traditional interactive fiction. Create a different passage for each room. When you click on objects, instead of using the normal Twine links, use the <<popup>> macro by Claretta. You only need the javascript code and not the provided css code. If you want the popups to automatically close when you click on links, create a passage called "PassageReady" with the following contents: <<set UISystem.close()>>

If you have something you want to share, just post it as a comment to the blog post. Be careful to use a separate account for posting and not an account you use IRL. Anonymous comments are welcome, but it would be useful to tag your comments somehow so we know which comments are from whom. AIF Central sometimes has difficulties dealing with longer comments. You can break up your posts into multiple comments, or sign-up to become a blogger on AIF Central and make a new blog post with your content.


  1. I've programmed up my room descriptions here:

  2. I've come to find embedded links to be annoying in choice games. Clicking them just feels like extra work to do before getting to the interesting choices at the end of a passage. I think that is why I'm struggling to add them to my project. I've sloppily added a few, but will likely remove them later on.

    1. You've written a ton! That's fantastic progress. I wouldn't worry about embedded links. I never know what to do with them myself. They aren't too useful for traditional choice-based games. I'm only using them to show that it's possible to make something with the feel of a parser-based game in Twine, but I hate having to write all the descriptions needed for parser-based games.

    2. I was impressed by embedded links as a feature in Twine when I first saw it as a way to substitute for descriptions, but I do see your point in that their presence pushes you toward reading all of them before moving on. (As opposed to descriptions in a parser game, which feel a lot more optional.)

      Perhaps a more judicious level of use for them is called for? Focusing on particularly interesting optional bonus descriptions here and there (if a woman has impressive cleavage you could optionally gawk at it) would allow some use of that feature without making it overwhelming. Or you could have a folded letter to read and clicking on the link reveals the text of the letter?

      I probably wouldn't use them for making all the descriptions a parser based game would have, though, as they tend to have way too many. I feel like I naturally drifted into a design style where object descriptions aren't used for much except a little extra atmospheric flavour text and the chance to conceal some secret bonus puzzles for the kind of dedicated players who really want to dig into the game.

      I do think that descriptions of body parts are something that players enjoy having, however. When you're trying to get accustomed to a new object of desire you want to look them up and down, so detailed descriptions should be in the game even if they're not in embedded links.

    3. Embedded links might also be useful for repeated descriptions. If you visit the same room again and again, instead of having the full detailed description each time you're in the room, only the main description is shown with the less important stuff that isn't expected to change hidden under links.

      We'll only find out what works when the games are finished though.