SpaceChem's Zach Barth on educational games & tutorial design

In 2011, Wired UK and New Scientist described how “SpaceChem, a science-themed puzzler hailed as one of the year's best indie games, is aiming to make the leap from bedrooms to classrooms.” Today, SpaceChem is used by schools in the United States, eastern Europe, and the United Kingdom to supplement computer science curricula. We spoke over lunch at GDC with Zach Barth, developer of SpaceChem and founder of Zachtronics Industries, about the challenges involved in creating this kind of game. (All of us at Motivate. Play. are thankful to Zach for permitting us to transcribe such an informal conversation.)

The first half of this two-part conversation jumps into the design philosophy that Zachtronics uses to design educational games, the challenges of creating games that incorporate programming concepts, and Zach's thoughts on games and learning. In the second half, we transition to some details about his studio’s upcoming game (Ironclad Tactics), lessons learned from SpaceChem, and how the studio is adjusting its process accordingly, especially with respect to tutorial design.

MP:  What's interesting to me is that the mechanics [of the educational games you have created for clients] seem fairly well married to the educational content.

Zach:  We use MDA: Mechanics, Dynamics, Aesthetics. It's a design philosophy. The idea is that when you make a game, all you're doing is implementing mechanics, right? But the interaction of those mechanics and how players work creates dynamics – let me give an example. In TF2, they have a mechanic called random crits. Sometimes you'll be firing and all of a sudden shiny, magic bullets will start coming out of your gun that do tons of damage, especially at long range. This just happens randomly.

So that’s the mechanic. On its own, it means nothing; it's just a mechanic. Is it good or bad? I don't know, it's just a mechanic. But in practice, it has this effect that… well typically, you go into an encounter in TF2 and the player who's better will win. Sometimes it also depends on class balance. The dumbest pyro against the best spy—the spy is going to die. That's the normal dynamic. Like if you have two heavies against each other, the better heavy will probably win— unless one of them gets random crits. So there’s this chance that the worst player will come out ahead just because of this random thing.

So that’s the dynamic: sometimes players who are not good can win in a situation where they should have lost. And the aesthetic that this creates is that, hey, sometimes you win more than you ought to when you're learning the game. The aesthetic it creates is that this game feels — I don't want to say TF2 is really easy to pick up because it's got a lot of nuanced hard stuff, but the mechanic makes it easier to get into. It gives new players a win; you're not going to have zero kills. You actually have a couple because you might have gotten random crits.

The reason I bring this up is that we use this for all of our designs because we make a lot of games from scratch. So this is sort of the model we use to try to at least have some understanding of what we're doing.

I think a lot of games insert the educational stuff in the mechanics; we go for the dynamics. So in Number Munchers, one of the mechanics is that you have to do math. You have to find the answers that are true and then you have to walk over to them. In our metabolism game, in the mechanics, there's no real educational stuff; you’re just flicking particles around and certain things combine. But based on the math that we have and the rules that we have, it creates these dynamics that actually resemble the real life system.

It also ends up creating the aesthetics not of a textbook or something, but just of a game. We have time pressure, so you're trying to do stuff quickly and do a lot of different things at once, like you’re trying to do something with the lungs while you're doing stuff with the stomach. And you have to make a ridiculous amount of energy, but to help with that we give you upgrades that are actually found on the body—like the fact that your lungs work automatically, you could buy that upgrade. So it just feels like a game.

MP:  So you’d say that the content—say, the relationship between energy and the lungs—is embedded in the fact that the dynamics map onto the real world?

Zach:  Exactly. It feels like a game with the mechanics, and it feels like a game with the aesthetics. It just happens that somewhere in between, it feels like real life. That's how we do educational games. I think that SpaceChem's a different kind of experience, because the metabolism game only teaches about metabolism. It doesn't teach you anything about problem solving, or discovery, or science, or any of that.

It's hard to make a game about science, because science is about not knowing what you're doing, but discovering it, which is the opposite of user‑friendly game design. Science is awful, when it comes to that. You can barely even see what's going on. You have to sometimes build tools just to intuit what's going on. It's not user friendly. It's not meant to be.

MP:  Was SpaceChem intentionally a game about science, or was it that after you completed it, you thought, "This is like the scientific process; this is like programming"?

