Grapple Go Postmortem
Originally Posted: Dec 14, 2025
Grapple Go is the game my team and I are developing for our Mobile Game Development class at Chico State. I hold the role of programmer and my team consists of Justin Culver as producer, James Songchalee as designer, and Sophia Villeneuve as modeler. Our game is a 2D side-scrolling infinite runner, similar to Jetpack Joyride, where the player mainly interacts through the use of a grappling hook to dodge obstacles and enemies. The player's goal is to try and cross as far a distance as they can while racking up their score to be later used to buy upgrades, helping them in their next attempt.
This post is a postmortem of the entire development process across six two-week sprints. Google Play: Grapple-Go
I've learned a lot during this project and I'm quite proud of the work I've done. One thing that worked out well was the constant innovation and improvement of my mechanics and systems. Each Sprint resulted in not just the addition of new features, but improvements made to old ones, both in terms of functionality and gameplay fun. I often revisited old work with new ideas, resulting in a more refined and effective product. The iterations and evolution of the controls and movement are a prime example of this. On the flip side of this, however, is the trap of spending too much time on already completed work and not getting anything new done.
 |
| Demo of movement at the beginning of the project |
While I'm pretty satisfied with the way this project went, there was still plenty of room for improvement. I think one of my biggest mistakes was a lack of overarching, project-wide planning at the start. I didn't create any class maps or similar documentation and always had a very vague idea of how I would implement the next task before starting it. I approached each task on a mostly feature by feature basis, neglecting to think about how they would fit into the overarching architecture beyond a few steps. This led to me building features in isolation and then needing to go back to revise or modify them to integrate them with my new work. While this process also helped refine and improve them, I definitely feel like I spent more time on it than I should or could have.
 |
| Demo of Boost Powerup |
What I Learned
One thing I learned was improved teamwork and the importance of helping direct my team with regards to the coding and in-engine side of the project. I realized my role wasn’t just “a” programmer but the “Lead” Programmer. It wasn’t enough for me to just take my tasks and complete them, with minimal regard for my teammates’ work or processes. Rather, it was my responsibility to help determine what needed to be done and how, what tasks my teammates could help with in my field, and informing them on what they needed to do to keep their work in line with my process and organization, and the overall vision of the game; something especially important in such small, specialized, and interpersonal teams.
 |
| Demo of Save System |
I think this project has grown my programming and development skills quite a lot. Since I did most all of the scripting for the project, I got a lot of practice with all the different components needed to make a game work. This was my first time developing for mobile, so everything in that wheelhouse was entirely new. There were plenty of other details about the Unity engine that I delved into deeper as well, such as the run time execution order and how it interacts with the Unity's event system, configuring individual instances of materials with material property blocks, or Canvas scaling and UI sliders.
 |
| Demo of Pause and Settings Menus |
Comments
Post a Comment