Announcing the "Text Adventure Literacy Jam" - starts Feb 25th

Announcing the Text Adventure Literacy Jam.

The theme of the jam is to “Create a TEXT ADVENTURE game suitable for children with no prior experience”.

Whilst games that offer an in game tutorial are nothing new, many of these games are still not suitable for absolute beginners to the genre, or even if they are, they are difficult to find.

The concept for this jam has been brewing for almost a year. This is the sixth Adventuron gamejam with all previous jams inviting newcomers to coding to code their own text adventure games. This jam is different in that it invites experts (or determined amateurs) to code a parser game for children.

Making these games accessible is the purpose of this jam. Until there is a younger audience for parser games, then the community is destined to die out, This is the first “Adventuron” jam that does not have an “Adventuron only” system requirement.

The jam as usual has a variety of prizes, including a Raspberry Pi 400, a Raspberry Pi 4, a Raspberry Pi Pico, a printed edition of Classic Adventurer magazine, as well as Pico-8 licenses. More prizes may be added before the end.

Thank you for the sponsors and if you feel like you would like to sponsor the jam somehow, mail .The only rule for sponsorship is that you cannot add a system specific prize, all prizes must be placed in the placement or the participation prize pools.

The jam itself is opinionated, and perhaps that will put a lot of people off from entering.

The purpose is to make a set of rules to avoid design pitfalls that seem to plague beginner players.

Games are required to have at least 6 locations, 6 puzzles, 6 objects, and an interactive tutorial that guides the player through concepts such as getting an object, dropping an object, checking inventory, examining an object, compass movements, and solving initial puzzle(s). Help and hints throughout a good portion of the game are encouraged, as are optional cheetsheets.

Brevity is the order of the day with locations allowing a maximum of two sentences to describe themselves, and responses being similarly limited.

The parser for the purpose of the jam is limited to VERB NOUN, and only rational directions are permitted (no diagonals or unidirectional connections, except for blocks).

SEARCH and EXAMINE must be synonyms, and all nouns must have a custom EXAMINE response

Making a game with graphics is encouraged, but it is not required. It is expected that children expect some level of graphical presentation, even if simple, but this rule is relaxed for the sake of perhaps using the jam to make a fast paced text only game instead.

More design rules are described on the jam page itself, but they all serve to reduce new player friction, at a cost of course of author freedom.

A full rules are available at this link here ( Text Adventure Literacy Jam - ).

Source code for the TALP version of Excalibur is provided to provide information on the design and implementation of an interactive tutorial.

It is strongly encouraged that games are playable in the browser, but this is not a requirement.

The judging methodology is not yet announced and discussions with possible judges are underway.
Having parent/child judges is not something I’ve ruled out - because after all - the jam is targeting younger players. I’ve asked a number of community figures to consider being judges too, but it’s too early to announce a panel yet.

Using the TALP suffix in conjunction with TEXT ADVENTURE in a Google search should be able to find many games that are beginner level, and assume no prior knowledge.

The goal with this jam is to win a new audience, an audience of the joyful variety. To do this the author burden must be increased unfortunately. I do hope this doesn’t put off people from joining in.


NOTE: There will be no summertime jam this year in order to make way for ParserComp 2.0.


Very nice selection of prizes.

1 Like

I love this idea!!! More IF for kids, please!


I think this is a great initiative and I hope the rest of the parser-based community gets behind it. The timing is also good because it allows us to work on a small game before ParserComp kicks off. Submissions close on 1 April, so that still gives us 4 months to work on ParserComp entries.

I’ve got an idea in mind. The tutorial aspect is going to be a challenge, but I’m always up for a challenge.


You mentioned that you were thinking about doing a choice-based Adventuron game jam. If you decide to go ahead with this, you could probably run it during your summer (my winter) without conflicting with ParserComp. I imagine that there would be minimal overlap, as the prospective authors in each comp tend to work in one genre or the other. I know there are a few exceptions, but they’re probably not Adventuron users anyway.

Just an idea. Feel free to ignore it.

1 Like

You mentioned that you were thinking about doing a choice-based Adventuron game jam. If you decide to go ahead with this, you could probably run it during your summer (my winter) without conflicting with ParserComp. I imagine that there would be minimal overlap, as the prospective authors in each comp tend to work in one genre or the other. I know there are a few exceptions, but they’re probably not Adventuron users anyway.

