When we were in Honduras last year we had a pretty crappy Internet connection. It was pretty slow and we had to pay for our bandwidth by the meg. When you pay by the meg suddenly podcasts and torrents are less fun. Fortunately there were a few indie games I sucked a lot of fun out of. They kept me entertained for days and all they asked for was a few megs of bandwidth.

One of those games was BrainSplode! by Rich Edwards. BrainSplode! isn’t even a proper game. It’s just a prototype. But it’s so good it drives me crazy that Rich is continuing to prototype stuff rather than just double down on BrainSplode!.

You can think of it as a game about programmable howitzer shells. I like it for a couple of reasons. One is because it is incredibly, rediculously fun. Another is that you can so easily enumerate the complexity of BrainSplode!.

I will give a very brief description but you should really just go play it. Brain Splode! starts off as a very familiar ballistics game ala Scorched Earth or Crush the Castle. But it mixes in some Roborally/SpaceChem style programmable elements. Namely, you can chose to change the direction of the shell, fire off a booster rocket, pop a parachute, or any combination of these three actions at any time after the shell is fired. You do this by lining up three ‘actions’ to take before you fire the shell and then activate them in turn by pressing the mouse button.

As an example, I can fire the shell high and to the left, then I can make it face backwards, then I can fire off a booster rocket which sends it flying to the right and then pop a chute to slowly glide towards my final target.

BrainSplode! has something like 6 variables to play with. Two for the cannon, one for how I program the shell, one for how I set the direction changer (assuming I use one) and then another couple for when I choose to activate each action.

Since a lot of these variables are along a continuum and not discreet choices it’s hard to enumerate the total number of options available but we can easily see that the solution space is huge. In fact I think it’s too big. BrainSplode! is yet another game in a long series of games that I love but utterly fail at convincing my friends to play. I pestered everyone I knew and almost no one else finished BrainSplode!. I think that has to do with the complexity of the solution space.

There is some good empirical evidence that the two variables of the ballistics game on their own represent a comfortable level of complexity (Angry Birds). So I think BrainSplode! is stumbling outside the optimum complexity fun-zone. As an interesting experiment I’d like to try pushing it back into the fun-zone. Here’s how the experiment goes. You can play along at home.

1. Download BrainSplode!
2. Beat BrainSplode! normally.
3. Go back to level 7 and set the cannon to shoot up and left with minimum power (put the power meter in the very top left of the square). Now beat level 7 without moving the cannon.
4. Do the same for level 6.

You have to beat the game first because steps 3 and 4 are very hard (since the game isn’t designed with them in mind) and if you didn’t the difficulty curve would be way out of whack. By holding the cannon variables constant we push BrainSplode! back towards the optimal-fun zone where the complexity is more manageable. I think as players and designers we intuitively understand when something is too complex or not complex enough, but only after the fact. We pretty much have to build something and play it before we know if it needs more or less stuff glued onto it. Worse still after we’ve been living with a game for a while we lose perspective on the optimum complexity: “I have no problem understanding the game I’ve been making for 4 months, I don’t know why other people are having trouble”.

I’d love to understand the relationship between complexity and fun better. Mostly I find it an impenetrable fog. I’m always trying though and BrainSplode! is probably the most fun experimental complexity playground I’ve yet to find.

p.s. if you’re really looking for a BrainSplode! challenge I have two more for you:

– Try level 7 but with only one set of programed commands. You can use parachutes and rockets and everything, but you can only set them once  at the beginning and never change them. This includes the green change-angle power. You can use it but you must chose one angle at the very  beginning and never change it. You also have to leave the cannon locked in one place, but you can set it anywhere you like. No changes to  anything! (if you play RoboRally then think of it as having all your registers locked).

– Then try level 6 the same way.

I’m pretty sure I’m the only one in the world to get these ones. Even Rich shied away from these challenges. Happy ‘Sploding!

I haven’t written much for a while because as soon as we got to San Francisco we got crazy busy. We have so many friends here it’s hard to find the time for things like blog posts. I’m having enough trouble finding the time to do development.

I also haven’t taken any pictures apropos to this topic so I’m just going to pepper it with random snaps from our time in SF. This blog is also about travel after all. Anyway, one advantage of having so many people around is that I can run experiments on them.

I’ve been interested in problem solving for quite a while. Specifically, the difference between just sitting down and thinking out a problem versus playing around with it and trying to tease a solution out. To get a feel for how good we are at just thinking something out I devised an experiment and tested some fellow indies.

