Final Project

Objectives

Create a full game from scratch!

From Start to Finish

It’s time to begin the course’s culmination: your final project! While most of the course thus far has been a series of assignments centered around adding features to existing code bases, this project will take place from the first line of code to the last, a true end-to-end experience to help tie everything we’ve learned together thus far.

Specification

Your game must be written in Lua. Your project must be built and tested using LÖVE 11.5.
Your game must be a cohesive start-to-finish experience for the user; the game should boot up, allow the user to play toward some end goal, and feature a means of quitting the game.
Your game should have at least three GameStates to separate the flow of your game’s user experience, even if it’s as simple as a StartState, a PlayState, and an EndState, though you’re encouraged to implement more as needed to suit a more robust game experience (e.g., a fantasy game with a MenuState or even a separate CombatState).
Your game can be most any genre you’d like, though there needs to be a definitive way of winning (or at least scoring indefinitely) and losing the game, be it against the computer or another player. This can take many forms; some loss conditions could be running out of time in a puzzle game, being slain by monsters in an RPG, and so on, while some winning conditions may be defeating a final boss in an RPG, making it to the end of a series of levels in a platformer, and tallying score in a puzzle game until it becomes impossible to do more.
You are allowed to use external libraries and assets, but the bulk of your game’s logic must be handwritten by you. You are allowed to reuse distribution code and your own written code from Projects 0 through 7 as a backbone for work you choose to do. Reused code, however, does not “count” as you having written anything for the project, for the next item. All imported libraries, music, graphical assets, etc. that did not originate within the course itself must be cited and credited to their original author in your project, whether in code or in the README.
Your project must be more complex than (and distinct from!) the games you’ve implemented in this course. You should expect to be writing more code than you did in any of those, as your baseline. Submissions of low complexity may be rejected outright. Think things through carefully!

The most common cause for failure of the final project is not spending enough effort on this next instruction. Your README.md file should be minimally multiple paragraphs in length, and should provide a relatively comprehensive documentation of what you did and, if applicable, why you did it. Ensure you allocate sufficient time and energy to writing a README.md that you are proud of and that documents your project thoroughly, and that distinguishes this project from others in the course and defends its complexity!

Your project must be at least as complex as (and distinct from!) the games you’ve implemented in this course, and should really be moreso. Submissions of low complexity will be rejected! You must explain your game in detail and why you believe it to meet the complexity and distinctiveness requirement in a README.md file at the root of your project.

How to Submit

When you submit your project, the contents of your games50/projects/2025/x/final branch must generally match the file structure of the other projects in this course. Your branch should also not contain any code from any other projects, only this one. Failure to adhere to this file structure will likely result in your submission being rejected.

By way of a simple example, for this project that means that if the grading staff visits https://github.com/me50/USERNAME/blob/games50/projects/2025/x/final/README.md (where USERNAME is your own GitHub username as provided in the form, below) we should be brought to the README.md file you need to write as part of the specification. If that’s not how your code is organized when you check (e.g., you get a 404 error or don’t see your file), reorganize your repository as needed to match this paradigm.

If you haven’t already, visit this link, log in with your GitHub account, and click Authorize cs50. Then, check the box indicating that you’d like to grant course staff access to your submissions, and click Join course.
Install Git and, optionally, install submit50.
Using Git, push your work to https://github.com/me50/USERNAME.git, where USERNAME is your GitHub username, on a branch called games50/projects/2025/x/pokemon or, if you’ve installed submit50, execute
```
submit50 games50/projects/2025/x/pokemon
```
instead.
Record a screencast, not to exceed 5 minutes in length in which you demonstrate your game’s functionality. Upload that video to YouTube (as unlisted or public, but not private). This video’s requirements are:
- It is not a YouTube “short”.
- The video begins with a slide or text overlay containing both your edX and GitHub usernames.
- It must show your game live and in action. Do not use this video to walk us through any code.
- The video has been uploaded less than one month from the time of your submission of the form for this project (the final step below).
Submit this form.

You can then go to https://cs50.me/cs502d to view your current progress!