[MUSIC PLAYING]
SPEAKER: So if everyone could welcome Zach Barth, the creator
of electronics Zachtronics, SpaceChem, Infiniminer,
TIS-100, Shenzhen I/O, and various other games.
[APPLAUSE]
ZACH BARTH: Thank you.
OK, so first things first.
I want to share secret with you guys, which
is that I hate talks.
They're really boring, and they're just--
God.
I mean, I've been to GDC so many years.
It's the Game Developers Conference.
And just sitting there and having somebody
just talk at you with their pre-planned deck of slides,
and it's not very fun.
So what I wanted to try doing this time,
mix it up a little bit, do some Q&A. So you
guys apparently asked a bunch of questions
and voted on the best ones.
And we don't actually know of the people who asked
the questions are here today.
Raise your hand if you asked a question on the website.
Did any of you actually ask a question?
OK.
Did you ask all the questions?
OK, so I guess you're going to have to do the proxy.
OK, that throws a wrench in that.
So I was going to have people ask questions and then answer
them and ask them follow up questions.
But apparently I can't do that.
I don't know.
I think it'd be cool to make this so it's not like--
Instead of preparing a giant slide deck,
I prepared a couple smaller ones.
I'm going to start with this one.
But then from there, I have a bunch
of things that are sort of answers to questions that
might be asked by the person who has a list of questions
that they're going to ask.
So we'll see how this goes.
So how many people in the audience
are familiar with the games that we've made?
So are you play with all of them or some of them?
OK, so what I was going to start with
is but just a history of how we got here and the gains
that we've made, so that we all have a shared context
and we can talk about games.
So I started making games when I went to college,
and it just started off as a fun thing.
And you get some lovely games like this,
which is the first game I guess I ever made,
which was for a game jam for the game development club,
where you're supposed to make a game that your mother would
play.
And I won because I was the only person who bothered to try.
This is probably the earliest game
that I've made that you can still
download if you go to our secret old website on the internet.
But it's really bad.
And it's terrible.
Another weird game that I made in college
was a game called Infinifrag, frat which was terrible,
and I really had no idea how to do
any of the things that are involved in making this happen
from a technical standpoint.
But as you may know, it went on to start some big stuff
years later, through some other stuff we'll get through.
It was a terrible game though.
So there's a game called Manufactoid
that I made-- also terrible.
There's a trend here--
in which you would build factories.
This was directly inspired by the show "How It's Made."
Back when I was less jaded about making games,
I saw "How It's Made" on TV, and it was like, wow,
this is incredible.
We're seeing how things are made.
It would be so cool not to like to make those things
but to make a factory that makes things like that.
And that this game doesn't really look like it
but was trying to get at that.
The biggest downside was probably
that you had to program it in Lua completely unnecessarily.
And that's a god awful experience.
So that was something.
Here's a game called Ruckingenur,
which was the super cruddy kind of exploration
into a game about electrical engineering mechanics
and reverse engineering.
The idea of it--
I'm going to point.
So there are these test points where you could--
how does this even work?
They're automatically-- this is a terrible interface.
You can interact with the circuits at various test
points, and you can reverse engineer the circuit
and try to unlock the lock.
And this was--
I mean, if you're familiar with our later games,
this is the beginning of an idea that re-occurs a lot, games
about electrical engineering.
This was probably the first kind of puzzle game
that I tried to make.
It was really terrible, but it's about sequential transformation
of data, the idea being that--
I'm sorry.
Can you-- you can't even see that.
So there's that hole on the left side, where data pulses come
in, which are one of different colors,
and that you can apply transformations,
like filtering them by color and redirecting them.
And it's a horrible game, but again, it
gets at some early ideas.
There's a game called Silicon Foundry.
Which is about-- you build ships.
You build ships by assembling little parts.
I don't think I really have any pictures of it,
but it was little Tetris pieces that would fit together.
And they had different input and output requirements,
and you would use it to satisfy very abstracted ideas
of these different products you could build.
And over the course of the game, there
were probably like 30 different products
that you build that are very simple simplifications
of electrical circuits, products and stuff like that.
And at this point, it should be obvious what my background is.
It's that when I go to college, it
was for computer science and computer engineering.
And all of these things, these ideas,
I'd known that they existed before,
as somebody who used computers and was fond of computers,
but starting to see how these things work behind the scenes.
It all starts coming out not really in my classwork,
because there was nothing special going on there,
but in these games that I'm building.
And there's some other diversions into other areas
that are more gamey.
This was a game we made called [? Tex-Mex, ?] where you ran
around on a pad.
That's like a giant sheet of carpet
with screen door material underneath of it.
And it's like a really pressure sensitive pad, so we
knew where you were standing.
And then we took a hacked Wiimote.
And this was right when the Wii came out
and people were starting to analyze the Bluetooth protocol
and figure out how to hack that.
I don't know if anybody was messing around with thaft stuff
when it happened.
It was cool.
It was really cool.
And for the first time in my life,
I had the technological skills to actually do some of that.
Stuff and so we took a Wiimote and took all the guts out
and jammed it into a piece of metal,
so it was like a lightsaber kind of thing,
and then made a game that was inspired by Gundam, kind of,
and visually kind of looked like it.
And you would run around and attack and do stuff.
It was like the Kinect, before the Kinect was the thing.
And it was probably about as popular.
Oh snap!
The last game that I made in college
was as I was coming out to Seattle to work at Microsoft.
It was a game called Ruckingenur 2.
And I would say this is probably the first modern Zachtronics
game.
This was the first one that actually people really played
to any degree on the internet.
It got on Hackaday.
So I submitted it to Hackaday.
And this was back when very, very few people
were following what we were up to, or what I was up to.
And I sent it to Hackaday.
I'm like, hey, you guys like electrical stuff.
Here's a game that's about electrical reverse engineering.
And they posted it.
And this was back in 2008.
And that was the first time that anything I'd ever made
got in front of a bunch of people, and it was awesome.
And a bunch of people came and played it.
And that brought a lot of people to my website
and kept them coming back.
And that was back in the blog era,
so that was the way to do it, I guess.
And so this is a refined gamier version of the Ruckingenur
nasty game you saw before.
And it has really terrible full motion video storytelling.
I should of brought more of that, because it's me,
just straight out of college, dressed up
with whatever I could find that looks like military surplus
clothing, running around, making my now wife film me.
We did a sequence where I'm running through a field
and have to go disarm the bomb.
That's all in there, and it's adorable and terrible.
So that was the end of the college years of games
and got into the Microsoft years, where I didn't actually
make games at Microsoft, but I made games at night
while I worked at Microsoft and worked on Office.
I worked on Visio for three years.
And that was really the opposite of making games.
I worked briefly-- when I was in college,
I did an internship at a studio called Breakaway Games.
And they made-- it was 50% expansion
packs to EA games and stuff, and 50% real serious games,
I guess.
They made a game that was like a simulation
of a military hospital.
And one of their infamous bugs was
that patients would die and then just get up and start
walking around anyway.
So they were like 50% serious, 50% expansions.
And I worked there.
I briefly interned there during the summer one year
and worked on a game that was an adventure game for kids,
but it was made for the Middle Eastern market,
and was done by a bunch of American businessmen
who wanted to promote American values abroad.
So it was a really weird introduction
to the games industry.
And so after a summer of that, I'm like, you know what?
I don't really like games that much.
I've been designing games while I was in college,
and then I go get a real game design job,
and I'm just like writing C++, which I'm not good
at, and still am not good at.
And it's just like, wow, I could just program anything
and it would probably be about as fun.
And on that logic, I went to work on Visio.
Which was, I guess, not true.
So when I was there, I worked on a lot of games.
Probably right away I started working on stuff for fun
at night.
And that's how I start making Flash games.
So downloadable games were a thing.
I guess they still are.
But this was quite right when Flash games were really
really taking off as exemplified by the fact
that when I was in college, I used to spend a lot of time
playing Flash games in class.
And so as that was taking off, I was like,
oh, I'm going to make some Flash games.
So you get the Bureau of Steam Engineering, which
is a game about steam engineering in a context that's
not really real steam engineering, but in a context
that didn't exist, which was a steam-powered civil war, which
is a theme that comes up again.
You get a game called the Codex of Alchemical Engineering,
which is a game about alchemy, where
you program little arms to move atoms around.
This is both a follow-up, I guess, to Manufactoid.
What if you could build a factory
without having to write Lua?
That's this game.
And then this later obviously becomes SpaceChem.
You get KOHCTPYKTOP, which is something.
This is a game about building integrated circuits, kind of.
It's, again, stuff I learned in college
but didn't learn in college.
So this is not how real integrated circuits work,
but it's kind of evocative of it.
So that was something.
You've obviously seen my love of Soviet nostalgia stuff leaking
through here.
I make a game called Infiniminer.
So my wife goes away back home to the East Coast
for the weekend, and when she comes back,
I've made the beginnings of Infiniminer.
And that's a story that's been a big thing in my life.
I have to get into the Infiniminer story, I guess.
So I made this game.
For me, it was the sequel to infinifrag and a way
to explore, oh, what if we took that really terrible block
engine that could only render 30 blocks without becoming
unperformant and made it so we could render an entire world
out of blocks?
And that was infiniminer, and accidentally started
some other game genres and stuff.
We'll get into that later.
I'm sure somebody will have a question about that.
Then I made a game called SpaceChem.
So this was our first commercial game,
and I guess the first game where me became an actual we.
There were like six or eight people who through some means
worked on this game.
And this was right after--
I guess I'd say this is like my post-Braid game.
Because Braid came out, and Castle Crashers.
And then it's like, holy shit.
You can be a nobody.
You can be not backed by a publisher
and make a ton of money and actually sell your game.
And that was inspirational, because before that I thought
I have to give away my games.
I mean, look at Infiniminer.
How could you ever sell Infiniminer?
How could you sell a game?
That and never make money!
This is really where I was at at this time.
SpaceChem is also a post-Minecraft,
and seeing that, wow, you can make a game and somebody
can make money off of it.
And so we made SpaceChem.
And We thought--
God, I mean, I spent like five grand of my own money
as an advance to our artist in the Philippines,
and everybody else was just working on profit-sharing.
I was like, OK, this game, we could probably
make like 10 grand.
And I was like, if we happen to make like 100 grand,
I'll quit my job and make games.
And so that just instantly happened.
We made it.
I'm like, OK, I'm not quitting my job.
That's not enough money to sustain
a bunch of people working.
We make it to three grand--
300 grand, then I'll quit my job.
And we did.
I was like, oh God, I guess we have to do this now.
So the core original Zachtronics is me and then my friend Keith.
And so Keith went to RPI with me.
He actually was there when I was designing Infinifrag.
It was his idea that in order to build a block off
of another block that you point and shoot at it.
So I'm apparently a hack too.
I've been working with him on stuff for a while.
We were the first two people to do Zachtronics.
We had a tiny little office.
He actually quit Microsoft a week or two before me.
That's how dedicated he was than me.
I guess.
And this is what started the indie years.
So our first game was Ironclad Tactics.
Which is kind of a lie, because Ironclad Tactics actually
came out two years after we started doing Zachtronics
full time, and during a period during which
we actually made a bunch of educational games, which
I'll show you in a second.
We thought this was going to be the hottest shit ever.
And if SpaceChem did this well, clearly Ironclad Tactics
was going to do this well, because all the complaints we
heard about SpaceChem were that like it didn't look good
and it was too hard.
This game was easier.
It looked better.
And instead of selling this well,
and instead of selling this well like SpaceChem,
it sold like this well.
So that was a bit of a thing.
We can get into that later too if we need to.
But during that time, the reason I'm still here today
and talking about making games and kept doing it afterwards
is because while we were doing Ironclad Tactics,
and perhaps squandering some of our future on that,
we made an educational games for a company
called Amplify, who is owned by News Corp., inexplicably.
It spent like a zillion dollars building
a tablet-based curriculum that literally caught on fire.
And so only once, and it might have been
a power supply or something.
I don't know.
We made a game about starch metabolism,
which is pretty cool for a game about starch metabolism.
They're all tablet games.
So it's like pinball, except if pinball wasn't pinball,
and you had a bunch of pinballs.
And so you flick the little particles around,
and you can push the button to pump the lungs
and it brings in a new set of air,
and then you can just take all the oxygen out and swipe it
into the bloodstream.
And so it was pretty cool, but it's terrible.
Probably the best educational game we made
was HabiTactics, a cooperative eating other creatures
simulator.
It's weird.
It's match three, and the animals
have to line up to be eaten by the next one up in the food
pyramid.
But it's really cool, because it represents how habitats work.
I can't say the word "habitat" without saying "HabiTactics"
now, which makes it hard to be taken seriously.
So this is a game called Faktr, which
is when Twitter and stuff were taking off, and the weird,
"we're going to take out vowels in our name."
So that was all my idea, Faktr.
Maybe not.
I love it, regardless.
And it's a game where you are the ship,
and you move your finger around, and it follows the ship,
and you pick up these numbers to take
on the identity of these prime numbers, which
allow you to then slice up numbers
that are divisible by it.
It's pretty cool for a math game.
So after the fallout of Ironclad Tactics and realizing like,
oh dear God, this game is not going to make as much money
as we were hoping it was going to,
we had to radically downsize, and we
had to think about what the hell are we doing.
We thought that going into the indie times
that you could just make any game,
and as long as it was fun, people would find your game
and play it, and you'd make lots of money and it would be great.
Because that's what happened with SpaceChem.
It turns out we accidentally did something right with SpaceChem,
I guess.
I really don't-- people claim to know what goes on in the games
industry.
I think they're all liars, or they just are confused,
or they did too well.
We're sort of blessed by doing well enough to still be around
but not well enough that we can't just accidentally coast
on our laurels.
That We're always just getting by.
And so that kind of thinking is what led to Infinifactory.
There was a long period of time in which
I made Infiniminer and then kind of felt bad about it
and felt like I couldn't really make another game like that,
or it would be weird to make a block game.
And Infinifactory was like, no, we can make any games
we want about blocks.
Who cares?
It would be cool to make a game that's kind of like SpaceChem
but in 3-D with blocks, and you build stuff like factories.
I mean, obviously you can see the repeating themes
in all of these games.
And that's what birthed Infinifactory.
And it did well.
We went from thinking, God, we'll
never make a game that will ever do as well as SpaceChem ever
again.
I legitimately believed that, that SpaceChem was just
an element of timing and that we'd never
make a game like that again and we'd just never do as well.
Infinifactory did better than SpaceChem.
So apparently that's not true.
That was a cool optimistic thing.
Also made a game called TIS-100, which almost didn't make--
I wanted to stop making this game so many times,
because it's terrible.
I was like, no one is going to play this.
I took it with me on my laptop to GDC one year,
and I had the little printed out manual,
and I wanted to get some people to play test it,
and I couldn't even bring myself to put it in front of anybody
to let them play test it.
Because I'm just like, no, this game is awful.
And we brought down the manual to show somebody,
and they're just like, oh my God, this is amazing.
I'm just like, really?
So we kept working on it, and we shipped it.
It was really just a little side project.
I had started working on this other game
because I was bored and wanted to make a different game
while working on this too.
And it was going to be this big adventure
game with a bunch of different puzzles in it.
And that was clearly not going to happen.
You can't make two games at once.
That's very hard.
And so TIS was just a tiny little portion
of that game spun out into its own little thing.
And we shipped it.
And it actually did really well.
And it did better than Ironclad Tactics.
Right?
That's crazy.
So clearly we don't understand how games work at all,
but we're successful.
The sort of irony here, I guess, is
that-- what's the next slide?
The irony here is that these games did well.
And I thought that nothing could ever do as well as SpaceChem.
And I learned that these games did well
while I was working at Valve after having
shut down Zachtronics, because I was tired of failing.
And so that was a weird thing.
VR was happening.
I felt bad because none of games really did well.
And VR was happening, and there was
no way we can make a VR game, and it
seemed like it was important to work on it.
And so I found myself at Valve.
I worked on VR stuff there.
There's a question for that, and we'll get there.
And then seemingly out of the blue, we sold Zachtronics.
So Zachtronics is not owned by me anymore.
Thank God.
That was the worst part of running an indie studio,
it turns out, is owning it and having
to do the business stuff.
I am not a business person.
I am not that clever or whatever it takes to do business.
And maybe not clever.
I don't know.
So needless to say, we actually we sold Zachtronics and we now
work for a publisher-distributor who's also Zachtronics.
And it's great, because it allowed
us to make Shenzhen I/O, which is awesome, right?
I mean, this is perhaps like the Zachtronicsy game yet,
and we made it while technically not being indie,
which is really exciting, because I didn't
have to do the business stuff and I
didn't have to do our taxes.
These are serious problems that I had to deal with.
And I suspect more of you are familiar with Shenzhen I/O,
because that's the new flashy one and stuff.
And that is the end of that.
So that catches up to where we are now.
We released this game.
December-ish it came out of early access,
and that's the history so far.
Does anybody have any questions about this part,
about anything you saw or any of the things I didn't mention
or anything?
SPEAKER: So we're going to take a couple questions
from the Dory and then we can open it up
to the large audience.
ZACH BARTH: OK.
SPEAKER: The first question was, "What
has been the most surprising or unexpected thing you've
seen a player do with one of your games?"
ZACH BARTH: Oh, OK.
You want to come back to that?
I actually have a another presentation
that shows off stuff, but it might be better
to not just blast through more slides.
I was trying not to make this a slideshow,
but apparently we're running that route.
SPEAKER: How long you spend designing the core game
logic of a game compared to coming up with puzzles for it?
ZACH BARTH: Oh, that's fun.
I definitely hadn't heard that question before now
and when you sent it to me.
That didn't work.
That was a joke.
So what is this?
This is not-- OK.
We're going to open this in here.
So Shenzhen I/O is unique.
So usually when I do all my design, it's in a notebook.
Which means that in terms of creating art--
I don't really scan my notebook, so it's
hard to show off what's in them, aside from scanning them,
which I don't do.
With Shenzhen I/O, it was designed not in a notebook.
And so this gives us an interesting glimpse
into easily scannable documents that show off
the development of Shenzhen I/O. And have any of you guys had
already seen this set of documents
from ordering the special edition?
Anybody get the special, the physical edition of Shenzhen?
Yeah?
OK, cool.
So most of you haven't seen this.
OK, so like all good things, a lot of my games
start with lists.
When we start working on a game, when
I start thinking of a game--
a lot of people talk about game design
in terms of emotional stuff.
You want to design something that emotionally
resonates with your players.
For me, as a programmer, it's like a mechanical emotional
resonance.
Like, oh, it would be cool if there
was a system that worked like this,
or if you had a system where if we
could take the idea of microcontrollers
and how circuits work and how modern embedded systems work
and turn that into a game.
For me, there's a feeling there.
I don't know if other people have feelings
about embedded programming that resonate on an emotional level,
but there's thing there.
There's a system.
If you look at a lot of our games,
clearly they're about systems.
I'm not coming to this from a storyteller.
I don't really know anything about telling stories,
but I have people who do.
but the part that I bring to this
is the understanding of systems.
Like here, on this totally boring-looking sheet of paper,
you can see some ideas forming about like,
oh, these are some parts, and these are some differences,
some abstracted differences between like what's
the difference in flavor, what's the difference in emotion
between a microcontroller and a DSP?
And in reality, they're the same and they're
just tuned different ways, but you can think about it an
a way that's an abstraction that has feelings like, oh, DSPs
are really good at math, and like there are certain ways
that they're different.
There's asymmetries that you can exploit
when making a puzzle game.
And so there's this high level ideas
of things that might be mechanics.
And in this case, it's based on a real life system.
This is where the game starts out.
And it probably doesn't spend that much time in this period.
I like to think visually.
So the best thing to get out is some visual ideas
of how would this look like as a system you're interacting with?
So we've got a sketch right over on the left side.
There's the cursor somewhere.
This looks a lot like a node in Shenzhen I/O,
with the exception that the pin's coming out the top.
And you start to see some ideas forming just
in these little sketches.
I'm definitely a big fan of drawing stuff to do that.
So from the basic high level ideas and the emotions
it turns into some sketches.
I start to visually explore some stuff like that.
For Shenzhen I/O in particular, we
interviewed Bunnie Huang, the Shenzhen guy,
who everybody goes to for anything about Shenzhen, which
almost seems kind of cliche that we did.
But actually, like everybody does, you
learn something food from him.
And he told us about some more things
that were emotional points of development in Shenzhen,
like going to the electronics wet markets, where it's just
stalls, and stalls, and sales of electronics.
And in the middle of the night, you're like, wow,
we need 10,000 transistors of this certain type.
Time to go buy some.
And then you come back with a box
of 10,000 transistors, which actually isn't even that big.
And these are the emotional things that I think go into--
I mean, how many of you have played Shenzhen I/O?
OK, some of you.
So it's a game about--
on the surface, you build circuit boards
and drop down chips and write code for them.
And then they do things.
They generate timing diagrams and they do stuff.
And but it also has a pretty intense story,
where there's a lot of e-mails with the people
you work with at this company in Shenzhen being told,
and they're funny.
And they argue sometimes.
And all of that stuff is informed by things
that we learned about what it's really
like to be an ex-pat in China and all of that.
I mean, we don't really have any first hand experience with it,
but we were able to get that from talking to people.
Some devices that were invented in Shenzhen, which we didn't
turn into puzzles, the barbecue tongs
that tell you the temperature of the thing you're tonging,
that was an original Shenzhen invention, not like a knockoff.
And same thing with the hoverboard,
although like I guess there's a Planet Money
or whatever that debates the origin of the hoverboard.
The thing I like to do-- and this
is really diving into my personal process,
but I love making little black and white grayscale pixel
art that lays out what am I actually going to be dedicating
screen space to?
I guess some people, when they start making a game,
would start with concept art.
But for me, it's incredibly detailed
technical-looking things.
What is the information that's being depicted in this game?
What are we dedicating space to?
You can't just say, oh, you're just
going to be able to code stuff and just make it scroll.
I have a huge aversion to scrolling in games.
Shenzhen I/O is the first game I've ever really made
where everything doesn't fit on the screen all at once at one
time.
And there's a reason for that.
I don't know if anybody has read the Tufte design books.
He talks about the PowerPoint Effect.
The lousy thing about PowerPoint presentations
is that as soon as I flip away from something,
you're going to forget what I was just showing you.
And if you can't look at two things side by side,
it makes it really hard to compare them visually.
It's a huge part of how our brains work.
So everything fits on one screen in most Zachtronics games,
although we're slightly pulling away
from that, like in Shenzhen.
But we can look at information.
Here's the design of Shenzhen Solitaire, which
is on this piece of paper.
From there, we have to come up with--
and this is a newer thing with Zachtronics games.
When we did SpaceChem--
Who's played SpaceChem?
Cool.
OK, so one of the biggest faults perhaps with SpaceChem
is that all of the puzzles just have you make
chemicals for no reason at all.
It's just like, oh, we need a bunch of acetylene because.
And that's it.
We have a story, and the story is over here,
and then we ask you for acetyline over here,
and there's no connection between the two.
And one of the biggest complaints
we got from SpaceChem was that it would be great
if there was any kind of story justification for why you're
building what you're building.
Any at all.
That was one of the ones that really resonated,
because like, oh yeah, that's right.
They don't mean anything.
I'm trying to think.
I guess with Infinifactory, we started exploring with that.
What if you could make things that
actually fit into the story?
And with Shenzhen, we went even harder with it.
And so every puzzle in Shenzhen is based off of a little pitch
that our writer wrote, that we brainstormed before.
But we turned them into these things.
We want to build a little story around each puzzle,
and we want to bring that puzzle to life
by creating a context around it that gives it meaning.
And I think it was really successful.
I don't know.
I mean, you can tell me.
So in this case, there's tons of ideas here for puzzles.
A lot of them we didn't do, because they're really
hard to turn into-- like a magic baseball bat.
This is our near-future, everything
is slightly lousier future.
I was going to make a political joke, but I'm not going to.
But you know the idea if a magic baseball bat.
It's like the selfie stick, or the baseball bat of selfie
sticks, I guess?
It just makes you hit a home every time.
And it fits thematically, but it's
hard to think of how do you make a puzzle that is that?
I don't know.
So not all the ideas really make the cut,
but we got a lot of good ideas here.
And then we start turning them into puzzles.
And so one of my other little quirks
is that I like to design every puzzle on a sheet of paper,
because then you can sort them separately.
Right now, we're working on a game that
has puzzle-like things in it.
And they're all pinned up on the wall,
like I'm some sort of detective that went rogue, and has
all the connections drawn up on the wall and the string running
between them.
I can see the pattern, yeah!
So with paper, you can do that.
You can pin up all your designs, and you can see them
all at once, and you can use the visual part of your brain
to see like, oh, do I not have enough of this mechanic being
represented and whatnot?
Making forms is fun too.
I guess that's I'm more of a reflection of my personality,
that I like making forms and filling them out.
So from there, yeah, I mean every puzzle
has its own little form.
And so to get back to your original question, which
I think I've diverged from highly, which is how much
time do we spend making the original mechanics
versus coming up with puzzles.
I'd say that there's a little bit of time up front
for coming up with the mechanics of the game,
and then I like to just try to make a whole bunch
puzzles without even being able to play them,
which I guess is another weird Zachtronics
thing, that I make all of my puzzles
without really testing them.
And then the ones that don't work
don't go in the game at the end.
Sometimes they do, and then they get replaced afterwards.
I mean, our games are really open ended.
Our games are usually that we build a toolset,
and then we build a bunch of challenges,
and we build them independently.
So that way you can tackle the problems however
you want with the toolset.
And that comes across in the puzzle design mechanism
that we follow.
The other thing too is that especially with Shenzhen
we change our toolset as we realize what is possible
and what isn't possible with the toolset
that we give you while you solve the puzzles.
And so in Shenzhen I/O, a really boring example is the memory,
that all of our memory used to be that you'd write to it,
and it would store the values, and then you'd read from it,
and then you'd get them back.
And that was all you could do.
And it turns out that's really useless,
and if you wanted to read from it non-destructively,
you'd have to read everything and then somehow write it back
in.
And it just made everything too hard.
And so right up until the last minute of Shenzhen I/O,
we were still changing mechanics in the game.
So you never really get to stop working on your mechanics
or your puzzles or anything.
I don't know what the moral there is.
Does that answer your question person
who didn't ask that question?
SPEAKER: That was actually me.
ZACH BARTH: Does that answer your question, person
who did ask that question?
SPEAKER: This one's actually from someone
who's not probably me.
"How do you make your game's fun?
I have tried to make educational games in the past,
and mine have turned out pedantic and preachy,
whereas yours are actually fun."
ZACH BARTH: Was that your question?
This is the person I wanted to grill.
So I wanted to find out what makes
them think Zachtronics games are educational,
or what makes them fun?
Because it's possible that they're neither.
It'd be easier if I had somebody to escalate.
Does anybody want to proxy for that person?
Has anybody tried making educational games here
and they're disappointed with that?
Was that a handraise or just a stretch?
AUDIENCE: [INAUDIBLE]
ZACH BARTH: So I have to imagine.
AUDIENCE: You can proxy through me if you want.
I have done a little bit of work in making
educational games many, many years ago
as a contractor for Big Fish.
And I also do find these games fun.
And can answer perhaps as to why.
ZACH BARTH: OK.
AUDIENCE: So if you want to proxy through me, go ahead.
ZACH BARTH: What's your opinion of educational games?
AUDIENCE: Often times, it seems like there's
some particular lesson that the creator
of the educational games wants the students to learn.
And it's very difficult to make that into a game
if it doesn't fit anything there.
It just so happens, I think that for a particular mentality,
engineering is fun.
ZACH BARTH: Yeah.
AUDIENCE: And so if you can make a game where you're just
doing engineering, the fun parts,
then it's somehow educational but also still fun.
ZACH BARTH: Yeah.
AUDIENCE: And for me, I will say personally,
as someone who came into computer science through
a non-traditional route--
I didn't actual take any computer science education--
Shenzhen I/O and TIS-100 were the first time
that I ever actually did assembly programming.
ZACH BARTH: Oh yeah.
AUDIENCE: And so I learned something there.
ZACH BARTH: OK, so that was the perfect answer.
Thank you.
SpaceChem, I made SpaceChem.
This game looks so educational.
I pretty thoroughly believed that like if only
we could make education like SpaceChem,
everybody would love it.
It would be great.
And this idea of taking systems and problems
and presenting them to people in a way
that they can solve in an open ended fashion
without having to just learn stuff and recite it later,
that seemed like it would just blow education wide open.
And it didn't.
I started really enthusiastic, and we
made these educational games, the ones
that I showed you before.
I would say as we were doing the projects,
my enthusiasm crashed pretty hard.
And by the time we got to the end,
it was like, why are we making these games?
And I think that part of the problem
was that when we make a game for real, we it just is what it is,
and we put it out there, and we say, hey, whoever
wants to play this, play it.
If you like it, you'll let us know by buying it or whatever.
When you make an educational game, they were testing them,
and they were forcing the kids to play them,
and just sitting them down and saying,
you are going to play this game now.
And then the kids would play it, because they
were told to or whatever.
And it's a game, so it's better than like, do
this math problem.
Kind of not.
They don't really have any agency
in doing that, which is the big thing in games.
And then they asked them afterwards.
They're like, now we're going to quiz them on what they learned.
And it's just like, oh God, these kids,
they're in middle school.
They're not really good at expressing themselves.
And even if they are, they're just saying the answers
or not saying the answers.
You're just so far divorced from what
it is to make a game at that point,
that for me, it destroyed all of the motivation.
Are we improving their lives by making these games
and making them play them?
Well, not really.
And then you start getting to questions like,
what is the point of education and curriculum?
This is, again, a reflection of me
more than any sort of reality.
But the idea of an educational game, there's
already so much bias, just saying an educational game.
It's meant for a school system.
It's meant for a curriculum.
It's really hard to design games to that, like you said.
Here's a fun anecdote for me.
I was at a serious games convention,
back when I was in my more naive stage
and thought that we could make educational games that
are great, and then games would save the world or whatever.
And there was somebody there from Full Sail who
was saying that they'd made an educational game,
but the lesson they learned is that you have education
and you have fun.
And you just have to dial in like where on the spectrum
you want to hit.
And of course, their game was terrible.
I"m not going to lie.
It was a game where you go around and fight people
and then do math problems.
And so there was fighting, and there's math problems
that would pop up.
We can agree that that's probably not the best
way to do an educational game.
But I actually had the audacity to raise my hand
and challenge the person who was talking and just be like, what?
This is ridiculous.
Surely we can make games that are
fun and educational by exploiting the naturally fun
things, like in engineering, exploiting
the naturally fun things in the educational content.
And then after having made them, I actually
feel like there's fun and there's education,
and you just dial it in and drop it in.
And there's perhaps some reason to believe
that learning things is hard, and things that are hard
are not fun in the way that games are.
There's all sorts of stuff about flow.
How many know about flow theory in games?
The idea that as you're playing a game,
you're going to get better.
And if this is like a graph, there's
an area up here that's too hard for you,
and there's an area down here that's too boring.
And so you just want to stay in this channel of not
being bored but not having the game be so hard
that you can't play and you can't advance.
And education does not line up with that.
It doesn't fit in.
You can design a game so that people get slightly better.
More often than not now, you boost their power level
by giving them experience and upgrading their numbers.
This is a huge thing that's destroyed game design, as far
as I'm concerned.
There's theories about difficulty, and a lot of people
say, people need to feel better while they're
playing your game.
Let's just make the numbers bigger
while they're playing it.
You can't do that in an educational game.
You can't just say, oh, your sword now does more damage,
but we're going to give you the same math problems.
You can't count on people getting better,
especially at external skills that aren't
even really part of the game.
It's difficult.
AUDIENCE: I think that moves nicely to you
"How do you view the difficulty curves and teaching
process in each of your games?
Is anything you ever wish you had done differently
or anything you want to try some day?"
ZACH BARTH: I have a picture for this one.
This is more interesting than trying to explain it.
So this is a difficulty graph for SpaceChem.
And so what this represents, each one of these is a puzzle.
The blue ones are the--
blue ones are required, the yellow ones are optional,
and the red ones are the boss puzzles, which you have to--
they're a special kind of challenge in SpaceChem
that's kind of hard, both because it's a hard puzzle
and because it obscures the gameplay in a way that
makes it harder to solve.
And so what this is for each one of these,
how many people started up a puzzle and then solved it?
And so it's the same overall.
We can see the optional puzzles.
There's a lot fewer people, who upon starting up
an optional puzzle, actually took the time to finish it.
Every other puzzle in the game was required, and often
in sequential order, which is the thing that we learned
is not a good thing to do.
And so they're pretty good.
The boss puzzles are definitely harder.
The last boss is definitely--
God, these poor people who beat every other level up to here,
fired up this level, and then only half of them finished it.
That includes me.
I'm in the people who didn't finish this.
I've never beaten the last level of SpaceChem.
I don't know how you could expect somebody
to do something like that.
AUDIENCE: And this is only the people who started a puzzle,
not necessarily people who are starting the game.
ZACH BARTH: Yeah, that would be graph number two,
which looks more like this.
This is what happens when you multiply
each one by all the ones before it and have it fall off.
If you fire up the game, this is your odds
of actually beating the last level, which makes that falloff
look less dramatic.
To some degree, I would say our games are pretty bad.
But to some degree, your progress for any game
looks like this.
I mean, how many games that you guys play
do you actually finish?
It's probably less than 100%.
So you can actually look at achievements in other games--
I used to have a slide for this, but it's not here--
about how many people beat various games.
So Bastion, that was beaten by like 15%
of people who started it up.
Super Meat Boy is beaten by about 4%
of people who fire it up.
And that's just on normal.
Super duper hard mode is like 2% or 1%.
SpaceChem is super duper hard mode.
It's like 2%.
So like 2% of people who fire up SpaceChem will actually
go through and beat all of it.
And on one hand, that's bad.
And that's not really like what I would want.
But on the other hand, that means
that there's a lot of challenge for people all along the game.
And this is something we debate a lot still,
which is how long should a game be and how hard should it be?
And you don't want somebodu--
Well, I guess it depends.
I don't know.
I mean, it's possible, perhaps.
A theory would be that you want people
to play through your game until they decide to stop.
It's worse if they play through a game
and then have to stop because they ran out of content,
or some other reason.
You want people to choose to stop,
and having the game get harder accomplishes that.
Personally, I'd feel disappointed
if I don't beat something, but other people are different.
But that's still a debate that we still wonder about.
So going off this for a second, you can line up.
The thing with this is, this graph is not really useful.
It makes a point, but it's not useful to us
in balancing a game.
A graph like this, this is how we do all of our stuff.
And we actually did a survey in Infinifactory
during early access, where we asked people,
after they beat a puzzle--
we only showed the survey to people who beat it.
We said, how hard do you feel like this level was?
Was it too hard, or was it too easy, or was it just right?
And when you look at the levels that people say,
I beat that level, I feel good because I beat it
but it was too hard, actually correlates close enough for us,
which is not really necessarily statistically good enough,
but it's good enough for us.
It correlates pretty strongly with people
who fired up a level and then never even beat it.
And the cool thing there is that we can measure this
without bothering people and without asking them
and without making them anguish over, "was it too hard or not?"
We can just track this stat.
And we do.
And then we track this stat in all of our games.
And nowadays, something like this right
here would say, OK, this level is too hard,
because they should all be flat.
And I don't have a picture of it for Infinifactory,
but in Infinifactory, it was pretty good.
The first levels pretty easy, and then it
picks up the difficulty through here,
and then it was pretty flat through the rest of the game,
because we were looking at them individually.
And then sometimes there would be a puzzle that spikes up.
It has like twice the fail-out rate or whatever.
And then that's how we know that puzzle was too hard.
So that's how we balance our games.
I don't know if that's the best way, but that's how we do it.
AUDIENCE: Do you have any data on how much
the social factor of SpaceChem helped people actually
keep on playing?
I mean, just the stats comparison, the--
ZACH BARTH: The histograms.
AUDIENCE: Because I was one of the ones that didn't finish it,
but I did come back to some levels because
of the social factor.
compared with other players and try to optimize the solutions.
ZACH BARTH: That would be a good thing to track.
It's hard to tell like somebody is playing a level,
and so I think that's why we haven't explored that.
The first thing I worry about is people just stopping
playing our game.
Because if you can't play a game,
it'll be impossible to enjoy it.
And so that's our first priority.
That would definitely be something
interesting to explore, the idea of what
keeps people coming back.
To some degree, we're a little cynical.
You compare does a new customer--
we could have somebody keep playing the game for longer,
or we could get a new customer, and which one is better?
One theory we have is that the longer that somebody is playing
a game, the more likely it is to expose their friends to it.
Sort of like, if somebody has a cold for longer,
they're more likely to share it with their friends,
in a similar way.
And so that's something we think about but have
very little data for.
AUDIENCE: And where did the idea of having the social parts
come?
ZACH BARTH: Oh, I have a thing for that somewhere.
Right here.
This will be the ending thing, maybe.
I'm just going to do the beginning of it.
So with the Codex, we made this game.
It was just a Flash game.
There were no histograms.
There were no leaderboards.
But there were forums where people would start competing
with each other.
Spontaneously, this happened.
They'd be like, oh, that's your solution?
This is my solution.
It's better.
I was able to shave off five cycles by doing this.
And they'd share it, and they'd just be one-upping each other.
And we thought of this when we did SpaceChem.
And the ways that we made this a real thing,
we made it official, was with histograms.
The funny thing is actually, we weren't on Steam
for a while with SpaceChem.
So we couldn't do leaderboards.
We would have had to roll our own leaderboard service
or something?
I don't know.
We didn't.
So we only had the histograms.
And then the leaderboards weren't very deliberate.
We're like, oh, Steam offers friend leaderboards.
Friend leaderboards are good.
I'd heard somewhere probably at GDC,
global leaderboards are useless.
Because obviously, they are, right?
You're not going to be number one.
You're going to be number 10,000.
No one cares.
Friend leaderboards get people riled up.
People like friend leaderboards.
And it just made sense for our games.
But again, I feel like I didn't think about it.
I don't remember thinking about it very hard.
I think we just added it because it seemed like the right thing
to do for getting on Steam.
Kind of naive then.
And I think, honestly, the leaderboards are probably
better than the histograms.
Not everybody has friends who play their games,
but when I hear--
I don't really hear that many people who are like, oh man,
and then I tried to move my line to the left on the histogram!
It's not the same as trying to outcycle someone
on the leaderboards.
And so in my mind now, I think the leaderboards
are almost probably more important than the histograms.
I don't know if that's going upset histogram fans out there.
Are you an histogram fan?
AUDIENCE: I am a histogram fan, because I
don't have any friends who play your games.
ZACH BARTH: You gotta fix that, man!
There's a name for the genre now.
AUDIENCE: I don't have have Steam friends that
play your games.
ZACH BARTH: Fair.
AUDIENCE: We should make a Google Group for this.
All the Zachtronics Googlers compete with each other.
AUDIENCE: No, I want to be at the top of the leaderboard.
That's not going to happen.
AUDIENCE: I like the histograms not
to try to move my line to the left but to see
how far to the right I am.
Because sometimes I had one puzzle in Infinifactory
that I did in a horrible hacky way.
And so my cycles graph was way out there.
And I was like, woohoo!
ZACH BARTH: Yeah, that's something.
AUDIENCE: [INAUDIBLE]
ZACH BARTH: No, totally.
We would never get rid of the histograms
because they're just too much fun.
I mean, it gives you an insight.
And especially because our players are so technical.
They tried editing histograms to Portal 2,
and it failed utterly.
Does anybody remember the histograms from Portal 2?
AUDIENCE: I liked those.
ZACH BARTH: OK.
Yeah, so you're the first person I've ever met who
even knew that they existed.
Which I guess means there's like 100% hit rate
for being successful.
But our theory on that is that they're--
now I feel bad saying that they're less
effective because you liked it.
But it's hard to directly compete
in a game like Portal 2, because you can't just
hit a play button to instantly replay your solution.
And so it doesn't quite have the same effect.
Although there's tons of action games that have scoreboard too,
so I don't know.
Maybe not enough people have tried.
When I was at Valve, I tried to convince them,
like we should add histogram support
to the leaderboard service, but I
would have had to code it up myself,
and that wasn't about to happen.
I would have broken it all.
SPEAKER: "Which game was the most fun to design and create,
and which was the least?"
ZACH BARTH: So I saw that question,
because I've seen all these in advance.
I don't have an answer for that.
I mean, I would argue perhaps that the least fun
games to create were the ones that we bailed on early
and you guys don't know about.
I'm very much--
I only make things when they're fun.
We've definitely started working on games that started off
looking fun, and then as I got into it, I just hated it.
And then when I hate what I'm working on, I hate my life.
And it just went downhill.
I'm just like, I gotta stop working on this game.
It's not good.
We've definitely pulled the plug on a couple of projects,
because it's just emotionally unsatisfying and bad to work
on it.
Apparently, I learned recently I have a very strong aversion
to recreating work that other people have done
and making games that feel like they're too much just like,
oh, every other game out there has this
and I need to can spend months and months making
the same kind of crap that everybody is making already.
And apparently I don't like that.
My favorite game--
Shenzhen I/O was really great because we had just
moved into a new office.
We just started our team back up.
We just painted the whole office and redid it
because our landlord refused to.
And we started working on this game,
and I had already had so much time to dream about it
and come up with all these ideas that we just were able to just
start working on it.
And it just like really clicked, and it was really satisfying.
And that's great when that happens.
And so that was probably the most fun we've had yet.
But maybe that's just an "everything
is always getting better" thing.
Who knows?
AUDIENCE: Yeah, so I have a corollary
to the previous question that I was a proxy for,
the fun versus educational thing.
But this is more about fun versus productive, or fun
versus useful.
So a lot of the games that you've made,
and in particular the ones I've been
a fan of, like TIS-100, and Shenzhen I/O, and SpaceChem,
you're doing some work.
You have some task that you're supposed to solve,
and it's an interesting problem-solving challenge.
Have you thought about any ways to try to somehow bring
the fun that you've managed to create in those games
into more useful work, in terms of either making our day
jobs as programmers more fun, or making the fun that we engage
in recreationally more useful?
Can it be done?
Do you have any thoughts on what we
might do to make that happen.
And I also ask this as somebody who is--
obviously, you have worked professional corporate
engineering jobs, where it's maybe
less fun than ideal for your programming capabilities.
I'm just curious if you had any insight on what
we might do to bridge that gap.
ZACH BARTH: So this ties into that
I used to think that games were great for education.
Now I think that games and education are just
game designers-- the only hammer they have is game design.
And so everything looks like a game that needs to be made.
I don't know anything about education.
Honestly.
But when I think about how maybe we could improve
it is not by bringing over games but by bringing over
this idea of fun and the idea that work can and should
be fun.
Especially if you're a kid and it doesn't matter.
It's an open question about why people play
and why play exists, but the idea that play is how we learn.
I think there's a lot of evidence for that,
and trying to bring more play into learning,
I think that's a lofty goal, but I don't really
know if that makes sense or if you
could apply that in any way.
As for making work more fun, oh God, I don't know.
I mean, to roll back into your question earlier, the games
that we make seem like they're about real life things.
They're inspired by it, but they're completely artificial.
And I don't know.
In Shenzhen I/O, we completely changed the way
that synchronization works, like a week before shipping,
because too many of our playtesters were stupid
and couldn't understand it.
And of course by that I mean it was not a good system,
because when you're the system designer,
if people don't get it, it is 100% your fault.
And we had to change it.
And if we were trying to make a game that was about real life
arduinos, because people need to know how to program arduinos,
you can't change it.
You just have to hit a little harder.
Oh, we'll just put some more tutorial text on there
or something, which doesn't work, by the way.
The only way to make your game more playable
is just to make it more playable and to redesign it until it is.
And so it's like the old saying about the way to win a battle
is to pick the right battle.
And that's very much what we do.
We take on task when making these games.
It looks like work, but we're really taking on the tasks
that we think that we can win.
And in education, I think it's much harder to do that.
Because you can't change anything about it.
All you can do is--
in our starch metabolism game, when we ran into problems,
we just backed off and didn't cover those topics.
And you can't do that when you're supposed
to be teaching specific things.
You can sit down.
I don't want to make you stand there just listen to me.
AUDIENCE: Thank you.
ZACH BARTH: Yeah.
The one idea I've seen in education
that seems really cool-- and again, I
say this as a person who knows nothing about education
from a technical standpoint-- is the idea
of cross-curricular classes.
So instead of saying you have math class and you
have history class--
there's a school, a charter school called Quest to Learn.
They have a few locations-- you have a codebreakers class,
where codebreaker classes is about codes and breaking them.
And that's what the class is about.
And of course that includes math and history.
And you can't take a class and not write.
But it's about codebreaking, and it's about something
that you can get excited about as opposed
to an abstract like group of tools, which is not super fun.
And I think that's a way that you can take--
Games aren't like, this is a moving game.
It's just about moving.
What about shooting?
No, it's just about moving.
There are some games that technically are that,
but that's not how you go about designing a game.
You try to have some emotional resonance.
You try to make it so it's interesting.
You give people tasks so when something is too hard,
they don't just have to try harder.
They can back off from that.
I was just talking to Keith, who I still
work with, about-- we've been really
into Heroes of the Storm.
The games I play are nothing like the games I make.
I am super lowbrow in my games and with what I play.
And so we've been playing Heroes of the Storm, which
is a MOBA, for those of you who don't know.
And apparently there was a talk by the lead designer at League,
Riot, with League of Legends.
One of his philosophies is that you
want to have lots of different skills for people
to master so that when like you get in a situation
where you're you keep trying to do this thing
and you just can't do it because you just don't have that skill
and you're not good enough yet, you can back off and do
something else instead.
And if you think about math class,
it doesn't allow you to back off and do something
that you can do and gain mastery in a different area
and then come back.
It's like, no.
We're just going to keep building on it over and over
again, and if you miss one step, you are out.
And that's how we do it.
And that's a very ungamey way to do that.
If that was a game, i would be a bad game.
We say, oh, we want to bring games into classes, not
that we want to bring lessons from games into classes.
And I'm going to stop ranting about that, because I don't
know what I'm talking about.
AUDIENCE: So the Zachtronics games I've been playing
are often about developing solutions for a fixed problem.
And everybody's graded against the same criteria.
They're compared indirectly via metrics, completion time,
and everything like that.
What do you think about games where
player solutions can compete or cooperate directly
with one another?
So it's not so much the environment and a fixed puzzle
but rather how they interact?
ZACH BARTH: That's a good idea?
AUDIENCE: Have you ever heard of RoboWars for Mac?
ZACH BARTH: Oh yes, oh yes.
No, I'm definitely familiar with a lot of those kind of games.
Yeah, that is something that intrigues us.
Maybe if you're lucky, yes.
It takes a while to make games.
That's the hardest part.
And so I would love to make a game like that.
AUDIENCE: I would definitely play it.
SPEAKER: So we're probably going to have
to wrap up soon, so we're just going to end up
with the question that we deferred,
which is, "What has been the most surprising or unexpected
thing you've seen a player do?"
ZACH BARTH: Oh yeah.
So we're good till 2:30, right?
Until 2:00.
ZACH BARTH: 2:00?
It said 2:30 on the--
OK, so--
SPEAKER: We have the room reserved
for clean-up afterwards.
ZACH BARTH: OK, well, let's start cleaning up while I talk.
So I wanted to show you guys something really quickly,
which is the secret origins of Zachtronics games.
Which is JFLAP.
Has anybody used this before?
Yeah?
You look excited.
So in college, I took a class about like models
of computation and computational theory.
And one of the exercises that we got repeatedly
was, implement a push--
an automata that satisfies these things
and accepts and rejects these different things,
and build a Turing machine.
This is a Zachtronics game, right?
I mean, there's actually a game out there
by somebody else called Manufactoria,
which is literally about Turing machines.
But this idea of "here's a set of criteria.
Here's a completely open space, where
you can design something that's technical
and kind of computationy, but not literally programming,
and have it meet these criteria over here."
And I think a lot of people who make programming games,
they never got to experience the beauty of JFLAP.
And they just thought, oh, I have to write code,
and then do this.
And I think this really tapped into something deep
in my psyche, the idea that you can build these things that
aren't code but are symbolic, or mechanical, or processes,
and still apply the sort of programmatic criteria to them.
And so that's the hidden origin of Zachtronics games.
I wrote this, and I have no idea what any of this means.
Yeah, I don't remember anything from modcomp,
yet it was still like the most important class
I took in college.
So
AUDIENCE: The homework actually stated I don't know [INAUDIBLE]
ZACH BARTH: Oh God, yeah, that was just talking about Java,
but yeah.
So I'm going to blast through this in three minutes
apparently.
So we get surprised by our players a lot of times.
People build impressive things, obviously.
Everybody has seen redstone computers
in Minecraft, that kind of thing of people
just building something that's surprising.
Well, not surprising but just impressive.
Sometimes in our games people, discover
unintentional mechanics and exploit them to great depth.
That's a fun thing.
And sometimes people just find out new ways to play our games.
So I showed you this about the origin of histograms.
There's also solution-sharing in SpaceChem.
It really looks like this.
There's YouTube videos.
But before that, we were like, oh,
what if it was like a website that it generated, and you
could click on it and stuff?
It turns out, you look at this, you have
no idea what's going on here.
I don't know what's going on there.
I mean, technically that's a solution to a puzzle.
But that was why the video came about.
And that was back when it was super
hard to record a video without codecs and stuff.
Managed to make that work.
In KOHCTPYKTOP, you'll see the first universal solution.
By connecting up the wires here, you
can just replicate any set of output universally.
And so this leads to something we call Volkswagening now,
after people did this to a great degree
in Shenzhen I/O, which is where you say,
to hell with what it's supposed to do.
Let's cheat and just get the right output,
the right criteria for the test.
That's somebody else's term.
That's not mine.
In Infiniminer, we were surprised by our players.
I built Infiniminer to play like TF2.
It has teams and classes and stuff.
I didn't know anything about game design then.
All of our players realized that it's more fun just
to build shit that's cool.
And this would be a thing where our players innovated,
and we were just like, oh, I don't know what to do.
And sometimes being at ground zero
is the worst place to see what's going on right where you are.
And that's definitely I think what happened with Infiniminer.
With SpaceChem, we have some-- oh, that looks terrible.
So this is the stall of waldo.
These are techniques that we had no idea were possible
until we shipped the game and people started doing them,
where if you just put in an instruction like this
and have it just run off, it'll just repeatedly execute
that, which it turns out is really cheap from a score
perspective.
I didn't even think this is possible,
but a strictly linear solution.
I don't know if you guys have seen that before,
but that's pretty cool.
And people figuring out the worst example of this.
These are fun.
This is cool.
Somebody figured out something clever.
When people figured out how our bonding algorithm worked
and that each bonder was technically
in a sorted list somewhere in memory,
and then if you figured out the order,
you could control the order precisely
in ways we didn't intend.
And this is a problem that continually bites us
in the ass, over and over again, which is that,
should something be deterministic,
or should it be non-deterministic?
And if it's non-deterministic, how
do we convey that it's non-deterministic?
This is a big problem in Shenzhen I/O.
In Shenzhen I/O, when you run a solution, every time you
run that same test run, it's deterministic.
But when you get to the next test run,
it's technically not deterministic
from the last one.
This happens all the time.
We added logic gates.
People are like, oh, I'm clever.
I'm going to build flip-flops.
So they build a non-deterministic flip-flop,
that if they took a class in electrical engineering,
they'd know it was non-deterministic.
But because they run the same test run over and over again,
it's deterministic.
It always initializes the top output first.
And then they get to test run two,
and suddenly it's the bottom one.
And they're just like, there's a bug in your game.
I get 70 e-mails, and they're like,
there's a bug in your game.
It's like, no.
Part of it's deterministic and part of it's not.
And it's super complicated.
Can I have five minutes?
OK?
You guys can leave if you need to.
That's cool.
So this is the greatest thing that anybody has ever
made for any of our games.
This is homemade.
They made it by hand.
It's a looping animated GIF.
And we were going to do YouTube video
uploads for Infinifactory.
And this was 2013, when everybody was getting really
into animated GIFs again.
And they made this.
You can't talk because you can't actually put animated GIFs
in PowerPoint it, turns out.
And so they made this gift.
And I'm just like, oh my God.
This is the greatest thing I've ever seen in my life.
And so within a day, I took our YouTube thing,
just ripped out all of the video stuff
that we were planning to do and made it spit out animated GIFs
instead.
And it was the most genius thing we ever
did, because then everybody just shared animated GIFs with all
their friends.
And because the factories loop, we
can make the GIFs loop seamlessly
and it's fucking amazing.
That's my favorite thing.
So here you can see some techniques.
You actually see you can see some techniques that people
discovered that I really didn't intend and I don't like,
but you can't do anything about it.
That rope.
Goddamn it.
See, if they supported animated GIFs, this would be easy so.
So it turns out rotating things is
quicker than moving them on conveyors because
of how rotating things work.
And then people also used this to build giant rotating arms,
where they'll just have these arms that
just swing effortlessly in one cycle back and forth
across the map.
To the point where, when people keep their own high score lists
with other people--
on Reddit, they do this for all of our games,
because we don't have an official high score
list, because I don't want to be responsible for making
sure people aren't cheating.
They'll say, here is your best score.
Here's your best score without giant rotator arms.
It's a huge problem, but we couldn't do anything about it
because it's just that that was the game we made.
We also had somebody--
this is a puzzle where you're supposed
to build a machine that you can drive
to like fight off a battle--
spoiler alert-- at the end of the game.
Somebody built a completely autonomous solution
that perfectly 100 percents the battle.
So I didn't even think that was possible,
but there they are doing it.
AUDIENCE: That was me.
ZACH BARTH: Wait, what?
AUDIENCE: That was me.
ZACH BARTH: Oh shit!
Well, what's your YouTube name?
SPEAKER: [INAUDIBLE]
ZACH BARTH: OK, so there might be more stuff in from you.
I don't know.
SPEAKER: [INAUDIBLE]
ZACH BARTH: OK.
So this is-- you can tell.
It's whatever you call the automata for that.
A couple people made these.
Somebody build a typewriter.
It's getting to the point where I don't even know.
There's all sorts of cool things that I, in theory, understand
you can do in the game.
You can build physical structures
that are data, because they're physical, right?
And so I'm guessing that's like a matrix of things
that encode the different characters, right?
So this dude, almost all these videos
are from this guys GTW123.
So he built a typewriter.
Then he built a calculator, which
uses the same kind of method for printing.
The crazy thing is, it actually supports a ton of precision,
because--
I'm going to skip ahead really quickly.
You can see it builds-- it does it physically.
So I think you guys can see where this is going.
So he's going to build this number,
and it just builds it as a stack of blocks.
And then the way you add them is you just
smash them together and let it physically carry over
and stuff.
So it's pretty cool.
He also implemented TIS-100 in Infinifactory.
So this is somebody who's far cleverer than I am.
So the code, the program is locked in,
but it is reprogrammable, and it's really executing.
I don't even know.
How the fuck do you do this?
AUDIENCE: Have you considered hiring him?
ZACH BARTH: I don't know.
I don't want this person writing code for my games, right?
So there was a little bit of--
TIS is boring by comparison.
So we had this instruction called
JRO, which lets you just arbitrarily tell
one node where to jump.
One node can tell another node how to jump.
And you can do insane things with it.
The problem is that that doesn't look cool.
Does anybody know what this is, this code?
Yeah, so this is the Quake 3 fast inverse square root thing.
It's infamous code.
It's really hard to tell how this
does an inverse square root, but it's create code.
And great solutions for TIS-100 look like this.
At best, you can tell there's a comment here
that just says "what the fuck."
So you know that something weird is going on.
You don't even get that in TIS, because there's not
room for such a comment.
So good TIS solutions don't look any different than a bad one.
Some people built little fun things.
This generates a maze that you can walk around in.
But that's about it.
A lot of people built emulators for TIS-100.
I guess that's kind of cool.
That there were a surprising number
of people who made emulators for TIS-100.
Which I guess is how programmers interact with stuff,
is to try to emulate it.
Shenzhen I/O has some fun stuff.
Is sound going to come through?
SPEAKER: Probably not.
ZACH BARTH: OK.
Oh, I can hear myself coming through there.
That's what's going on.
That's confusing.
I'm going to try to--
can we do the microphone into the computer?
Does that work?
We'll try that in a second.
So this is one of those people who
built a flip-flop that's non-deterministic
and they think it is.
What?
That does seem like an error.
That was just supposed to be funny.
OK, here we go.
So here somebody built a Game of Life.
These are just things that I didn't--
I guess that works.
Evidently, it works.
I don't know how it works.
There's a bunch of that with Shenzhen I/O.
The best ones are the music player ones.
So we're going to try this.
No, that's just going to be feedback.
That's not going to work.
It does play music, which is hilarious if you could hear it.
So that doesn't work with that joke.
So here's the last thing I'll show you.
So somebody built a 3-D maze, where
you can walk around this maze.
They couldn't actually store the maze anywhere.
So it algorithmically generates the same maze every time.
Because otherwise, you just wouldn't be able to fit it.
And so all of the crazy Shenzhen I/O solutions
have this trait of you just can't even tell how they work.
And it's like magic.
But there's no fun mechanics to discover in that game.
So I think the giant rotator arms are probably
the best for what somebody has done.
So there's another quick thing I want to show you guys.
So somebody asked about the TIS-100 patches.
And so that was totally inspired by Activision.
They used to give away--
I don't know if you had to send in money,
but if you photographed yourself getting a high score
in a game next to the TV or whatever,
and then you'd send them the photo,
and then they'd send you back a patch
so you could join their high score club or whatever.
And so I saw this, and was like, yes, we
need to do this for Infinifactory.
And so that's for the first 100.
And the first 100 people to beat all of the puzzles
in the first part of the game got a patch,
and it was pretty cool.
Yeah, I guess we should stop.
Does anybody else have any questions?
We have time, right?
SPEAKER: Thank you for coming.
ZACH BARTH: Yeah.
SPEAKER: Can we get a round of applause.
[APPLAUSE]