Sarah and I work during the day at a workspace we share with some other SF indie game makers. It’s nice to be surrounded by peers and their good ideas and it’s also a convenient space to hang ropes. Lately I’ve been hanging ropes from the light fixtures and proposing a challenge to everyone in the office. I’ll propose it to you now and you can see what you think.

The setup is simple. There are two ropes that hang from the ceiling. One rope has a loop in the end, and one rope has a knot. Your goal is to put knot through the loop. The ropes are easily long enough to accomplish this but they aren’t so long that you can grab one and then walk over and grab the other. If you tried to do so you would find your outstretched arm about a meter away from the limp second rope.

Now find 4 ways to put the knot through the loop. You can use anything you might find in a typical office. You can not cut the ropes or untie any knots. Give this a few moments thought, you are in a perfect position to be part of the experiment.

When I do this in the office I let half of my subjects play with the ropes to find solutions. The other half can merely look at the ropes and propose solutions. You are in the second category and I imagine that your performance will not be as strong as the people in the first category (especially since you have to imagine the whole setup).

Alright, are you comfortable with the solutions in your head? I’m going to give you the four intended solutions:

• Take a chair, put it in the middle of the room, place one rope on the chair while you fetch the second rope.
• Find an Ethernet cable or something rope-like to tie to the first rope. Use this to make the first rope longer so that you can reach the second rope.
• Find a long tube or a stick. Grab the first rope and walk as far towards the second rope as possible, then use the stick to reach the second rope.

Now here comes the important one. The first three are all pretty easy to find. If you were in the room you would have come up with them all. This next one is the one I’m interested in because people tend not to find it if they aren’t actually playing with the ropes.

• Tie something heavy to the end of the first rope and give it a big swing. Then run to the second rope and back in time to catch the swinging first rope.

If you thought of the swinging solution then well done. If you thought of it in less than ten minutes then really well done. You are in the vast minority of people I tested. Most people had a lot of trouble finding the swinging solution unless they got to play with the ropes. Conversely, people who did play with the ropes often found it fairly easily. This is because the rope with the knot on it swings a little bit on its own.

People who got to play with the ropes would usually find the chair solution first (actually there’s a couch in the right place so people tended to just use the couch). But after finding the chair solution they would drop the ropes and the rope with the knot would swing a little bit. They didn’t always notice it. Sometimes they were looking elsewhere, but by the time they found the three easy solutions it was almost inevitable that they would see the rope swing and that would give them the idea for the fourth solution.

This is important because I think we tend to be overconfident in our ability to imagine solutions to problems and imagine how ideas will play out. As a game designer I am very guilty of this. I will discount ideas because I can’t imagine them being cool. The problem is that we aren’t as good at this as we think. Natural human problem solving relies on playing around with things. We shake things and pull at them, we hit things and try to mush things together. When we play we’re looking for novel behaviour. We’re looking for cracks in the problem that we can exploit and make wider. We can do this in our minds as well but we’ll never be able to find a truly surprising solution unless we’re in the room playing with the ropes.

This means I should be prototyping more. I should stop discounting ideas because I can’t imagine them working. I should sink an afternoon into hacking them out. I might waste a few afternoons at this but it’s also the only way I’ll find unexpected wins.

It also means we should just hurl ourselves into those huge, daunting, problems that are so intimidating (like Spacechem). They are daunting because we can’t imagine all the moving pieces but we don’t have to. We can just play around and let the solutions make themselves known. It’s how kids solve every problem, I think we’ve just gotten lazy.

Colin: How did you start working on SpaceChem?

Zach: I started working on SpaceChem in November of 2009 with a friend who, being familiar with my previous works, wanted to make a game. Over the next year we picked up another programmer, a musician, an artist, a writer, and a sound designer. My goal for the project was to up the scope an order of magnitude from my previous games. There were plenty of times when it felt impossible, but with the help of my team we nailed it in the end.

Playing through those previous games you can see ideas evolve from game to game. The Codex of Alchemical Engineering obviously had a strong influence on SpaceChem. When you started SpaceChem what did you want to keep from The Codex and what did you want to change?

While I wanted to keep the mechanic of building structures out of “atoms” by “bonding” them together, I also wanted to add a bunch of new ideas that came to me after releasing The Codex, such as inputs being more complicated than a single “atom” and a greater context for the puzzles. I also made sure to fix some of the glaring gameplay errors, such as requiring structures to be built exactly as shown and having the complexity of solutions ramp up exponentially.