Yes, I’ve considered this. Indeed it might be an ideal time to try it as ParserComp 2.0 has a “Must use a parser requirements” being an ideal contrast to “do not use a parser”. It might be a good time to take a rest too, hosting jams takes a lot of work, and it’s a good excuse to take the summer off :slight_smile:

1 Like

This seems to be a very interesting competition and I am considering to enter an ADRIFT game. Thus I started to work on a Verb-Noun-library, which fulfills all the rules. However, I have some questions about the rules, both some general questions and some specific questions useful if you write with ADRIFT.

  1. ADRIFT games can be distributed as Windows executables and adrift-blorb-files but they can also be played online. To play online, I would have to upload an empty game-file to the ADRIFT site and then point at it from my submission page on Once the games are live, I will replace the empty game-file on the ADRIFT site with the real game. Would this be acceptable?

  2. By default, ADRIFT displays a location on the map when the player has visited that location. It is possible to display the entire map when the game begins and it is also possible to click on locations to navigate. Is this allowed? It is possible to disable navigation by clicking, so the map is still displayed and it is possible to turn the map off completely, which I think is a shame as it adds something positive to the game (the player can turn it off if they want to).

  3. If not, I suppose I can still include a map either in location graphics or object graphics, such as if I examine a map I have found?

  4. In addition to east, west, north, south, is it allowed to go up and down e.g. some stairs?

  5. The number of objects should be at least six. Does that mean carryable objects or also e.g. scenery objects?

  6. It may be because I am not a native English speaker but exactly how is a suffix applied? Something like: The Big Adventure(TALP) ?

  7. Rule 15 says “Sudden death is not permitted unless your game supports auto-save, and quick restore.” Is UNDO acceptable as a “quick restore” ?

  8. The location description can be maximum two sentences. Does this include the line saying e.g. “You can go east and west from here.” ?

I know it is a lot of questions but I think it is important to get it right so no one gets disqualified.
Thanks :slight_smile:

  1. Yes, that sounds fine.
  2. As long as the game is playable via the keyboard without clicking, then any additional click controls are permitted
  3. Yes
  4. Yes, but not diagonals (ne, nw, se, sw).
  5. It is ambiguous in the rules, so assume 6 objects including scenery.
  6. TALP must be added at the end, it can be with any punctuation (or no punctuation) as you wish. Putting in parenthesis seems fine to me.
  7. If with UNDO you can instantly go back to the point before death, then it is acceptable. But the player must be told that they can do this.
  8. The exit list sentence and object list sentence is not included in those two sentences. I’ll update the rules to make this clear.

Thank you for the quick reply :smiley:

1 Like

@Denk, Regarding question 1, can you please provide the data file (or blorb file) as a downloadable file, perhaps in addition to the online option? I hate having to download a huge Windows executable (which our non-Windows friends won’t be able to use anyway), when I can just download the data file, store it locally and play it using Adrift Runner.

Sure, I will upload the blorb-file without the executable. I was under the impression that I can add more than one file on but perhaps that is not the case for competitions/jams?

If I can only upload one file, I will leave out the executable and upload a zip file containing:

  • blorb-file
  • html-file pointing at online version
  • A cheat sheet

I suppose I can put a link on the submission page to those who would like the executable. Sometimes, people new to ADRIFT find that easier despite the false positives given by some antivirus-software.


You can place any number of downloads on the game page. I sincerely doubt that the game jam infrastructure places any limits on this. I’ve certainly seen others put multiple downloadable files for things like source code and hints or solutions.


There are some limits, but they’re pretty generous and they’re just to help with spam: if you e-mail and ask I believe they’ll raise the limits for you without having you jump through any particular hoops.

IIRC it’s 10 files per project and…maybe 1GB per file?

Looks like a fun jam! :slight_smile:

A few questions:

Rule #3: Are we required to reject any input that isn’t two words? For instance as long as “TALK TROLL” is accepted, may we also accept “TALK TO THE UGLY TROLL”.

Rules #6,7,8: Does the sentence count include tutorial text?

Rule #9: Are IN and OUT ok?

Rule #22: I’m not sure I understand what a “complex” container is, from the examples (get thingamabob from box, put banana in bowl) it seems like any container would be banned (they would already be hamstrung by the VERB NOUN parser constraint anyway)

1 Like

