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.