Table of Contents
My Background
I am currently working as an Assistant Language Teacher (ALT) at three different Japanese schools, One middle school and two elementary schools. Outside of my regular duties, I like to make games and activities to teach English.
My latest project is “Let’s Learn!”, a puzzle game made to teach English to elementary and middle school students. Each puzzle has an English sentence that the player must follow to complete the puzzle and progress to the next level. You can play the game right now in your browser. I have also been posting devlogs on the itch.io page.
Deploying to the Web
Since the beginning of development, my build target has always been deploying to web browsers using Godot’s built in WASM export profile. This lets me deploy the latest build of the game to a github page without requiring my students to download an app to their school-provided IPads. This is useful for two reasons:
- I don’t have to deal with Apple developer fees and hardware
- I don’t have to get approval from the IT department
Sharing the game is as simple as pushing the latest build to the github page and generating a QR code that points to the page’s URL. I can then share the QR code on the classroom projector, similar to how Kahoot quizzes work.
The Importance of Playtesting
The importance of playtesting cannot be understated. It shows how real players are interacting with your game and what difficulties they may have with your designs. Because I want to target people of all ages and backgrounds, I needed my design to be as intuitive as possible. The entirety of “Let’s Learn!” can play played with a single finger.
Currently, I do not have a single explanation of how the controls work. Despite this, players are able to figure out how to pickup objects and how to rotate the camera without any issues. This is because I carefully watched each playtest silently (<- Very important), redesigning and refining my controls until I could confirm first-hand that my player’s did not need any explanation.
I consider control tutorials to be a bug, not a feature (obviously there are exceptions to this). The most egregious example of this is Doom Eternal. Before you are introduced to EVERY. SINGLE. GAME. MECHANIC, the game teleports you to a padded safe room with passive AI and holds your hand through the entire experience. It is incredibly immersion breaking and is the complete opposite of the image of a “bad-ass demon hunter”.

These tutorials are so bad, that I assume they are a result of rushed development. Because proper playtesting and tutorial design isn’t something that can be brute forced. It requires lots of care and attention.
I prefer the “show, don’t tell” style of tutorials. These are often seen in Valve games. My favorite being the Half-Life 2 introduction of the headcrab.
You see a crow fly into the tongue of a headcrab and die. You now know everything you need to know about this enemy. Plus, you might have gotten a laugh out of the encounter. Comedy plus gameplay tutorials are a surefire way of making sure your players are learning and remembering your mechanics.
Playtesting in the Classroom
A typical day in our classroom consists of following the main JTE’s lesson plan (Japanese person Teaching English). Occasionally, I am given 10-20 minutes at the end of class for “ランデン先生Time.” In the past, I have done activities such as Kahoot quizzes or English Uno. Lately, I have been doing mass playtests of Let’s Learn.
It is only after reflecting on these playtests that I have realized how powerful and unique this situation is.
Every time I need to test a new feature or puzzle, I can have 10-20 students of varying ages and English abilities all simultaneously playtest my game in parallel. While they are playing, I can walk around to any student and see how they are progressing and see what troubles they might be facing.
Beyond the amazing QA this provides me, it is also a great way to brainstorm new puzzles. One such example, was when a player was struggling with an early prototype of picking up objects. Because he was unable to interact with the object, he tried using the perspective of the orthographic camera to “place” the object on top of the goal location.
Another player, one of my co-workers, used the object pickup system to try to solve a pachinko puzzle in reverse, by grabbing the object before it exited the area.
These two examples are puzzles that I would love to add to my game in the future. The first puzzle being similar to a puzzle you might find in “The Witness”. The second puzzle having a solution such as, “An Apple on the ceiling.”
This is a Very Unique Scenario
Despite all the useful information I have received from this experience, it is something unique to my situation and cannot be easily replicated.
For all this to work, you need to be an educator who has free class time they can allocate to activities such at this. Furthermore, the concept of your game must be related to the subject matter that you are teaching.
There are ethical questions to having students playtest a game. I believe my actions are justified for the following reasons:
- This is an activity specifically designed for them.
- The objective of the game is to teach English, not just play a video game.
- The game will always be free to play.
- I intend to share this activity with other English teachers.
And, of course, this is not something I am doing secretly. I love watching my co-workers play the game and I love hearing their feedback.
Thanks for reading.