Project Requirements

• 💯 Worth:
  • Proposal: 5%
  • Implementation: 25%
• 📅 Due:
  • Proposal: November 29 @ 23:59
  • Implementation Demo: Your demo slot date/time on Moodle.
• 🚫 Penalty: Late submissions lose 10% per day to a maximum of 3 days. Nothing is accepted after 3 days and a grade of 0% will be given.

🎯 Objectives

• Combine everything you’ve learned during this course to create your own video game.

✒️ Description

This is it - the culmination of all the skills and knowledge about game development over this past semester. It’s like fighting the final boss at the end of a game. I know you have everything it takes to conquer it! 😉

This project can be done, at most, in pairs. The project scope should scale with the number of people. In other words, I expect a bigger game with more features from pairs than from individuals. I will try to ensure this as best as possible based on your proposal. No, you do not have to work with someone from your own section.

The game itself is largely up to you - I want you to get creative!

Tip

If you’re having trouble thinking of ideas, try browsing game assets from itch.io and opengameart.org. Sometimes finding a cool asset pack helps spark ideas!

Another strategy is to mash 2 genres together and see if that sparks anything. Maybe you’ll make a 2D side-scrolling platformer with puzzle elements? Maybe you’ll make an endless runner dungeon-crawler with a physics engine?

The sky is the limit!

📐 Proposal

I ask that you go about your design and architecture in a meaningful and purpose-driven way. For this reason, I’m asking you to first write a proposal for your game. This will make you think about the different states, classes, relationships, design patterns, etc. that you will have to adhere to when it comes time for the implementation.

The proposal is due November 29, but this is a soft deadline with no late penalty for submissions after this date. However:

• Submitting BY the deadline: If you submit your proposal on or before the deadline at the top of this page, you will have the opportunity to incorporate my feedback and resubmit continuously until your proposal meets all the requirements for a perfect score (5/5). This ensures your implementation is based on a strong foundation.
• Submitting AFTER the deadline: If you submit your proposal after the deadline at the top of this page, your initial proposal grade will be final. While you won’t be able to improve your proposal grade, you can still use my feedback to refine your approach and ensure your implementation aligns with the project criteria.

Caution

Remember, the longer you delay your proposal, the less time you’ll have to work on your implementation. Submitting early allows you to take full advantage of the iterative feedback process to set yourself up for success in the final implementation phase.

• The proposal document should be the README.md for your repo.

  • Please look in the Sample-Proposal folder of this repo to get an idea of how your proposal should look.
  • If you’re not familiar with writing markdown (.md) then please do this short tutorial. You can also look at any of the README.md files I’ve written for you over the course of this semester for reference.

• The proposal must include the following sections:

  1. Description including the premise, the genre (ex. puzzle/action/adventure/shooter/etc.), the control scheme (ex. mouse to shoot, w a s d to move, spacebar to jump, etc.), and the gameplay.

  2. Requirements about what the player should be able to do in your game.

  3. Diagrams

     • State Diagrams including game states (ex. Breakout) and entity states (ex. Mario or Zelda).

     • Class Diagram where you outline:

       • All (important) classes in your game and the relationships between the classes
       • Inheritance and polymorphism
       • Factory pattern

       Arrows

       Association: X -> Y reads “X has a Y” or “X contains a Y”, and you can use the multiplicity symbols like 0, 1, * (many) to show how many of one thing is contained in another.

       Inheritance: X -|> Y reads “X extends Y” or “X is a Y”.

     • If you’re curious how I do mine, I use Mermaid to write out my diagrams in plaintext and then render them automatically.

     • If you’d rather use a GUI, app.diagrams.net and Lucidchart are good free tools.

  4. Wireframes to give yourself a rough idea of what the game will look like and to give me a preview of what to expect.

     • These can be hand drawn (paper or tablet) or digitally drawn using tools like MSPaint, Photoshop - whatever is easiest for you!
       • If you go hand drawn then please scan in photos of your drawings to include in the proposal document.
     • Here’s a great example video of game wireframes.
     • Here’s a great collaborative tool to create your wireframes. This tutorial shows how to use it for web wireframes, but you can use it for anything.

  5. Assets describing which images, sounds, and fonts you’ll be using for your game and where you’ll get them from.

     • It’s imperative to always cite your sources!

  6. And any other sections you think are relevant to explain the implementation details of your game.

     • Maybe you’re using an external library?
     • Maybe you’re not using canvas/JS and using something else like Godot?
     • Maybe you’re implementing an interesting algorithm?
     • Make sure to explain it all in detail here!

Yes, the final implementation will probably not be 100% accurate based on the proposal, and that’s fine. Things change along the way, that’s just how development works. What’s important is that you start from a place of intentionality and don’t immediately start by writing code. My goal is for you to satisfy all the grading critera!

🔨 Implementation

This is where the fun begins! As I said, the game itself is all up to you, however, I want to see specific elements in your code that show me you’ve progressed as a developer and aren’t writing first-year level code! 🙈

Caution

Depending on the game you decide to make, you may not be able to fulfill all of the requirements just by the very nature of the game itself. If this is the case, come talk to me and we can figure out a compromise.

📃 Requirements

• 🤖 State Machines
  • At the very least, you should have one global state machine that controls the state of the game.
  • The bare minimum for states are TitleScreenState, PlayState, VictoryState, and GameOverState, (you can rename them if you wish) though I expect you’ll have more for your game.
  • As we saw in Mario and Zelda, individual entities can have their own state machines as well.
