Machineers is a recently-Steam-released puzzle game by Copenhagen-based development studio Lohika. Originally a master’s thesis project at IT University Copenhagen, the game is an attempt to translate the particular skills (and joys) of programming into a different visual language.
It’s similar in goal and mechanics to Zachtronics’ 2011 game SpaceChem. That game blended mechanical-appearing programming concepts with chemistry and tied them together with a space corporation story. Knowledge of chemistry wasn’t required, though—in fact, it wasn’t so much chemistry as Lewis structures: an abstraction of molecules that is simplified (abstracted!) into two-dimensional drawings showing atoms and their bonds.
Machineers takes a different approach: instead of modeling the procedures on a molecular level, it models them at a mechanical one. You control Zola, a young robot girl who’s come to Tivoli Town to become a machineer. She strings together gears and belts and switches to repair broken machines: an automaton, a doorbell, a DJ machine, and a mechanical Space-Invaders-clone.
Tivoli Town is broken down and rusted. Visually it resembles a flattened pop-up book, with lots of texture in its rust and bolts. Your pointer changes from an arrow to a wrench whenever it hovers over something Zola can interact with. Usually it’s one of the town’s inhabitants, other robots cobbled together from scrap and charm.
Both of the two available episodes (there are three more planned) has twelve puzzles, each with something for Zola to fix. Usually these puzzles are preceded by a bit of conversation with the robot in need of help. The areas are smallish, and it’s just a matter of finding which robot is waving to Zola for her help.
Clicking your wrench on an object brings up the puzzle screen. The visual is of the guts of the machine, gears and belts missing. A brief animation (which you can view again at any time by clicking an icon on the right side of the screen) shows you what your goal is (get the wings to flap at the same time, guide the trains to the correct garages). Hints are available from the right-hand menu. After you’ve viewed all of them, a blueprint becomes available. The blueprint overlays the solution onto the puzzle. It completely removes any possible frustration from the puzzles and acknowledges that just because you couldn’t solve the puzzle yourself doesn’t mean you shouldn’t be able to learn something from the solution. The blueprint metaphor is also nice because it fits the repair theme so well: you couldn’t figure out where everything goes, no, but you can follow this blueprint and still put everything in its place.
Granted, because you’re not actually building physical objects, the reading and executing the blueprint is just a matter of pointing and clicking. There aren’t manual skills, tool-using, that you’re gaining even as you’re following a set of visual instructions. And maybe, with a puzzle game, that means that the sorting out of what to do is more important than doing it.
All programming is abstraction, translation of the world into algorithms into code into machine-followable-instructions. I don’t necessarily hold with the idea that people who do not know how to code will be less capable in society—I don’t know if coding is a skill more akin to reading and writing or cooking or auto repair.
After you finish helping the residents, you’re sent off to the next location (and the next episode) to learn and help more. But in order to do that, you have to build your transportation. Where the rest of the puzzles have a specific solution (more or less) because they are focused on repairing a broken object, there’s room for improvisation here.
Example: to get from Tivoli Town to River City you need to build a car. You’re asked what kind you’d like to build, which determines how it will control. I, perhaps unwisely, chose to build a “tank,” which still looked like a car but had tank controls.
Rather than repairing a broken vehicle, the game takes you to a blueprint. Where the repair puzzles limited your resources, you can add as many gears and other bits as you want. I chose to focus on functionality over form and so after building the control system and choosing not to power the disco ball headlight, I very gingerly drove the car I had built or programmed or assembled to River City.
Had I known ahead of time that I’d actually be driving, I would not have chosen the tank controls.
Machineers was originally a thesis project and the accompanying written thesis is available for download. I didn’t read all 100+ pages, but I suspect it may be interesting for folks who want to see the thought processes behind the designs, the shortcomings and successes. I also didn’t look at the thesis until after I’d played the game, at which point I saw that one of the thesis supervisors is someone I correspond with: Pippin Barr.
It’s hard for me to judge how successful Machineers is at “teaching” programming, or at least a kind of thinking that is useful to programmers. I suspect that the more visual, physical metaphors of gears and switches might be easier for some people to grasp. Once those metaphors are understood, then maybe the more linguistic metaphors of code will become easier to process.
Machineers was developed and published by Lohika Games. Our review is based on the PC version. It is also available for Mac, Linux, iOS and Android.
Does Brian Taylor like puzzles because he can write code, or does he write code because he likes puzzles?