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

The point is not to be grammatically correct. The point is to give s simple rule for the player so they know the scope of how they can grapple with the parser. The two word limit makes things less grammatically correct but it makes things actually easier for the player. In Excalibur for example there is only one key, no problem with key adjective.

Connective words are allowed via the jam rules but I do think in many ways this is a mistake as it breaks s simple.rule (maximum of two word inputs). Being able to explain something easily to a child is the highest priority. The rule anyways is relaxed for those that wish to enter the competition with systems that do not support the rule. The rule isn’t there to put other systems (other than adventuron) at disadvantage, it’s there to be able to be able to be an easy to explain the rule and increase the pace of the game. Anyways, connective words are allowed but should be discarded.

Aureas already made a very playable game within these rules and there are many playable verb noun games in existence.

The real frustration with parade games is not a game that expects bad grammar. The real frustration is not knowing what the game understands.

About the complex transcript, all the two word commands are permitted, even with containers. When you open a container its contents should become the contents of the room and can no longer be placed back in the container.

Using adjectives with nouns should not be required, adjust the design accordingly. Try not to have too many keys coexisting. The rules do allow connective words (that can be discarded) but the parser should not understand adjectives for the purpose of disambiguation. The design itself should not require disambigustion. Authors have control over the design, but these are the constraints.

I know it’s not easy, and making the parser less friendly in some ways counter intuitive to the goals, but the jam.ks opinionated that a rule known to the player is more important than parser flexibility for beginners. If that assumption is incorrect we will discover.



I’m entirely sure that an 8 year old will indeed type TALK TO THE TROLL and GET THE APPLE first off, rather than TALK TROLL and GET APPLE. But kids are really smart (generally much smarter than adults) so they’ll pretty soon get it, especially if they’re told ‘just say “talk troll” and “get apple” and the computer will understand’ when they try it.


It may be a good idea to have a limited panel to determine some special title and prize, but I really hope that voting will be open to everyone. If not, I am sure much fewer people will play the games. I doubt a lot of IF-players will play most games if they cannot vote.

I can only talk for myself, but I enjoy family-friendly games, also when they can be understood by a nine-year old kid.

Normally, competitions and jams are good places to publish your games, because you will get a lot of feedback, both comments and average scores. but if only a few people can vote, the amount of feedback will be very limited.

1 Like

I agree that it would be preferable to have a public vote of some sort - I think the problem is accommodating both types of vote (a public and a closed one) on itch. I’ll do my best to play and review the games but I’d definitely be more motivated to do so if I could vote on them as well.

1 Like

I really love the idea encouraging more beginner friendly games and games that have built-in tutorials. However it seems like some of the rules (crippled parsers, sentence caps, …) are more focused on pretending we’re in the 1970’s — pre-Infocom — than on actually making games beginner friendly.

Which is perfectly fine, retro-computing can be a lot of fun (I for one am looking forward to the next S.A.L.A.D. game :)). I just misunderstood and thought the jam was about introducing children / new players to parser IF when it in fact is about introducing children to retro parser IF.

1 Like

I disagree with the assertion that a verb noun requirement is regressive/retro.

The purpose of the jam is not to introduce children to more complex forms of text adventures or interactive fiction, but the basic fun of manipulating world state or story via simple textual commands in a known format.

As stated earlier in the thread, a VERB NOUN parser requirement avoids undue stress of fighting with the parser.

If you know everything is two words, there is no stress. Adventuron as with other engines supports parsing many more words than two words, so it’s crippling itself for the purposes of this too.

Verb noun games are very fast paced, and the other rules tries to add a brevity to the storytelling too. Fast pace and fast rewards are more important than parser precision or complexity.

Over Here! by aureas is a good example of VERB NOUN magic. Parser grappling is non existent, and the game is all about the characters and the puzzles. It’s not perfectly suitable as a TALP game due to lack of tutorial but the concept of a minimal game with lots of interactive media attached is demonstrated well. Game in the jam can use a modern or retro aesthetic. It could all be hand drawn art, or no art at all. Animations, mp3 sound effects. It could be any Google font, or ttf. Nothing about the presentation has to be retro.

