[Opinion] Increasing Mainstream Appeal (In Object/Puzzle-Centric Text Adventures)

I’m currently hosting An Adventuron Christmas Jam, and I wanted to offer some tips and advice for inexperienced game authors on how they might think about designing their game in order to be able to hold the attention of non IF/TA players that might chance across their game on itch dot io.

Rather than limit this discussion to the jam forum, I thought I’d post here…

  • The list deals with design considerations when trying to hold the attention of players that have never played a text adventure before, and perhaps would NEVER player a pure text game.
  • This list applies to puzzle-centric TA rather than narrative-centric parser IF, and I’m not devaluing a good story based game - but I (personally) view them to be different genres (with significant overlap).
  • I’m not presenting this as the “one true way”. See the bottom of the post for a little epilogue. Dissents very welcome.

1. Make A Good Initial Impression

When I start an illustrated text adventure game, I like to see something a “loading screen” (or banner image) that sets the tone.

You can set this using the “loading_screen = graphic_id” setting in your game source file. The loading screen should set the tone.

Don’t worry if the loading screen isn’t “beautiful”, just try to ensure that it’s not completely bland.

All locations should ideally have a unique graphic. The graphics may be copied, pasted and adapted, but each location image should be unique.

2. Right Sizing Graphics, And Choosing A Style

It’s good if graphics are provided per-location and graphics should generally be super widescreen in aspect ratio. Excalibur used a 16:5 aspect ratio . but 3:1 aspect ratio is just as good. The reason for this is that vertical screen space is very important.

Graphics should choose an art style and stick with it. If you have decided to use a “pixel-art” art style, the art should be hand drawn for best effect, even if it’s amateur-level hand-drawn rather than digitised. If digitised is the only available option, then go with higher resolution digitised rather than ultra-low resolution.

3. Font Choice Matters

Your font should match the tone of the game and the graphic style. If you are using a pixel art art style, then Google Font or other proportional fonts generally look jarring.

You can choose any “bitmap style” font and it will look better (almost always) than a high resolution font next to a scaled pixel art image. Damien Guard’s fonts are 8x8, and are suitable for most purposes, but there are excellent sources of other fonts out there, so do experiment.

4. Give The Player A Clear Goal

Plays like to see some short description of they story / protagonist / goal. Unless there is a specific reason for not giving the player their goal, then you should always present the goal either in the prologue text, or upon performing an obvious action in the pre-game. Placing a player in a fantastical world is boring without an initial goal. You are free to change the goal mid-game.

(In Adventuron) This is usually placed in the on_startup {} block of code.

5. Make Your Location Text “Scannable” At A Glance

If you are wring an IF style game, in which location descriptions are very wordy what I personally like to see as a player is for every noun to be highlighted, especially right at the beginning. Modern players are going to get bored very quickly with a puzzle centric and text-heavy game that doesn’t highlight verbs. Of course, this advise doesn’t apply to story-centric IF, where such highlight might be distracting.

In the case where your game has concise location descriptions, then I like to see a nice list of interactive objects, in addition to, or instead of location text, to save me again from having to scan the text for nouns.

If you are going for a “TWO” or “OVER HERE!” style concise text adventure then it pays to make the object list update automatically as the player gets and drop and otherwise creates or destroys objects in the game world.

(In Adventuron) To do this use redescribe = “auto_beta”, at the top of your source file.

6. Tell The Player What You Expect Them To Type

It is a courtesy to provide players playing your game with information on kind of sentences your game expects. If your game is VERB NOUN only, and will only accept one or two word inputs, you MUST disclose this to the player. You should also tell the player that the game only accepts two words if they accidentally type three words to re-enforce the understanding.

If the game is mostly VERB NOUN but you have one or two places where an additional preposition and noun are required e.g. " THROW ROPE AT ROCK " then tell the player the syntax that the game expects if the player types the short form " THROW ROPE ".

A good HELP screen is useful to inform the player of the accepted commands. Writing a custom HELP handler is advised but Adventuron wires up a HELP screen by default with the standard VERBs explained.

If you don’t inform the player, and the player doesn’t know the correct way to communicate with your game, then it is very likely they might try things that are impossible to succeed again and again and they will form a negative view of the game.