Rule 3 -. It’s a hard two word limit. The reason for this is to keep it super simple. If every time the player types more than two words it tells the player, the game only accepts (a maximum of) two words, then the player knows the constraints and isn’t trying extra words to see if something will work. The moment you break the rule and allow three words, kids are going to try extra words “just in case”.

6,7,8 - Tutorial text should be a maximum of two sentences, and isn’t included in the response text or location text limits. I’ll clarify this.

9 - Yes, IN / OUT / ENTER / EXIT are OK.

22 - Containers are allowed, just not complex container implementations. e.g. EXAMINE BOX (creates some objects that are contained inside the box - fine). Being able to put things in and out of a box is not allowed. Again, I’ll clarify.

1 Like

Just to be absolutely sure: You wrote that Excalibur could be used as a reference. In Excalibur, I noticed that when you include the optional word “the” then three words are allowed, e.g. GET THE LADDER.

So should the parser be stricter than Excalibur?

I am asking since in ADRIFT, the word “it” (e.g. GET IT) will only work if the optional word “the” is allowed to be the third word, i.e. 3 words are only allowed when the word “the” is included. This is due to something hardcoded in ADRIFT that I cannot change.


Good spot.

I’ll update Excalibur/Adventuron shortly to remove that loophole, but I understand that a lot of engines can’t be so specific in how their parser handles these things therefore I have updated rule 3 to allow connective words if the engine requires it, and instead required that if it is possible to detect a second noun, that the game reports to the player that it is unnecessary.


On the subect of containers, I don’t see why complex containers can’t be used, so long as all interactions with the containers can be accomplished with two words. For example, EXAMINE BOX can tell you the contents of the box. Let’s assume one of the items is a comb. You can GET COMB using two words and you can PUT COMB or INSERT COMB using two words (and the box is implied), whereas DROP COMB does a normal drop. Would that be acceptable?

1 Like

So with the new rule, would a game with the following two transcripts be allowed?

You are in a purple room. There is a brass key here. An exit leads to the north.
You pick up the brass key.
> N
You are in a taupe room. There is a chest here. An exit leads to the south.
(with the brass key)
You hear a *click* and the chest’s lid pops open, inside is a Fabergé egg!
You take the Fabergé egg from the chest

You are in a purple room. There is a brass key here. An exit leads to the north.
[By the way, you only need to use VERB NOUN commands in this game!]
You pick up the brass key.
[No really, two word commands suffice to win this game.]
You are in a taupe room. There is a chest here. An exit leads to the south.
[Note: No commands in this game require explicit indirect objects]
You hear a *click* and the chest’s lid pops open, inside is a Fabergé egg!
You take the Fabergé egg from the chest

I don’t mind adding messages letting the player know that two word commands are enough, but I’d find writing code to make my parser less user friendly rather distasteful.

Another question, from the additional guidance section:

All nouns should have a custom response to an EXAMINE noun (action or custom text).

By noun can we understand objects you can interact with or do you really mean every noun that appears in the game? If it’s the latter we’ll have to be very careful with our descriptions lest every game turn into Lime Ergot. :smiley:


Regarding the two-word input, this is very hard to achieve in most authoring systems, as they normally allow multi-word input by default and their standard libraries are designed to cater for this. I use Inform 6 and I would basically have to rewrite all the standard grammar and action routines to restrict it to two-word input.

I think I know the rationalé for this restriction (make it easier for kids), but it does not encourage good English. For example, why should I force a little kid to say TALK TROLL, when the normal English would be TALK TO TROLL? Why should I force him/her to play guess-the-verb for a simple verb like GET, when the more natural expectation from a child’s point of view may be PICK UP.

Similarly, it means that my game can’t have something like a brass key and a silver key or I get into disambiguation hell.

Which do you mean, the brass key or the silver key?

You can only use two words.

Which do you mean, the brass key or the silver key?

At this point, the little kid runs for the hills, never to play another text adventure in his/her life.

I really think it should be restricted to a verb phrase and an optional noun phrase for the direct object, but no second noun phrase for an indirect object. In your example, you can use UNLOCK THE CHEST (and the brass key is implied) and GET EGG (and from the chest is implied).

Regarding every noun having a custom response, I wondered about that myself. I normally do this as a matter of course, so it’s no big deal for me, but I’d be interested to hear Chris’ rationalé. I think it’s so that kids can examine anything without getting a response that says, ‘You don’t see any wall.’, when there’s clearly a wall mentioned in the description. However, I can’t see anything wrong with saying, ‘You see nothing special.’