[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]