7. An Examine Message For All Nouns & Avoid The SEARCH Noun.

Every noun should ideally have an examine message and/or examine action.

Trying to examine a noun that is present in the text, and receiving a “you see nothing special” message will immediately make me think that the game is not very well polished or tested.

(Controversy Warning) Others may disagree, but I do advise to steer clear of using SEARCH as a verb, as the meaning is so close to EXAMINE that players might be unaware they need to try it, and in addition, if they discover they need it even once, it forces them to brute force use of SEARCH with every previously discovered object/noun in the game, just in-case. A more detailed discussion of the reasons behind this view can be found here.

8. Focus On Hyper Interactivity In The Start Location(s)

The first few locations in your game should be especially interactive. Think of all the actions that could be performed on all the objects / nouns in these first few scenes,. and provide responses for the actions.

You don’t need to extrapolate the effort put into the early scenes for the rest of the game, but the goal for your first few locations should be to convince the player that the game is super interactive, and that they have the ability to try literally anything and it may work (which is true). The first input that they view as sensible but is rejected as unrecognised will reduce immersion.

As an example, if you have a location by the side of a lake, then you should make sure that SWIM LAKE provides a response that is bespoke. You don’t need to actually describe that it takes the player anywhere, you just need an excuse for it not changing the state of the game, something like “Taking a look at the corpses of fish floating on the top of the water, you decide against it.”.

Another good exercise is to think about all the common sense verbs associated with any nouns you place in your game text / object descriptions. Even if you have no use in the game for those actions, writing a handler for that verb will increase immersion. As with all things, this is clearly a trade-off, your time for their pleasure.

9. Build a Pre-Game

A pre-game is the part of the adventure that basically sets up an easy puzzle (or puzzles) to solve. I like games that have a limited set of locations at the start of the game, and that open up after solving a puzzle (or puzzles). This is a good way to ensure that players (especially inexperienced players) do not get lost, or frustrated with the compass based geography of your game.

(In Adventuron) Using the barriers {} section to make sure the player is limited to a few locations at the start of your game. It is strongly advised that players are not granted access to the whole map at the start of the game.

10. Teach How To Play

(Optional) If you have time, it’s nice to sacrifice one or two puzzles at the start of the game to a “tutorial mode”. Guiding inexperienced players through the process of getting, dropping, examining, navigating, and VERB NOUN inputs will give them the tools they need to explore past the pre-game.

The tutorial can either hint to the solutions to puzzles or even deliver the solutions to puzzles outright. This is a wonderful way to access 100% of the potential audience of a text adventure game, rather than the 25% of people in the world that still remember how to play them.

To learn more about creating in-game tutorial read about Text Adventure Literacy Project.

To see how a tutorial can be structured, check out Excalibur: Sword of Kings.

11. Jingles - All The Way

Depending on the maturity level of the game and the audience you are going for, I find blips to be a fun way of informing the player if they are making positive progress. If your game features sound, then it should always have an option presented to enable or disable it at the start of the game (Adventuron handles sound permissions automatically).

(In Adventuron) Use the “: success” command to signify if the player made some progress, and the default success jingle will play. These jingles are configurable, but if you make a custom jingle, try to make sure it doesn’t need more than 1 second to player. For more information on jingles, see here.

12. Playtesting

No matter how clever you may be, it is absolutely essential that your game is playtested.

Testers will challenge your assumptions and try commands you never dreamed of. If you have 5 playtesters, you might find 95% of the command commands a player might try in a given scenario, but without playtesting, you might only be able to imagine 50% yourself. Every command that the player tries without a response will build frustration.

(In Adventuron) Adventuron supports transcribing a gameplay session through the TSTART and TSTOP commands, which playtesters must manually type. When they type TSTOP (or close a window holding a game that has been TSTARTed), the game will download a .txt file containing their gameplay session. Testers should mail the file to authors. This process requires affirmative consent from the tester.

Gameplay transcripts are worth their weight in gold. Release a game that has never been playtested at your peril.

13. Interactive Graphics

If you have time, it’s a good idea for the location graphics to respond to actions in the game.

(In Adventuron) If there are just two or three states of a location, then : set_graphic “” can be used to update the graphics in response to an action in the game.