• 🧱 Inheritance & Polymorphism
  • I want to see good object-oriented practices in your code. As soon as you have different “types” of anything in your game, that’s the telltale sign that you need to use inheritance to define them and polymorphism to control them. So, think of what types of something you can have in your game. In Breakout and Mario, for example, we had types of power-ups. In Angry Birds, we had types of Birds - get the idea?
• 🏭 Factory Design Pattern
  • To create all of the aforementioned “types” of something in your game, a good idea is to stick the creation logic inside its own dedicated Factory class.
  • See EnemyFactory from Zelda or BirdFactory from Angry Birds as an example.
• 🔢 Enums
  • Get rid of any magic numbers or strings from your code using enums.
  • Almost every game we’ve done has had at least some enums so refer to those as an example.
• 🍄 Game Entities & Game Objects
  • Starting from Mario we learned about entities and objects. Usually, entities are more “intelligent” than objects. Entities can interact with objects that are collidable, solid, or consumable. You should know the deal by now!
• 🎯 Collision Detection & Hitboxes
  • Whether it’s AABB, tilemap collision, or using a physics engine, I want to see some form of collision detection in your game.
  • To make your collisions more realistic and interesting, feel free to use the Hitbox library class.
• 💾 Persistence
  • Remember in Breakout where we persisted high scores? I want your game to use persistence as well using local storage. You can save scores, game options, or for full points, even the entire state of your game so that a player can come back and start off where they left!
• 🎉 Win & Loss Conditions
  • The fundamental thing that makes a game a game is the fact that you can win or lose. This should be pretty self-explanatory.
• 🏆 Score/Points/Prizes
  • Maybe your character gains points as they kill enemies, maybe they accumulate a number of wins per round or level, maybe they’re awarded some kind of medal or trophy at the end - who knows! It’s all up to you.
• 👾 Sprites
  • Your game should be nice to look at - no coloured canvas shapes! There is tons of free sprite work you can find online.
  • A lot of the sprites for the games in this course have come from itch.io and opengameart.org.
  • Be sure to provide the proper credit to the creators of the art. This can be done like I did for all the games so far at the top of the main.js files.
• 🏃🏾‍♂️ Animations
  • Give the appearance that your sprites/entities have life by iterating over multiple sprites in a sprite sheet.
  • Use the Animation.js library class to achieve this and go back to the notes if you need a refresher.
• ➡️ Tweens
  • There should be elements in your game whose values need to be changed over a given period of time. These can be things like the Pot position from the Zelda assignment or the Tile elements from Match 3.
  • Use the Timer.js library class to achieve this and go back to the notes if you need a refresher.
• 🎵 Sounds & Music
  • Sounds always adds that extra bit of polish to a game. I want to see sound effects for things like UI element selection, walking, fighting, shooting, jumping, winning, losing, you name it, whatever makes sense for your game!
  • The sounds for the games in this course were largely taken from freesound.org and opengameart.org.
  • Be sure to provide the proper credit to the creators of the sounds! This can be done like I did for all the games so far at the top of all main.js files.
• 🖋️ Fonts
  • Like sounds, fonts also contribute to the polish factor of your game. Have different fonts for your title screen and the various UI elements in the game.
  • I got mine from dafont and Google Fonts.
  • Be sure to provide the proper credit to the creators of the fonts! This can be done like I did for all the games so far at the top of the main.js files.

🫥 Template

The starter template contains the skeleton of every game we’ve done this semester. Mainly, it contains the lib/ files required to build the various components of your game. It’s up to you if you want to use it or not, but I think it’s a useful starting point.

Caution

All the code should be contained in this repo regardless of which game engine you decide to use.

🌿 Git

You can use either the Git CLI or you can also use VSC’s built-in Git GUI client.

🖱️ GUI

1. In VSC, click on the third icon down in the left navigation bar to see a list of files that have changed and are ready to be staged.
2. Hover over where it says Changes (right below the commit textbox) and click + to stage all the modified files to be committed. Alternatively, you can add specific files by clicking the + next to the individual file.
3. Type a commit message into the textbox and click the checkmark above it to commit all the files that were just staged.
4. Click ... and then push to push the commit(s) up to GitHub.

⌨️ CLI

1. Run git status to see a list of files that have changed and are ready to be staged.
2. Run git add . to stage all the modified files to be committed. Alternatively, you can add specific files like this: git add src/Project.js.
3. Run git commit -m "A descriptive message here." (including the quotes) to commit all the files that were just staged.
4. Run git push to push the commit(s) up to GitHub.

Regardless of the method you choose, it is very important that you commit frequently because:

• If you end up breaking your code, it is easy to revert back to a previous commit and start over.
• It provides a useful log of your work so that you (and your teammates if/when you’re on a team) can keep track of the work that was done.

📥 Submission

Once you’ve made your final git push to GitHub, here’s what you have to do to submit:

1. Ensure that the README.md for your repo is the proposal document.
2. Notify me via Teams as soon as you push so that I can take a look and give you the green light to start implementation.
3. Schedule an (online, on Teams) demonstration appointment with me where I’ll be grading your submission on the spot using a grading rubric.
   • Details for how to schedule the demo will be available closer to the deadline. You don’t have to wait until the official slots are available to demo. If you’re done earlier, let me know, and we’ll find a time to demo so you can get this class off your plate and focus on the 42 other things you have to do for school!