There are certainly strong limitations in the parser elements of the jam, but you (generally speaking) couldn’t add complex graphics, animations, sound effects, interactive maps, or other innovations to 70s games, because of technical limitations of storage / hardware.

The VERB NOUN requirement is purposeful, and a limitation of this iteration of the jam. Children will understand the rule quickly, and be able to structure their commands accordingly.

The sentence caps are there because of attention span deficits, and being inclusive for an increasing number of children that have ADHD. There are plenty of books and comics that convey their stories with low amounts of text, so that is another design challenge for authors.

I think the modern approach is not to design a regular game with a tutorial, but to design a completely streamlined game with a tutorial. Sentence caps are part of that. There is no sentence cap on game startup text now, but there are still caps on location description and response text. I think this is 100% the right decision for being as inclusive as possible, and appealing to the widest possible range of children, including those that would immediacy switch off when confronted with a screen full of text. In many ways, I wish the sentence cap was just one sentence, and I think the most minimal games will do well in the jam, so allowing two sentences is a good A-B test.


I like the idea of reclaiming simple parser games from being seen as “retro”! A lot of what makes a parser game feel retro isn’t required here: if a blocky/pixely aesthetic and obscure/unfair puzzles are taken away, I’m not convinced that allowing only very short inputs will feel retro at all.

We will have to make worlds that can be satisfyingly modeled in a simpler way; that’s the interesting challenge to me.


I don’t agree with this thesis. What makes fighting a parser frustrating is a guess the verb situation due to an under-implemented set of verbs, not the fact that some of the verbs are phrasal verbs or that you occasionally have to disambiguate a command.

I don’t understand.
I don’t understand.
You pick up the key

Is much more frustrating than

Which box do you mean, the red box or the blue box?
Inside the blue box is a brass key.

To take Excalibur as an example, I gave up at the end and had to peek in the source to find the solution of the final puzzle (the non-standard verb reflect spell) after trying oodles of commands that weren’t implemented (dodge spell, wave sword, wield sword, fight spell, …). The fact that it was a two word parser didn’t help at all.

I think making games more accessible would be better served by mandating a common verb set (and by requiring the verb set to be enumerated in the tutorial) then by enforcing arbitrary restrictions on the form of the grammar.

That’s fair enough.


Having a blue box and red box is something you would not design in a game for this jam. It’s a design constraint. Having two words is the constraint, and you adjust to it. The player should never be faced with anything that requires disambiguation, and therefore the problem will not occur.

GET and TAKE should reasonably be aliases in any standard engine. PICK UP is usually an alias in Adventuron, but not in this jam, where it would be reported as “The game only accepts up to two words.”

You say that grappling with the parser is mostly to do with “guess the verb”. It’s not only this though. It’s also guess the quality of the parser, guess how specific you have to be, guess if you have to be specific this one time. The VERB NOUN requirement eliminates all that guess work, and all that’s required is a simple message to say you entered too many words when you have.

About Excalibur’s last puzzle, it’s obtuse for sure, but it’s also a port, with the TALP tutorial being added afterwards that takes you to half way though (through to the castle).

I have never presented Excalibur as a perfect adventure, nor as a perfect tutorial, it’s a reference implementation bolted onto a game I enjoyed so much as a child that I bought the rights to for the purpose of teaching about the good and bad aspects of the game. The Adventuron tutorial B actually discusses design flaws in the original game and leaves them in for the purpose of discussion of design.

The jam is an opinionated jam by its own admission. A two word parser is part of that opinion. It’s not presenting itself as the only way to do text adventure games, but rather a way of trying out verb/noun as a way to increase understanding. If ultimately the experiment doesn’t work, we will have new information, and the next experiment will adapt, perhaps allowing an adjective too. There remain plenty of places to innovate within the constraints.


I mostly agree that a two-word parser don’t necessarily make a game more accessible, for the same reason others have pointed.

I think too that that’s is the important part. As far as I understood, Adventuron doesn’t really have a concept of actions like, say, Inform; it only has the concept of commands. While writing my game for the Christmas jam, I found that this encourages the use of one-off verbs and other “non-standard” commands, since there are no common base authors can rely on.

