How to do anything

QuestJS gives you access to everything, so there is no limit to what can happen in your game as long as it can happen inside a browser. For the purposes of this article, I am thinking more specifically about what is happening in the game world. How do you go about coding that bizarre, complex and wonderful feature of your game?

The first step is to define exactly how it will play out. Write out some transcripts that show what the user will type and how the game will respond. I would suggest at least three, one being a perfect run through, and a couple when the user gets it wrong in different ways.

This is vital because it will tell you if your feature can be translated into interactive fiction. If you cannot think what the user might type, or how the game might respond, then your feature is not going to work - in any IF system.

Once you have a transcript, you can build the environment - create the relevant location and items. You might want to create a CHEAT command so you can quickly get to the location to try it out.

Presumably something will change - or several things. Think about how that information will be stored and where. If items are moving, you can just use the "loc" attribute, if opening and closing, use the "closed" attribute, if switched, use "switchedon". However it is likely there will be other changes. The new attribute should go on the object that changes apart from anything else, this just makes it easier to find later. If it is an either/or thing, use a Boolean. If there are more than two states, and they form a natural progression you are probably best with an integer, but otherwise you might use a string. In either case, it is worth noting what values are allowed - I would suggest doing so as a comment above the code that creates the object.

Now create the custom commands. For the script, whether on the command itself, or the verb on the item, go through all the conditions that mean the command fails. You might want to do one command at a time.

At this stage you can go into the game, and test it out. Have the console open so you can see error messages. You can also test the state of an object by typing it in. To see if the big box is open or closed:

w.big_box.closed

Once the commands are working, you can fine-tune. Think about synonyms for commands and items. Look at the descriptions - items and locations - and see if they still make sense after things have changed.

What happens if the player does it twice? Or tries to do it before she should be able to? Or tries to do it in a different way, or tries the same thing with something else in your game?

---

A couple of links to external web sites about puzzles:

https://grumpygamer.com/why_adventure_games_suck

http://www.inform-fiction.org/manual/html/s50.html