Games People Play
I recently finished Trainyard, an addictive iPhone puzzle game. The goal is simple: get various color trains into matching stations. There are only a few different track sections (which you draw with your fingers) and all the trains move at the same speed. If a train arrives at the wrong color station or runs off the end of the tracks you’ve drawn, it crashes.
Passing trains mix their colors, so you could have a red train and a yellow train turn into two orange trains. If two trains arrive at merging tracks at the same time, they become one. So you could have a red train and a yellow train turn into a single orange train.
As these variables (number of trains, number of stations, and their locations) change, the puzzles get progressively more difficult. It’s quite an achievement in terms of the gameplay mechanics, and its author Matt Rix, has plenty to be proud of including the success of his game and the generosity with which he shares his process and challenges.
Playing Trainyard, I found myself thinking about ways to optimize my solutions and then about how to generalize solutions or parts of solutions. And then I started thinking about the parallels between these tasks and engineering problem solving.
When I first started playing this game, I had to learn the basic rules of the game world. Simple examples that illustrate a point helped with this. I also explored on my own. Once I learned the basic building blocks, I could combine them to solve more complex problems. And once I solved a particular sort of problem or sub-problem a few times, I started thinking of the solution as a pattern. Then I could combine these patterns as chunks, in order to reason about yet more complex problems without overloading my brain.
I took a number of approaches to the harder puzzles out of necessity: Drawing partial solutions to problems, and then letting the trains crash in order to make incremental progress. Observing the behavior of the system in slow motion to infer previously unseen interactions. Making small changes to pin down their consequences. Turning harder problems into simpler ones before analyzing the situation again.
I mean… Isn’t this exactly what we want students to learn to do in computer science and software engineering? When did I learn to do this stuff?
Thinking back, it might have actually started when I was a kid. We had an Apple II/c computer at home. I played a bunch of games on there, but the two that come to mind at the moment are Rocky’s Boots and Robot Odyssey. Like Trainyard, these games let you freely build a solution to a puzzle from parts — in this case, logic gates let you build a circuit — and see the solution play out via animation.
I’m pretty sure that working with circuits — or simplified computer models of circuits — at an early age had an impact on how I think about logic and information and problem-solving. And I wouldn’t have done it unless it was fun. Even though it’s been almost 30 years since those games came out, I think the gameplay concepts have remained engaging.
Trainyard is a modern game that carries the same spirit. It’s less obviously about digital logic, but that might be a strength. If you’ve got kids — even as young as 6 or 7 — this is probably one of the best things you can put in front of them. Who knows… they might well be thinking back 30 years from now and realize it helped them structure their approach to solving problems.