Zach:  There's a little bit of that. The programming part was deliberate. The part that I think is great in SpaceChem, that really came out—and we never intended for it to be an educational game but it’s definitely in there—is problem solving. That's a big thing. All my Flash games had a lot of problem solving, engineering, programming, and that's just because programming is problem solving. When you make a game about programming, it's going to have some problem solving in it, unless you do it poorly.

We offered SpaceChem to schools, and one of the things that you had to tell us was how you were planning to use it. This is more anecdotal than anything else, but American schools would say, "We want to use this game as a chemistry review for our students." Basically, half of them. This is the worst game for that. We had to say, "No, you should not use this. This is not for that problem." But a lot of the schools in the UK wanted to use it to teach computer fluency stuff, because there's a big computing‑in‑schools push in the UK; they’re into the idea that kids should be computer literate.

It's a very practical version of STEM. STEM is very lofty, and doesn’t mean much on its own. But computing in schools is very specific: exposing kids to stuff like programming, and making websites, and tech literacy. They were like, "We want to use this game to teach kids about programming." I think they have a lot of people who teach clubs; they use it because SpaceChem is really a programming game.

The Eastern European schools, a couple of them contacted us saying "We want to use SpaceChem to teach problem solving, abstract critical thinking." I think that's a cultural difference there in what they prioritize.

MP: A lot of things in SpaceChem map onto pretty solid programming concepts. I was curious whether that was by design.

Zach:  There are a lot of people who make programming games, and a lot of times, it's really hard to escape conventional programming paradigms. Even in my old games. I made a game called Manufactoid, which is like the granddaddy of SpaceChem. There's a show called, "How It's Made," which I love. I saw this show when I was in college, and I was like, "This is amazing. I want to make my own factories. I want to make my own assembly lines, and I want to make a game to do it." I made this really crappy Python version, and eventually, I made a proper release of it, and called it Manufactoid.

The problem was that the way you automated your factory was by programming it in Lua, which is completely inaccessible. I really liked Manufactoid, and people liked it. But having to program in Lua is ridiculous. I was like, “Even I don't know Lua, this is stupid. No one can play this game.”

A lot of people make programming games now. A lot of people who play my games make programming games. I think one of the mistakes that a lot of people make is not having an original enough programming paradigm. Because otherwise, it's just programming.

You want to make sure that it feels like programming, and is functionally like programming, but, is so different that it opens up new—like when you're playing "Portal." You have the whole "Thinking with Portals" statement, which is not just their tagline, it is literally what happens the first time you play "Portal" and you're like, "Holy fuck. This is strange. There are new pathways forming in my brain."

You can feel it, because you can feel the dopamine rush that's associated with forming new pathways in your brain, or whatever. I'm not a neuroscientist, so, I don't know if that's technically it, but you can feel it. It feels great. If you make a good programming game, it will feel like that, because you're teaching people a totally new way of thinking and structuring things.

I took a class in Chinese. I'm terrible at it, and don't remember much at all. But when I first started, you're writing out these symbols, and you can feel it changing how you think. It's like, "I've never written a symbolic language like this, a non‑phonetic thing, an ideographic language." It's awesome. It's like, "This is something that's so different, but yet so functional and meaningful that it's making me think in new ways."

I think a lot of people don't realize that's the draw of SpaceChem. They just make a game like, "Here, you can program in Lua." That doesn't count.

MP: One concern I would have if I were, say, a CS teacher thinking about using SpaceChem in my classroom, is that it's a great metaphor for a lot of important programming concepts, but I don't know if they would actually transfer [to real-world programming ability].

Zach:  I almost think that's totally missing the point. If you want to teach people to program, just teach them to program. It's fun. That's why I started programming. You don't need to beat around the bush. Teach people programming, and make it fun.

But if you want to teach kids that thinking about stuff can be fun and that problem solving is good, then let them play a game like SpaceChem. SpaceChem teaches programming concepts, but whatever, that's not the point. If that's what you need to hear in order to sell you on it, this is not for you. The reason you have to want SpaceChem is because you want SpaceChem. Programming doesn't involve building machines that fight monsters. It doesn't have a story in it. That's why SpaceChem is fun. But the problem is nobody in education says "we need more things like SpaceChem." They say "oh, we need things that teach people real life skills."