Are there other games in the back-catalogue that had a big impact on SpaceChem?

The defense missions are very similar to the battles in The Bureau of Steam Engineering, as they both require players to build a mechanism to power massive weapons with timing and sequencing requirements.

I found that idea interesting because of its contents and because of my familiarity with it. This is a bit of trend with all of my mechanics: I invent a new problem in the form of a new game and use both brand new ideas and lessons learned from previous games to solve it.

A lot of indipendent game authors take a very iterative aproach to design. Do you work in the same way or do you plan things out from the beginning?

A mixture, really. I started designing SpaceChem by drawing up initial concepts for mechanics, progression, interface, story, and almost every other aspect. After that we wrote a prototype to test out the reactor mechanics and then began working on the full game.

Over the development cycle, though, we changed many details as we learned what worked and what didn’t. For example, pipelines were originally based around an economic model that rewarded efficiency and allowed you to either “pass” or “master” the level depending on how many constraints you were able to optimize for. You could place as many reactors as you wanted and discard as many molecules as you needed to, but in order to “master” the level you’d have to balance the number of reactors against the number of products you chose to produce and maybe not throw away any molecules.

Although I’m sure some of our hardcore fans will think we were stupid for throwing this system away, early playtesting indicated this was far too confusing. After a bit of discussion we vastly simplified the system to a single binary goal of “produce all compounds using the number of reactors allowed and generating waste only if the level includes a recycler”.

How much impact did the rest of the team have on the design of SpaceChem?

Although I was essentially the “gatekeeper” of design, many of the decisions were made as a group, to the point that I can’t even identify who was responsible for what ideas.

How long did you spend on the initial design phase when you were drawing things up?

The initial design phase consisted of a year of spare moments and snippets of conversations that birthed ideas that would go on to make SpaceChem and about two weeks of sketching and discussion when we decided to get down to it. I sketched out most of the design not related to the core mechanics while prototyping was being done by Collin, the aforementioned initial programmer friend.

In prototyping we found that the core ideas could work, but not much more, as the prototype only encompassed the core reactor mechanics and lacked critical touches such as the line drawing and reconfigurable bonders (they were originally all 2×2). As mentioned earlier, a lot of the little decisions about how to make everything fit together nicely were made incrementally.

When it comes time to do design, my primary tool is sketching, which forces me to fill in the gaps in ideas that exist only in my imagination and allows me to visually inspect the finished product and imagine how it will function. In the early design sketches you’ll see the cut features I mentioned earlier: pass/master goals, an economic model, and tower-defense style defense missions.

Now that it’s out the internet is peppered with glowing reviews for SpaceChem. I’m a huge fan of the game myself and I’m proud to say I’ve finished every level. The final level alone took me 10 hours to solve though. Were you not worried that the game requires too much stamina and prolonged intense focus? Is SpaceChem written for a specific audience?

This was definitely a question that was on my mind, but more truthfully it was something we had very little information about. Some of my previous games were similar to SpaceChem, but were both free and short; we had no idea how players would respond to a scaled up version, let alone what would be the best way to broaden the scope.

SpaceChem wasn’t written with any specific audience in mind, and from what I can tell it hasn’t resonated with any one audience in particular. I’ve read an astonishing number of players remark that they normally don’t like puzzle games, but that they can’t stop playing SpaceChem!

Most important question for last: when are you finally going to write Ruckingenur III?

Hah! Ruckingenur II is by far one of my favorite projects – it’s just so sexy! The puzzles were really difficult to make and had zero replay value, though, which in addition to the inherent niche-appeal makes me think that a sequel isn’t likely. I hope to explore the general concept more in the future, though…

Thanks very much to Zach for answering some questions about how he and his team designed a great game. You can buy SpaceChem on SpaceChemTheGame.com or on Steam and you can play Zach’s back catalogue of games (including the really excelent Ruckingenur II) at ZachtronicsIndustries.com.

I’m pretty giddy that I have a place I get to talk about games I love now. Expect some posts featuring my favorite games from the last few years. SpaceChem is one of my favorite games ever. It is wonderfully hard-fun. It’s all about learning, finding tricks, and letting your brain slowly sink into the game until you absorb its very essence. Lo’ you have become a master where once you were but a wobbly newborn colt. SpaceChem is a very good game. Unfortunately today I come not to praise Ceaser, but to bury him.

