Submissions open from 2025-03-01 00:00:00 to 2025-04-30 23:59:59
Starts in
years
months
days
hours
minutes
seconds

Aim

Write a text adventure that is suitable for beginners to this genre. The game must include an in-game tutorial.

Schedule

You can start your game at any time, but you can't submit your game until submissions open. There are two months for submissions and one month for judging.

Submissions open:1 March 2025
Submissions close:30 April 2025
Voting opens:1 May 2025
Voting closes:31 May 2025
Results announced:1 June 2025

All times and dates are in UTC time. The itch.io banner shows the times for your local time zone.

Background

This is the fifth annual Text Adventure Literacy Jam.

The concept of the Text Adventure Literacy Jam is based on the Text Adventure Literacy Project (TALP) launched by Chris Ainsley in 2019. The goals of the TALP were threefold:

  • To encourage authors to create text adventures that target beginners to the genre.
  • To teach a new generation the skills required to play classic text adventures and, in doing so, encourage them to create their own games.
  • To provide an easy acronym (TALP) to search for beginner-friendly text adventures on the internet.

The Text Adventure Literacy Jam addresses the first and third of these goals. The games produced for the jam will hopefully address the second of these goals.

Is this competition appropriate for you?

Writing a text adventure is hard. Writing a text adventure suitable for beginners with an in-game, context-sensitive tutorial is very hard.

If you have never played a text adventure, then you should not enter this competition as an author, as you will not have the knowledge or experience to appreciate what constitutes a beginner-friendly text adventure. However, the games produced are intended for you and you are strongly encouraged to play and rate all the games.

If you have never written a text adventure, but you have played several text adventures and you are familiar with all the conventions, then this competition may be suitable for you. First-time authors are welcome, but we recommend that you find a mentor that will help you write your first game. Make sure you start planning early and allow plenty of time for testing.

If you have written a text adventure before and you have played several text adventures, then you know what it's all about. This competition is for you.

If you need some inspiration or you want to see how others have approached a game intended for beginners, see the higher-rated games from past competitions:

Irrespective of your experience, everyone is encouraged to play and rate all the games when the voting period opens.

Please join our Discord server to chat, ask questions, find a mentor, create a team or communicate with the organisers.

Theme

The theme for this year's competition is 'Time travel'. The theme is optional, so you are not obligated to use it. If you are looking for ideas, there is no shortage of inspiration from books, TV and movies. The Time Machine by H G Wells, Dr Who, The Terminator and Back to the Future are just a few of the classics. Do an internet search for 'time travel' and you will be inundated with ideas.

Rules

Despite the name, this is a competition, not a jam. All entrants must adhere to the following rules. See the guidelines below for further elaboration of the rules and general recommendations.

  1. The game can be written in any programming language for any computing platform.
  2. The game must be a text adventure, also known as parser-based interactive fiction.
  3. The game must use the keyboard for input. Input is in the form of text commands expressed as simple English sentences.
  4. The text commands must be processed by a parser.
  5. The game must use text output to show the results of each command.
  6. The game can use graphics and/or audio, but this is not mandatory.
  7. The game must be in English.
  8. The game's title must have a '(TALP)' suffix on itch.io.
  9. The game must have clear instructions on how to play.
  10. The game must have a tutorial at the start of the game. The tutorial can optionally be turned on and off.
  11. The game must have at least five puzzles, not including any 'give-away' puzzles in the tutorial.
  12. The game must not include any offensive content. Any game with adult content must have a content warning at the start of the game.
  13. The game should preferably be merciful or polite on the text adventure cruelty scale.
  14. The game must be an original work that has not previously been published. The game can be made public 24 hours before submissions close.
  15. The game must not contain any copyrighted material, other than your own, unless you have obtained permission to use that material or it is covered by the fair use provisions of the copyright law in your country.
  16. The game must not use any AI-generated code or text content. AI generated images are permitted, providing credit is given.
  17. The game must be free to play for the duration of the voting period.
  18. If the game can be played online, it must additionally have a downloadable version that can be installed and played offline.
  19. The author must agree that the downloadable version of their game can be archived on the Interactive Fiction Archive for preservation purposes.
  20. The game can be a collaboration, but must be submitted under a single itch.io account. Any prizes will be submitted to the owner of that account.

Any games that do not adhere to the rules will be disqualified.

Guidelines

The following guidelines provide additional advice and recommendations to assist with interpretation of the rules.

Programming language

This is related to rule 1.

The game can be written in any programming language, but it is much easier to use one of the well-known, long established adventure authoring systems, as this will have a strong support community and will already do a lot of the hard work for you, such as the parser and a library of commonly used functionality.

Common authoring systems for retro systems include:

  • DAAD
  • GAC (Graphic Adventure Creator)
  • PAWS (Professional Adventure Writing System)
  • The Quill

