Text adventure for learning to code

[snider]

Hello everyone,

I’m developing material for teaching programming to middle schoolers. Text adventures seem like a good type of program because they require little code and lend themselves to modification and extension. So I tried to write a minimalistic game and, not being very familiar with the genre, I would love to hear what you guys think of it. I hope this is the right place to ask.

The game: https://app.code-it-studio.de/project/present/38916
The programming tutorial: https://app.code-it-studio.de/project/38914

any feedback is appreciated

[StJohnLimbo]

Hello, welcome to the forum, and thanks for showing us your project!

The graphical block-based coding tutorial approach is interesting, I’ve seen that done in some tutorials on the web and can imagine it helps newcomers to get a good grasp of the concepts visually. But I can’t comment on that in depth from a newcomer’s perspective, because I already know some programming languages.

It might get unwieldy once it reaches a certain complexity, as is often the case with visual tools.
I like that you also offer a view of the corresponding JS code.

About the game itself:

It is, as you say, very minimalistic at the moment (but that’s okay for a coding example).

It shows a basic form of resource-gathering loop, which is a slightly unusual game mechanic for “our” genre, because a lot of IF/text adventure games are typically more focused on puzzles (combining and using inventory and environment items) or on choosing a story path through an unfolding narrative.

That doesn’t mean there’s anything wrong with your example.

I think it serves its purpose to show that a compact amount of code can already achieve a playable game loop. In that regard, it is probably didactically more useful than a branching story would be (display text A if player chooses to go left, text B if player chooses to go right etc.), although such a dynamic story would be less repetitive in the gameplay.

Depending on what you want to show to the pupils next, I could see this being developed in several directions:

• you could introduce different levels of gear (as suggested in the tutorial), put in a crafting element, and types of fruit and fish with varying nourishment values – in short, turn it into more of a simulation, and/or
• you could introduce some locations to explore and a more exciting story (for example, you encounter a wild animal which you can tame and befriend, or you find an old overgrown temple in the jungle)

A few small nitpicks:

• The text display window doesn’t word-wrap (for example, it breaks the line within the word “weak” here):
  […] You feel too wea
  k to swim all the way […]

• Waiting for several seconds between displaying text can become annoying due to very different reading speeds. I’d say, if you want to do so, it would be best to keep it as short as possible.

• I’d separate the action selection prompt by an empty line or paragraph break from either the preceding or the subsequent story paragraphs (or both), otherwise it all runs together visually.

[ramstrong (Harry Hardjono)]

It may be a good idea to specify platform requirements because it doesn’t seem to work for me.

For something this simple, it maybe a good idea for the students to do Design Document/Pseudocode/Board Game Prototype, and make sure they can work it out on paper before coding it on computer. In my experience, it makes debugging session smoother.

And I hope you get better feedback here as compared to what I got recently.

[tundish]

I had a quick play. It’s impressive you can do so much with Scratch (I think that’s the system).
There’s a typo (stuning) on your cover page. Is this within your power to fix or is it part of the platform?

Sorry, this post is all questions Here are the most important from my perspective:

• How old is your cohort of students?
• At what point are you introducing Python?

[8bitAG (Strident)]

It’s definitely an interesting idea. My concern would be that the actual game & mechanics might not interest the students that much. It seems a little odd, in some ways, to use such a visual coding interface to make such a text heavy game.

I’ve been thinking of exploring creating some simple “clicker” style games with students… seeing as they spend so much time loading them up when they shouldn’t. That sort of game could explore similar sort of ground to what you’re looking to focus on in that tutorial, I guess.

[tundish]

@8bitAG

It seems a little odd, in some ways, to use such a visual coding interface to make such a text heavy game.

Yes, and I think that is the key point for me.
Thank you @snider, none of this is to diminish your achievement in creating educational resources for your students. That is admirable. To the degree that it has created discussion (useful I hope)

I take issue with a section of this description of graphical languages which says:

By eliminating programming text, beginners are able to minimise mistakes and focus on foundational principles, such as ordering; creating a fun and easier learning process

The medium of Interactive Fiction is the bridge between literature and technology. And so to pursue IF, is to embrace both writing and engineering.

To eliminate text is to plague both those houses, in my opinion.

[Warrigal (Garry Francis)]

