Ratings

This jam is now over. It ran from 2023-04-12 00:00:00 to 2023-05-31 23:59:59. View results

Introduction

This is the third annual Text Adventure Literacy Jam.

The aim of the jam 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 and Text Adventure Literacy Jam 2022.

Please join our Discord server to chat, ask questions and communicate with the organisers: https://discord.gg/57uuPGrCsR

Schedule

Submissions open:	00:00:00 Wednesday, 12 April 2023
Submissions close:	23:59:59 Wednesday, 31 May 2023
Voting opens:	00:00:00 Thursday, 1 June 2023
Voting closes:	23:59:59 Friday, 30 June 2023
Results announced:	00:00:00 Saturday, 1 July 2023

All times and dates are UTC. Don't forget to adjust for your local time zone.

Rules

Despite the name, this is a competition, not a game jam. All entrants must adhere to the following rules. Any games that do not adhere to the rules will be disqualified.

See the guidelines below for further elaboration of the rules, general advice and recommendations.

The game can be written in any programming language for any computing platform.
The game must be a text adventure, also known as parser-based interactive fiction.
The game must use the keyboard for input. Input is in the form of text commands expressed as simple English sentences.
The text commands must be processed by a parser.
The game must use text output to show the results of each command.
The game can use graphics and/or audio, but this is not mandatory.
The game must be in English.
The game's title must have a '(TALP)' suffix on itch.io.
The game must have clear instructions on how to play.
The game must have a tutorial at the start of the game. The tutorial can optionally be turned on and off.
The game must have at least five puzzles, not including any 'give-away' puzzles in the tutorial.
The game must not include any offensive content. Any game with adult content must have a content warning at the start of the game.
The game should preferably be merciful or polite on the text adventure cruelty scale.
The game must be an original work that has not been previously published. The game can be made public 24 hours before submissions close.
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.
The game must be free to play for the duration of the voting period.

Guidelines

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

Platform

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 you target the most common platforms. In any case, you must provide full details on how to download and play your game, including any emulators and/or interpreters necessary to play the game.

If providing a downloadable game, it is recommended that you also provide a browser-based version, if possible, as anyone can play your game in a browser.

If providing a browser-based game, it is recommended that you also provide a downloadable version for those that prefer to play offline, perhaps to use a screen reader.

Programming language

You can write the game in any programming language, but it is much easier to use one of the well-known 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 (Text Adventure Builder)
TADS (Text Adventure Development System)
ZIL (Zork Implementation Language)

What is a text adventure?

A text adventure is a form of computer game that uses artificial intelligence and 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 tools 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

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 must 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

The parser is crucial to a text adventure. You do not need to know how the parser works, unless you are writing your own. All the established authoring systems provide a parser, so you will be safe if you use one of these.

Output

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 screen reader to play your game. For example, if using ASCII graphics, provide an alternative text-only description for visually-impaired players.

Multimedia

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

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

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

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

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 are 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 cannot 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

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

There is no theme and no limitation on plot or story line.

Your ideas and inspiration can come from anywhere, 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

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

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

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 © 2023 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.

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

Voting

Games are available for download, playing and voting from 00:00:00 UTC on 1 June 2023.
Anybody with an itch.io account can vote for games, including the organisers and prize donors.
Entrants cannot vote for their own game(s).
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 particular games.
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.
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)
- Tutorial
- Documentation (any external instructions, game page, feelies)
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:

US$100* donated by Garry Francis.
US$100* donated by pinkunz.
US$100* donated by an anonymous donor.
€40* donated by Gianluca Girelli.

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

Prize terms

The organisers are not elligible for prizes. If an organiser submits a game that would be elligible for a prize, then this prize passes to the next place getter.