MALE SPEAKER: Carolyn
VanEseltine, our guest today,
has been in video games
since roughly the start
of the current century.
She got hooked on
designing them,
and then on observing
what kinds of games
other people are making
and connecting those,
and also what kinds of games
people haven't been making
and are just thinking of now.
So Carolyn VanEseltine.
[APPLAUSE]
CAROLYN VANESELTINE:
Hi, everybody.
As [INAUDIBLE] introduced
me, I'm Carolyn VanEseltine.
And I'm here today because
everybody can dance.
I know there's this punch line
that normally goes after that,
everybody can dance, but
not everybody should dance.
I don't believe that.
I believe that
everybody can dance
and that everybody who
wants to dance should dance.
I think they should dance,
I think they should sing,
I think they should
write poetry.
I think they should do whatever
art expression moves them.
I think that art expression
is a natural human right that
transcends every
boundary we have.
The problem is, this hasn't been
true for our youngest art form.
And by our youngest
art form, of course,
I'm talking about video games.
Historically, there's
been a very high border
to being part of video games,
because historically, in order
to make video games, you
need to be a programmer,
you need to know
somebody who can program
and who's willing
to work with you,
or you need to have the
money to hire a programmer.
For this reason, the people
who've been making video games
are extremely different than
the people who have been singing
or writing poetry or dancing.
I have a quick
question before I fully
get into this,
which is, I'd like
to know how many people
here are programmers.
Great.
OK.
Thank you so much.
Just didn't want to
make any assumptions.
Now there's a
terminology thing I
should hit before I keep going.
There is a difference of
opinion about the difference
between coding and programming.
So I just want to
admit I'm going
to use those synonymously
for the most part.
When I talk about someone who
is a no-programmer, what I mean
is someone who is not fluent
in any scripting language,
or-- I mean, someone who is
not fluent in any programming
language, or I mean someone
who identified themselves
to me as not being a programmer,
because a lot of this
is about self-identification.
So I want to take a
step back and tell you
a little bit about my history
with video games, which
starts in 1980, when I
was born into a house
with a computer, which
was true of fewer than 1%
of American households
at that time.
When I was five years old, my
dad, because he is awesome,
introduced me to
Colossal Cave Adventure.
I thought that this was the
best thing I had ever seen.
I could tell the computer
things and the computer
would do things.
It was fantastic.
He printed out the
source code in Fortran
on our old dot matrix printer.
It was about this big,
from the perspective
of someone about this tall.
And I would carry
it to day care.
I wanted to understand it.
I wanted to know
what was going on.
Fourth grade.
My fourth grade elementary
had a school computer lab.
I met Logo there.
Logo go with the turtle.
The turtle is awesome.
You told it what
you wanted to do,
and it would just
do it on the spot,
and you could make
procedures and you could link
all these commands together.
In fifth grade, I had decided
I wanted to make video games.
I had this idea it was like a
mashup of Infocom's Wishbringer
and Colossal Cave Adventure
and Jurassic Park.
It had dinosaurs.
It was going to be great.
And I would map it all
out on graph paper,
and I would write all the
text descriptions down.
By eighth grade I
knew a little Basic.
I knew a little Pascal.
At one point I borrowed
a book from the library
that had an explanation of
Conway's Game of Life in basic.
So I typed it into
the computer, and it
was a really bad implementation
of Conway's Game of Life.
So every time the cells
hit the edge of the board,
they would break.
My parents saw what I was
doing, and one of them
showed me one way
to make it better,
and the other showed me the
other way to make it better.
Of, you know, the
millions of ways you could
have made that program better.
It was a pretty
bad implementation.
But the point I'm
trying to make here
is that I wanted video games.
I wanted this.
I wanted to be part of this.
I had wanted it my entire life.
And I had every advantage.
There was a computer in
my house when I was born.
I have never lived in a
house without a computer.
Both my parents
were programmers.
There was a computer
lab at my school
I had basic programming concepts
from about five years old.
So I went to college and I
majored in creative writing.
And I never took a single
computer science course
because one of my
friends had told me
that the Comp Sci professor
who taught Comp Sci
101 deliberately washed people
out who didn't want to major.
I didn't want to major.
Programming was great, but
it was a means to an end.
And there weren't any
game programming classes.
I didn't know how to take
my little bit of Basic,
my little bit of Pascal--
even if it had been expanded,
I didn't know how to take
that and make something
with graphics.
I didn't know how
to make something
that you could put on a
disc in a box on a shelf,
and then someone
could go to the store
and buy it and put
it in their console.
Those were the people
who made real games.
It wasn't a meaningful
aspiration for me
and so I faded out of games.
I'm standing here in
front of you today,
and I did say I was a
professional game developer.
So you can tell that at some
point I got back on the horse.
But I didn't do it by
learning to program.
I came in the back door.
There was a company
called Simmtronics Games.
And they started somewhere
in '94, 95, I think.
And I apologize if I
just got that wrong.
But the pertinent part is
that what they were making
was a pay for play mud.
And it was available
on America Online.
And I wound up doing volunteer
customer support for them
in exchange for my pay for
play being play instead of pay.
So I got through the door there.
Eventually they hired me on.
When they hired me, it
was to run in-game events,
it was to write
documentation, and it was
to do more customer support.
At that point, I was
in the games industry.
And I had no idea how
to make my own game.
I knew how to support
someone else's.
But games were for people
who knew how to program.
They were for people
who could put that disc
in that box on that shelf.
I didn't know how to
do any of that, which
meant they weren't for me.
So obviously, at some
point, I got over this.
I got over this because of
a system called Inform 7.
Inform 7 made it possible for
me to release my first game.
One Eye Open is a
psychic horror game.
It was a collaboration between
me and my friend Caelyn Sandel,
and it came out in 2010.
The reason I was able to
create and release a game
is because of a system
called Inform 7.
Inform 7 looks like that.
It does not look like
a programming language.
To me, with my limited
background and experience,
when I saw something
like this, when
I saw something that
looked like English,
I was a creative writing major.
English was comfortable.
I knew how to work with it.
I had the confidence.
I said yes, I can make
something that looks like that.
Inform 7 was created
by Graham Nelson.
Graham Nelson was looking
specifically at non-programmers
and trying to make a system that
was more comfortable for them.
It has an integrated
development environment.
It is actually a transpiler.
It does not go from
Inform 7 to working game.
It goes from Inform 7 to
Inform 6 to working game.
What you're looking
at right here
is a relatively
common in fiction
snapshot of a game
called Cloak of Darkness.
It's a very bad game.
But the point of
Cloak of Darkness
is to show how various
systems handle the creation
of various game elements.
This is what Cloak
of Darkness-- well,
this chunk of Cloak of
Darkness-- looks like in Inform
6.
If you know how to program,
this is not scary looking.
If you don't, computer
code is intimidating.
Computer code is intimidating
because the computer
doesn't think like a person.
The point of learning
to program is
learning to think like
the computer operates.
That's the whole point
of computer science.
If you don't know how to think
like the computer operates,
then you need some kind bridge.
You need something
that makes it easier
for the way you think to
correspond with the way
that the computer operates.
And that's what
Inform 7 was for me.
When I originally
launched my game,
I was working at
Harmonix by then.
I'm not going to go
into the details of how
I got there, but assume it
was kind of like how I got
into games in the first place.
When I launched my game, I
was really excited about it.
I told a bunch of people at
Harmonix, hey, I made a game.
And one of the engineers
asked to see my source code.
I would be happy to
show you my source code.
I sent over my source code.
Inform 7 actually tells you your
word count instead of your line
count, so I knew that it was
upwards of 100,000 words.
I had no idea what that
meant in lines of code.
I still don't.
But I sent it over, and
he sent it back and said,
you accidentally sent
me your design notes.
I wanted to see the source code.
But that was my source code.
I didn't have anything
else to show him.
He had looked at it and
seen it as something
that a non-programmer
could do, something
that a non-programmer
could understand.
Inform 7-- don't get
me wrong-- can actually
do some extraordinarily
complicated things.
But Inform 7 was
released in 2006.
In the year 2006, use of Inform
6 it dropped like a rock.
An by the time you
get to 2012, Inform 6
alone was hardly being
used anymore at all
because the people who were
making interactive fiction
were people who were coming
from a programming background,
but also from a
writing background.
They had the same
experience I did.
Also, Inform 7 has an integrated
development environment,
which makes everything
so much better.
Here's the problem
with Inform 7.
Inform 7 is a
scripting language.
It has a very specific syntax.
The syntax is actually
as specific as the syntax
for Inform 6, which means that
even though it looked intuitive
and it was easy
to read, oh, man,
you can get the most amazing
compiler errors out of it.
And because it's trying very
much to help you and figure out
what you meant to do,
it's not as simple
as, I think there might
be a semicolon missing.
It's kind of amazing, actually.
I love Inform 7.
I don't claim that
it's for everybody.
I'm going to digress
for a second,
because I do come, as
a hobbyist, very much
from an interactive
fiction background.
Inform 7 is used to
make parser games.
Parser games tend
to look like that
when someone who doesn't
know how to play parser games
plays a parser game.
They try commands that don't
work because they don't
understand the limits,
because they haven't been
taught to play parser games.
There's an actual
skill involved here.
You need to know
that you need to make
these noun-verb or
verb-noun combinations.
And you need to understand
that it's just not
understanding English.
There are a lot of people who
play and love parser games.
There are a lot of people who
get frustrated by the fact
that the prompt is
giving them this illusion
of infinite choice,
but in reality they
have very limited choices
available to them.
But there are systems
that are easier than this.
This is the other major
branch of interactive fiction.
It's called choice-based
interactive fiction,
and it actually comes from
the tradition of game books
and from choose
your own adventures.
Instead of giving you an
illusion of infinite choice,
it shows you exactly what
you can do in that room.
And the actuality
is, all you can do in
that room is walk around.
That makes it so
much less frustrating
to people who don't
have the skill
to interact with that program,
who don't have the experience.
So bringing it back
to game engines.
What's needed is
a game engine that
is just as accessible
as this, something
that takes that experience
of, I don't know what to type,
and turns it into, I know what
I can type, or not even type.
This is Construct 2.
And Construct 2 is a
visual scripting engine
for making graphical games.
It is something that
presents everything in menus.
It presents everything
with drag and drop.
What you're seeing
right here is actually
a script in the making.
If you click the little
heart image, which
is the A frame sprite with
the left mouse button,
it will rotate 90 degrees.
And it's currently
offering me the chance
to add another action
to this script.
This is not a
complicated script.
But once you start adding them
together and chaining them,
just like a small program can
become something dramatically
larger, a small script can join
with others to become a game.
Just because it works
with visual scripting
does not mean that a program is
necessarily going to be simple.
All it's doing is making
the syntax accessible.
Here you can see that
there are a lot of things
you can do from the system
object, many of which
are extremely
important, many of which
require mastering the engine
apart from the scripting side.
There are actually a number
of engines in this style.
They are engines that
are based around the idea
that it will be
easier for people
to code if they don't
have to fight with syntax.
This is an image from the game
Airscape: The Fall of Gravity.
Airscape was greenlighted
through Steam.
It received multiple
awards, including
an award on its physics
engine specifically.
It was created entirely
in Construct 2.
It is a fiendishly
difficult puzzle platformer.
And the developer selected
this system specifically
because he didn't
have experience making
games with programming yet.
He needed something that was
accessible to where he was
at the time he was starting.
There are a number of other
game engines in this same vein.
Clickteam Fusion, GameMaker:
Studio, GameSalad, and Stencil.
The last one is Stencil.
And there are others, but
those are some major ones.
I'm not going to go through
and detail all of them,
because what I actually want
to do is move to show you
a completely different
kind of game engine.
This is Twine.
Twine is designed
specifically for making
choice-based interactive
fiction games.
What you're seeing here
is the design interface.
And since Twine games are played
as this series of web pages,
essentially, you can see with
a map the web page forming.
This is actually the exact
same Cloak of Darkness section
that you saw before,
although I didn't
implement the rest of it.
Here's the thing about Twine.
I didn't try to
teach you Inform 7.
I didn't try to teach
you Construct 2.
Those take half
an hour, at least,
to teach somebody,
if what you want
is for them to go
from zero to game.
And that's regardless of
whether they have a programming
background or not.
Let's face it, a
language is a language.
There's syntax to learn.
There's a system to learn.
I can teach you to
Twine in 30 seconds.
I have done this repeatedly.
You can make a basic Twine
game with the information
you get in 30 seconds, which
is, start at the start.
Type whatever you want
into that passage.
Whenever you want to make
a link to a new passage,
put in double brackets.
It will open up a
new passage for you.
Keep going until you are done.
Hit Build.
Build story.
You now have a
playable web page.
You can put it anywhere you want
and people can play your game.
It is that simple.
And that is why
people are flocking
to Twine right now, because
there is no game engine more
accessible.
Twine is free.
It is also open source.
And it supports a lot more
than simple hyperlink.
It has full support
for variables,
for conditional logic,
for extensions with images
and CSS and video and sound.
And it also extends
with JavaScript.
But for that basic game,
the first experience
of, I made a thing,
there it is, it's
amazing for someone
who never thought
they could make a game before.
Here's a different engine.
Choice of Games.
Choice of Games is also an
interactive fiction engine.
But it's an interactive
fiction engine
that is aimed at a
very specific audience.
And it's aimed at a
very specific audience
because it's used to create
a very specific kind of game.
Choice script is
used specifically
to make novel-length
interactive fiction.
Choice of Games is
a commercial company
that is making its
money on selling
novel-length
interactive fiction.
They are not aiming
at programmers.
They're aiming at
writers, specifically
writers who never intended
to make this kind of system.
It's as simple as it
can be because they
need it to be accessible
to this specific audience.
There isn't actually an
ID for Choice of Games,
for Choice of Games
choice script.
The system you use actually has
extraordinarily simple syntax,
and you just write it
in manuscript form.
When you're done, what
you get looks like this.
This is actually optimized
for people playing
on their iPads or other
touchscreen devices,
but you can play on
a computer as well.
And again, it's very
intuitive to play.
Select your option,
click Next, move on.
These are three
examples of engines
that are also aimed at creating
very specific kinds of games.
Ren'Py is specifically
for visual novels.
RPG Maker is
specifically for RPGs.
Adventure Game Studio
is specifically
for click and point adventures.
Again, I'm not going to walk you
through the full details of all
of these.
All of these engines
are aimed, or had
as a primary audience,
people who don't know how
to program in mind.
This one was aimed programmers.
Unity is a big deal.
They currently have 45% of the
market share for game engines
used in commercial games.
47% of developers are using it.
4.5 million developers
are registered.
And they have 600
million gamers,
at a minimum, playing
projects created with Unity.
Unity uses C# and
JavaScript as its languages.
This is not something
that's accessible to people
who don't know how to
program, except that a company
saw the void.
The people who make playMaker
put a visual scripting system
on top of Unity.
It is in use at actually
some rather large studios.
Most famously, Blizzard used
the visual scripting system
playMaker when it was
making Hearthstone.
Hearthstone is a digital
collectible card game,
and the income is estimated
at about $20 million a month.
It's a very
successful card game.
The reason why
they used playMaker
was so that, with their
15-person team that
was working on it,
the art team was
capable of building
things in the engine
without needing to pull
a programmer off what
they were doing at the time.
Specifically, playMaker
is a visual state editor,
and it's also a runtime library.
But the net effect is of a
visual scripting system that
was built directly into Unity.
In addition to large
studios using it
for specialized projects, it
is possible to make a full game
with playMaker.
Jenna Hoffstein is the founder
of Little Worlds Interactive.
Her launch product was
The Counting Kingdom,
which is a tower defense game
that is aimed at teaching kids
arithmetic.
She made it completely in Unity
with the support of playMaker.
Now I've been talking
about non-programmers.
I've been talking
about programmers.
When it comes to
game development,
do programmers have an
advantage over non-programmers?
It depends on what
you mean by advantage.
A lot of people ask
if non-programmers
can use these tools to
compete with programmers,
but that depends so much on
what you mean by compete.
When I talk about
game developers,
I'm not just talking
about people who want
to make games commercially.
I'm going to show you
one of my favorite quotes
about game development.
It's from Zoe Quinn.
"How to win at game jams: Go.
Make a thing.
It doesn't have to
be good or finished.
OK, cool, you won."
This is an attitude I
can get behind 100%.
Games are not intended to be
polished commercial games.
This is kind of like
a 48-hour hackathon.
You want to get from zero
to game, and at the end
you have the joy
of having done it.
And possibly you polish
and refine it and continue.
But the concept of
compete isn't meaningful
if you look at game
development as a whole.
It's only meaningful if you
look at game development
in a commercial market.
I made this game once.
It was specifically
for one of my friends,
and it was called Coffeeee
with about five E's on the end.
And it was this tiny text
adventure about how awesome
it is when you wake
up in the morning
and someone else brings
you a cup of coffee.
It couldn't compete with Super
Mario Brothers for the Wii U.
Super Mario Brothers
for the Wii U
couldn't compete with Coffeeee.
They're in two completely
separate worlds.
They're in two completely
separate universes.
Yes, video games are
a commercial market.
So are novels.
Not everyone wants to
be the next JK Rowling.
Some people just want
to make little games
that they can show
to their friends,
or just make them for fun, or
just keep them for themselves.
These concepts exist in writing.
People write for fun.
People write for their friends.
People write for themselves.
Postcard Game is the
term given to a game that
is just for one other person.
Diary Game is the
term given to a game
that you made just for you.
These things, you might show
them to someone else later,
but that's not necessarily
why you made it.
This is an art form.
People practice this
art form for themselves.
As I was preparing
for this talk,
I spoke to a number
of game devs,
actually about 35, who
are not programmers.
I asked them, why do
you want to make games?
What's in this for you?
Is it really worth it to you?
I got an amazing
variety of answers back.
And I just want to
read you a few excerpts
that exemplify themes
that people talked about.
One of them was joy.
Darryl [? Calvo ?]
told me, "For me, games
are windows on other worlds.
Discovering new things,
ideas, ecosystems.
It's about creating
tiny play spaces
to create and share wonders."
People talked about the
unique nature of the medium.
Valentina Christopsomo
told me, "There
are two reasons I make games.
One is that I love the
idea of creating something
that people can
interact with and get
an emotional response back.
Two, I love the
idea that people can
have such a strong emotional
response, that it's in my power
to make them feel
it, that people
resonate with a story in a game
more than any other medium."
People talked about
self-expression.
That's something
you can't access
in the world of commercial game
development in the same way
that you can if you're
sitting down at your computer
and making a game for you.
[INAUDIBLE], "I
showcase an aspect
of what is important to me,
using themes and elements
taken from my life.
I want to walk with
whoever ends up playing.
I also want people to finish
the game and have a part of me
to walk away with."
People talked about contributing
to the greater body of art.
[INAUDIBLE], "I want to
make video games because I
like to pretend there's more
to this medium than escapism
and power fantasies.
I don't like competition.
I don't like capitalism.
I don't like violence.
I can't stand the values
mainstream games usually
convey.
I like to pretend
I can change that
with my very limited skills, at
least for the handful of people
I can reach."
And here's one
very common theme,
from Talen Lee, "I make games
because people make games.
Little kids make games
on the playground.
We make games when we
walk on tiled floors.
I've basically always,
constantly been making games.
And computer games were just
another thing I wanted to do."
I spoke with 35 game devs.
Of all of those
people, one person
mentioned money as
a primary motivator.
I spoke with multiple
professional game devs
who are making their
incomes off the games
that they were making.
They didn't get into
this for the money.
Singers don't get into
music for the money.
Artists don't start
painting for the money.
Actors don't start out
in theater for the money.
Of course, it's
nice to get paid.
Everybody likes to get paid.
Getting paid is great.
But what brought them in
originally was the art form.
They found something in it
that spoke to them, something
in it that resonated with them.
It's the same way
in game development.
There are 7.3 billion
people approximately,
a very large approximation,
on this planet right now.
Of those people, how
many people like to sing?
I can bet you it's a lot
more than the people who
are making their living off it.
I would guess that it's
millions, hundreds of millions,
perhaps literally billions.
All we see, usually, is that
little tip of the iceberg.
But there's this huge
iceberg of people beneath it
who want to sing, just to sing.
In game development,
historically, there
was this barrier.
You had to know how to program.
You had to know a
programmer or you
had to pay someone
to program for you.
That meant there wasn't much
below that tip of the iceberg.
You saw the professionals.
That was pretty
much what you saw.
To be clear, to be fair, there
were game creation systems
in the '80s, things like
Pinball Construction Set, things
like Adventure Creation System,
things like Gary's Kitchen Game
Maker.
There were more in the '90s.
RPG Maker originally
showed up then.
Divinity for Realms.
But those systems existed.
You had to know
where to find them.
You had to know that
they existed even
to go looking for them.
And all this time,
it was easiest
if you knew how to program.
So historically, most examples
of this art form that we have
are the examples that were
created by programmers.
Most of them were
created in studios,
which means by corporations,
or by solo developers working
on their own in a context
where their games might not
be seen afterward, even
if they wanted them to be.
This is the youngest
art form we have.
We don't know who
invented singing.
We don't know who
invented acting.
We don't know who
invented painting.
We know who filed the
patent for the very first
interactive electronic game.
That would be Thomas
T. Goldsmith, Jr.
and Essel Rayman.
They filed a patent
for something
called the cathode ray tube
amusement device in 1947.
That was 68 years ago.
And given that it was
analog, we might not even
count that when we're
talking about digital games.
Pong is commonly cited as the
first video game that we had.
Pong is from the '70s.
This is young.
This is a very young art form.
And right now it is undergoing
this incredible revolution
where instead of this
tiny group of people
being able to make video
games, there is a land swell.
Here's what we know
about the people who
are at the tip of the iceberg.
The IGDA-- that's the
International Game Developers
Association-- runs
a survey every year.
And one of the things they
do is collect demographics
about the people who answer.
Most of these people are in
studios, either large studios
or small ones, or
are freelancers
associated with the industry.
Here's what the IGDA said
in 2015 about its members.
The people who responded
were whites, they were male,
they were cisgender, they were
heterosexual, they were young.
They were usually married or
in a long term relationship,
but they did not have children.
Most of these people were
in the United States.
And 93% have some amount
of higher education.
93% of people in the world
do not have higher education.
93% of America does not
have higher education.
94% of the people
who own computers
in their homes, or gaming
systems, or smartphones-- it's
not 93%.
This is a very specific
group of people.
Right now, the
profile of video games
is changing because the
profile of the people making
video games is changing.
We are not just
seeing games now that
are made by this profile of
people, which means that we're
not seeing games that
are necessarily aimed
at this profile of people,
because that is also
what was happening here.
Because this was the profile
of people making games,
they were making
games for people
who looked like themselves.
They were making games
for white men in America.
And they were making games
where the protagonist tended
to be a white heterosexual
man with American attitudes,
though not necessarily
in America.
So this is a very big
change, for people
who are not in this
profile to be realizing,
we can make games, too.
We can take this
into our own hands.
We are capable of being
part of this art form,
even if we don't know how to
program, even if-- for those
of you in this
audience who don't
know how to program-- even if
you don't know how to program.
Game dev is open to you.
It's changing.
The barriers are coming down,
and this is a moment in history
that people are going to look
back to and see that an art
form became available
to the public
instead of to a
small, specific group.
Now, this is an argument
I've heard before.
If people want to
make video games,
they should learn to program.
It doesn't make
sense for people who
don't know how to program
to be making video games.
There is no merit in
these systems that
are making it
possible for people
who don't know how to
program to make video games,
because the people who
know how to program
will make better video games.
This is not true.
I have worked in
AAA development.
It does not make you
a better game designer
to be a better programmer.
These are two
separate skill sets.
The one does not
follow the other.
It's like having to learn
human anatomy before you're
allowed to sing.
But what about the
limitations of the tools?
Well, tool limitations
relate to design.
If you're trying
to design something
that runs outside the
limitations of your tools,
then yeah.
It's like having a hammer.
If you have a hammer, and
that's what you've got,
you can be incredibly
versatile with it.
That hammer can
be a screwdriver.
It can be a lever.
It can be a panini press.
It can be a s'more stick.
There are so many things you
can do with that one hammer.
If you're used to a full
toolbox, having one hammer
is terrible.
But if that's not
what you're used to,
if someone gives
you one tool, you
can do amazing things with it.
Yeah, if you're used to
having the full power of C#,
or the full power of
C, for that matter--
let's go even lower level-- than
visual scripting is incredibly
limiting.
But that doesn't
mean that you can't
make amazing things with it.
Remember Twine?
I talked about Twine
as the game engine
that is the fastest to
pick up, the one you
can learn in 30 seconds.
This is a non-extended
version of Twine.
This is what you can
do with variables.
If you can set variables
and you can check variables,
you can make so
many amazing things
happen with game development.
Comparing Twine to
Unity, yes, there
are huge differences
between these two programs.
Twine cannot do 3-D animation.
It doesn't have a built-in
physics engine at all.
And it doesn't, for
example, make a good tool
to make something like
World of Warcraft in.
There are no Twine massively
multiplayer role-playing games.
But Twine runs in your
browser, which Unity does not.
Unity can run in your browser.
It requires a plugin.
You have to download the plugin.
You have to get
the plugin to work.
The plugin does
not work on Linux
or, appropriate to
this audience, Chrome.
You cannot play Unity games
in Chrome in your browser.
So Twine might have its
limitations, but Unity does,
too.
And this is because every
tool has its limitations.
Going back to
1841, 1841 was when
it became possible to
purchase pre-made oil paint.
Before 1841, if
you were an artist
and you wanted to
make a painting,
you were probably
grinding your own pigment.
You were probably
mixing it with oil.
And you were probably
stretching your own canvas,
because let me tell
you, pre-made canvases
did not exist back then either.
So if you have an
idea for a painting,
and it's about six
feet by two feet,
and you happen to have a
six-foot by two-foot canvas,
you're fine.
Your image for the project
fits within your parameters.
But if the idea
for a painting you
have is six feet by
two feet and the canvas
you have is four by three, if
you know how to stretch canvas
and you have the supplies,
you're still good.
You can just stretch the
new canvas that you want.
If you don't know how
to stretch canvas,
then you can either
alter your design
so that it fits within
the materials you have,
or you can paint on the wall.
The second version
is not recommended.
So that's what programming
is like in this context,
in the context of this art form.
If you know how to
program, you know
how to grind your own pigment.
You know how to
mix your own paint.
You know how to stretch
your own canvas.
You can go beyond the built-in
limitations of your tool.
And that's fine.
And that might make
amazing things.
But it doesn't mean
that a game made
within the limitations
of the tool
is innately inferior,
because games
that are designed
with their tools
in mind, whether you know
how to program or not,
are going to work
better than games
that are not designed
with the limitations
of the tool in mind.
But everyone should
learn to program.
Programming is awesome, and
I say that with the greatest
enthusiasm, because one of
the things you should know
is that, by now, I do, in
fact, know how to program.
I think it's wonderful.
I've been doing C#
for about a year.
I've been doing C for
about three years.
Programming is so
cool, you guys,
as many of you in this
room doubtlessly agree.
But not everyone should
learn to program.
The people who want to program
should learn to program.
There are no huge
definitive you must do.
There are things that will
make your life a little easier
in this society.
If you know how to read, that
will make your life easier.
Knowing how to
program-- it's actually
not a basic societal skill.
And game dev is an art form.
Art is a basic part
of human society.
Game dev is a valid
end in and of itself.
It doesn't have to be a
gateway to anything else.
If somebody tries game
dev and they get excited,
and they want to learn to
program, like yours truly,
that's fantastic.
More power to them.
But if they just want to
make a game, that is OK.
So going back to the 35
game devs who I spoke with,
the 35 game devs who are
not, in fact, programmers,
I asked them this question.
If it were impossible
to make games
without learning
to program first,
would you still have
chosen to make games?
Some of them said yes.
More of them said no.
Many of them had already
tried to learn to program.
They had not succeeded.
And it wasn't a lack of effort.
They were up against
huge barriers
that they had no personal
control over, barriers
like time, money, energy, the
former education that they were
coming into this with,
access to tools and teachers
and people who would give
them feedback on their work,
confidence, social pressure.
I want to tell you a story
about social pressure.
This comes from Megan
Hughes, a game maker
who uses Twine and GameMaker.
Megan Hughes, "I went to an
all girls high school here
in Durban, South Africa.
We had a male teacher
for computer science.
While he taught us well,
he would make comments
about the fact that women
should not be programmers.
He'd chuckle to
himself if anyone
spoke of that sort
of career for women,
and he was generally
patronizing,
even when we might
correct him about code
he'd put on the board,
as in, he humored us
throughout our education.
For most of the three
years I had him teach me,
I thought he only
had a son of whom
he spoke incredibly fondly.
Somewhere near the
end of the third year
he accidentally
mentioned his daughter,
a well-accomplished
specialist daughter.
This attitude,
combined with the fact
that the male friends I
knew who were into computers
seem to sell far
ahead of me, having
dads that encouraged them
and taking apart machines
and coding from an
early age, whereas I
was blamed for anything
even slightly off
on our home computer.
And we certainly didn't
have the funds for me
to run risks of breaking
anything with code attempts.
I figured I'd already lost
the race before starting.
In the end, I pursued my
other love, psychology."
This is not just about America.
This is about
everybody worldwide
who might want to
access to this art form.
This is about me, but it's
also about Megan Hughes.
It's about everybody I heard
from who wasn't in the United
States, and everybody who was,
but who never thought that they
could ever learn to program.
Some of these
people, the ones who
thought they would never,
ever learn to program,
are learning to program
because of game dev.
This is especially
common in Twine,
that super simple language.
And the reason it's
especially common in Twine
is because Twine
extends with JavaScript.
People working in Twine
see what other people
have done in JavaScript.
And some of them are getting
curious and some of them
are getting involved.
This is Kiva Bay.
"I'm 32, and I feel for
the first time in my life
like I could learn programming.
Maybe not well, but I could
figure it out with some help.
And I think it's because
I've made a Twine game now
that I feel confident
enough to even try.
Programming always felt
like a secret society hidden
behind a locked door
I could never find.
Twine showed me a window
to sneak through."
Kiva Bay's first game is
about her personal experience
of homelessness.
It's called 12 Hours, and it
just went through green light
on Steam.
This is not a game
that would exist
if she had to learn to program.
But while some
people are inspired
to learn to program by
their game dev experience,
it's not true for everybody.
This is Mike Rosen, who works
in Quest and Adventure Game
Studio.
"I have mild dyscalculia,
which is basically
like dyslexia but with numbers.
It's nearly impossible for
me to recognize or make
sense of patterns and
sequences in numbers,
and I'm also pretty bad
with computer logic.
Years ago a friend
tried to teach me
some basic programming,
and I just could not
get a handle on it at all.
I just assumed making a
game would be something
beyond my abilities until
I found these programs."
I spoke with 35
non-programming game devs.
They work on over a
dozen different engines,
and between them
they have created
literally hundreds of games.
Some of these games are
hours and hours long.
Others are 15 minutes, 10
minutes, five minutes, two.
Some of them have
created just one game.
Others have created dozens.
The vast majority of
these games would not
exist if they had had to
learn to program first.
We are better off because
their games exist.
We are better off for these new
voices, these new experiences,
these new ideas
about what is a game.
We are better off
even for the games
that were just created for
one person, or for no one else
to see.
Has anyone ever
drawn you a picture?
Has anyone ever
written you a poem?
It doesn't have to be big.
Just something small,
like, oh, a dirty limerick
or a new version of "Roses
are Red, Violets are Blue."
What would the world be
like if no one could?
What would the world be
like if your choices were,
write the entire
"Iliad" or nothing?
That is where video
games have been.
That is what is changing
right now, right here,
at this moment in history.
Every single person in
this room, programmers
and non-programmers,
could go home tonight,
download a free game engine,
and start making a game
if that was what you want to do.
This is how the
world is changing.
This is incredible.
This is huge.
And more people every day,
thanks to the internet, thanks
to free tools, thanks to
other people telling them,
you can make a game too--
more people every day go home,
download that free
software, try it out,
discover that they
can be part of this.
The world is changing.
It's changing right now.
This is the future where
everyone can make games.
And it's really important.
Thank you.
[APPLAUSE]
I would like to take
a moment to thank
the devs who were
willing to speak with me
and share their insights.
There were more stories
here than I possibly
could have shared
with you, and I
wish I could have shared more.
I was deeply honored
by their willingness
to tell me their stories.
I would also like to
thank the people who
take the time to make software
to help non-programmers
into this art form, particularly
the people who are releasing it
for free, as many of the people
coming into game development
do not necessarily have the
money to be able to afford
an expensive game engine.
So, any questions?
Yeah.
AUDIENCE: I'm 20
years older than you,
but I remember witnessing a
fairly similar phenomenon with
HyperCard, where there were
people developing interactive
stories in the mid-'80s.
CAROLYN VANESELTINE: Absolutely.
And I think part of
what's going on right now
that makes the change
here is the internet.
I think how easy
it is for people
to pass their games from
one person to another,
because HyperCard, not as easy
as just downloading someone
else's file or playing online.
But yes, Hypercard an
example that absolutely
fits into this model.
AUDIENCE: So you don't have to
be a programmer to use Twine,
but presumably a
programmer created Twine.
So from a meta
design standpoint,
if you wanted to make
tools for game designers,
what advice would you have?
CAROLYN VANESELTINE:
The question
was, from a meta
perspective, what
would be my advice to
people who want to make game
engines for non-programmers.
This is actually a really
interesting question for me,
because one of the things that
I've been working on quietly
behind the scenes has
been exactly that.
There are reasons why
I wanted to learn C#.
The thing that I
would say is most
important to keep in mind
is that you want to minimize
the number of walls that
people can run into,
that if it's possible
to keep people
from using bad syntax, for
whatever the system is,
keep them from doing that.
Make it impossible to
make bad decisions.
Make it possible to make
interesting decisions.
And I recognize
that it's very hard
to get rid of runtime
errors, like, you
can't help the people who go
and divide by zero deliberately.
Yes, you divided by zero and
now everything is going to stop.
But if it's not
possible for them
to hit go and then have compiler
errora after compiler error
fter compiler error, if it
will run but give them a heads
up about what went wrong,
that would be my advice.
Make it as streamlined as
possible to make something.
I also want to give credit
to Chris Klimas, who
is the creator of Twine,
who was looking specifically
at this kind of question
when he created it.
Anybody else?
AUDIENCE: So I have
a question that's
a little bit of a
tangent from your talk,
goes a little bit
beyond game design.
The thing I find really neat
about what you've been saying
has been the-- I guess I'll say
the bridge between programmers
and non-programmers in
the field of game design
that's been created by these
different systems where you can
actually do some game design.
And I think of these
different systems
as providing different ways to
express programming logic that
are somewhat more intuitive
to people who haven't gone
through the, OK, let's learn
Assembler from scratch,
and all right, this is
how the computer thinks
and that kind of stuff.
And I'm sort of wondering,
how do we expand that
beyond game design?
Because you said, should
everyone learn to program?
No.
And I certainly sympathize
with the feelings behind that.
There are people who
can't learn to program.
There are people for whom
it's really not worth it,
and they will not enjoy it
and they will be miserable.
But our society is
more and more one
that's like, just, the computers
are accumulating under our feet
and we're being
risen up by them.
And for the people who
don't understand anything
about programming, don't
understand how computers work,
I think the feeling
is just being
more and more helpless in the
face of all sorts of stuff
around them.
So I'd love to see that bridge
that you're building in game
design outside of game design.
Do you know of any
efforts in that
area, ways to make, I'll
say programming in general--
although, wow, is that
broad statement-- more
accessible to people
who aren't programmers?
CAROLYN VANESELTINE:
Code Academy.
Code Academy comes instantly
to mind from a game design
perspective, because
hey, I come back to this.
It's my lodestone.
AUDIENCE: That's your head.
That's this talk.
So go ahead.
CAROLYN VANESELTINE:
There is a system
that was created at
MIT called Sketch.
And what's really
interesting about Sketch,
it's aimed at eight
to 16-year-olds.
But it works in the browser.
And not only does it not
let you fail your syntax,
but all of the
visual drag and drop
scripting, all the
pieces of it are kind of
shaped like puzzle pieces.
So you can see how
they all fit together.
So it makes it very
easy to understand, OK,
if I have an if else,
there's this little gap here,
and that little gap means
that I have to have what
my conditional is in there.
But you also asked
a broader question,
not just about programming,
but about growing
more comfortable with
computers at large.
And I want to point out that
another way to look at this
is that it's a UI challenge.
And that is a UI challenge
that, number one,
is being tackled at Google,
number two, Apple excels at.
And there are so many
people continuing
to tackle this challenge of, how
do we make computers that look
like they think like people?
How do we make things Intuitive
And it's an ongoing struggle.
It's an important struggle.
And how to teach
programming is undergoing
that exact same struggle.
AUDIENCE: Yeah.
I'm worried.
I mean, I'm behind
efforts to make computers
think more like people.
But I think that
the way computers
think has a way of their own and
it's always going to be around.
And helping people in general
understand a little bit more
that would be valuable, too.
But that's a
programmer perspective.
CAROLYN VANESELTINE: Well,
so I had an experience
a couple weeks back where I was
working on a roguelike game.
So these are the top
down dungeon games,
procedural generation,
whole nine yards.
And I was working
on line of sight.
So here's my player character.
How far can they see?
What can they see?
How are things getting exposed?
How does this interface
with the light mechanics?
And it was the
first time I'd used
my algebra in about 20 years.
And before that, I was in school
doing something in school.
But it was important
for me to learn algebra.
In the same way, I
think that there's
merit to learning programming
in the context of actually
programming.
There's a lot to be said for
knowing some programming.
There's a lot to be said
for knowing some algebra.
And possibly it'll
show up 20 years later,
and you'll sit there going,
I'm so glad I paid attention
in that class.
Why didn't I listen
to my trig teacher?
Or why didn't I listen to
my programming teacher?
But my protest is
against the idea
that a barrier
should be in place.
The barrier, when it's not in
the context of being a barrier,
is another matter entirely.
Anybody else?
AUDIENCE: So I had a general
question about building tools.
So in some sense, building a
game with a restricted language
is like building a
very specialized tool.
So for mechanical things, you
can build either a hammer,
and a hammer is very
good at hammering
but terrible at other things.
And their other tools
are Swiss army knives,
which are kind of expert use.
So I've seen this
in game engines
that you try to build, too.
This is a tool.
It knows how to
speak certain things,
but it's extremely
frustrating when you
try to go beyond that paradigm.
And I don't know if
you can talk a bit
about that trade-off
between generalized tools
and specialized tools.
CAROLYN VANESELTINE: Certainly.
So that's something that we see
with choice scripts, RPG Maker,
Adventure Game Studio, Ren'Py.
They are aimed very
specifically at doing
one specific kind of game.
And once you branch
off that, it's
that question of making
sure that the system you're
using to make what
you're making actually
fits with what you're
trying to make.
And I got rescued by
a programmer once,
about a year ago, because
I had this great idea
for an asynchronous multiplayer
game written in Inform 7.
And I knew that Inform
7 can support data that
holds over from play to play.
And I thought to myself, I can
make a game that's multiplayer
where multiple people can
play it and affect each other
by just putting it on a server.
I didn't understand
what was going
to happen was that it was
going to cache in the browser
and people would not be able
to interact with each other.
I didn't understand
the limits of my tool.
I wound up-- and this
was for a game jam--
so I wound up running,
actually, to my fiance,
Danielle Church, who
is extraordinarily good
at programming,
and said, save me.
I have created an idea
that is beyond my toolset.
And she set up server
communication and JavaScript,
and made it so that
it could actually
happen the way I had
originally pictured it.
Yes.
There are dangers if
you decide that you're
going to use your hammer
as a panini press.
It is a good idea to look
around and see if you have
a panini press available first.
Anybody else?
Well, in that case,
I want to thank you
so much for your time.
I really appreciate that you
came here to hear me speak
today.
And I actually have a
blog at sibylmoon.com,
I think about game dev
and the state of game
and the people making games.
So if that's of interest
to you, please stop by
thank you so much.
[APPLAUSE]