With games, you have to make a leap, and you have to let some stuff go. You have to stop worrying so much. It's hard to say that and have people take you seriously. I'm not trying to sell anything on that basis. This is what I think. I think lots of things that are ridiculous.

Part II: Ironclad Tactics, lessons learned from SpaceChem, and tutorial design

Zach:  I was talking to people from Steam for Schools. We're trying to get SpaceChem on there. And they're like, "Well, what about your next game? What about Ironclad Tactics? Takes place in the Civil War, right?" I'm like "Yeah… no. This is not even remotely what you want."

MP: One of the things I really liked when I heard about your new game's story was that it reminded me of...Do you play Jamestown?

Zach:  I love that game. Their story almost got cut. At the last minute, one of their friends came through and did the paintings for them. That was my favorite part of the game. That's what completely pulled it together and made it one of my favorite indie games. It draws you in and pulls you into that little stupid made up universe. It's so compelling. It's like "What happened? What is the mystery of Jamestown?"

MP:  That's what I thought of when I saw Ironclads. On one level it looks like a solid--I hesitate to even label it with a genre...

Zach:  It's a tactics game with robots in the Civil War. It's a little bit like Plants vs. Zombies, actually. Real time, has cards in some of the modes, lane based.

A lot of tactics games and card games are really slow. I'm a really impatient person. I've always wanted to play Warhammer. But I never, ever could. A, because I'm cheap and it's expensive. And B because I'm impatient. The game takes like eight hours to play. It's just something I'll never do. There are so many things you have to pay attention to, so many rules you have to know. So we made this game where it's technically turn based, but a turn lasts five seconds. This freaks out a lot of people who like turn based games. They're like "I like taking my time and thinking." This is not for that, sorry. You'll like it, but it's not what you think it is.

There is a little timer on the bottom left hand corner that runs. There is nothing you can do to stop it except for pausing the game. It's turn based, but a turn lasts five seconds. You have basically five seconds to play whatever cards you want. It's multiplayer, but you play your cards at the same time. It's simultaneous in real time in that aspect, for like, five seconds. Then everybody draws a card. You can only have five cards in your hand. If you have five cards, you draw another one, bam, it just shoves it out of your hand, and it's gone. It automatically makes everybody move. The guys that you have set to move will move, everybody who can attack will attack, and then it’s the next turn. It's this weird cross between a turn based and a real time game.

MP:   You're with a whole studio now, right?

Zach:  We're six, seven people.

MP:  OK, that's what I was about to ask. Is that the same group that you did SpaceChem with?

Zach:  Partially. SpaceChem was very remote based. I live near the other programmers, so we were the core team. But we got a guy in the Philippines to do all of our artwork. We have a musician in France who we contract all of our music from. We have, outside of the core team, seven people. We use a lot of contractors. Ironclad Tactics has a story, totals a 70 page graphic novel in-game and it's all interwoven. It turns out that making a graphic novel is really hard, and none of us had any idea what we were doing. We're on top of that now. That's going to be the last part of the game that's finished.

MP:  Was that also contracted out?

Zach:  There's a lot of stuff to making a graphic novel. There's a lot of stuff that's very easily contracted out. All of the illustrated cards are actually in‑house, but the main illustrator of the comic is technically contracted out, ‘cause it lets her work from home—it’s just a business thing. We have two people, actually, whose specific jobs are just to flat. After something’s been drawn and inked, they go in and fill it in with colors. It's such a time consuming...We've got this huge pipeline, and that was part of the problem I think. It's like a five stage pipeline, worse than anything else we do.

MP:  How was that process, scaling up?

Zach:  The educational game thing is what kicked it up into gear. We were only three people until someone came along and said "Hey, do you want to make some educational games?" They were specifically saying, "You guys are too slow. We want you to do more, but we don't want to push you. It would be great if you could do more." So, we scaled up to be able to do more.

MP:  I guess you'll talk about this some in your talk, but were there any big lessons learned?

Zach:  SpaceChem, there were mistakes.

MP:  But you obviously did a lot right as well.

