Zach Barth (2017)

This is a difficult and loaded question! What is fun? Is it really a consideration when designing games? You didn't ask this, but I certainly ask myself: does being fun make a game successful?

People like building machines. People like writing programs. People like making them faster, or smaller, or more efficient. Requiring players to sequence parallel tasks with emergent tools is a surprisingly deep design space. People don't really like puzzles, but I think that puzzles are the best way to exercise the kind of systems that I like to design and our players like to build with, and maybe that makes puzzles okay, and possibly even fun? Being challenged is painful, but solving a challenge is euphoric, so maybe the interplay between those two states feels like fun?

Is it possible to do something and be good at it, but not really understand what you're doing?

Considering that we essentially just re-made the Codex I think that anything is possible!

They were removed from the iPad release because, when we ported SpaceChem to iPad, everyone was still on first-gen hardware! We couldn't get the simulation to run anywhere near the "real-time" speed setting that is required for the boss battles to make sense. Our metrics also indicated that they were the hardest puzzles by far, so when porting to a platform known for the casualness of its audience it seemed like a sensible solution.

Did you play through the second campaign in Infinifactory? There's totally a boss battle at the end!

There are lots of little reasons why we haven't explored boss battles in our more recent games (I guess except for that one that's totally at the end of Infinifactory):

• They were generally harder, and caused more players to quit the game.
• They require you to design a solution that drives a real-time simulation that you don't know the parameters and timing of, which means that as you learn more about the simulation you have to constantly refactor your solution, which can really blow up the time and difficulty.
• They're typically more content heavy, as now you have to design and implement distinct bosses.
• It's difficult to reconcile the micro-scale of simulation time with the macro-scale of boss time.
• They turn optimizing for cycles into the optimizing some dumb simulation that I wrote about laser beams and turning speeds and cooling systems.

We had considered making some puzzles for SHENZHEN I/O that were about taking feedback from a simulation and then feeding inputs back into it, but they had all the problems listed above without seeming like they'd really help make the game that much more enjoyable. At least the boss battles in SpaceChem had loads of personality!

We have five people on the team right now: me, another programmer/designer, a musician/writer, and two artists. We do have a tendency to scale up a little during production, but it's always a challenge to strike the right balance between contracting and employment that satisfies everyone's needs and desires.

I don't know what this means considering the kind of games I like to make, but I strongly believe that the best way to teach someone to program is to sit them down with a programming language and let them build something that they want to build. If you have an end goal that you want, and have the means to get there (books, mentors, etc.), you'll make it happen. This is how I, and many others, learned to program. I'm not sure what the decline of the personal computer means for this, or if there really is a decline in personal computing as a cultural phenomenon.

Also, if I learned one thing making educational games it was that I am not an educator! Sure, it's a discussion that everyone can participate in, but there are literally experts in this field...

When thinking about games with programming as a mechanic, I differentiate between "programming for programming's sake" and "programming as a means to an end". Our games all fall strongly into the former category, and we make lots of design decisions to support this (like designing our in-game programming languages from scratch). Games like Minecraft or Space Engineers I'd bucket into the latter category, where you're trying to accomplish something. The key difference is that, when you're programming as a means to an end, it doesn't matter if you write the code yourself or if someone else did. If you do that in a Zachtronics game, however, you're a dirty cheater. The programming is the point.

1. This definitely helped, along with the fact that I've been kicking around the ideas for Opus Magnum since 2013! We made Infinifactory instead, though. We actually spent a few months between SHENZHEN I/O and Opus Magnum prototyping an idea that didn't pan out, so being able to about-face and charge straight for a known target was convenient.

2. I think about this a lot, because a lot of people suggest it. It's possible I'm wrong, but I see the gap between these games as being much larger than people realize! See my comments above about "programming for programming's sake" versus "programming as a means to an end" above. Also, I suspect that I don't actually have any interest in making fake-resource Skinner box games, but I also don't think I have much room to talk because whatever we're doing with our puzzle games is clearly also ~~addictive~~ "highly compelling".

A year or two after the release of SpaceChem, Keith (our other programmer/designer) and I had dinner with some programmers at Bungie who were fans of our games. I'm paraphrasing here, but they lamented the fact that the puzzles were so hard to solve that they didn't get as many opportunities to optimize as they would have liked. This tracks with something we continued to see in our puzzle games: very few people beat them, but many people love to optimize the early, easier levels.

Opus Magnum wasn't necessarily envisioned as an "easy" game, but once we figured out it was we chose to embrace it. We've always wanted to explore the idea of making a game where the puzzles were easier to solve but still interesting to optimize, and with Opus Magnum we've gotten the chance! Some people liked the extreme constraints of SHENZHEN I/O, but lots of people also complained about it, so maybe this is a good experiment? Maybe making a more casual Zachtronics game will open it up to a larger audience? It's too soon to tell, but we'll know eventually.

