Now that I’ve played all the games, I must confess that some of the games are not really suitable for beginners. In fact, they’re more likely to put beginners off, rather than attract them to the genre. This is a concern.
I’m thinking that we need to provide something like a training course for new authors to address all those things you mentioned and more. I’ll give this some thought for next year.
Yes, there’s that risk someone will see the TALJ as “here’s how I wrote my first one” instead of “here’s a good one to show you what’s fair and what’s not.” It’s worth thinking about. But I imagine it would be tough to reject a text adventure someone worked very clearly on. Perhaps you could say, okay, show us 2 weeks before to make sure you’re not wasting time, or if there’s any question, let the organizers have a private password to see a build in progress for suggestions.
And also make a note ParserComp happens soon after.
Instead of rejecting the entry altogether, maybe it would be more beneficial for the voting criteria “tutorial” to be expanded to “beginner friendliness”, with a better name possibly. Or a new criteria to that effect could be added, leaving “tutorial” criteria as it is.
I’m taking notes for next year.
It’s not about rejecting an entry, but rather realizing that it’s kind of difficult to write a piece of “educational” software to teach others how to play a certain genre if you don’t have a firm grasp on that genre yourself. First-time authors are always welcome and must be encouraged (I was one of them until a couple of years ago, so I really cheer for them), but maybe this is the wrong competition where to start your new journey. My humble suggestion is to start with something less complicated, develop your skills, and then enter this very jam. Just my two cents.
Except that creating beginner-friendly games is the entire point of the 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.
Then you’d be disqualifying all games that aren’t easily written. Such games that requires new verbs? Special actions that need to be expertly coded? Any customizations beyond standard library behavior is automatically off-limits as to be hard to write.
You don’t want to be the one deciding what is easy/hard.
We should encourage easy games, for sure, but outright banning “difficult” games will cause hurt feelings no matter how it’s resolved, thus no new entrants.
I think there might have been a miscommunication here!
As I understand it, these games are only meant to be easy to play (at least enough to be accessible to folks who are new to IF).
But they don’t necessarily have to be easy to program — there’s no restriction on the authoring side, as long as the playable result can be considered an IF tutorial.
That’s the end goal, isn’t it? You don’t want to tell beginners that creating IF is extremely hard to code and takes years to do!
Which is exactly what everybody told me whenever I propose new techniques to easily write IF.
I definitely agree that’s a problematic thing to tell beginners, and is far from the truth!
I admit I’m not sure I see the connection with the TALJ, though; it feels like that might be a separate issue, which would be best hashed out with the people making these specific claims?
I worry that we’re getting away from the point of the jam (and of this review thread)!
No entries will be banned. Now, let’s not side-track this topic and let Andrew get back to his reviews.
Thanks, Garry … there certainly are points for debate. And I want to bring them up. But Harry, I’d like to stick to reviews here, even if I did bring up questions for further discussion. It’s not a huge distraction, but it can make me lose a side thought or two that might be important in a review.
Perhaps the theory section of the forum would be better for other questions you have.
Hey folks! 
Don’t forget you can use “reply as linked topic” if you’d like to branch a peripheral conversation into a new topic to avoid derailing or cluttering someone’s review thread.
I’m still working my way through all the entries but I have found the ones I’ve played so far to be mostly not very beginner-friendly, which kind of defeats the purpose of the TALJ.
I think part of it is that TALJ, having originated as an Adventuron-hosted jam, has traditionally been quite Adventuron-heavy (I’m not sure why this is still the case as it’s widely promoted across other parser system communities as far as I can see, but Adventuron games are still unusually highly represented at 40% this year) and Adventuron jams have always attracted a lot of new parser authors (it’s how I got started back in 2019!). I wonder if this is also maybe an Itch thing - perhaps there are a lot of ‘parser-unfamiliar’ (for lack of a better term) authors coming across TALJ on Itch and deciding to enter?
It’s difficult to think of a solution to this that doesn’t discourage new people - it’s really great to see so many new authors giving it a go and I wouldn’t want to lose that, but at the same time, in order to write a parser game that successfully teaches new players how to play parser games, I do feel you need to have some experience of writing - or at least playing - parser games in order to know what the standard parser conventions and expectations are.
Perhaps there could be multiple categories in future - one for new authors and one for more experienced authors? Potential issues with this might be (1) it would perhaps be expanding the remit of the TALJ to catering for new authors as well as new players and (2) people might feel less welcome if segregated.
It’s a tricky one, definitely.
(post deleted by author)
Harry, I think you are mistaking player beginners friendly with authors beginner friendly, like it has been mistaken earlier in this thread, aren’t you?
There are different approaches to that goal. I think generally hints are what it takes. This can have many different forms. Especially at the start the game must explain what the player has to type.
Clearly there’s some tension between the jam’s aims of getting new players and getting new authors, but it’s hard to think of a way to absolutely legislate for “beginner-friendly” games, really. If that’s the aim there probably has to be a sorting process of some kind once the games are made.
As a first-time parser-writer with an entry in this year’s jam I know it’s possible to make a beginner-friendly game (the game has flaws of course but I know it can work for beginners as it’s getting played by lots of friends / children of friends / my son’s classmates etc, lots of whom have never seen anything like it before). But I didn’t know how to do that or how to test if it was possible before doing it.
(As an aside, the game’s made in Adventuron and honestly wouldn’t have got made if it wasn’t. While there isn’t a full Adventuron Tutorial book, the online “classroom” tutorial is excellent and thorough and once you need to go beyond it there are very helpful people on discord. 
)
It probably helps that I have thirty-something years of experience of playing parser games (and of hating being stuck or confused). But what really helped was timely playtesting. I was astonished and embarrassed at how difficult people - people who I know are intelligent and experienced players - found the early draft. I think as a beginner writer this is the trickiest thing to figure out, really imagining not knowing what you know. But hey, this is explained in the jam, too, and if I’m not mistaken Garry emailed us all at least twice to prompt us in how important it is. Not sure how much more could be done on that front, unless, again, there’s some winnowing process post-writing.
Agreed, playtesting makes a huge difference! And I know how easy it is to run out of time and hence neglect this aspect. Maybe there could be a minimum amount of testing for games as part of the rules, though I can’t think of an uncomplicated way of going about it.
Booping in as a returning entrant, where TALJ was the jam where I created a first (proper) parser game while having limited parser playing experience. It was a great experience and I am extremely thankful for it, because it helped me essentially break through my issue with parsers both as a player and creator.
I’ve definitely been enjoying playing parsers more because of the jam. And both because there were super beginner friendly games, and games that tried to be beginner friendly but missed the mark (my first entry was in that second category). The ranking of the jam shows what worked and what didn’t, what was easy and hinted and what way too hard, what were good examples and what should be more considered as a cautionary tales.
I mean, my own entry that first year ended up being considered more Cruel than Polite/Merciful because of the last puzzle (choice)… But I’m glad it still stayed in the competition and wasn’t removed because I failed to realise that it was a bad/hard section. It ranked low for a reason, and I learnt a bunch from it as a result (and I hope I made a better game this year as a result).
I think we should maybe have more a conversation about what is beginner-friendly and how we can communicate this better to entrant and players. Like truly, what component HAS TO be included to be considered beginner-friendly, how should a lambda puzzle look like in terms of clearness and hints and what not…
I know there is a comprehensive explanation of each rule of the jam on the itch.io page, but the language can still be up for interpretation. Like:
Consider providing a context-sensitive HINT command
Consider using a HELP command for the in-game instructions.
The wording doesn’t mean you have to include it in your game, even though it will be useful to players. Only that you should consider including it.
Or how a HELP/HINT command should look like.
Or for the tutorial section:
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.
I would go even further and include a tutorial on verbs used for puzzles or at the minimum a warning that other verbs may be used/are hinted in some section of the game. Because guess-the-verb isn’t fun as a beginner player, especially when the verb is not a “usual” verb (my mistake last year).
There is also no mention of walkthrough, which can be the only way for players to go through a puzzle in some cases, or other external elements (map, verb list). Nor are there examples of good beginner-friendly games (playable or source-code - I know you can look at past winners).
Or resources that explain how to make a beginner friendly game (further than the tutorial and think about HELP/HINT), like what are considered simple puzzles and what should be avoided, or how to hint at how to solve a puzzle without giving away the answer to easily, or which verb to include/avoid…
This would have helped me quite a bit on my first try 
I don’t know… throw in there a checklist for authors or something 
Making beginner-friendly games is a skill that might be easy for some, but if we have resources for the ones who want to try their hands at it, it will make the competition even the more stronger!
