Results

The results are in.

1.	Who Kidnapped Mother Goose?
2.	The Basilisk and the Banana
3.	Lysidice and the Minotaur
4.	Bakemono no Sekai - World of Monsters
5.	The Wolf
6.	A Princess Saves a Dragon
7.	Lulu and the Asteroid of 100% Guaranteed Doom
8.	Their First Meeting
9.	Day Out
10.	Camelot Jack

Congratulations to all the winners and thank you to all the authors and judges for another great competition.

Introduction

This is the fourth annual Text Adventure Literacy Jam.

The aim is to write a text adventure that is suitable for players with little or no prior experience of playing text adventures. The game must include an in-game tutorial.

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.

If you need some inspiration, see the games in:

• Text Adventure Literacy Jam 2021
• Text Adventure Literacy Jam 2022
• Text Adventure Literacy Jam 2023

Please join our Discord server to chat, ask questions and communicate with the organisers.

Changes this year

There are two new rules regarding the use of AI generated content and the provision of a downloadable version of your game for archival purposes. A couple of other rules have been added to clarify questions raised last year.

We have also introduced an optional theme (described below).

Theme

The theme for this year's competition is 'Fairy tale'. The theme is optional. You are not obligated to use the theme. If you do, you might want to consider the following ideas.

• Develop a game based on an existing fairy tale. There is a myriad of inspiration in the works of Aesop, Charles Perrault, Hans Christian Andersen and the brothers Grimm, but consider looking further afield to the lesser known works, such as Andrew Lang's fairy books and the rich body of works in non-European cultures.
• Develop a game inspired by an existing fairy tale. In this case, you can take the characters, setting or general storyline and develop a new fairy tale so that the outcome is not known in advance. You may also consider a 'fractured fairy tale' where you twist or distort the original fairy tale like they did in The Rocky and Bullwinkle Show and various Looney Tunes.
• Develop a game that's a mash-up of various classic fairy tales.
• Develop a game based on your own original fairy tale.

A Google search for fairy tales will produce lots of inspiration. As most of the books on classic fairy tales are now out of copyright, they are available at places like the Internet Archive (if you know what you're looking for) and Project Gutenberg.

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:	Friday, 1 March 2024
Submissions close:	Tuesday, 30 April 2024
Voting opens:	Wednesday, 1 May 2024
Voting closes:	Friday, 31 May 2024
Results announced:	Saturday, 1 June 2024

All open times are from the start of the day and all close times are at the end of the day. Dates and times are in UTC time. itch.io converts the dates and times below the banner to your local time.

Rules

Despite the name, this is a competition, not a game jam. All entrants must adhere to the following rules. See the guidelines for further elaboration of the rules and general recommendations. The guidelines are cross-referenced to the rules.

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 be merciful or polite on the text adventure cruelty scale.
14. The game must be an original work that has not previously been published or is a finished version of a game that was previously entered in IntroComp. 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 act 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 will be asked if they agree to the downloadable version of their game being 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 and platform

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:

• ADRIFT (Adventure Developer & Runner - Interactive Fiction Toolkit)
• Adventuron
• Alan (Adventure LANguage)
• Dialog
• Hugo
• Inform 6 using the standard library
• Inform 6 using the PunyInform library
• Inform 7
• Quest
• TAB (ThinBASIC Adventure Builder)
• TADS (Text Adventure Development System)
• ZIL (Zork Implementation Language)

The game can run on any platform, from 8-bit and 16-bit retro computers to modern Android, iOS, Linux, Mac and Windows 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 you target the most common platforms.

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 match 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 speech 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 do.

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 beginners. 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 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. 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.

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 your game is intended for 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.

We have introduced an optional theme this year. You are not obligated to use the theme. If you do, then see the suggestions at the top of this page. Otherwise, there is no limitation on plot or storyline.

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 act 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 originally 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 to indicate that 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. 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 in 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 © 2024 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 Night Cafe 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 platform.

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/or 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 in future, we will archive the downloadable version of your game at the Interactive Fiction Archive if you give your permission to do so. You will be asked for your permission when you submit your game.

Collaboration

This is related to rule 20.

Most text adventures are authored by individuals, 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 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 suitable for 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 they're 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 2024.
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 the following categories:
   • 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)
   • Tutorial
   • Documentation (any external instructions, game page, feelies)
7. Each category is rated from 1 star (poor) to 5 stars (excellent).

Prizes

You've got to be in it to win it and we have some great prizes:

1. US$100* donated by Garry Francis
2. US$100* donated by pinkunz
3. US$100* donated by John H Doolittle
4. €50* donated by Gianluca Girelli
5. Three puzzle books from Critical Thinking Press donated by John H Doolittle

*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.

Prize donations

We are seeking further prize donations. 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 using one of the methods listed below.

Contact

If you need to contact the organisers, please use the Discord server, a private message at intfiction.org or the Community page. We have an email address at TextAdventureLiteracyJam, but this is not monitored very regularly, so your reply may be delayed.

Credits

Cartoon in banner adapted from an image by Ron Leishman of Toonaday.com.