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