Project Overview

The M&M Make project is a 2D game that Syntax Terrors created by remembering what some of us created in CSSE2, and made it into a game used for learning.

  • Planned the game’s structure and milestones.
  • Implemented two distinct game levels (including level transitions).
  • Implemented player and NPC classes, created the beta interactions but not the finalized interaction.
  • Reviewed and fixed some of my teammates’ commits when they needed help.
  • Maintained clear and consistent communication with the team throughout development.

Planning and Project Structure

The steps included:

  1. Create a canvas, a way for the game to be drawn. Find a place to have this file located in the repository and start making the base for it .. like the adventure game some of us in CSSE2
  2. What we want to do is have different npcs that the player can talk with. So, we have to create multiple npcs around the map. It is probably a good idea to have the npcs be pretty small, depending on how many steps we want the lesson to be.
  3. maybe have some kind of challenge after 2-3 npcs to make sure that the player understands how to set up the correct steps to make with theme
  4. after finishing the npc interactions and learning, have a finale to the game where the blank m&m takes all the colors that they have collected from each npc to finally make themselves colored !

I created a project board and broke tasks into milestones, making it so that each step builds onto the last until it was finished!

Level Design — GameLevelSummer & GameLevelChocolate

We implemented two game levels that demonstrate different environments and gameplay elements:

  • GameLevelSummer: The level with both the red and orange m&m, where they teach you how to set up your VSCode before starting make
  • GameLevelChocolate: The second and final level where the blue m&m tests the player

Implementation highlights:

  • Encapsulated level logic in classes so levels can be swapped easily.
  • Used a gameEnv object to provide one gameEnv for all levels

Players and NPCs

I authored modular Player and Npc classes to separate concerns between entity behavior and engine systems.

  • Player responsibilities:
    • Collision resolution and interaction with level objects.
    • State machine for animation
  • Npc responsibilities:
    • Basically the same set up as the Player, but they’re completely stationary

Sample snippet showing constructor patterns and composition:

const sprite_src_blank = path + "/images/mm/blankwalking.png";
    const BLANK_SCALE_FACTOR = 6;
    const sprite_data_blank = {
      id: 'Blank M&M',
      greeting: "I need to learn how to makes",
      src: sprite_src_blank,
      SCALE_FACTOR: BLANK_SCALE_FACTOR,
      STEP_FACTOR: 1000,
      ANIMATION_RATE: 25,
      INIT_POSITION: { x: 0, y: height - (height / BLANK_SCALE_FACTOR) },
      pixels: { height: 70, width: 216 },
      orientation: { rows: 2, columns: 6 },
      down: { row: 0, start: 0, columns: 6 },
      downRight: { row: 0, start: 0, columns: 6, rotate: Math.PI / 16 },
      downLeft: { row: 1, start: 0, columns: 6, rotate: -Math.PI / 16 },
      left: { row: 1, start: 0, columns: 6 },
      right: { row: 0, start: 0, columns: 6 },
      up: { row: 0, start: 0, columns: 6 },
      upLeft: { row: 1, start: 0, columns: 6, rotate: Math.PI / 16 },
      upRight: { row: 0, start: 0, columns: 6, rotate: -Math.PI / 16 },
      hitbox: { widthPercentage: 0.45, heightPercentage: 0.2 },
      keypress: { up: 87, left: 65, down: 83, right: 68 } // W, A, S, D
    };

Reviewing and Fixing Teammates’ Commits

One recurring task during the project was reviewing incoming pull requests and fixing issues introduced by teammates (either by accident or because a refactor missed an edge case). I followed this approach:

  1. Run the code locally with the branch checked out and reproduce the bug or failing test.
  2. Read the related commit to understand the intent.
  3. Add targeted unit or integration tests when possible to codify the expected behavior.
  4. Make minimal, well-documented changes and add comments explaining tricky parts.
  5. Communicate changes with a clear summary and a short explanation of the fix.

A few example fixes I performed:

  • Fixed problems when make wasn’t working
  • At times, we struggled to communicated when we’re making changes and that makes it so git pull fails to work
  • When that happened, I learned how to merge the branch manually by typing git --no -rebase or git --rebase in the terminal

Team Communication and Process

Effective communication was crucial. I used the following practices to keep the team aligned:

  • Daily conversations and check ins with teammates, asking what we needed to get done next
  • Clear commit messages and descriptive PR titles.
  • Paired sessions for complex issues — this reduced debugging time and spread knowledge of what we did wrong and how not to do it next time

Lessons Learned & Best Practices

  • Maintain single responsibility principles: components with one focused job are easier to test and refactor.
  • Keep shared mutable state minimized; prefer per-level state objects.

Final takeaway: balancing coding and working on the game with clear communication allowed the team to move quickly and keep the codebase healthy.

Closing

Overall, this project whilst working with this team was very rewarding, and I would love to make another game or project with these people again. There was a bit of a commuication bug, but with all bugs, we quickly fixed it. I learned how to successfully plan something out for a big project such as this one, and I learned how to communicate with others in order to divide the work evenly! In git we trust.