This is the opening of the ambient puzzle game Osmos, by Hemisphere Games. “This is you,” is all it says, as if you’ve always been a glowing blue orb. Most games start by introducing the player to their avatar, but it’s usually a human character with a backstory. Puzzle games are an exception: they rarely give the player an avatar whatsoever. Normally you play an unacknowledged manipulator of abstract blocks according to fixed rules and patterns. Osmos is an exception to the exception.
Osmos also has masterful use of player training and learning curve. It begins in the simplest possible setting with the simplest possible task: “Move to the blue circle and come to a stop.” You accelerate by ejecting mass, which propels the rest of you in the opposite direction. The game tells you these things in the same order I relayed them to you: first objective, then the means. Osmos could have said, “Hey, look how you can move by ejecting mass! Now use this ability to move to this outlined circle.” But it didn’t. The progression is guided, focused, and objective-based, especially at first. The levels build on each other, reinforcing knowledge from previous levels as the player gains experience.
Impasse 1 In a rare moment of explanation, Osmos introduces players to the idea of using ejected mass to move the red motes out of the way so they can get to the blue ones.
Impasse 2 Immediately afterwards, players are asked to apply that principle in a puzzle that looks harder than it is.
Osmos presents players with the Odyssey, an sequence of levels that introduce gameplay concepts in a logical order. The Odyssey runs from the tutorial described above up through medium difficulty levels. After that, players gain access to a Sandbox mode where they can explore different game types at different difficulties. That is, a level of Osmos is distinguished not only by quantitative difficulty by qualitatively, by the kinds of game mechanics and obstacles found. More fundamentally, Osmos is played in discrete levels that can be won, lost, restarted, and randomized, rather than an endless arcade of increasing difficulty like Bejeweled. Players can skip to and play any level they have unlocked at will; a session of Osmos can last three minutes or three hours.
Players are incentivized to complete the Odyssey and get as far as they can in the sandbox, but there’s no climactic end of the game. No explanation is given why some levels seem to take place in a petri dish while others in orbit around a star; it’s wonderfully abstract in that regard. It’s impossible to “win” and there’s no victory cutscene. It’s neither so boring and open-ended you don’t want to play nor so scripted you only want to play once. There are achievements (badges) awarded but they seem extraneous to me.
And now to the point of all this: what can we learn from Osmos when designing software for education?
By the structure of its gameplay and incentives, Osmos lends itself to the sporadic and time-limited technology access found in many schools. Instead of leaving students behind who didn’t win the game, or trying to pry a child who’s “gotten far” away from the computer or tablet, it’s easier to take a break from Osmos. Meanwhile the nature of gameplay means that it’s very much a solitary experience, a personal journey of discovery. For all the hype given to social gaming over the last few years, it’s not conducive to deep thinking.
And yes: agency, in the sense of being a specific agent. In Osmos, the player is someone, or at least something: this is you. As I’ve said, most puzzle games don’t give the player anything to latch on to. Neither does formal arithmetic, nor algebra. Symbol manipulation provides no agency. It forces mathematics into the unnatural third person perspective (unnatural from a human’s point of view). When I played with blocks as a child I would often imagine an ant climbing and exploring my structures. Pen and paper mathematics allows the mathematician to move blocks around but not to be an ant inside his or her own creation.
Seymour Papert developed LOGO to provide children with agency. LOGO is a cross between a game and a programming language. Players manipulate the “Turtle” by telling it to turn left or right or move forward, where forward is relative to how it is turned. When children first encounter difficulties, they are told to ”play turtle”. By moving their own bodies through space, they are able to debug and refine their program. And by thinking how they move their own bodies through space, they are given a tangible grip on both computation and thinking.
Scratch was developed at the MIT Media Lab, which was co-founded by Papert. Scratch, though very much a descendent of LOGO, adds more commands to increase the user’s power and control. Many of the commands were discussed by Papert in his book Mindstorms or seem to be reasonable extensions of it. Others (thought balloons, sounds, arithmetic, color effects) are superfluous. Still others, like if-else statements, while loops, and Boolean operations, are taken from the nuts and bolts of programming. This comes at the cost of downplaying the two high-level skills which Papert thought were so vital to learning any subject: subprocedures and debugging. With LOGO, children learned to compartmentalize knowledge into reusable pieces, and to make incremental improvements to see the results they wanted.
One of LOGO’s defining characteristics was its limited set of commands, which are relative to the current position and heading of the Turtle. Osmos players can eject mass in any direction, but nothing more. In both cases, artificial scarcity of control forces users to think in a particular way. On the other hand, Scratch freely mixes LOGO-style “move forward” with Cartesian commands, both relative (“move up by”) and absolute (“move to”). It’s impossible to have agency with something that can be teleported across the map. Rather than force the user out of lazy and weak ways of thinking, Scratch offers multiple paths and users take the one of least resistance. Often this will be a hodgepodge of many different styles and systems of commands, reflecting incomplete and imprecise thinking.
The large number of commands create a cluttered and unintuitive interface. 78% of Scratch’s default interface is control while only 22% of it is the canvas. The results, the thing the user cares about, are squished in a corner. Osmos has minimal controls that disappear when not in use, leaving the entire screen as the portal into the game world. Moreover, Osmos has just enough visual detail to be eye candy and not clutter. Games, in general, have excellent usability because bad usability is by definition not fun.
Scratch’s default user interface, with overlaid percentages. A similar image for Osmos would be 100% purple.
The differences in the command set and user interfaces belie the different purposes of the software. Scratch is meant to provide a canvas for a play or a animation, and so gives the user plenty of options for control. Osmos and LOGO are both puzzles in the sense that the controls are extremely few, yet powerful. a A tool is designed to give a competent user maximum power to create; a puzzle is designed to teach new ways of thinking under constraints. By this metric, Scratch has more in common with CAD software used by engineers to design mechanical parts than it has with Osmos and LOGO.
But there is another feature that groups the three differently. Both LOGO and Scratch are sandboxes; they enforce no requirements or value judgements on the player’s actions. Papert envisioned a teacher guiding the student and keeping her on task. Osmos takes a different route. As a game, it has clear objectives to complete and obstacles to avoid. There are good moves and bad moves. There are levels, with definite beginnings and ends. The Odyssey is just a long tutorial: it presents each feature and some advanced ideas before handing the player full control. Scratch and LOGO do just that as soon as they’re opened. In particular, Scratch provides no guidance on its cockpit’s worth of controls.
There is a misconception, common among edtech types but not among traditional teachers, that the answer to all problems is better distribution. People are ignorant because they don’t have access to knowledge. People can’t code because they don’t have access to the software and documentation. But this is simply not true. Give people tools and they won’t know what to do with them or how to use them. Instead, we need to give students of all ages training, knowledge, and understanding. We need to force students to think about wrong ideas and make them right, and to see why they are right. We need to to show students the metacognitive tools to solve problems. An educational game isn’t about what to think, but how to think.
Now read the follow-up post: Beyond Agency: Why Good Ideas Only Take Us So Far.