Zach:  If you say so. Anecdotally, yes, that is true. The big things were: our tutorial is awful, unusable; the game was really, really hard; and it's really, really long. Those are the big problems. It's too hard for a lot of people, and it's a really hard sell. It looks like it's about chemistry. Once you get past the part of thinking it's about chemistry, you realize it's actually about programming, which is also not that sexy.

MP: On the other hand, there are games like say FoldIt, which has this core, cult following who are really excited that they’re learning something about how actual proteins work, and that they're actually contributing something real to science and so forth.

Zach:  You know what game makes more money? Call of Duty. The truth is, though, that I love these kinds of games. We can only go so long without making something puzzley. I just love puzzle games. I ought to get you a copy of our paper version of SpaceChem. It's SpaceChem, but it's a paper puzzle like sudoku. We printed out a bunch of them, and we're giving them away. I love puzzle games, especially the engineering, open-ended games.

MP:  So when you're designing a puzzle, do you start with the solution and work backward?

Zach:  Oh, God, no. The opposite. You can't start with the solution for SpaceChem. That doesn't really make a lot of sense. I can start with a solution, but the way with a lot of SpaceChem puzzles is just to ask "What's an interesting molecule? And how could you possibly build that?" There are two kinds of solvability in SpaceChem: Do you actually have the elements in the right proportions that are required? And can you fit a solution easily in the amount of space we give you? The way we designed the puzzles was, I just chucked in a bunch of puzzles that were technically solvable but might not have been actually solvable, and then playtested. I've never beaten the last level of SpaceChem. I really deliberately went through and made sure the stoichiometry worked out but just had no desire to solve it. We give you enough tools that it's almost certainly possible, and I had other people playtest it to make sure it was. It was the last thing I felt like doing, which is a sign. That was a lesson learned. If you don't want to do your own last level then it shouldn't be your last level. Our whole philosophy on playtesting was nonexistent. We did a little bit of playtesting, and half the players didn't resonate with it and got stuck. That should have been a red flag, but, instead, we were just like "eh, this is good, let's ship it."

MP:  So this time you had your in-house team play it, play again, and...?

Zach:  Well, not exactly. This time we've done proper playtesting, actually. We bring in people all the time, ever since the beginning. We've been working on Ironclads for a year and a half. Ever since the first playable version, we have a four man playtest. That was where we started. It's really important to playtest the entire time and constantly playtest. Whenever I have anybody play the game, I'm always taking notes, because there's always stuff that's wrong. It takes forever to fine tune stuff. I don't know how other developers are, but I rarely ever get anything right the first, second, third, fourth, or fifth time.

Trying to make something that teaches someone something effectively...It's just constant failure, and, if we're lucky, we'll figure out something that we think is really smart and then that won't work either. And, then, we'll actually figure something out.

We haven't made a puzzle game since SpaceChem. All of our knowledge that we've learned is going into Ironclad Tactics, where it's a different kind of thing. Can someone pick up our game and not read a single word of the text and play it? That's really an important thing. The mistake we made with SpaceChem was expecting that "Oh, if we tell people, they'll have to read it, and they'll have to understand it." And that's not true. The University of Washington, they have a games research department. They put out a paper on tutorials. My takeaway from it, which might not have been their takeaway, was that any time you make a tutorial for somebody, they are basically doing trial and error. They are putting on their little scientist hat, whether they know it or not, and they're trying to use their trial and error skills to figure it out.

If trial and error involves reading something, and then understanding it, that's great. But it's not like they're going through, looking for text, reading it, thinking about it, and then doing it. They're just clicking stuff trying to get it to work, and that's all.

So you're not really designing educational materials. Educational pamphlets are expecting people to read something and then think about it. That's not how you should do tutorials. You should make little experiments, setting up little environments where people go in with trial and error, having no idea what they're doing, just clicking on stuff, and you make sure they have a really high chance of succeeding.

If you look at SpaceChem's tutorial through this kind of framework, you see that it fails miserably. Because right off the bat there's so much boilerplate involved. It's so easy to get it wrong. It should be like a hallway that gets slightly narrow and comes to a point at the end. That way you can bounce around all you want but as long as you keep going, you're going to end up in that point. Whereas SpaceChem is a really wide hallway with one door. If you bounce around, there's a good chance you're just going to smack into the wall at the end, because you've done something wrong. So people place some arrows and a GRAB instruction, and an INPUT instruction, but when it comes time to drop it they don't have a DROP instruction, they have an OUT instruction. They're like "why isn't this working?" There are just so many things you can do wrong, it's ridiculous. It's not suited to trial and error learning. The big thing for us is realizing that trial and error learning is the only way that anyone ever learns, in general.

