Anyhoo, I just started playing SpaceChem last weekend, (got it for a dollar. Thank you Steam sales.) and while I only just finished the second world this morning, I'm not kidding about that title.
For the uninitiated, SpaceChem is a game in which you are an engineer working for a chemical engineering firm in the 2700's. Your job is to build and connect custom reactors which take one to two chemicals in and sent one to 2 chemicals out. The inside of a reactor is split into 2 halves, the red half on the top and the blue half on the bottom. Each half has its own input, output, and 'waldo', a bull's eye looking thing that travels at a constant speed along the 2D circuit you layout. Along the circuit are commands to grab or drop an atom (and any other atoms attached to it), bind/unbind atoms, admit a new input, release an output, or wait for the waldo on the other circuit to pass a given point. There are probably other commands I haven't seen yet, but what I've described is enough to get the gist of it.
The trick is that while the waldos can run over and through each other all day, the atoms they are carrying cannot. Any collision between atoms crashes the whole process, so you have two parallel systems that have to work together and cannot collide. On top of that, your reactor will be part of a pipeline and if a reactor down the line is slower than the reactor feeding it, the unused input will queue up at the pipe until the molecule at the back is unable to leave the reactor and is it by the molecule behind it, again causing a crash.
So you have a set of procedures with inputs and outputs that run in parallel, form a pipeline, and must not crash. Some of you are probably thinking, "Man, that sounds a lot like programming!" and if so, good, because thats basically my thesis here. Not that I'm the first person to say it by any means, in fact that was basically the pitch from my friends trying to get me to play it. But I think it's more interesting than that.
On the surface, the game is obviously very different than conventional programming. But I think the reason everyone relates it to programming is that it captures the core experience of programming without duplicating the everyday mechanics. When you open a fresh reactor, you come up with some idea of what you need to do, assemble the circuits, and then run. And then it breaks. Something doesn't happen the way it's supposed to, so you look it over and diagnose the problem, then change the circuits to fix it, and try again. And it breaks in a different way, so you find the new problem, and fix that. Test, analyze, modify, and repeat until done. And when it works, it's just as surprising and thrilling as seeing seeing your program finally doing what it's supposed to do. If I wanted to explain to someone how programming worked, I would probably show them a simple program or point them to turtle graphics or something. But if I wanted them to understand why I program, to understand what it felt like, I would make them play SpaceChem. It hits all the same notes without having installing any new libraries on their computer, except Mono if they're on a Mac. (Pro tip: nothing makes a downloadable application sound safer than naming after an actual virus.)
And that is why I think everyone should play this game at least once. It communicates the basic appeal of programming that so often gets lost amongst the jargon when you try to explain it to them. I don't think it should be a mandatory course, just one of the many applications on the elementary school lab computers that students ate encouraged to try. And if a student really likes it, get them started on python or javascript, because they're probably good candidates for future programmers. And your future software engineers? Look for the kids who can't abide a backup even if it isn't bad enough to keep them from winning.
As for people who are already programmers. Play SpaceChem anyway, it will be good training for you too. The game's focus is on parallel processes in a pipeline, where the goal is fast, reliable throughput. These are concepts we talk a lot about in computer science, but for practical reasons, rarely get to play with. At one point in the game, I wound up having to slow down one a producer to keep from overwhelming a necessarily slow consumer. That situation would never come up in my hobby projects or my job, but in large scale data management, it's a very real possibility.
So there you have it. Whether your a programmer yourself, or someone trying to understand what programmers are on about, or even just a person looking for unique and interesting game, you should definitely check out SpaceChem.
....Why are you still here......
Oh you want update on the other thing... *sigh*...
Stratagem (working title) has been through rather a large pivot over the last several months. After my last post I dove into getting an HTML5 javascript version a good way in, but I was dragging my feet. At the same time, I came to a realization that nearly every studio in Vancouver is using Unity, so my not knowing how to use it was a bit of a negative for future resumes. And then I thought about why I chose the HTML5 javascript route in the first place: playability on lots of devices (via the good ol web) and a skill set I needed to build anyway, and I realized that both of those apply to Unity way more. So I dropped the old prototype and started working on a Stratagem Unity project. The only problem was that I knew jack all about Unity and was slow to force myself through learning it. I've gotten over that particular ump now and I've officially surpassed the old prototype's functionality. I'm hoping to have a really simple playable version by new years eve, but I have other stuff I need to do as well and it's Christmas, so we'll see how far I actually get.
See ya.
.... What? You need me to sign off? But it's super embarrasing!
Fine.
I'm Lambwatt, and this is day.... 236?! OH #*@& ME!