With Inform, I first look at and implement the built-in verbs because I know they can be considered as “standard” and that experienced players are likely to try them first. I think that a game that teaches the genre to newcomers should teach these kind of conventions used in most games instead of forcing something (e.g. the two-words parser) that isn’t used a lot in mainstream games.

Well, today, the most used authoring systems have parsers that can handle complex phrases, so you don’t need to think about it a lot in practice. In an ideal world, it’s the job of the author to think of the sensible commands that a player is likely to type (according to me).

Now, I’ve got nothing against using a two-word parser, and I don’t think it reduces the accessibility that much. Children are resourceful enough to quickly understand that you have to type 2 words at most. And as @adventuron is the organiser, he has the final word, even if I don’t fully agree with him; we may be a bit overreacting on this parser issue.

Also, the discussion now revolves a lot on whether a two-word parser is good for newcomers, and we’re not really discussing about the jam anymore (even if both subjects are linked.)


I’m open to the idea the two word parser constraint is a bad idea (although I obviously have my bias), but a really good way of figuring this out is to test it.


Oops. My last post was indeed about whether a two word parser is good for beginners in general and not in the context of the jam. I wouldn’t have brought up the disambiguation example otherwise. I apologize for derailing the thread.

To bring it back on topic, I’m still not sure whether my example from this post would be acceptable. That is: a game designed to be played with VERB NOUN input; that only teaches VERB NOUN commands; that, when receiving more than two word commands, outputs a message saying that VERB NOUN commands are sufficient but still carries them out.


Whether people can agree or not on which of the many rules are preferable for newcomers, the rules apply to everyone. So I still think this is an interesting challenge, similar to having a theme, as long as there is some flexibility so that most (all?) IF tools can be applied despite some hardcoded limitations. The rules are the same for everyone.

I just hope that voting also will be open to everyone, as that is the most fun. :slight_smile:


Speaking (or writing) not just as a fan of IF/TA but also as a Dad of two young boys I think this is a great idea! :smiley::+1:

Remember the Text Adventure Literacy Project (described in the link provided on the OP) was to help promote and teach “playing text adventures” to young children rather than to teach literacy per se.

Don’t forget that the many IF systems, jams, comps etc have their own unique rules so keeping to a two-word parser is - in my humble opinion - one of the many different methods available. Not many do this if you think about it, so why not have a jam that keeps a tight constraint on VERB - NOUN and let’s see what interesting games can be produced as a result!

Please get behind this everyone, it’s a great initiative and I look forward to playing the games with my kids (and you’ll get very honest feedback from them I promise!)

Adam :slightly_smiling_face::v:


… Also, worth noting that the location graphics in these games have historically been bloody brilliant! So that’s something I’m also looking forward to seeing!



If some of you are not sure on which IF-tool to use for this two-word parser jam, you might want to take a look at ADRIFT, as I have just released a Verb-Noun Library for ADRIFT as described in this post:

Release announcement

In the post, there is also a link to a video, which should give you some idea of how ADRIFT works.


That’s very useful!

Verb noun parsers can be very pleasant as long as you know that’s what the game expects and there are no exceptions.

The only exception is the word “the”. So if the sentence includes " the " then three words are allowed, e.g.:

I had to allow this, otherwise commands like GET IT would not work, as ADRIFT internally changes “it” to “the object”.


OK, I started judging. There are enough games for an interesting competition but not enough to be overwhelming. I knocked off three in an hour, so I’m optimistic I can complete in the next 24 or so days :slight_smile:


There’s an old trick of getting the two words from both ends of the sentence.

GET the old KEY
LOOK at the incredible shrinking MACHINE

I say that if you want 3 word structure, you can get away with using the word just before positional words.

THROW the golden COIN up into the AIR
PUT the teddy BEAR in front of the PILLOW
DROP the valentine CHOCOLATE on top of the COVER
GET the COIN from inside the PURSE
HIDE the MAGAZINE under the BED

Those constructs may not be as good as a true parser, but it should cover most reasonable instances. It is up to you whether you want to list all unknown words, or just silently accept them.

There’s a problem with


And you can possibly check whether NOUN1 exists, and if not, then you can shift NOUN2 into NOUN1. Or you can just tell the user to use X for EXAMINE. :slight_smile:

1 Like