Some people do read stuff and try to correctly do it, but I don't. I was playing this game Star Control, and it's translated from Russian. Their tutorial consists of a couple text screens. You bet your ass I just dismissed it. That's the last thing I wanted to do. I don't even know why. Usually I'm a thoughtful, conscientious person, and I try to read stuff. But I'm just like "eh, I'm not reading that." So, I learned from my friend and had him explain it to me. I doubt the tutorials even explained what he explained to me.

There's a Kurt Vonnegut book called "Cat's Cradle" where one of the people is an index writer, because you can't write your own index. You need to find someone else to write it. My tutorials are almost like that. You can't write your own tutorial. You wouldn't even know what to explain. The best you can do is set it up so people can bounce into the game reliably.

That's actually our plan for Ironclads. We have a thing in Ironclads where—and this is a thing that we're still struggling with—there are these flags that you can capture that give you more points to play more cards. Ironclads—the robots—are really powerful, but they can't capture flags. You have to send out the little soft, squishy dudes, the infantry, to capture them.

We had a really bad time getting people to learn that infantry capture flags. A lot of people don't even know what flag capturing is. They don't see it. There's so much stuff going on that we've had a really hard time getting people to look in the right direction. We're not going to compromise on it and make it a slow turn based game or something. It's real time. We just have to find the clever ways to do it.

Keith, who does a lot of design stuff with me, was like "Oh, you know what we should do? We should have it so when you start that level there's already one of your guys on the field. So, even if you didn't put one in your deck, there's a scout of your faction on the field, and he's going to run out and capture a flag for you the first turn." Stuff like that does a way better job of illustrating it than any amount of text ever could. It's a hard thing to explain, but if you show people they'll get it. Stuff like that is really the secret.

The best way to teach tactics to a player, at least in Ironclad Tactics, is not by telling them to do it, but by making the AI do it. Because if the AI does it then it's obvious. There's a thing in Ironclads where the Ironclads can basically step on the squishy guys and instantly kill them. People have a hard time realizing this is a thing. The first thing we did is we made the AI start doing it. All of a sudden the AI is going out of its way to squash their guys and that teaches them a tactic, when they hadn’t even realized they could move onto these guys like that.

The other way we teach that is, on the first level that introduces these enemies, their army's deck is half scouts for no reason other than to show that you can step on them. You're not going to be able to not step on them. Learning by showing. In some games, like a first person shooter, you can really direct somebody. But a game like this is a lot harder, because we have a lot less control over where you're going with our level design.

We've come a long way with our understanding of tutorials. It's embarrassing. At first, I was like "oh, here's stuff we've learned." But now I'm just embarrassed. With SpaceChem, it feels like I’m talking about some other asshole who made a shitty game. I'm talking about his game. It's just not me anymore.

MP:   Probably when you were working on SpaceChem, you felt that way about your older games?

Zach:  Absolutely, they were so bad, oh my God. Tutorials, they have always been my hardest thing. I have never really heard other designers talk about tutorials, which either means they are bad at it and don’t realize it, or they're all really good at it, and I'm just terrible. I think that's by far that's the hardest part of making games, now. We address it as if it was the hardest part. Just making sure that people can play.

If you're making a game where everybody already has played that genre before, you have a lot more freedom with how you do it. We're against that, that is the opposite of what we do. We try to make something completely new every time. So, it's hard.

MP:  Do you have an estimated release month yet?

Zach:  Summer.

MP:  OK, great.

Zach:  Yeah, definitely. The game’s announced, we've got some screenshots online, but no game trailer, because we've been too busy making the game. But it's coming out this summer, hopefully. Fortunately, we don't have a publisher, so it's done when it's done.  Probably July, before PAX. If we don't have it out by PAX, we've screwed up majorly. That would be so embarrassing, to have a booth there for yet another year and be like, "Our game is almost out, but not yet." [laughs] That would be terrible.