Common authoring systems for modern systems include:

Platform

This is related to rule 1.

The game can run on any platform, from 8-bit and 16-bit retro computers to modern Android, iOS, Linux, Mac and Windows-based operating systems, including desktop computers, laptops, tablets and mobile phones.

In order to have your game played and judged by the maximum number of people, it is recommended that your game can be played using a web browser. Anything else is a bonus.

What is a text adventure?

This is related to rule 2.

A text adventure is a form of computer game that uses natural language processing to communicate with the player. The player enters commands in simple English sentences. A parser processes the input to break the command into individual words and matches these to patterns or grammar rules. If the player has entered a properly formed sentence that is understood by the game, then this is converted to actions that allow the player to move around the game world, examine things, manipulate things and interact with non-player characters in order to solve puzzles. In the process, the game reveals a story.

Text adventures were first developed on mainframes in the 1970s and became very popular in the home computer boom during the 1980s and early 1990s. Companies stopped producing commercial text adventures in the late 1990s, but they never died out, they just went underground. Many authoring tools were developed to make it easier for amateur authors to produce their own text adventures and these are still being developed or improved to this day.

Nowadays, text adventures are usually referred to as parser-based interactive fiction to distinguish them from other forms of text-based games and other forms of interactive fiction. There are many jams and competitions for text adventures and other forms of interactive fiction held each year.

Input

This is related to rule 3.

The keyboard may be a physical keyboard or a virtual keyboard on a touch screen.

The game may use additional touch, mouse, joystick or voice inputs, but the game must be completable with the keyboard alone.

Choice-based input should be avoided, but may be used sparingly, such as for a menu-based conversation system or hint system. If minimal choice-based input is used, the options should still be selectable by keyboard.

The game may use two-word input (verb and noun) or multiple-word input. Remember that you are writing a game suitable for new players, so use the input that is easiest for them to use. For example, PUT THE CHICKEN IN THE OVEN is fairly easy for a new player to understand, but how do you express that in two words? Make sure you use lots of synonyms and various ways of achieving the same thing. For example, GIVE MEAT TO DOG and FEED DOG WITH MEAT should both achieve the same result.

Do not use SEARCH as a verb, unless it is a synonym for EXAMINE, it is an obvious thing to do (such as searching a dead body) or there is a hint to indicate that this is something you should try.

Processing

This is related to rule 4.

The parser is crucial to a text adventure. You do not need to know how the parser works, but it should be easy to see from the commands and responses that the game uses a parser. All the established authoring systems use a parser, so if you use one of these, you will be safe.

In essence, the parser is responsible for breaking the player's command into individual words (lexical analysis), matching those words to patterns or grammar rules (syntactic analysis), and determining what actions to perform (semantic analysis).

Output

This is related to rule 5.

Output includes describing the current location in the game world, listing any exits from the current location, describing any objects in the current location, providing responses to each command and describing any changes in the game world due to the independent actions of non-player characters, timers and daemons.

There is no limit to the length of output text, but be considerate to the player. Long flowery descriptions should be avoided if they are not important to the game. As a general rule, location descriptions and responses should be concise. Any scenery mentioned in location descriptions should be examinable.

Any messages related to the tutorial should be identified in some way, such as a different colour, italics or surrounded by square brackets, depending on the capabilities of your game or the game's interpreter.

Please be considerate to visually-impaired players, who may be using a text reader to play your game. For example, if using ASCII graphics, provide an alternative text-only description for visually-impaired players.

Multimedia

This is related to rule 6.

Graphics, animation, music and/or sound effects may be used in your game to make it more appealing to a beginner. However, this is not mandatory and there must be nothing in the multimedia that provides hints that are not given in the text output.

Language

This is related to rule 7.

All text input and output must be in English, except for any 'flavour' text. Flavour text may include things like signs, books, speech or puzzles that may be in a foreign language, alien language, fantasy language or code.

TALP suffix

This is related to rule 8.

TALP is an acronym for Text Adventure Literacy Project. The game's title must have a '(TALP)' suffix on itch.io. This is so that it can be easily found when doing an internet search. The TALP suffix does not need to appear within the game itself.

Instructions

This is related to rule 9.

Remember that you are writing a game for people that are new to text adventures, so you should write instructions with those people in mind. The instructions may be on the itch.io game page, in the game itself or both. If using both, consider writing long instructions on the game page and a summary (or memory jogger) in the game itself. Keep the instructions concise, as people hate reading instructions.

Consider using a HELP command for the in-game instructions.

Tutorial

This is related to rule 10.