(As a side note, we try to do a lot of experiments like this. Having a puzzle editor at launch? Experiment. Translating the game at launch into five additional languages? Experiment. Finally adding an option for global records on the leaderboards? Experiment!)

I think the next Zachtronics game is going to kick your ass, but maybe don't hold me to that.

I used to view the extreme difficulty of SpaceChem as a negative, but I don't anymore. Lots of people love SpaceChem. It's just the way that game is!

The "survival rate" of Opus Magnum is much lower than 95%. If we're lucky maybe 10% of people who start the game will finish it? It's tough to tell early on, where most of our data is from people who haven't put down the game for good yet. Weirdly, we lose people the fastest in chapter 1, but I guess it makes sense because that's when it actually becomes a puzzle game instead of a tutorial game.

> How did you market/PR/tell people about Opus Magnum? Which way is the most fruitful?

I don't really believe in PR. We do boring stuff like Tweet and email people on our mailing list, and obviously the branded GIF recorder is a deliberate attempt to help the game "go viral". Our biggest and best asset by far is the fact that I've been doing this for 10 years now, which has given us name recognition and an army of fans (❤) who understand what we're all about.

> Did it sell well? Do you care whether it sells well now that you don't run your business?

We don't have a lot of data yet, but even if we did I probably wouldn't answer that here. Sorry!

> Does it help to be prominent/having a fan base or do you need to start over each time in terms of marketing?

Absolutely! See answer above.

> Why do you use the "infini" prefix for block games?

If Infiniminer started the block game genre, why wouldn't we keep using it? The "infini-" prefix is actually something I started using in college for all of my games that involved creating the content as you played, like Infinifrag and Infinitron. They're both very bad.

> Are you planning to make more block games?

We just released Opus Magnum, geez!

> Why didn't you let arms move other arms in Opus Magnum?

We wanted to avoid what we call "octopus arm solutions" where you painstakingly but inelegantly program a single arm to do everything.

> Is The Incredible Machine a design-based puzzle game?

It depends on the puzzles, largely. I recall that they tended to limit your parts and give you puzzles with "gaps" to be filled in with specific parts, which makes me say no, but I also remember open-ended puzzles with much more Zachtronics-style goals.

I remember reading years ago about people who put their experience leading WoW guilds on their resumes. Apparently it worked sometimes? Maybe you should include some Opus Magnum GIFs on your next resume?

I don't think so. I certainly know of other games out there like ours, but I haven't played any other than Silicon Zeroes, which I did really like. There's probably another one that I liked but have forgotten...

> Which of the game design decisions in your recent games do you regret the most?

I try to live my life without regrets.

> Do you watch videos of people playing your games during the Early Access?

I tend to focus more on reading emails, Tweets, and forum posts, but everyone else in the office likes watching people play our games, especially our UI artist, who uses it to collect information about what parts of the UI trip people up.

> Can we expect a new Infinifactory-ish game soon from Zachtronics?

What makes a game "Infinifactory-ish"?

> Where do you find a lot of your inspiration for your projects?

Real-life engineering disciplines, often. People have designed lots of strange systems for solving problems, like ladder logic and BASIC and pneumatic mail tubes.

> What do you recommend to someone to start learning more about this sort of systems and logic?

Take or audit an introductory course in computer programming or digital design (logic gates, etc.) and you'll learn more than you ever wanted to know!

Oh, but they're all great!

Opus Magnum is probably the easiest, followed by Infinifactory. SpaceChem is arguably the hardest? Not sure where TIS-100 and SHENZHEN I/O fit in, as they're about more explicit programming and require you to literally read manuals...

The one where Tim Allen upsets his wife, but then gets advice from his neighbor.

Lately, a lot of Heroes of the Storm and Worms Armageddon with friends! I'm not actually sure how much I enjoy playing video games in general anymore, but that's like... some deep stuff to unpack elsewhere...

One of my shitty superpowers is that, generally speaking, I can look at a puzzle for a Zachtronics game and intuitively judge how solvable it is. It's not perfect, though... my wife spent about 8 hours trying to solve an Infinifactory puzzle that turned out to be obviously and fundamentally impossible in retrospect.

For the puzzles in Opus Magnum, the process looked something like this:

• Brainstorm a set of mechanics, in this case the different types of arms and glyphs.
• Work with our writer to come up with a list of "puzzle concepts" that mesh with the narrative. (This is somewhere that we've grown a lot since SpaceChem, where most of the puzzles were just random chemicals with no connection to the story. In SHENZHEN I/O we tried hard to make every puzzle its own mini-story and were very pleased with the result. We did the same thing with Opus Magnum and will presumably do this for every puzzle game we make going forward.)
• Design a "level design form" for the game that has places to put everything a puzzle requires.
• Sit down with a stack of the aforementioned level design forms and bang out a little more than a full game's worth of puzzles. (During this step I learn about the game's puzzle design space, both by thinking them through in my head and testing them in the game, which is presumably getting prototyped simultaneously.)
• Integrate the puzzle designs into the game and playtest them, smoothing out overly easy or difficult sections and removing redundant or boring puzzles.
• Expand playtesting up to and through release, using a combination of over-the-shoulder-observation and remote data collection to further refine the difficulty curve. (We had a survey in Infinifactory during Early Access that taught us a lot about how the data we collect correlates with how players self-report about difficult and enjoyment.)