You should take a look at Adventuron, as it was originally designed with the education market in mind. It is a completely textual programming language, but beginners seem to understand it fairly easily. It runs in a browser, has an integrated development environment with syntax colour coding, hinting, code suggestions and instant click to play.

Work-in-progress can be saved to a text file and the finished game can be compiled to a single html file that includes the game engine. It has a couple of very good tutorials, online documentation, cookbook, over 100 games to play (so that you can see what’s possible) and an active Discord server.

Just out of curiosity, what age group are you targetting?

[snider]

Wow, thank you all! I’ll combine responses into one post, if that’s ok.

It shows a basic form of resource-gathering loop, which is a slightly unusual game mechanic for “our” genre, because a lot of IF/text adventure games are typically more focused on puzzles (combining and using inventory and environment items) or on choosing a story path through an unfolding narrative.

I have thought about that distinction, but you put it more clearly. Do you have an example of a small puzzle game? We’ve had students create story games that “branch out” at each player decision. They quickly run out of steam though, because of the exponentially increasing number of branches to write . Here’s an example. It’s in german, because most of our users are german.
How is that best avoided? Combining a loop with branching or having main story and have all branches lead back to it?

Thank you for both expansion suggestions. I think they can even be combined. I also added your suggestion except wordwrap, which is tricky.

It may be a good idea to specify platform requirements because it doesn’t seem to work for me.

We show an error page for Internet Explorer, but any other browser should work. Can you tell me you browser version or maybe even check the console for error messages?

For something this simple, it maybe a good idea for the students to do Design Document/Pseudocode/Board Game Prototype, and make sure they can work it out on paper before coding it on computer. In my experience, it makes debugging session smoother.

Or maybe a flowchart of all the story branches? This could teach a great intuition of what if-statements are good for.

I had a quick play. It’s impressive you can do so much with Scratch (I think that’s the system).
There’s a typo (stuning) on your cover page. Is this within your power to fix or is it part of the platform?
How old is your cohort of students?
At what point are you introducing Python?

• It shares an underlying tech with Scratch, called Blockly. Many educational projects use that.
• Thanks for the typo! It’ll be fixed with the next release.
• We develop only block programming content, with ages 10+ in mind.
• Teachers mostly switch to text programming after 1 or 2 years. Some start with python right away.

It seems a little odd, in some ways, to use such a visual coding interface to make such a text heavy game.

Yes, it’s kind of backwards, a GUI code editor for a text based game
We chose the terminal as program environment because it is simple: you have to understand text input and output and that’s it. Compare that to GUI programming. There you have to offer a number of UI primitives (button, input, label, dropdown, checkbox, image) along with their event handlers, styling and layout controls. The mental model and API (no matter if text or blocks) is just a lot bigger than the terminal’s. We tried to implement this some time ago, with a clicker game in mind, but put it on hold for this reason.

To eliminate text is to plague both those houses, in my opinion.

I think they try to argue against text as a way to edit programs, not against IF or in general programs that work with text.

You should take a look at Adventuron, as it was originally designed with the education market in mind…

This sounds like the ideal next step for students that want to go further. I will look into it, thank you!

Just out of curiosity, what age group are you targetting?

10+, although this tutorial is not aimed at absolute beginners.

edit: sorry, couldn’t get your usernames into the quotes

[StJohnLimbo]

@snider

Do you have an example of a small puzzle game?

Puzzle games are typically more associated with a parser-based approach (for example, check out Adventuron as recommended above) and a full world model (where the system models inventory, location, containment etc.), but you can in principle also do them in a choice-based game.

Using variables, you could implement environmental interactions and/or a sort of inventory and offer interaction options at certain points according to whether the appropriate item is in the inventory. You’ll probably want to offer several plausible-looking choices, or some sort of general system of using items on items, otherwise there will be no real puzzle.

Depending on the complexity, this might evolve in the direction of a point-and-click adventure like Sierra or LucasArts, only without the graphics.

For examples of choice-based games involving puzzles/inventory/world-model, check out Hallowmoor, 16 Ways to Kill a Vampire at McDonalds, 4x4 Archipelago, and Detectiveland.

Those go far beyond the scale of a coding example, and also have different user interfaces, but might provide some inspiration. Also take a look at Robin Johnson’s Gruescript, which is a system similar to the one used in Detectiveland, by the same author.

