Have played up to, but have not yet completed, the final puzzle in level 7 (of 9), in 13 hours, 2/26/15–3/3/15. Plan to continue to the end, eventually.
[It’s a design-your-own-solution game, so it doesn’t really lend itself to being watched passively on YouTube — pure solution videos go by too quickly to make sense to a non-player, and realtime play session videos are all about the player’s thought process rather than the game content. But if you search you’ll find plenty of both. Here, here’s a guy’s solutions to the first half of the game, with some videos where he talks through trying to build a more efficient solution; I guess any of that will do to give a sense.]
Okay, I’ve decided that posting placeholder entries is needless even by my standards, so I’ll just put it here: there’s one further not-quite-game from the Frozenbyte set, but I’m skipping over it until I regain access to a computer with a 3D card that can handle it, unlike the lower-end machine I’m using at present.
That brings us to the end of the games in the Humble Frozen Synapse Bundle at time of purchase on 9/30/11. However, on 10/5/11, one last game was retroactively added: SpaceChem.
I really love computer puzzle games. I have, in the back of my mind, a semi-serious case I could make for why their special potential for elegance and depth merits their being considered not just as a genre of game but as a distinct artform to be considered alongside traditional artforms. For the present I am not going to make that case; just mentioning it as evidence of my enthusiasm.
The puzzles I have in mind, though, are all puzzles with unique or tightly limited solutions. Then there’s a whole other category of puzzle game, to which Crayon Physics and SpaceChem belong, where the puzzles do not have unique solutions. They’re really just assignments, made non-trivial by constraints. These are not actually puzzle games to my enthusiastic taste. They are rather what I would call “engineering games,” the crucial spiritual difference being that in such games, responsibility for elegance and depth is on you, the player.
(That said, I am still basically okay with calling these “puzzle games,” because they have discrete pre-designed problems in them. I absolutely do not condone the now-standard usage of “Puzzle” as the category name for any post-Tetris abstract solitaire. Bejeweled and its ilk are clearly not puzzle games, despite what the iTunes store might say. That genre should properly be called “Procedural.” I guess that doesn’t sound very appealing. But people could learn to love it, just like they did with cop shows.)
Being good at engineering and being good at puzzles with unique solutions are two very different things. Interest in design is not the same as interest in necessity.
I’ve never been very good at design because I’ve always feared the absence of authority implicit in its freedoms. That’s a psychoanalysis, of course; what I thought was going on was that I was seeking an elegance that eluded me. But I had confused elegance with necessity. There’s boundless opportunity for elegance in all problem-solving, but you have to accept that the problem won’t be its source; you will. That can be hard to accept.
The premise of Oulipo (the constrained writing movement) seems to be the appeasement of a psychology that fears freedom. Necessity is a drug and we’re all addicts; if we get our fix, it stabilizes us enough to be creative again. Yes, but wouldn’t a cure be better? Schoenberg came up with the twelve-tone system for the same reason: actual freedom terrified him, so rather than bearing that fear until it subsided, he decided he needed to be straitjacketed so that he could go back to finding freedom appealing again. So he made up an Oulipean straitjacket system and started writing Oulipean straitjacket music, and then eventually the straitjacket was mass-produced because there was so much demand.
“Necessity is the mother of invention” is, I think, not actually true; just look at all the splendiferation of unnecessary stuff that litters the internet. Glorious surplus! It turns out that people are actually much more inspired to create when it comes to useless stuff that nobody asked for. You’re the man now, dog!
The reason necessity seems to be the mother of invention is that when an invention happens to meet a general necessity, it goes on to fame and ubiquity and takes up a lot of our mental space. It sure seems like the telephone got invented because we needed a telephone, but actually it just got famous because we needed a telephone. It got invented for the same reason that everything else happens: that’s just what people do.
This is the same distinction as one must make in understanding evolution: nature doesn’t “come up with solutions to problems,” it “constantly does random crap”; when some of it happens to solve a problem, it ends up persisting as a result. “Selection pressures” do not create life; they kill it. But all the same life, uh, finds a way. Remembering this difference is important when it comes to trying to motivate ourselves. Necessity is in fact the scourge of invention. But we’re so inventive, we get by anyway.
Anyway, I dipped my toe in SpaceChem a few years ago but I felt the old chill right away. “Oh dear,” I thought. “I’m going to have to freely make things up?” I only made it through two or three puzzles before the sense that I was somehow an idiot became overwhelming and I had to stop.
But this time it went differently. Realizing that necessity isn’t a necessity is a big one for me, and I felt like my success with SpaceChem this time around represented my having gotten over a big one.
Basically, the game gives you some raw materials and tells you how they need to end up, and then you build a machine that will turn the input into the output. The premise is that the materials are molecules, and you’re doing chemical conversions, but that’s just a skin — beyond being named after the elements and being bondable to one another, the pieces aren’t anything like atoms, and what you do to them has nothing to do with chemistry. They’re essentially just abstract game pieces; your job is to construct a system that will shuttle them around and pull them apart/stick them together as needed. It’s a programming game. Here are the available resources, here’s the program specification, here’s the language: write something that works.
The pride of the programmer is a special kind of pride, combining the pride of satisfying authority (the superhuman authority of the computer’s needs) with the pride of having willed something as an authority. To many, this dual pride is the ideal pride. And perhaps something like it can be for me now, too. Finally.
When I was younger I could not find any pleasure in programming. I managed to pass untouched through a lot of “but you really seem like you’d be into this” encouragement. Programming wasn’t authoritative enough to offer me a gold star of correctness (there was no “right answer”), but it was far too needy to gratify my pent-up desire for freedom from authority. If I want the pleasure of making things up, why would I seek it in this hyper-demanding anal-retentive robot?
And yet in the abstract, thinking about myself from the outside, it does seem like I ought to have been attracted to exactly what it offered, the balance of doing both at once, of being simultaneously authority and subject to authority.
I think the bottom line was that my loss of hope that I could ever put real trust in any new authorities (i.e. from beyond the safe zone of my parents) happened very early. By the time I was supposed to learn to program, I was already a skeptic in my heart, and the tutorializers who were trying to step me through initializing arrays and declaring variables seemed as suspect as my teachers at school. Why should I have to “declare” anything, and have to decide in advance whether it’s likely to be “floating point” or not, just to add x+y? That sure doesn’t sound like something I’d do! It all seemed to fall into the same category as the tedious and manifestly meaningless pro forma homework assignments that were my official occupation at the time.
Furthermore, the idea that I could do anything really cool with programming seemed intuitively impossible. Yes, maybe some faraway other people had figured out how, and had somehow made the games I played, but of course they had all those many and enormous advantages that seemed to inhere in otherness and farawayness. Whereas when I went dutifully to try to learn programming, it was clearly a different story, and that was the story I needed to work within. It was more like: “Suppose you have a shoe store and you want to keep a database of all shoes sold, and their prices. You’d use an array.” This was a real example in the book I more than once tried to push through. That’s all I could see from where I sat.
I won’t lie: I do still carry with me a subtle feeling that SpaceChem is actually for “natural programmers” who “feel at home with this stuff” and that I am “just somehow managing to stumble through it, but not the way you’re supposed to.” But that feeling is understandable, because these things die hard; or more accurately, these things don’t die, they just grow or shrink. And there’s no question that this one has shrunk since a few years ago when I couldn’t even wrap my head around the third puzzle in the game because I felt so completely overwhelmed. Now I just feel a little sheepish occasionally: for example, after I make an elaborate plan and spend 20 minutes building it piece by piece, and finally set it going, and only then realize that it’s all premised on a weird dream-logic oversight in my assessment of the situation, and doesn’t accomplish anything remotely like what it’s supposed to, and that I have to start from scratch. Stuff like that makes me feel a little red. But not beet red, not red-alert stop-the-game red. Good news!
And the compensation is, when you build a thing and it does what it’s supposed to: there it is! You get to watch it go zoop, vip, zoop zoop, wait, wait, zoop zoop, ding! And then back to the beginning to run again. Is it elegant? Usually no. But anything that goes without stopping tends to feel right. The extreme busyness of inefficiency can actually enhance that effect.
I’m starting to think that part of the personality of a programmer is really just attraction to things that go without stopping, things that go zoop, vip, zoop zoop, wait, wait, zoop zoop, ding!, regardless of what that “ding!” represents. I guess I am such a person — I certainly like marble runs, factory tours, and Rube Goldberg machines. It’s really just that connecting that attraction to the constraint of meeting specified goals is still very new for me, still a very rickety rope bridge. The circumstances need to be just right for me to dare cross it. That was my cranky complaint about Crayon Physics: you didn’t put me in the damn mood!
SpaceChem did a lot better. Unlike Crayon Physics, its system is tight and 100% reliable. Unlike Crayon Physics, it is not trying to sell me a bill of nostalgia. And most importantly, it goes zoop, vip, zoop etc., where Crayon Physics kind of just went murrrrrrrhhh. I’m not talking about sound effects, just general feel. We think we’re in it for the problem-solving, but we’re really in it for the zoops. SpaceChem has an extremely barebones nerdy left-brain design sense, but the actual actions of the mechanisms are sufficiently zoopy.
Though I do think it would have further calmed my embarrassment had it all been a little tastier and more tactile. That aesthetic whiff of MIT — or in this case, of Redmond, WA — always puts me into a certain cagey place, socially: bracing myself to be both outsmarted and outdumbed. It’s an old cage, and one that I have had some good experiences while inside, but I’d like to put it behind me. Neither being outsmarted nor being outdumbed ought to require me to brace myself.
It struck me as a clever innovation that the game has “boss battles” which take place on a time scale where your designs are running at hundreds of cycles per second. This of course is how programming works in the real world, but I think it’s the first time I’ve seen that kind of timescale-stratification built into a game.
The presence of “bosses” in a puzzle game is justified by a kooky bureaucracy-plus-horror story that gets doled out in dry vignettes between levels, which I guess added a little bit to the atmosphere of the gameplay, though not much. Telling a slight story while people are solving puzzles is a good idea in theory, but is also inherently a goofy thing to do, and this was fairly goofy. I will undoubtedly have opportunity to talk about this general issue again in future games, and this entry’s already awfully long, so enough about that.
The game has a “cinematic” soundtrack, where “cinematic” is in quotes because what it sounds like is the adjective “cinematic,” rather than like actual movies. (Well, not like good ones, anyway. I guess a lot of movies do feel pretty “cinematic” these days.) It’s full of “drama” and “sweep” and mostly feels nothing at all like sitting for a long time solving one of these puzzles. There are also some peculiar horror-movie effects in there, I guess inspired by the peculiar horror-movie touches in the storyline. I could imagine that the designer said: “Since the game is so cerebral and nerdy, probably the music should help counter that by being dramatic and cinematic.” But that’s silly; the music needs to support what’s actually going on. I don’t like to turn off music in games, but in this case I had to turn it off.
This game is very hard. Most people who start it do not finish! I would like to finish it and think I can. But I also started the next game to give me something easier to do at the same time, and I’ve already finished that one, so the time had come to post. If the game has a really really great ending I’ll come back and say so between these next two lines.
“Zachtronics” means basically Zach Barth made this, with help. Turns out his wife wrote the story. The entire credits as they appear in the game (with joke intact):
Design and Production: Zach Barth
Programming: Collin Arnold
Anti Programming: Keith Holman
Visuals: Ryan Sumo
Music: Evan Le Ny
Sound: Ken Bowen
Narrative: Hillary Field