In-game tutorials are very hard to write, so plan this carefully. As a minimum, your tutorial should explain the screen layout and command prompt, how to refresh the location description when it scrolls off the screen, how to move about, how to examine things, how to pick things up, how to drop things and how to take an inventory to see what you're carrying. Other things to consider are wearing and removing clothing, opening and closing doors or containers, and interacting with non-player characters.

You should consider a 'give-away' puzzle at the beginning of the game and walk the player through that puzzle. The puzzle can be 'on rails', whereby the player can't do anything other than follow the tutorial. A better approach is to provide a 'smart' tutorial, where the tutorial provides guidance along the way, but the player can follow it or ignore it at their own discretion. Do not repeat the same tutorial hint over and over again.

For experienced players and anyone playing the game multiple times, allow the tutorial to be turned on and off using commands such as TUTORIAL ON and TUTORIAL OFF.

Puzzles

This is related to rule 11.

Text adventures typically consist of exploration, examination and manipulation of objects in order to solve puzzles. You can think of this as a text-based escape room. There is no restriction on the type of puzzles you use, but you should have a variety of puzzles, some easy and some not so easy. As this game is targeted at beginners, you should probably avoid very difficult puzzles.

All solutions to puzzles should be hinted at in subtle (or not so subtle) ways. Make sure you allow for different ways of expressing commands that the player will use to solve the puzzles. There should be little or no guess-the-verb, as this will cause the player to get frustrated and give up.

The solutions to puzzles should not require any specialist knowledge. As a general rule, everything needed to solve a puzzle should be provided in the game.

Consider providing a context-sensitive HINT command for when a player has missed or forgotten a hint, or runs out of ideas.

Content

This is related to rule 12.

The competition has an optional theme of 'Time travel'. You are not obligated to use the theme. If you don't use the theme, then there is no limitation on plot or story line.

Your ideas and inspiration can come from anywhere, including AI, but the writing and coding must be entirely your own work. Fan fiction and parodies of published works are permitted, subject to the fair use provisions of the copyright law in your country.

The game must not include any offensive content including hateful, racist, misogynistic or homophobic content, or anything that would make people feel bad about themselves.

Adult content (such as sexual references, swearing, violence and drug use) is permitted, but it must provide a content warning at the beginning of the game.

It is preferred that your game is G-rated (suitable for a general audience) and would appeal to children.

Cruelty scale

This is related to rule 13.

The text adventure community uses a cruelty scale to measure how fair a game is to the player. This is a measure of fairness, not a measure of difficulty.

The scale was devised by Andrew Plotkin and has five ratings of merciful, polite, tough, nasty and cruel. As your game is intended for beginners, you should aim for a cruelty scale of merciful or polite.

Merciful means the player can never die or get into an unwinnable situation.

Polite means the player can die, but cannot get into an unwinnable situation.

In the case of a polite game, you can kill the player if they get into a dangerous, but avoidable, situation or they do something stupid. However, there must be no 'sudden death'. Sudden death is death without warning. For example, you enter a location and get shot by poison darts or fall into a pit of man-eating crocodiles, even though there was nothing beforehand to indicate there was any danger in that location.

If your game can kill the player, then it should include UNDO, so that they can go back one move without having to restart from the beginning or restore a saved game.

Publication

This is related to rule 14.

Neither the source code nor the story file or executable can be published in a public place prior to the submission closing date. The only exception is that the game may be a finished version of a game that was previously entered in IntroComp. You can send the game to testers, but this must not be done in a public forum.

If you are storing your source code in a repository, such as GitHub or GitLab, make sure it is a private repository. You can make this public after the submission closing date.

When your game is ready for testing, it is recommended that you upload it to itch.io, mark it as private and add a password for access. You can then give the url and password to your testers via email or a private message.

You can submit your game any time before the submission deadline, but it should remain private if you submit early. You can make your game public on itch.io within 24 hours of the submission deadline.

Copyright

This is related to rule 15.

You retain the copyright to your game unless placing it in the public domain.

All works are copyrighted by default, but you should include a valid copyright statement at the start of the game, so that it is clear that it is not in the public domain. The copyright statement should include the year of publication and the copyright holder's name, e.g. 'Copyright (c) 2025 Joe Bloggs'.

If the game is in the public domain, then this should be stated instead of a copyright statement, e.g. 'This game is in the public domain'.

Any licence restrictions should be made clear at the start of the game.

AI content

This is related to rule 16.

We realise this is a controversial topic, so we want to be conservative, but not unreasonable. You can use generative AI (such as ChatGPT) to get ideas, in the same way that you may visit a library or use a Google search to do research. However, you must not use AI to generate code or write any of your descriptive text.

If your game uses graphics and you are not an artist, then we will allow AI-generated images. However, you must acknowledge the source of the images in the credits, e.g. 'Images generated using Midjourney' (or NightCafe or 123RF or whatever). Of course, it is preferable that you do the images yourself or get an artist to do them for you.