@snider

How is that best avoided? Combining a loop with branching or having main story and have all branches lead back to it?

Sam Kabo Ashwell has written a very useful reference post about typical structures: Standard Patterns in Choice-Based Games | These Heterogenous Tasks

The approach you mentioned, where the branches lead back to the main story, corresponds to what he calls “Branch and Bottleneck”.

I think that can work very well. With that structure, you can offer:

• some “flavour” choices that directly fold back into the story: choose to drink tea or coffee for breakfast → describe the taste (but with a little detail and variation, so that it doesn’t just feel like: “ah, the <X> is good”) → continue with the main story immediately.

• some short optional detours: go straight to place X or stop on the way at the eerie abandoned petrol station. The petrol station might consist simply of three passages/paragraphs: one to describe the setting and to offer a choice between two options (let’s say, going to the loo or exploring behind the counter), and two paragraphs to describe the result of each option. From both of those paragraphs, you continue with going to place X. (Assuming that neither option is fatal – otherwise we might be creating what Sam Ashwell calls “a deadly gauntlet”, which would also be a way to prune the branches.)

• several ways to get to the same goal:
  Obtain the magic sword either by buying it or by charming or by overwhelming the current owner (each path can be as long or as short as you like, including sub-branches), but no matter which branch is taken, we can be sure that the main story can continue with the hero possessing the sword.

And since you have variables at your disposal, you can also offer options that have long-term consequences, where differences persist beyond the bottlenecks. See also this related post for reference: By the Numbers: How to Write a Long Interactive Novel That Doesn’t Suck - Choice of Games LLC

@snider

It’s in german, because most of our users are german.

I’m German, too, by the way (Hallo! ).
Good job by Nils (who is one of the students, I assume?) in showing how to start something like a Fighting-Fantasy-style gamebook.

I noticed some flaws (click to expand as it's not immediately relevant in our overall context):

There are several (well, to be honest, a lot of) typos; I think I’ve hit a dead end (no ending, no more text) after killing the guy in the hut; a message is displayed twice (“Du hast deinen Gegner getötet.”); the remark about the annoying 2 sec. display delay between text lines applies too; and the ASCII box formatting is off in a few places, like this:

╔═════════════════════╗
║Spieler hat 105HP╚═════════════════════╝;

@snider

sorry, couldn’t get your usernames into the quotes

You can mark text in posts which you want to quote and the forum software will offer an overlaid “Quote” function; if you click that, it will copy the text into your post edit field and put the username at the top. You can also do that several times in posts by different people, and it will append the additional quotes with usernames to your post.

[zarf (Andrew Plotkin)]

@snider

How is that best avoided? Combining a loop with branching or having main story and have all branches lead back to it?

Games of the old parser-puzzle style have a single big loop: accept input, parse the command, carry out the command, repeat. Then the game keeps track of a model world (the location of every object) so that it can carry out the command with the appropriate result (or error).

The best example of a small puzzle game in this style is Cloak of Darkness, which has been ported to a lot of IF languages. http://www.firthworks.com/roger/cloak/inform/index.html

This doesn’t have to be complicated, but it does have a layer of abstraction that doesn’t exist for Twine-style branching games. In the latter, every passage of code is a “page” for the player. In CoD, you can see that every passage of code describes an object or location; the player sees several of these “at once”.

[ramstrong (Harry Hardjono)]

@snider

Can you tell me you browser version or maybe even check the console for error messages?

I tried it using Android phone. No console output.

Flowcharts are good, too.

[snider]

Ok, that was quite the rabbit hole, very interesting. The parser-interpreter approach is probably too hard for programming beginners, but the patters from the Ashwell article could be represented very well by subprograms and conditional statements. Change your code layout and you get a different kind of story game. That could become a follow-up tutorial.

Persistent stats like karma or strength-vs-agility are straightforward to implement as well and I think they can be combined with the above patterns. Thank you very much for introducing me to the subject! If students like the first tutorial, I might be back with a another one.

@StJohnLimbo

I think I’ve hit a dead end (no ending, no more text) after killing the guy in the hut

Yes, that’s true for pretty much all of them. The games branch out and the students get tired and abandon their projects.

@ramstrong

I tried it using Android phone. No console output.

Ah, sorry. The site targets desktop users, I didn’t mention that.