(In Adventuron) For locations with multiple elements each with multiple states, you can employ the new (advanced) overlay method (see cookbook for more details).

14. Right-Size Your Map

A good rule of thumb is that there should be at least one puzzle per two locations in your game, and there should be no two locations in a row with nothing to do in that location.

It is not a goal for the game to represent the scale of a landscape with lots of empty locations. Such locations make your game feel lifeless.

For a game with 12 puzzles, between 20 and 30 locations is a good number. A really interactive game would have one to two puzzles per location (on average), and that is averaged across occasional locations with nothing or little to do.

15. Avoid Linear Puzzles

Linear puzzles are puzzles that must be executed in order. A good game is a game in which (at most times) there are multiple puzzles for the player to consider and solve. Puzzle dependency charts are a useful method of visualising your puzzle linearity.

Ron Gilbert (co-creator of Monkey Island) wrote an excellent blog post on puzzle dependency charts, and how they were used in Monkey Island.

Non-linear games correlates to a “wide” puzzle dependency chart, rather than a narrow chart. Wide games are overwhelmingly more fun to play than narrow games.

There will always be bottle necks in your puzzles that correspond to larger goals in your puzzle-game or narrative game, and as the player approaches the goal, the number of puzzles they have to consider shrinks, but this is a good way of overwhelming the player with too many seemingly random puzzles. Each phase of your game will be like the edge of a diamond in the puzzle dependency chart world.

If you want if your game is linear or non-linear, then check out Puzzlon, a free tool for visualising puzzles. You should read Ron Gilbert’s blog before checking out Puzzlon.

16. Everyone Enjoys A Good Laugh

I love games with humour and puns. If your game will have pun-related puzzles, then guide them make the first puzzle very simple so the player knows the author is a little bit silly. This is not appropriate for games that are serious of course. Never mix tones.

17. Memorable Characters

Quirky characters are a good way to build fun in a game. They can be completely one-dimensional, as long as that dimension is fun. Children especially love characters that convey a visible emotion (happy, sad, lonely, angry, confused).

(In Adventuron) You can convey these emotions in text, or optionally in a graphical portrait that appears above the character text. A : clear_screen; command followed by : print_graphic “graphic_id”, followed by character dialog, followed by a : press_any_key, followed by a : redescribe; is a good pattern when you are talking to a character that has a graphical portrait.

The more children connect with characters, the more they will love your game. See Over Here, or Spooky Adventure, for a good examples of how to use character portraits during dialog.

18. Build Tension Through Sudden Death + Rollback

I like a game with a bit of menace. The general consensus is that sudden death in a game is bad design, but I don’t think that it’s quite that simple. I will agree that true sudden death is a bad thing, but there are other types of “death” that can make a game infinitely more fun than no death at all. The first thing to make sure of is that you are using a game engine that supports “rollback”. That is, death should be reversible. In that way, a death is not truly a death, but rather a groundhog-day style learning experience.

For this type of “death”, it can be fun to be cruel to the player. If a player enters a spooky castle in a game that has no death there is no sense of tension or unease. If they walk straight in to the castle and there is poison gas in the air, and they die, accompanied by the : failure; jingle, it can startle the player, then lead to a giggle, then the player accepts the offer of “rollback” and they are safely outside the castle again. Now the player will have (a) a sense of adventure and danger (b) a new puzzle to solve, all without typing EXAMINE XXXX, or having to pre-warn the player about the gas.

(In Adventuron) Using the new “checkpoint” system in Adventuron is another way to use sudden death mechanics too.

If you are using a game engine that doesn’t have a rollback mechanic, you can still use sudden death to build tension, but you have to warn the player that death is approaching, multiple times if possible, so that they are prompted to save their game.

19. Avoid Unwinnable Scenarios

Make sure your game contains no unwinnable state transitions, anytime, but it’s the kiss of death at the start of the game.

If it’s possible for an action to destroy an object that is still required by a pending puzzle, then you should make sure that it’s possible to reset the state (get another of the same item) or to block the action with a reasonable excuse, “No, it looks expensive!”.

Absolute interactivity means the ability to destroy winnability in your game, and therefore complete interactivity should not (generally) be a goal.