Since this game is so good everyone must be playing it right? It’s crazy that you’ve never played it eh? Obviously a good rigorous playthrough is in order. Here is the free demo (there is also a mac version). Alright. Tried it? Got through the demo? Ready for more? No? You didn’t get anywhere and the game seems confusing and overcomplicated? Well that’s because it is. I’ve tried to get everyone I know to play it and I think I’ve managed to make Zach about two sales. No one else I know has beaten it despite my attempts to portray this as a sort of sword-in-the-stone accomplishment. I seriously considered adding a monitary bounty to the feat. People won’t play SpaceChem even if you pay them. This is despite the fact that it is an astoundingly good game.

I have a theory about why SpaceChem is so very hard to play. It is because Zach aproached interface design from the point of view of an Autocad designer instead of a game designer.

There is one major difference in the two. The Autocad designer can not change the nature of buildings and the plastic hee-haws that Autocad is made to model. A game designer has complete control over the domain of their problem. It is foolish of us to not abuse this ability! Autocad will never be as fun as Fantastic Contraptin because Autocad has to model the real-world which is messy and complicated. Contraption’s world, on the other hand, is specifically tailored to fit hand in glove with the tools used to interact with it. The real world has depth but depth is akward to manipulate on a 2D screen; depth is thrown out the window. We’ll use a “sticks collide, water rods don’t” metaphor to get us 90% of the way towards depth. In the real world when three things are connected at the same point and one of them has an engine attached you have to specify where that engine is. You can’t just say “one of them is a wheel and the wheel spins” wheels spin about other things. Which of the two other things does it spin about? Nope, that question goes out the window, we tailor the world so that it doesn’t matter rather than tailor the interface to perfectly model the world.

This is why SpaceChem feels overcomplicated. The game-world makes no concessions to the interface, to the tools used to interact with it. Since you played the demo I can discuss one example and how I would do things differently. You know how the game is about grabbing a couple of circles from the left hand side of the screen, doing some stuff to them, and then passing them off on the right hand side of the screen. You can see that quite clearly in this screenshot. See, over on the left you can see where you pick them up, and then see, over on the right you can see where you drop them off. Excpet no, you can’t. The drop-off and pick up spots are only nebulously marked. They are the large squares marked with a greek letter. You can drop stuff off anywhere inside that square and stuff gets dropped in… well there’s a tiny little diagram on the left that tells you where it’s dropped in and you just have to do the mapping yourself.

This is not how most games would solve the “place to pick it up and place to drop it off” problem. Most games would have a little outline on the ground of where stuff will come in on the left and another little outline on the ground of where stuff must be dropped off on the right. This would make the goal of the game crystal clear to players. It would make the perceived level of complexity go down. SpaceChem, though, is not most games. Its dreams encompass not just the rolling hills but also the jagged snowy peaks, and as such, this solution would not work.

See in SpaceChem you build these little machines. But in some levels you also build several machines at once, linking them all up to eachother with pipes. Like in this screen shot over here on the right. Now you see why printing outlines on the ground doesn’t work. Since the player decides what gets spit out of these machines and where they go you can’t have the strictly-enforced outlines. The game simply doesn’t know what’s comming in and going out. Whats worse is that advanced players will pass more than one thing into the same pipe in different and odd proportions.

So the game as it is designed can not have these nice outlines that tell new players how to play SpaceChem. To solve this interface problem we need to change the game design. Instead of letting the players build little machines that take in anything and spit out anything lets give them a selection of machines with pre-set inputs and outputs. We can include all the machines necessary for the intended solution, a couple of common alternates, and mabey a few red herrings/challenges for advanced players.

Now the interface is clearer, the perceived complexity is lower, and more people will play (and buy) SpaceChem. The pipes-levels definitely lose some of their magic but the pre-set machines offer another kind of challenge that might turn out to be almost as strong.

There are other ways which the domain of SpaceChem could be changed to better suit the interface and I don’t know if rounding all the edges off it would have made me love it less. It is certainly possible. But damn if I don’t just want everyone in the world to be able to enjoy my games. And damn it if it isn’t incredibly frustrating to try to get my friends to play SpaceChem.

But you’re made of sterner stuff. Go buy SpaceChem and remember, if you don’t find it fun it’s only because Zach overestimated your intelligence.