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.
Epilogue
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?