Free to play

This is related to rule 17.

The game must be free to play for the duration of the voting period. You can use the itch.io optional payment system if you want. Mandatory payment can be added after the voting period closes.

Downloadability

This is related to rule 18.

If providing a browser-based game (such as Adventuron), you must additionally provide a downloadable version for those that prefer to play offline, perhaps to use a screen reader or to play without internet access. This also allows the game to be archived for future generations.

If providing a game that must be downloaded in the first place, you must provide full details on how to play it, including any emulators and/or interpreters required. For common game file formats, such as ADRIFT, Glulx, TADS and Z-code, do not package the interpreter with your download, as this just bloats the download for players that already have their own preferred interpreter for their system.

Archival

This is related to rule 19.

When submissions close, details of your game will be entered in the Classic Adventures Solution Archive (CASA), Interactive Fiction Database (IFDB) and possibly other places. These may provide links to the online version of your game and the downloadable version of your game. In the past, we have seen games removed from itch.io, causing broken links and no way for people to play the games recorded in databases, unless they happen to be captured by the Wayback Machine at the Internet Archive. In order to prevent these problems, we may archive all the downloadable versions of the games at the Interactive Fiction Archive. If you do not want your game to be archived, then do not enter the competition.

Collaboration

This is related to rule 20.

Most text adventures are solo affairs, but collaboration with other people is permitted. For example, one person may design the game and other people may do the coding, graphics and/or sound.

The game must be submitted under a single itch.io account and any prizes will be sent to the owner of that account. It is up to that person to share the prize with their collaborators as they see fit.

Testing

Games should be thoroughly tested by the author, then tested independently by other people. Try to allow at least two weeks for testing. This gives your testers about one week to thoroughly play and test your game and submit their feedback. That gives you about one week to do any bug fixes and enhancements and do a final round of testing if necessary.

You can request testers on the Community page, on our Discord server or in the beta testing category at intfiction.org. Try to get three to seven testers. Ask testers for a commented transcript and any further comments and suggestions in a text file. If you are looking for anything specific (such as how long it took to play or were the puzzles too easy or too hard), let them know before they start testing.

As your game is meant to be targeted at beginners, try to include some new players in your test team. This can be friends, family or work colleagues.

Testers are your friends. Treat them with courtesy and respect. Listen to what they have to say and don't get defensive if you disagree with them. They are trying to help you and doing it for free.

You should also offer to test other people's games.

Voting

  1. Games are available for download, playing and voting from 1 May 2025.
  2. Anybody with an itch.io account can vote for games, including the organisers and prize donors.
  3. Entrants cannot vote for their own game(s).
  4. Entrants and judges are encouraged to promote the competition, but they must not encourage others to vote for a particular game, uprate a particular game or downrate any games.
  5. Judges can only vote once for each game. Any attempt to vote for the same game multiple times using multiple itch.io accounts will be carefully monitored by itch.io and the organisers. If any instances of cheating are detected, all those votes will be cancelled. If the cheating is instigated by an entrant, then that entrant's game will be disqualified.
  6. Games will be rated on:
    • Story (plot, goal, prologue, atmosphere, gradual revealing of story, conclusion)
    • Writing (clarity, spelling, grammar, punctuation, capitalisation)
    • Puzzles (originality, fairness, consistency with the game setting)
    • Implementation (technical aspects, lack of bugs, responses to unanticipated commands)
    • Beginner-friendliness (easy to play, no 'guess-the-verb', appropriate in-game hints, usefulness of HINT command, quality of tutorial)
    • Documentation (quality of your itch.io game page, including attractiveness, instructions and any downloadable extras, also known as 'feelies')
  7. Each category is rated from 1 star (poor) to 5 stars (excellent).

Prizes

Prizes will be awarded as follows:

  1. US$150* donated by anonymous
  2. US$100* donated by Garry Francis
  3. US$100* donated by John H Doolittle
  4. US$50* donated by Gianluca Girelli
  5. A Guide to ZX Spectrum Adventure Games 1982 - 1985 by Shaun McClure, donated by the author
  6. [TBD]

*The winner of any cash prize must have a PayPal account.

Prize terms

The organisers are not eligible for prizes. If an organiser submits a game that would be eligible for a prize, then this prize passes to the next place getter. If a prize donor wins their own prize, then their prize will be swapped with the next place getter.

Prize donations

All prize donations are greatly appreciated. Prizes do not have to be cash. They may be T-shirts, books, computer games, vouchers or anything else that is likely to be of interest to text adventure authors. If you would like to donate a prize, please contact the organisers.

Contact

The organisers can be contacted using one of the methods below:

Credits

Cartoons in the banner were drawn by Ron Leishman of Toonaday.com.