For the solitaire games, my process so far has largely involved taking established games and reimagining them around some sort of theme, and then pushing them a little further in the direction of the theme to make them worse than what they're inspired by but more novel and appropriate as a companion to the primary game. Sigmar's Garden isn't going to be the next Shanghai, but I think it enhances the texture of Opus Magnum and makes me feel like I've shipped two games instead of one. I love shipping games!

We made three educational games that were ostensibly for kids and I never want to do it again.

Opus Magnum is a perfectly fine kids game... it has way fewer dead bodies and porn magazines than Infinifactory!

https://www.reddit.com/r/IAmA/comments/78wv2h/im_zach_barth_the_creative_director_of_the_game/doxmnxa/

As a genre, puzzle games don't sell that well, although there are obviously exceptions. I don't know about you, but they physically make my brain hurt! That makes people want to stop playing them, which is a tough quality to have when you're selling a product that is 100% voluntary and for entertainment purposes.

We try to be savvier about collecting data and using it to tune the difficulty of the puzzles, but overall my philosophy hasn't changed much. These are difficult puzzle games. Regardless of what my goals are as a designer, when you look at the finished product it really gives the impression that I don't care if people finish our games or not...

1. Play all of our games and pay attention to what they have in common and what is different between them and other puzzle or building games. I guess you could skip Ironclad Tactics, but that has some novel game design ideas too.

2. One mistake I see a lot of people make in custom puzzles for our games is to artificially restrict the tool set to push players to solve a puzzle in a particular way. This is the enemy of open-ended design.

I'm okay at our games, but far from the best. It's not remotely possible that I could ever set a record, unless I was using some kind of secret mechanic that no one else knew about maybe, but even then someone would manage to find it and do better than me.

I feel that I get away with it because I have a pretty good intuitive grasp of the design space of these games, even if I can't predict them fully.

3D is hard, both from production and design standpoints. I'd never go out of my way to make a 3D game, even if you can charge slightly more for them. When we come up with a compelling game design that requires 3D, however, I'd jump back in a heartbeat.

We've used C# since SpaceChem. I can't imagine using anything else, honestly. Infinifactory and TIS-100 use Unity, while everything else uses some kind of lightweight SDL-backed C# engine.

SHENZHEN I/O and Opus Magnum are both using a very minimalist C# "engine" inspired by some of Casey Muratori's ideas on game engines and game programming. It uses DirectX or OpenGL for graphics, and SDL for everything else. It's basically just one giant Update() loop, and is the greatest game engine I've ever had the pleasure to work with. Despite this, I would not advise novice game programmers to do the same.

We try to do projects sequentially. TIS-100 was a weird exception, where there was so much production work to do for Infinifactory that I was somehow able to make TIS-100 on the side.

We're not good at making mobile games that people actually want to buy. Maybe it's because they're too hard? Maybe it's because they're not free-to-play garbage? Who knows! Either way, I think it's PC-only for the foreseeable future.

If you're actually interested in making games you're probably best off learning Unity. It's a great tool that solves a lot of the hard, boring problems that you don't want to get in the way of shipping a game.

Our artists are struggling to answer your question. It turns out that color selection is sort of a... fundamental concept... in making art.

There is nothing elegant, efficient, or optimized behind the scenes of a Zachtronics game. It's all a sham, really...

I don't really like achievements. There are all kinds of arguments to make for them, like rewarding players for doing something clever and surprising (a valid argument), to rewarding players for playing your game because people can't be bothered to do something if it isn't constantly rewarding them (less valid, in my opinion).

Of all our games, I like the achievements in TIS-100 the most, but they were hard to come up with. It's possible we'll add more for Opus Magnum, but it's also possible we won't. I think that the leaderboards and histograms do some of the work in this space, and I'm much more pleased with them as a mechanic than random magic-circle-breaking achievements.

I don't know if I believe in "target players". I'm sure that many of our players are programmers, but some of them have never programmed before, and some of those people were huge fans of TIS-100!

The best way to convince your friends to play is probably to buy them copies. Maybe we should sell a four-pack...

The weird thing about the podcast is (was?) that I only interview people that I really like on a personal level. I guess the Zoop interview was a little different because in that case I didn't know the interviewee but did really like the game on a personal level, but then I got lucky and ended up really liking him. Either way, this makes it pretty hard to find guests, which makes it hard to make episodes.

Anything is possible! That's the value of IP, I suppose.

In general I try not to talk about shelved projects, since it's quite possible we'll pick it back up again. After all, Opus Magnum was a shelved project from 2013!

I looked up a bunch of Erlang sample programs and tutorials when we were designing the TIS-100 puzzles...