Sprint 4 Final Review
Live Performance Review
Name: Lucas Masterson
Date: 12-08-2024 / 12-09-2024
Project: Platformer4x
Role: Srum Master of Scrum Masters (Project Manager?)
Overview of contributions
In this cycle, I was responsible for managing the project overall, live updates (integration), bug fixes, and implementing new features in the main production game.
Branching Strategy and Fork Management (I know what I’m doing!)
Branching Approach: I maintained and regularly updated the dedicated branches within our team work (platformer4x-LEAAAAM), designed for general updates.
- Created 4 (5) branches for updates.
- Ensured compatibility by merging upstream changes from the main repository and resolving conflicts.
The Incident
I merged a faulty pull request (that me and my team developed), which brought down the production game ~5 minutes before the end of class. I was, however, able to fix this in a hot-fix and re-added the audio capabilities; I did lose Alex’s commits though. The changes are described in: nighthawkcoders/platformer4x#18. The problematic merge is: nighthawkcoders/platformer4x#17. I had to perform multiple hard resets over 3 branches, the main repository, and merge conflict resolution. Was able to fix it in the end!
Problematic merge:
Hot-fix merge:
Contributions:
Disabled fun facts by default (nighthawkcoders/platformer4x#13)
Hotfix Completed && Audio Capability Added (nighthawkcoders/platformer4x#18)
This one took a while, mainly because I had to navigate through ten bajillion references and tested with a bunch of jank workarounds to get audio to work right, haha. In the end, I was able to locate the playSound()
method under GameEnv
and implement this in our level. I took a few steps to get this working on our level and not apply universally:
- Updated
GameEnv.js
with a couple static methods:loopSound()
andstopAllSounds()
// Play a sound by its ID in a loop
static loopSound(id) {
const sound = document.getElementById(id);
sound.loop = true;
sound.play();
}
// Stop all sounds
static stopAllSounds() {
const sounds = document.getElementsByTagName('audio');
for (let sound of sounds) {
sound.pause();
sound.currentTime = 0;
}
}
- Updated our game level (Winter) to load the music when loading the background (I couldn’t find a better workaround for this)
import Background from './Background.js';
import GameEnv from './GameEnv.js';
export class BackgroundSnow extends Background {
constructor(canvas, image, data) {
super(canvas, image, data);
// Start the background music in loop
GameEnv.loopSound('everlong');
this.parallaxSpeed = 0.3; // Speed for vertical parallax scrolling
}
- And then you just load the sound into
index,md
with an ID.
<!--Audio for music -->
<!--Audio for Everlong by Foo Fighters (Winter) -->
<audio id="everlong" src="/lucas_2025/assets/audio/everlong.mp3" preload="auto"></audio>
Update v0.1.5 (Update v0.1.5 nighthawkcoders/platformer4x#19)
Merged commits from Alex, Aneesh, and Aditya in addition to mine. I added Winter audio (Regicide) to Narwhal level, and updated Winter audio.
A LOT of Co-Authored Commits
Basically what it says; I collaborated and wrote code for all other aspects of our level.
Project Manager
I did quite of organization for our 6 teams and coordinated all the PRs into the main repo. And code reviews… oh my. But yeah, regular management antics.
Movement Tweaking
I was recently informed of a fix made last year by a former CSSE student for the movement of the game. I’ve since implemented this in an experimental fix, and the movement works really nice. Jump is also fixed!! Do be warned, however, that the collisions with the top of platforms is still quite jank. This can be found on the movement
and pong
branches on the platformer4x-LEAAAAM fork.
The Ending
Currently in the works of adding an alternative ending that entails Pong. I’m sure you’ve seen minigames for picking locks in games and such, and I wanted to put this in practice for the platformer4x game. I was originally planning a TLI like game, but couldn’t figure out how. Currently in the works of a Pong minigame.
Overall
I did a bunch of PR reviews, integrations, and work with branches. I helped both of my teammates via Liveshare to complete the features they wanted to add, and distributed the info needed for audio changes on levels. I’d say this was a pretty successful cycle! I’m having quite a bit of fun with GitHub and the work dynamics here! Next “Incident” is probably very imminent.
Reflecting on Sprint 4
Branching
To streamline our development process, we implemented a branch approach within our forked repository (platformer4x-LEAAAAM
). This workflow was crucial for maintaining order and avoiding unnecessary conflicts. The steps were straightforward but critical:
- Create a new branch for each feature or fix.
- Commit incremental changes to that branch.
- Push the branch to our fork.
- Open a pull request (PR) to the fork for review.
- Once approved, make a PR to the main repository for final integration.
Via the CLI (which I do all my GitHub actions through) goes like this:
git checkout -b feature-branch
git add .
git commit -m "message"
git push --set-upstream origin feature-branch
gh pr create --title "Feature description" --body "Detailed description of the feature"
gh pr merge
Divide and conquer!
Code Reviews
For every PR made to the fork and to the main repo, I completed a code review to ensure safety in the code being merged (don’t want another “incident”). I sometimes assigned code reviewers in addition to myself for larger changes, and I would say we kept the code pretty neat.
Merge Conflicts
I hate these. Had to go through a few of these (which was good experience) to learn. Can’t just rebase
:/. Anyhow, I also learned how to perform resets, both hard and soft, and was able to remediate potentially catastrophi commits.
Code Style
Documentation! I’ve always been a strong advocate for documentation, and as such, requested every change to include documentation (sometimes closing PRs if they didn’t include docs). I’ve start adding a lot of documentation to my code, and would like to see others do the same.
Studies?
Game mechanics. I now know how the game functions for the most part, and how OOP plays into this with file exports, imports, etc. This was predominantly done via my experimentation with the GameEnv.playSound()
method, and I was able to teach classmates (viz. my team) how this works (which, arguably, acted as a better learning method for myseof). But yeah, basically just higher understanding of how the code integrates into a whole.
Final Reflection
I would say this Sprint 4 went relatively well for me. I was able to learn (most interesting to me) a bunch of GitHub functionalities + JavaScript OOP (merpp…).