GUY WHITE: Hello, everybody.
This is Guy White with Harvard CS50.
And thank you so much for joining us today
with Making Small-Scale 2D Games with LOVE and Lua.
I'm so excited to be with you here today and be presenting this topic.
Before we get started, what I'd like to do is just simply see who's with us
today.
If you would, go to the chat box.
And in that chat box, let's figure out how experienced
you are with game programming.
If you are a die-hard game programmer, and for some reason
you found your way into this introductory seminar,
you're going to put a five.
If you are brand new to the idea of programming games,
you've not programmed games previously, if you'd put a one.
And give yourself a rating somewhere between one and five-- one, brand new;
five, a seasoned expert, you probably could teach this.
Go and pop that in there in the chat box.
And what I'm seeing is lots of ones, a few twos.
And I wanted to say thank you for being here
today, because this seminar is going to offer you the chance
to dip your toe into the world of 2D games
through an amazing framework called LOVE that implements the Lua programming
language.
I am Guy White.
I'm a teacher in Harvard CS50, a teaching fellow at Harvard CS50.
I'm a business owner, and I am a small-scale game designer.
I reside in Portland, Oregon with my three soon-to-be black belt
children and my awesome spouse.
And this presentation is really the culmination, at least for me,
of what led me into wanting to do game making,
and how could I assist you in avoiding some of the major roadblocks that
get in the way when you are getting your start in game design and game
programming.
I want to thank you for your time.
I want to give you my commitment today that I'm
going to do everything in my power to hand you as much as I possibly
can during this about one-hour session.
And I give you that commitment with the idea that at the end,
I'm going to be providing you some resources about where
you can take this next.
Here, in this CS50 ecosystem, there are plenty of supports for you
to take this work further.
And I'm really excited to share those with you.
I grew up in the golden age of console gaming.
I grew up in the golden age of PC gaming,
where games were relatively small, they were often expensive.
You would go to stores and there would be boxes on the shelves
that you would peruse, and you would make
your selection based upon, usually, the box art and the type
on the back of those boxes.
During that time, when I was exposed, and maybe you
can relate, where you first got into gaming,
where you really longed for a teacher to teach you about how to get
started in game design and programming.
Now, in my 30s as I sort of entered into my,
I guess, second or third career with programming.
And through Harvard Extension School, initially dipping my toe
into the edX world, I really wanted someone
to hand me a pathway where I can make my own games
and bring my own creations out into the world.
And now, finally, when I started my first game,
when I was taking Harvard CS50, I really wanted to make sure
that all my time was properly invested.
Because for those of you that are engaged right now in Harvard CS50,
whether through Harvard Extension School or through our edX
platform or OpenCourseWare, you know how much of a time commitment
a lot of this work is.
My hope is that, through the steps that we talk about today,
that you're going to feel like, OK, not only do
I know how to get started in game design,
but I really know how not to waste time in the process.
This seminar is specifically for you if you're interested in 2D game design.
Though, surely, much of what we're going to be discussing today
is applicable to the 3D world, as well.
And you want to create a very clear, or at least
find a very clear, worthwhile, pathway that will help you
in getting that game started.
And you want to make sure you're not wasting your time.
Today, we have three, I guess four objectives today.
First, I'm going to be talking about how to design a small-scope game that
can be created within only 14 days.
These are not massive projects.
These are ones that you could probably use for if you're in a computer science
class.
If you're in CS50, you could probably use this for your final project.
Or another small-scale project that you'd
like to work on with a short turnaround time.
We're going to talk about how to get started
using the LOVE 2D framework to create that 2D game of your initial dreams.
And we're going to end today by talking about the three
landmines of small-scope game design that get in the way of programmers
finishing, game designers finishing.
And a fourth and final objective our time together is I
want to provide some opportunity for you to ask some questions.
That chat box is right down there right now.
And I want to tell you that you can be asking questions throughout.
Many of the questions, though, we're going
to be addressing there at the end of the session, probably
in about 30 or 40 minutes or so.
So with that, I'd like us to jump in to how to design a small-scope game that
can be created within 14 days.
Now, to that chat box, I would like all of you to take a stab at this.
What do you think that scope means, in terms of game design?
What is scope?
And why might that be important?
Just your quick one, two, three word definition is perfectly fine.
If you want to write a paragraph in that chat box, that is fine.
But I probably won't see it in time before I hit the next three slides.
So one, two, or three word definition.
Yeah, "your aim," Maria says.
Thank you, Maria, for that.
"Who will play?"
Cecilia says Connell says, "the entire idea."
And most definitely what scope is--
it's defined as the extent of a player's possible in-game activity.
The extent of the players in-game activity
that is going to create certain restrictions
and demands upon the person that's creating the game.
So I want you to think about the games that you enjoy right now.
I want you to, in your mind, start envisioning
what games have led you to this seminar today.
And as you're thinking about that, I want you to ask yourself,
is this a small-scope game?
A tight game, where, essentially, it can be played within a matter of minutes?
Or is this a massive-scope game, games that can take hundreds of hours to play
and probably took thousands of individuals--
without exaggeration-- years to program.
A lot of those big blockbuster games often can be just like that.
You see, the most common and persistent mistake that game designers can make
is overcommitment to the scope of the game.
Usually, those overcommitments in scope often
come in terms of the features that are in the game,
the artwork of the game, the storyline.
Often, the expanse of the in-game universe that you're creating
can often be places where you or any other game designer
might find themselves overcommitting.
When you think about it, chances are you're on some sort of time frame.
You might be somewhat on your own, just learning
about computer science on your own.
You might be engaged with one of our classes here at CS50.
But a challenge is that you want to do useful things within a useful time
period.
So in your mind right now, I want to budget you.
I want to ask you really directly, how much time
are you willing to invest in this first project into 2D gaming?
Are you willing to invest years in this first project?
Or is this something small, something that you can get your effort behind,
organize your time around?
And so, in your mind right now, consider--
is this a two-week project that I'm working on?
Is this a three or four-week?
Or is this a many month project that I'm working on?
And chances are, if it's your first game,
I would implore you to choose a small time frame, somewhere probably around
14 days, maybe 10 days at most.
The big question that I hope you have on your mind
is, how, then, do I make sure that I'm not
overcommitting to a game scope that's going to exceed my capabilities
and my available time?
Because, indeed, one of the worst things that could happen
is that you get into this project some direction and then you give up
and you walk away.
It's those unfinished ideas that often become like cuts in oneself, where
I have this unfinished project that I didn't bring to fruition,
and, accordingly, I'm less likely to bring my future projects into fruition,
because I started developing this habit of not finishing.
So there are three steps that I'd like to discuss about preventing
that level of overcommitment.
And that first step in making sure you don't overcommit
is taking stock of the game dynamic that is the core of your desire for a game.
Now, you might be asking, well, what is a game dynamic?
A game dynamic is essentially what the basic gameplay is about.
I want you to picture any sport that you might have played recently,
or perhaps as a child.
There are a certain set of dynamics that go
into making a game a game, like catching a ball, or throwing a ball,
or throwing a ball at a target, putting a ball in a hole,
keeping a ball out of a hole, touching your opponent,
running away and not being touched by your opponent,
hiding or finding your opponent, hiding from or finding your opponent,
avoiding an obstacle, amongst many others.
And these are the things that make games fun.
And at the core of every game, there is some sort of core game dynamic.
The authors Romero and Schreiber, in their book,
Challenges for Game Designers, they talk about 10 core game dynamics.
And those core dynamics are quite familiar to if you think about some
of your favorite games, games that involve territorial acquisition,
prediction, spatial reasoning, survival, perhaps is a type of game you really
enjoy playing, destruction, collection-- my Pokémon fans--
chasing or evading, trading, and race to the end
are common core game dynamics that you might be used to.
And so, right now, I want you to start thinking about, what
is my game going to be about?
Could I distill-- could you distill your game down
to one of these 10 core game dynamics?
And so go ahead and go to the chat box when
you think that you have chosen yours as we talk just for a minute about Mario.
So if you think about Mario, the core game dynamic
is mostly avoiding being touched, avoiding being touched.
Now, it just so happens that there is the option
to stomp on top of your enemies.
But in general, Mario is all about not being
touched by these evil characters that are running around the screen.
And for those of you that were exposed to this game as a child,
or even perhaps recently if you have a classic system, in that opening
frame of this game, you're presented with a coin box and a platform
and a Goomba, a little enemy walking towards you.
And chances are in those first moments that you played,
you ran right into that Goomba sideways and you died.
And the game started over again.
So right away, Mario sets up this game dynamic
that there are objects that we can touch and are OK
and other things onscreen that we can touch and they are not OK.
And we are basically on an obstacle course.
It is, in a way, a race to the end game, where the dynamic is don't be touched.
And that makes this game what it is today.
If this game was anything else, if it was territorial acquisition,
this would not be Mario as we know it.
It becomes an entirely different game.
So as you take a look at these game dynamics,
my beautiful people, please go and take one of these
and write down in the chat box, which one do you
think that you are going to be pursuing.
And for those of you that are listening to this on recording,
whether on YouTube or one of our websites, what I would just simply say
is take notes on your side about what we're talking about during this time.
And I'll be cuing you.
As I'm saying to write things down in the chat box,
probably a great thing to write down on your side.
And so lots of-- wow, lots of race to the ends here.
And a few survival people.
And one spatial reasoning.
Really great.
So the second step in making sure that the scope of your game
is just right, probably for about a two-week game,
is to take stock of what you'd like to create.
And, in general, when you're thinking about this,
you would probably think about it in terms of game features.
This becomes a dangerous area for us as game designers
or as programmers, because it can be really tempting when you're
working on your own or in a small team to load up on features as an overcommit
to the number of features that are going to be present in your game.
I want you to think about some really core questions right now.
I want you to think about this game that you're producing.
What is this game about, anyway?
And how does one win the game?
How does one play the game?
What are the basic gameplay rules?
And what are those features that are going
to be in your game that support that core dynamic?
And so linking us to what we were discussing before,
if your game has a core dynamic, a specific purpose for playing
the game, what are the bare number of features
that you would need to accomplish that?
How do you win the game?
And how do you play it?
And it's that, those essential pieces, that
become the start of a very tight game, a game
that you, perhaps, could produce in your limited time.
Now, there are a lot of different game features
that you'd have to pay attention to.
You'd have to ask yourself about the player.
Who is the player?
And how does the player move?
What's the environment in which the player is living?
And are there other characters that that player is going to be interacting with?
A concern that tends to come up rather quick in one's work is the artwork.
And, often, programmers can get distracted in that artwork,
and sort of live there instead of working
on the core dynamic of their game.
The abilities of the characters and the player also become of interest.
The levels in which they are going to be working, the power ups they can get,
and the score that they can get.
These are all pieces about what makes your game unique and yours.
For example, if we think about probably my favorite open-source game,
Endless Sky--
pretty amazing.
This is designed as an open-source game that you
can download right now for free, available on great Steam
applications everywhere.
We have a game where a player is in their own shuttle,
and they're floating in this star system amongst this seemingly endless
universe.
And they're alongside other NPC ships that
are attacking them, or stealing items from them, engaging in trade with them,
drawn with this high-density, professional art.
And every single one of these ships-- enemy ships and the main ship--
are able to expand their capabilities using thousands of different power ups.
And you, with your own whimsy, get to decide where in this universe
you are able to travel.
Hundreds and hundreds of star systems, searching
for power ups, all for the purpose of building
the ultimate fleet of your own.
And you can understand how confusing and how big
this project can get if you're not reigning in each one of those features.
Because, in the end, you could end up with designing a game
that could take hundreds of individuals or thousands of individuals years
to create.
That game might be in your mind, but what is the specific type of game
that you are capable in making in the time frame
that you have available to you?
And so, likewise-- if I can get to my next slide--
that's always interesting.
This is Death by Layers' team.
There we go.
So let's think about game features for a moment.
Let's think about Mario.
So in Mario, we have dozens upon dozens of levels-- just the original Mario.
So you as a game designer, I want you to make some guesses.
Yeah, "the meme broke it," Angela said.
Yep, the meme did break it.
I want you to think about if you were a game designer
and you were creating a game within two weeks,
what will you have to do to make it possible to create something like Mario
in that short amount of time?
Well, you probably the first step that you would take
is you would look at all these levels that you potentially create and you
probably would limit it just down to one.
You would say, given that this is two weeks long,
I'm just going to take only--
of all the different things I could do, I'm just going to create one level.
In fact, just to get started, rather than doing one level,
I'm saying do one frame, one little piece of that giant level.
So that way, I can get the core game dynamic down
and get it working before I expand out to something greater if I have time.
Indeed, rather than having all the different Marios
you could possibly have--
small Mario, big Mario, fire Mario--
you would say, you know what, just for this project for the next two weeks,
just small Mario.
Likewise you think about in Mario there are dozens and dozens
of potential bad guys.
I guess in the original Mario, there's only about a dozen or so characters.
And you would probably just resort down to one.
One single character would be in the game.
And by doing this, what you're essentially
doing is taking all of this what could be and boiling it down, saying,
what is the core game dynamic that I want
to communicate in my game that is possible for me
to produce in this two-week or so time period?
And you think about it--
a finished prototype of this game that you potentially amp up into something
greater is far more effective than an unfinished, massive game
that you attempted but never finish.
So step three, step three of producing a game that is of the correct scope
would be to reduce the game down to that minimal viable product.
And so the way to do that--
when I say minimal viable product I want you to think about
if you are producing something for the marketplace,
what is the minimum product that you could create
that could be viable in and of itself?
One of the big games that I was interacting with early on
was Minecraft.
And you got to think about what makes Minecraft a great game.
For those of you that have played Minecraft, go to that chat box
and tell me, in one or two words, what makes--
I'll give you three, even-- what makes Minecraft a great game?
One, two, or three words.
"Voxels," someone says.
"The freedom you have."
Absolutely.
"Open-endedness creativity, and exploring."
And notice that we just took this game that has loads of features
and we boiled it down to a core dynamic.
And that core dynamic is something around freedom and exploration.
You're able to do something creatively.
What does it take to do that?
I mean, now, of course, Minecraft is completely massive in a way
that I can't even comprehend.
But if you were designing something of that,
imagine the features that would make it in the game
and that wouldn't make it in the game in your two-week time span.
Something you could bring forth to others, present to others,
perhaps even turn in as a final project, maybe even
bring to market as some introductory game, your first game.
But it still has that core, because you knew from the start what that core was.
Just looking at this, this doesn't look like much.
We have a good, green box, we have a bad, red circle, and we have a star.
And it's OK for us to touch the star.
And it's not OK for us to touch that red circle as the green box.
We are the green box.
Notice, it's exactly what Mario is.
It's just like that.
Boiling it down to that essential core dynamic.
And so when you're producing something, I
encourage you to start thinking about, rather than
think about all the thousands or hundreds of features that might end up
in your game, even the dozens of features that might end up
in your game, take that entire list of your greatest desires,
take a piece of paper, fold it in half, and on the left hand side,
put the must-haves, the things that make up your game.
Without them your game does not exist.
And then on the right hand side, put the things that are the nice-to-haves,
the things that you'd like to add on later
that could create an even better game, perhaps
a second version of this great game, but are not the essential core dynamic.
Because if you think about it, you have an opportunity
to create something that in and of itself
is complete and whole, based upon that minimal--
the core game dynamic, or you could create
something that is potentially massive but you just simply don't finish.
So with that, to our third step--
or excuse me, I'd like to talk briefly now about getting started in LOVE 2D,
because that's what a lot of you have come here for today.
So just to give you some background, I want--
for those of you that have prior coding experience,
you can imagine how building a game engine that would run something like
Mario--
that is the physics, the way sprites are drawn on the screen, the way
that levels load, the way memory is handled--
all those things, traditionally, once upon a time were handled in very
low-level programming languages--
C, C++, even C#, of course, many of you touched on now.
And, of course, over time programmers have
had benefited from layers and levels of abstraction
moving away from those languages because--
well, for many reasons.
I suppose a chief reason is, if you think about old games, games,
potentially, that were created either before you were born,
or games, perhaps, in your early life, those games
were produced during a time when there was very limited system resources.
And those resources were exceedingly expensive.
Games like DOOM were created, Wolfenstein were created in C.
And they needed to do that, because one, that was one of the few things
available to them when creating this, but also because they needed
to go as close to the hardware as possible
to pump out as much as they possibly could from that limited and very
expensive hardware.
Well now, because of the popularity of game programming,
there are tools out there that you can use, frameworks,
that allow you to get a quick start at your game work.
Probably my favorite growing up was, oh gosh, was it's not Game Workshop.
Carter, what is that thing called that I'm thinking of?
Not Game Workshop.
What is that framework called?
CARTER: Game Creator?
GUY WHITE: Game Creator, absolutely, was where I got my start, most definitely.
LOVE 2D is another framework that's, absolutely, of course,
we'll be discussing today.
And then Unity is one that's out there and usable by most people today.
And so where you get your start is really up to you.
I want you to go into this by asking yourself, really,
some really fundamental, core questions.
They're almost existential questions of, who am I?
Am I the type of person that wants to design a game in code?
That is, am I a person who wants to iterate through code,
creating functions and code in a coding environment that produces a game,
or am I one that wants to work in a graphical environment
where I can see a lot of these sprites on the screen
as I develop them, move them in a 3D environment, potentially.
That choice, who you are and how you'd like to work,
could really determine which direction you go.
For those of you that are interested in creating
a game without any coding at all, Game Creator
is actually a really fantastic option for you.
For those of you that are really wanting to learn and work
in the coding environment, LOVE 2D is absolutely a fantastic framework.
Unity also.
But Unity is a very graphical environment
and offers you different things.
So as we're talking about these basics, just know that you have a choice.
And the great hope is that if you decide that a tool is not working for you,
you can go find another tool that perhaps functions better,
more in the way that you think about game creation,
and more in line with who you are as a person, as a creator.
So with LOVE 2D, the main dot lua file, which
is the essential file that runs any LOVE program,
has simply three main functions, and that's it.
We have the love.load function, as you see here,
and we have the love.update, and the love.draw.
And as long as those three functions are present in our main dot lua
file, what this will do is this will allow our game to run.
And right now, this is as basic as it gets.
All I'm doing is I'm saying, draw, when we run this program, a rectangle.
And we're going to use a line to draw that.
And what we're going to do is we're going to have
it 100 pixels wide, 100 pixels tall.
And I'm going to put it at position 200, 200
on our screen, which is, from the top left, it's 200 over and 200 down.
And the other functions here, love.load, are the pieces of code
that run only once, once the file is loaded.
And also love.update is what happens as a function of time,
what happens every single moment as a function of time
that we are running through our program, running our program.
And, as you can imagine, this doesn't do much.
As you can see here on our screen, what this does
is it simply just displays a box.
Angela is mentioning Adventure Construction Set,
which is absolutely another interesting tool you should take a look at.
Now, to our second level, what we could do is-- notice what we're doing now.
We're adding some features here.
So in the previous, notice at the bottom where
we started, love.draw, all the way at the bottom of the screen.
What we have is we have the rectangle being drawn,
but this time, rather than telling as hard coding the compiler
to run this with 100 pixels wide and 100 pixels tall, what we're going to do
is, this time, we're going to go up into our love.load function
and we're going to add those as variables there.
And we're doing that for the purpose of the ability
to manipulate those items later.
And as you can see in the love.update, as a function of time
throughout our program as it's running, what
we're going to be listening for using these if statements is,
is the keyboard being pressed?
Is our W, S, A, or D key being pressed?
And depending upon which we press, we're going to take an action.
So in the case of the W, we're withdrawing from the y,
we're moving our object up closer to zero and so on.
So our y up here at our top and our love.load function, is moving up,
and hence, our rectangle is moving, too.
And the opposite being true.
And, of course, using our A and D keys, we can move that box left or right.
Now, as you implement this in LOVE, what you'll find
is an immediate challenge we have is this box can leave the screen.
And it almost infinitely can leave the screen.
I don't know, I have not held down that A key for an hour
to see if it would cause an error, but I know that the box leaves the screen.
And at some point, it takes a great deal of time for it
to come back, if you'd like to.
So what we can do is we can create some, in a way, some collision where
it checks, where it says, are we out, are we
hitting the boundary of our screen?
And so adding, again, another layer of abstraction here.
Rather than just simply having x and y-coordinates, what I might do
is I might create an object called mySquare.
And what I'm now doing is I'm assigning an x-value to it, and a y-value to it,
and a height and a width to it, and so on.
And rather than just simply controlling the x or the y, I'm actually--
or x and y arbitrarily, I'm working with only mySquare's
x and y, as you can see that I changed here in the update function.
And most poignant for this part is this second piece of our code
where we start adding some if statements checking to see
is the x and the y-value of the square moving
outside the bounds of our screen?
And if it does attempt to go outside the bounds,
we're going to push it back just a little bit, not enough for the user
to say, whoa, that's a big jump, but enough just to make it stick there
and prevent it from moving any further.
We're having it bump all the walls, as it were.
And as you can see in the love.draw function,
we are adding that level of abstraction down there, as well.
So what do we have now?
Well, we have a box that appears on the screen.
And we have the ability to move the box around the screen.
And now, we have the ability to keep that box inside.
Now, you could take this small, very small-scale game to a game level
by simply adding something to it.
And the options are almost limitless.
All my team here on the chat box, what is one thing
we could add, in just a couple of words, what's
one thing you could add to this game to potentially, now, make it a full game?
Just one little thing you could add.
So we have a box moving around a screen.
Yeah, we can have a platform, absolutely.
So as Greg says, we could have it on a platform.
And if we step off the platform, it falls.
We could have items to collect, where the box has to move around the screen
and grab items.
Angela says, "something to dodge."
Absolutely.
So notice, just based upon a box on a screen,
how you three just came up with three different games
with three different core dynamics.
What an interesting thing.
So how, then, complicated could you make your game?
How feature-filled could you make your game, then, within two weeks?
And so imagine that.
Imagine where, instead of creating-- just setting out to say,
I'm going to create the next whatever that big game is,
imagine, for one of your first games, that you say,
I'm going to distill something that I think is fun down
to its most essential core dynamic.
And I'm going to implement that.
And if you think about those two sides of the piece of paper I talked about,
the must-haves and the good-to-haves, imagine, then,
within two weeks looking at your side with the must-haves,
accomplishing all those, and then bringing those over, bringing
over the nice-to-haves into the feature list, and saying, OK, now
that I've implemented the core of the game,
what would I like to implement next?
And this is where I bring up my warning about artwork.
I am not blessed artistically.
Many of you are, and congratulations on that.
I might hire you one day.
But for the majority of us that are not artistically blessed,
it can be really distracting to get stuck
in the artwork phase of your project.
And so what I encourage you to do is as your prototyping,
as you're building out your minimal viable product,
try to avoid getting stuck in places that you really
don't need to address at this moment-- artwork being one of them.
Artwork, you can most definitely address later.
But to get the core dynamic working, probably not.
So I'd like to talk to you about the phases, then, of producing a LOVE game.
And this, in a way, speaks back to those existential questions
that we spoke about a moment ago.
One is-- there's the setup phase.
That's where you go to the LOVE2D.org website.
I hope I'm getting that URL right.
And you run the setup there.
You follow the setup instructions.
If you're on the Mac platform, there are some specific terminal-related things
that you'll need to do.
Same thing for the Windows setup as well.
And you get running on your computer.
You know that you finished this phase when you can open a LOVE file
and it will run on your screen.
And they provide some sample LOVE files that you can download,
so that way, you can test your setup to make sure it works.
The next step is really the gut-check phase.
And the main question that I'd like you to ponder as you're engaging in this
is, is this framework right for me?
Is this way of making a game the way that I'd like to make a game?
If the answer is no, that's OK.
Go find a tool that works well for you, a framework that works well for you.
Choose one granular element that is going
to make your game your game, just one little piece, and ask yourself,
is this really what I want to be doing with my time,
implementing this type of thing in this type of way?
GameMaker Studio is open to you, Unity is open to you, Godot is open to you,
LOVE 2D is an amazing tool.
Corona SDK is open up, too.
There's so many different frameworks that are out there, ready for you.
So you have a choice.
And the day to choose that is just a matter--
the time to choose that is just a matter of an hour or two, probably,
into the process of working on the game.
Next is the game dynamic phase.
In this place, you're going to be choosing the core game dynamic,
and you're going to be implementing it there in your game.
And you want to test it.
And you want to get it to a point where you have a playable copy of your game
where you can show other people and have them play it,
and watch how they react to getting the core, the most basic, the must-haves
of your game running.
And then, from there is the MVP phase.
And this is taking it from a prototype that's
playable into something that is, in fact, finished,
something that is releasable, something that-- it might not be the best
release ever, but it's something that you can give to others,
and it's a completed game.
It's something that has a beginning and an ending,
or at least has the potential of being perpetual forever, potentially.
And, finally, there's the feature phase.
And this is where, after you've produced that minimal viable product,
you're adding in more features to make it an even better game.
You're adding menus, you're adding levels,
you're potentially adding power ups. And that way, the material that you're--
that way, what you're putting into the game
is on top of what has already been deemed essential.
Because you've already created a game that accomplishes the goal that you
set forth, that core dynamic, and the features
are something that are going to want to further enhance that core dynamic.
Many of you have played games before where the game was absolutely almost
perfect as is, but then they added a new element to it,
and it actually took away from the game.
And so you'll be doing some soul searching
during this period of your work in LOVE to decide,
is this a feature that really should be implemented now?
The best resources that I can hand you to get started,
flat out, is first of all, is Sheepolution's How to LOVE.
It is, perhaps, the most comprehensive, step-by-step tutorial
that I've ever seen.
What I like about Sheepolution's tutorial
is it gets you to a built game very quickly.
And getting to a built game, building a prototype game
using someone else's instruction is a great way
to familiarize yourself with this framework and what is possible,
what it can possibly do.
And on top of it, to learn about how you can use this,
how you can implement each of the individual pieces that
are discussed there in that tutorial, like
how to implement a different level, and game states, and so on.
Simple Game Tutorials is another amazing one, as well.
What I appreciate about Simple Game Tutorials above all
is you are reimplementing games you already
know about out there in the world.
And so games like Pong are on there where you can reimplement.
Creating a basic pinball machine is one on there as well.
And it's by building from those very basic templates
that you could potentially create your own game as well.
I would be quite remiss if I did not mention
Brenda Romero and Ian Schreiber's book, Challenges for Game Designers.
This book is a huge guide for me in my life, has been very helpful.
Both of these authors have another book about breaking into the game
industry, which is exceptionally good.
But for you, in your stage of creating your first game,
I think this book is probably the best place
to start if you are a book person.
I love listening to YouTube videos, watching YouTube videos,
especially as I'm on the go.
And so Extra Credits is an amazing site.
Many of you have absolutely--
you've been exposed to this before, probably, if you've been on YouTube
and searched game design.
And I, of course, can't think Colton Ogden enough for his work
in CS50's Introduction to Game Design.
I took that class while I was at Harvard Extension.
And it was instrumental in allowing me to produce the games that I've
produced to this date.
And you can access it there at that URL.
However, do know that as you go in, it is a full course.
So don't fall down the rabbit hole too much as you're
creating your two-week-long game.
So lastly, as parting before we get to your questions--
and by the way, this is a great chance for those of you
that are here with us live.
If you have questions for us, please direct them to that chat box
now, as we're engaging in the final moments of our time together.
Because I'd love to answer your questions and just say
thank you to you by name.
So how do you avoid the three landmines of small-scope game design?
And this is for, really, I suppose this applies
for really well seasoned programmers as brand new ones alike.
The first landmine is skipping the prototyping stage.
The prototyping stage is where you create a product--
that is, create a game that is playable--
that implements the most core game dynamic.
And it is not the prettiest thing.
It is not fancy, probably, in any way at all.
But it's playable and allows you to test to see if the core game dynamic works.
This phase is what tells you whether or not your game is going to work.
Taking a stone and dipping it in chocolate
is not going to make it taste better.
It is still a stone dipped in chocolate.
And so, likewise--
I appreciate the smile, Bernie.
Thank you.
So that, likewise, prototyping enables you to see,
is this thing viable in its most core state?
Adding on 16 levels of bad is not going to make it better.
It's still a bad game.
And only you can decide, I suppose, if it's
a bad game or not by your own standard.
And then, you can put it out to others and see is it worth it.
Sometimes, what game designers can do is they can really overcommit to an idea
and they get so far down the production pipeline
that it's almost like, I don't want to turn from this bad idea,
because I've just invested so much into it.
If one had taken just the time even a few hours, just a prototype,
we would have seen if this was a good direction or a bad.
Naturally, the big thing we've been talking about today is over scoping.
That is the second land mine, is producing
a game that's just simply too large, beyond your capability,
potentially, but more about your time than about your capability.
Because capability can always be--
not for an academic course--
but for business pursuits, you can always outsource creativity.
You can always go find great people that can do work with you.
For those of you that are engaging this in an academic environment,
like a class, such as CS50, you might be working
with a partner who might complement your strengths, complement your weaknesses.
But still, if the game is over scoped in terms of time,
that's going to prevent you from finishing this project.
The final landmine is focusing on features over function.
We've been talking about that all the way through here today.
But I really want to hit home that this is the biggest problem that all game
programmers face, is sometimes they can lose sight of what creates
the essential greatness of their game and try to add
features that get away from that core.
And so focus on the minimal viable, the core dynamic of this game
before you go and create a million features on top of that core dynamic.
So it's with that, beautiful team, that I would love to take your questions.
And I see Ezra is asking, "what are some examples of recent games that
have innovative game mechanics?"
Well, first of all, I pose that to everyone here in the chat box.
Anyone here have some innovative game mechanics
that you would like to bring forward?
And as you're typing those out, like games that
have really innovative game mechanics--
one thing that I think is really fascinating, there's a game on LOVE 2D
called Stray, and the game dynamic is it is a boiled-down survival
game, the most boiled-down it can be, but it
looks like you're watching the whole thing on a CRT security monitor.
And I think the game dynamic that works so well in that is it
takes all the things we'd expect of a survival game
and it distills it down to its most essential elements.
And when you take something and you distill
it down like that and your brain fills in the gaps,
because it doesn't have anything extra in it,
that is really fun, a really great game dynamic.
As far as the templates for this, number one
is these slides are going to be released on the CS50 website.
If you're watching this on YouTube, there'll
be a link appearing below that where you can also access those files.
And those templates will be there.
In addition to that, if you're talking about the Simple Games Tutorial,
the link is provided in the slides which you'll also
have access to at the conclusion of our time together today.
So this is our final opportunity for any questions.
If you quickly type, I can surely answer your question.
And so my encouragement for all of you, first
of all, number one, what I want you to do
is I want you to dip your toe into LOVE.
And I want you to gut-check--
is this the framework for me?
Or is there another framework that can potentially
allow you to express yourself more quickly or more in line
with who you are trying to be?
John is saying, "I am self-taught and trying to get a job as soon as I can.
Building a game sounds really fun, but is it
something that many employers want to see
in a portfolio for an entry-level position?"
I would say if it's an entry-level position in game design or game
programming, absolutely.
In fact, I think what, as Romero and Schreiber
both say in their other book, what they're looking for is--
often, employers are looking for are you creating games,
or is this a theoretical idea?
So, yes, spending a week or two and creating a small-scope game,
that could be really beneficial, John.
If you're asking for a general job, whether it's in computer science
and programming or one of those associated fields,
I would say creating something you can show others is really great,
because, often, the people that are hiring in entry-level positions--
I suppose it depends where.
If you're talking about a small company, a mid-sized company that's
not traditionally working in computer science or in those associated fields,
the people hiring you might not be entirely familiar with programming.
So being able to show them something is useful.
For those of you, though, that are looking
for entry-level positions in a technology-related field,
and you're probably going to an employer that's hired many people like you
before, they know exactly what they want to ask you.
Is it an absolute necessity?
No, I don't think so.
But your ability to show the type of work you've
done before, that you can manage your time,
that you can manage workflow, and also answer their coding questions.
And we have a great video, by the way, in CS50 about the coding interview.
I think you should also watch.
You can see that on our YouTube channel.
That could be potentially useful as well.
So my encouragement is yes, create a game.
One to two weeks, you'll have something that you can show.
Let's see here.
Nathaniel is saying, "with all the noise in the gaming environment,
what is the best way to break down the noise
and find a new area to focus on a game?"
Gosh, so many different sources.
I would just go to any source of creativity.
I would say the most creative people aren't necessarily the people that
think the most deepest, necessarily.
I think, often, people that are most creative
are those people that notice things more than other people.
And so what I encourage you to do is, as you're walking,
Nathaniel, throughout your life and your day,
is I want you to notice what interests you.
And if you start noticing things that interest you, certain dynamics in life
or certain things that are happening out in the world today,
see if you could somehow bring that into a game.
Because if it interests you in your life,
surely it can be something that would be interesting to others as well.
If we're talking about game marketing, I am not
the person to ask about game marketing.
But there's a lot of great experts out there
that you can most definitely find.
GDC, the Game Developers Conference, is an excellent resource for marketing
and things of that nature.
And forgive me if I get your name incorrectly, Alercio says,
"can I make larger games with LOVE 2D?"
You absolutely can.
You can take the small game you've already created
and create something big.
You can create large games.
In fact, as you go to LOVE 2D's website, you
can most definitely find other games that have done quite well in the space.
Angela is offering that "people want to hear a good story."
Sometimes.
Many of you know games that tell no story.
There's no story at all.
And that's part of the fun, as you fill it in with what you need.
But there's lots of games that have a great story.
And, Angela, it sounds to me like you love games with a story.
So an interesting point while we're talking
about a minimum viable product, the question becomes, how much of a story
can you tell in that?
If this is a two-week-long game that you're creating,
how much story can go in that?
Is the five paragraph background of the main character going to make it?
Probably not.
You probably only have a few sentences to get across that main idea.
Jonathan's asking, "is there a simpler graphical game design framework
for beginners similar to Scratch?"
Well, Scratch is a great one.
I would take a look at Godot.
I would look at GameMaker Studio are all ones that can get you started,
most definitely.
I'll also offer, Jonathan, that it might not be as difficult as you think.
But if you're looking for a graphical game design tool,
GameMaker Studio, as well as Godot might be ones that are helpful.
Unity also has amazing training available.
The docs are really helpful and wonderful.
Ezra's asking, "what are some key things to keep in mind when designing sound
for a game?"
You know, I'm not a huge--
I'm not a sound expert, but what I would say
is that one is simplicity over anything else.
And if you're looking for someone that is an expert in sound,
I would go find an expert.
Go find someone that's really great in sound design.
You can go on to most musicianal hire websites.
And you'll type in sound design, and there are people
there that you can hire if you're wanting to hire.
If not, go to YouTube and type in "how to design sound for a great game."
There is a great tool--
in fact, this is one of the unexpected things.
That's why I love Q&A. There is a tool out there called BFXR--
like Bob, Frank, X like X-ray, R as in ray--
BFXR.
And this tool is a synthesis tool, like a sound synthesis tool,
and it creates free, usable sound effects for your game.
Like, there's a coin button, and it knows what a coin sounds like,
and it will join, it will hit, it will do a random coin.
If you want a power up, it has power ups there.
And again, I want to think Colton Ogden for pointing that out to me.
BFXR.
So with that, team, I want to say thank you for being here today.
If you want to go deeper in this, I encourage you, first of all,
to check out our offerings here in CS50.
If you're watching this on YouTube, just simply go down below this video
and you're going to see a host of links for you to access.
I would encourage you to delve deep into the next two weeks or so into one
project and not give up on that project unless you're absolutely
sure that it's simply not viable.
And if it isn't, immediately turn around and decide
to create something that's viable and work in that project.
So an absolute honor working with all of you.
And I wish you a great day as you go out and you create the game of your dreams.
Have a great day, team.
Thanks again.