Managed interactivity is required for objects that are critical to forward progress… The worst possible sin in text adventure game design is to leave the game in an unwinnable state without informing the player.

20. Barriers And Secrets

Games work best when there is some level of curiosity about what lies beyond a closed door, or an ice cold lake, or at the top of a spooky tower with no door … which is to say, don’t reveal too much of your map at first.

Solving puzzles to be rewarded with new graphics, locations, objects, and puzzles, is the part of the game loop that works best in the text adventure genre. The worst thing that you can do is to reveal 90% of your map right away, discovering new locations is an absolute joy.

In TWO, there is a blocked cave entrance, and an island on a lake, both of which are inaccessible at the start of the game. Teasing the player is good. By clearly revealing these locations as secondary goals, the players now understands the barriers as secondary objectives, which stimulates attention.

Designing a fun adventure is a mind-reading game.


As stated at the beginning, this isn’t the “one true way”, just my own feelings and opinions on ways to increase fun and decrease frustration after many hours of watching “let’s plays”, together with my own experience as a player.

What do you think? How many of the 20 points do you agree with? How many do you strongly disagree with? How many of the 20 do you think you have incorporated into your design?


Good article! A couple things I was planning on doing with my game I did not know were already considered “best text adventure practice”, namely, early hyperactivity, and also a sort of limited “warmup game”, for the newcomers. As for unwinnable situations, I was toying with a mechanism that would set a random # of turns delay, which would then notify the player later that it’s become unwinnable without explicitly telling them what they botched. Hardcore players could turn the notification off… but still not sure if I will implement it or simply disallow the player to destroy valuable items. I also didn’t know puns were a mainstay of a good game, and mine was going to attempt not a few. Also almost every character a bit quirky…
I’m in the process right now of paring down some empty locations… trying to find the balance between the blahness but also creating the sense of distance for parts that need it. I’m wondering if in a large world to explore, a single instance of two subsequent “travel-only” locs is forgivable in order to make a certain destination feel remote. Anyway…
I’m using a difference between ‘examine’ and ‘search’, however… all new players are highly stressed to read the instrucs before playing, and it is explicitly stated (for my game) that ‘search’ and ‘look in’ will always yield identical results. Therefore, ‘examine’ basically means to get a description of it by looking at it (which for some things, is the only kind of depth you need for any clue), but ‘search’/‘look in’ means either handling it or taking a close look inside/within. Yes, this opens the possibility that players have another verb to consider on an object, but only those objects which logically could have something “in” them (you don’t have to ‘search the rock’), and I hope it’s not unreasonable to suppose that ‘examine’ should not perform an implicit ‘open, manipulate and search’ on every object that could conceal something in any fashion.
I would enjoy doing a graphic adventure if I had the time/art skills, but for now I’m all text with a little bit of an opening screen, so it is what it is! Anyway, thanks for a good article.


Agree that 7. (examine then search) is quite annoying. Even more annoying is examine and then examine again to reveal more things that you didn’t see the first time round. Laurence Creighton does this often in his Zenobi games (along with random sudden death) and it is maddening. Which is a pity, as they are otherwise quite fun.

The broader question of whether any non-IF/TA enthusiasts (perhaps anyone outside of this forum) would ever bother with these games in any case, however many efforts are made to attract them, is something I do wonder about. I suspect they will remain forever a niche interest (suits me; who wants to be mainsteam anyway?).

1 Like

Mainstream is a relative term. To me it means non IF enthusiasts with a theoretical interest if friction was low enough.

1 Like

An interesting article. It’s a pity I didn’t find it before the Christmas jam. If I was to use it as a check list, I think my Christmas jam game met all the rules, except #18. There is no sudden death at Santa’s workshop. Even so, that doesn’t necessarily make it a good game. I think my players found the information gathering at the beginning a bit monotonous, simply because they didn’t read the responses to the things they’d already done and went off on a wild goose chase, rather than just concentrating on what they needed to do.

The only downside to these rules is that if you stick to them religiously, then your games become a bit formulaic. I prefer each game to have its own character and style. Some games will have lots of puzzles in the first room, some won’t have any. Some will have lots of barriers, some won’t. Some will have a concentrated map, some will be spread out. It really depends on the game.

