Schoolhouse Jam Postmortem
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
(Originally posted on wertle.com)
Last weekend I participated in (and assisted in the wrangling of) a small experimental game jam focused on games for classroom learning. I've always recognized educational games from afar as something challenging and impressive, but this was my first time dabbling in it myself, with 0 experience making an educational game. I learned SO much about educational game design and the shortcomings of my own design intuition in this context, even from one small weekend prototype. It was incredibly valuable!
For some background, the purpose and structure of this small jam was thus: Have a teacher on each jam team with an actual classroom problem they are trying to tackle, come up with a game solution for said problem, and have the teacher present on the jam team the whole time. We weren't quite sure how this structure was going to work out, so we kept things small, seeing what we could learn for a potentially larger scale jam later this summer. The teachers involved were already familiar and passionate about the idea of games in the classroom. The teams took two different approaches - one group focused on more broad structure and interface for an existing classroom game format . My team went more narrow, starting with a very specific problem and making a game with that problem in mind.
Our teacher, Erik Ward, was looking to tackle a specific issue he dealt with in special education, namely how to promote self-advocacy in a student. The pattern he saw was that a student coming in to school with a learning difference or disability would often tune out during the initial discussion with teachers and parents about their needs, not wanting to fall under the "spec ed kid" stigma. Then, in class, would fall behind, not taking into account whatever their learning need was. Students that developed self-advocacy - understanding their particular learning difference and being proactive about figuring out what they need to address it - did much better.
So the question was, could we make a game that got students to think about this? The act of identifying a weakness and figuring out what was needed to counter it? Even if the game was just the introduction to a talking point with the teacher, to get them into that mindset would be helpful.
This was my first bit of insight into games for education - that it wasn't always about teaching content but could be about teaching student skill. In this case it wasn't even in a particular discipline, which makes sense, as in this district "special ed" covers a very broad range - physical disabilities to learning differences of all sorts. Making a game to help a specific issue of a very small subset of students could have value, but addressing a skill that would be useful to students across the whole range would be more helpful.
I worked with Erik and fellow designer Laura Lantz to come up with a pretty simple collecting game. You can play it here. The idea is that You choose two abilities and get a third one assigned to you (thus leaving you with one "weakness." After playing a few levels, that deficit will more likely than not cause you to not be able to reach the goal, and then you'll get to choose to upgrade an ability, test it out, then decide to keep it or pick another one. The "abilities" ended up evolving out of conversations with Erik about issues he works with in a lot of his students - different strengths in processing information (the two different types of collectibles), short term memory (how much you can grab at once) and long term memory (how your inventory scales). These are largely symbolic correlations but they ended up making good talking points with students after playing the game. After having people play, Erik went through the sorts of questions he would talk to a student about - what was your weakness? What exactly was causing the problem? What did you pick to overcome it? Did it work?
While making the game, there were several points where the educational intent went against my intuition as a designer, mostly in the realm of clarity of information. I thought these were pretty interesting moments, so I'm going to outline each one:
1) Being randomly assigned an ability
In the beginning, the player picks 2 abilities that they want, but then we randomly give them a third without telling them which one it is. This felt unusual, because it's not really something you see in games where you construct a character off of abilities, where player choice/control is kind of key. Even in games where random attributes are a thing (Rogue Legacy sprung to mind), the information is presented up front (and even in that game the player still gets a choice). That led me to think: are there games where you are randomly, secretly given an ability and that information is obscured? I couldn't think of any off the top of my head, but if there are examples I would love to hear them.
Anyway, the point is, it wasn't intuitive to me. But the situation was this: Erik wanted the student to figure out what the ability deficit was based on the play experience, not based on given information. So rather than say "My weakness is x because the interface tells me so," he wanted them to play, and when something went wrong, have to think about and figure out WHY it went wrong. You do eventually get to see what your third ability was when you wind up back on the upgrade screen, but it is not present up front.
2) Intentionally subtle feedback
In the game, you are collecting two little bits of "magic" and sticking them in your cauldron. Even if you don't have the ability selected to keep one or the other types, you can still grab it and stick it in your inventory. There it will take up space, but will eventually fade away. What can end up happening here is, say you only have the ability to collect the music notes, you can be grabbing a bunch of the glyphs and sticking them in your cauldron and feeling like you are collecting a bunch, but then say at the end of the level you have not reached the goal because all of the other type of glyph have faded away. Their fade-away is very subtle, especially because the player attention is focused up on the grabbing of elements, with only quick checks back to the inventory.
Both Laura and I had the initial reaction of wanting to make this information clearer. Perhaps the "bad" glyphs in your inventory could turn red, perhaps they could flash more dramatically before disappearing. Something to call out "hey you can't actually keep these! This information is important!"
But once again, after talking with Erik about how he would use this game, and the goals of the player experience, we went with the very subtle fade-away. That moment of confusion at the end when you felt like you had collected a ton but still hadn't reached the goal was desirable. Erik wanted the students to run into this and ask "why?" He wanted them to notice that something was going wrong, but make them have to decipher what exactly that was.
3. Obscured Upgrade Levels
When you go back to the upgrade screen after failing, you can choose to make your inventory bigger, make your catcher bigger so you can catch more at once, or if you can't keep one of the glyph types you can choose to keep them both. While the glyph type is binary, there are 3 different upgrade levels for the inventory and catcher (a level 2 catcher can hold 2 glyphs at once instead of 1, etc). If you picked a big catcher in the very beginning, though, there's no information to tell you that you already have a level 2 catcher on the upgrade screen.
My intuition was to present all this information in a clear way so that you would know which one you had picked - perhaps labeling the inventory and catcher with which level they were at, and then showing a little upgrade path so you could see if you were actually about to max it out or not.
But again, knowing exactly what you had at all times from the interface was not the intent, so we ended up keeping this information obscured. When it came time to pick an upgrade, Erik wanted them to choose which ability to improve based on the play experience they just had, not based on the information presented in the interface. The game is quite short, and intended to be played a couple of times. If the student didn't remember that they had picked a big catcher to begin with, and after failing thought a bigger catcher might help solve the problem, then we wanted to let them do that. If it didn't work, we wanted them to think about why. With our playtesters, the second or third time they played the game was when they started thinking back and remembering what their initial choices were. This was fine with Erik, as the whole point of the game was to get people in the mindset of identifying weaknesses and figuring out what they needed to overcome them. It was being used as an entry point to a conversation.
In all three of these examples, the points where my design intuition ended up not being right for the job all had to do with clarity of information. When information was unclear, my initial reaction was "we need better feedback/presentation here so that the players understand exactly what is going on." I think this is because so often in my experience, the concept of players choosing abilities and upgrades is ancillary to the core experience of the game, so you don't want confusion there. You are giving them tools to play the main game and don't want to get in their way in that sense. In this case, the goal was different - even though the "main game" was "collect the given amount of thingies in the time given," that wasn't REALLY the main game. This was more about presenting the players with a system with the goal being that they decipher it, and so in order to get people thinking "okay, what went wrong and what do I need to do to address it" based off of the play experience, it meant some information had to be obscured. In a way, it was a bit like presenting players with a puzzle that they had to poke apart by playing.
Also, there was the initial insight that educational games aren't necessarily always about teaching content, but about teaching skills. This was one of those things that in hindsight should have been obvious to me, but there you have it. Educational games are hard, you guys!
These insights brought to mind two things. One was my recent thoughts on flawed games and my starting to question my habit of addressing usability above all things.
The other was this blog post by AnnMaria De Mars about teaching the skill of perseverance and the need to stop and think in their math game. I recall it because reading it at the time was an insight for me into the different design needs of educational games, and it stuck with me. (Note, if you are a designer and want to learn more about educational games, you should definitely read that blog. There are all sorts of great knowledge bits in there!)
So, the long and short of things - I'm really grateful to have participated in this jam. It was a wonderful experience for the educators (their post-mortem is on the way) and I learned yet another place that I can grow and stretch as a game designer - not necessarily by making educational games but by learning to pause and question my initial design intuitions and ask: is the decision I want to make actually serving the experience we want to convey?
As I said, more write-ups about the game jam as a whole are on the way, but all in all I feel it was successful all around and we definitely want to do another one! Meanwhile, I'm intrigued by the idea of a game where your ability is randomly assigned and obscured and the goal is to figure out what exactly it is...