I would like to add some extra suggestions for rules (in no particular order):

Have lots of variety in the puzzles. With some puzzles, you’ll find the puzzle before you find the objects needed to solve the puzzle. With others, you’ll find the objects needed to solve the puzzle, but you won’t know what those objects are used for until you find the puzzle.

Have some objects in plain sight and some objects hidden. Objects can be found by examining something, opening a container (perhaps locked in some way), completing a task (give money to hobo and he rewards you) and so on.

Objects should generally be found in a location where you would expect to find them in real life. For example, you would expect to find a shovel in a garden or on a construction site, not in the lounge room of a mansion.

There’s nothing wrong with a sprinkling of red herrings, especially if it adds to the realism of the game.

Don’t allow the player to carry around a zillion items. Inventory management can be just as much a puzzle as the puzzles themselves.

Modern players are very lazy and they want everything to be done implicitly. For example, if you OPEN DOOR and the door is locked, is it better to automatically use the hairpin to pick the lock, then open the door, or is it better to have the player work this out for themselves. Personally, I hate implicit actions, both as a player and an author (except in two-word games, where you have no choice), but if you’re going to use them, use them consistently and always give a response that explains what was done implicitly.

Have a variety of easy puzzles and hard puzzles. The hard puzzles should require some thought and perhaps some trial and error. If the player has a good idea, but it’s not the right solution, try to anticipate this and give them a funny response, an encouraging response (you’re on the right track, but…) or a subtle hint (the fork won’t fit in the lock, perhaps if you tried something finer).

Try to use everyday objects in unusual ways.

Try to have a mix of mechanical puzzles and logical puzzles, but keep obscure mathematical or scientific puzzles to a minimum.

Do not have puzzles that require specialist information (such as the mixing of chemicals or the formula for gunpowder) unless that knowledge can be gained from within the game.

Try to avoid stereotyped puzzles that have been done a million time before.

Make sure your map has a realistic transition from location to location.

Avoid guess-the-verb scenarios. Use common verbs with lots of synonyms. If you’re going to use an obscure verb, hint at it in one or two of your responses.


Sudden death would have spiced up Santa’s workshop no end.

Thoughtful response, but for heaven’s sake don’t call them ‘rules’. ‘Suggested guidelines for best practice’ is much less of a turn-off.

1 Like

I stand corrected. ‘Guidelines’ is certainly a better term.

This one won’t be popular with players, unless you’re putting some interesting spin on it. At a time it was just the done thing - I think all of Infocom’s games do it - but this is a remnant of the same false ideal of ‘realism’ as hunger daemons, limited light sources and randomised combat. I did it in The Party Line (in my defence, a jam game written in under two weeks) but honestly, I did it because it was easy. It superficially adds puzzle depth in that it causes the player to take longer to solve the puzzles, but not in a way that requires any creative thought.

The perceived utility to the author is that the player won’t accidentally solve puzzles just by happening to carry the right object at the right time in the right place. But as soon as they figure out that there are “carry the right object at the right time in the right place” puzzles in your game, you’ve effectively tasked them with an exhaustive search. Exhaustive searches aren’t fun.

In my parserlike games, the “holding” mechanism alleviates this a bit, but not totally. The proper solution is creative puzzle design, which is hard.


I won’t ever agree about the EXAMINE and SEARCH point… looking at something closely is simply not the same as searching through something, moving things in order to do so… As any parent who has ever sent their kids to find something will tell you.

If I examine some junk, I might see that it’s made up of a collection of old computer parts. If I search that pile of junk (or those parts) then I might reveal the computer mouse (object).

As long as you’re consistent, and hopefully flag the use of both early on, then I don’t see the issue.


The repeated EXAMINE (and indeed repeated SEARCH) is annoying when you go back to the games these days, but that was common behaviour during the time Laurence was writing, so the majority of his players would’ve been used to trying it. The same goes for a lot of the LOOK BEHIND, LOOK UNDER, that you get in games of that same vintage. Adventures were being written for a small, mostly closed circle of players back then… They weren’t being designed for a wider or mainstream audience.

I don’t have a problem with inventory limits as long as it’s not cruel. With cruel I mean, for example, 4 items like it is in some old, 2 word parser games. One thing I don’t like that was prevelant in old Infocom games is the juggling. I.e. when you pick up an item and you exceed your inventory limit and then drop TWO items. I have often missed that I dropped a vital item.

1 Like

The inventory limit has been an adventure game mechanic ever since ADVENT. It’s quite a reasonable thing to do. After all, the player is not a Mack truck. All the early games had an inventory limit and I used to really enjoy working out the optimum solution without dropping and getting items unnecessarily. And I still enjoy doing that. All authoring systems have an inventory limit (and a wearable items limit), but you can set it to a ridiculous number like 100.

Modern day players are really lazy. They’re not prepared to think or plan or draw a map or experiment or type anything more than they have to. To them, I say, “Tough luck”. My game has an inventory limit whether you like it or not, and if you don’t like it, you don’t have to play it. Mind you, some of my games have a LOT of objects. If there was no limit, you could get 3 or 4 screens of objects every time you take an inventory. Does that make sense? Of course it doesn’t. If your inventory is full, just drop the items you’re finished with. It ain’t rocket science.

Modern games also have GET ALL and DROP ALL. Is that too much to type? Give me a break.

Anyway, I’m an old fart and I like old-style adventures with lots of puzzles and reasonable limits on reasonable things, so I’ll stand my ground on this one.


I tend to agree. I’ve used SEARCH once or twice, but I’ve used it for good reason and only in situations where it makes sense to do so. For example, examining a haystack (“It’s big.”) is not the same as searching a haystack (“You find a needle in the haystack.”).

1 Like

I never had a Spectrum, so I’m not familiar with the UK games of that era. I remember that Jyym Pearson used the double EXAMINE (actually double LOOK) on several occasions. I thought it was unfair, but once you got used to it, you just got into the habit of trying it.

I can only remember one other game that used it. That was an Atari BASIC game. It really had me baffled until I went around reexamining everything.

I used it in one of my own games just recently, but the first examine gave you a hint that there might be something else to be found. No one complained about it, so I think it’s okay if you provide the hint.

The default inventory limit in Adventuron is 10, and a lot of authors don’t ever consider it.

In verb noun games in particular having an infinite pocket means that you might not know why your verb noun worked if you have every object in your pocket at the same time. I think 10 is a healthy number.

In games with complex parsers (or command builder UIs / speech UIs), then an infinite pocket doesn’t seem like a problem to me, as long as the game is not especially supposed to be grounded in reality.

I think 10 is reasonable.

Oh, I know - I’ve played loads of Zenobi and similar games by now. They’re great fun, but you do need to understand the lingo (examine and search everything, look under and behind, climb carefully etc) before they become enjoyable. Same with any game mechanic really: it’s only frustrating if you don’t know what you’re supposed to be doing.

Adventuron’s guidelines are a pretty good checklist for combining the best of the tried and tested (ie old) with things that cater for the sensibilities of modern players, I think.

Ten what, though? Ten bowling balls, or ten matchsticks? Some older games don’t make the distinction, and it can seem very silly when you’re forced to drop a toothpick in order to pick up a television. If authors insist on having an inventory limit, they should at least incorporate a system that gives objects a volume or mass.

There is something quite silly about allowing the player to carry around an infinite number of objects. I lampshaded it in my first ever game by having the PC complain about being asked to carry around yet another item. But it’s become a convention of modern IF, for the very good reason that inventory management, if it can be considered a puzzle at all, isn’t a very fun one.


It’s better if there is volume and mass, but I think 10 items on average when the items are evenly sized and with normal weight.

I don’t know if it’s considered an inventory puzzly, but the time-travel puzzle when you have to provide your younger self with the right objects in Sorcerer is one of the best in that game.


It’s a tricky one to get right really. In reality, holding ten of anything in your hands and still being able to do anything else, like unlock a door, is a pretty impossible task. But that’s somehow doable in an adventure game.

I’ve been thinking about this a bit as I’m (slowly, slowly) writing a game at the moment that has a bicycle in it as a mode of transport between locations. Currently you can hop on your bike while carrying a set of keys, a spade, a gravestone, your mother in law, some champagne glasses etc and still arrive at your destination without mishap! Not very realistic but something that your average text adventure player would hopefully turn a blind eye to.