Grapple Go | Sprint 3 | 9/25-10/9

    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 details some of my process working on the game during our Sprint 3.

Demo of Shield Powerup

Challenges & Problems

    I think the biggest challenge I faced this sprint was in the process of refactoring and reworking a lot of my previous code. I spent a good amount of time reworking my player controller and grapple controller, mainly to eliminate the collision tunneling bug I mentioned in my last blog post, as well as the terrain generation system. Ultimately, this lead to much more effective and simpler code, but I found it frustrating how long it took me to get to these optimized versions, and I still feel there's some room for improvement.

    This is a trend I've noticed in a lot of my work: I can produce very high quality material but it takes a very long time and many multiple iterations to get to that idealized state. Two reasons I think attribute to this issue is poor planning at the beginning of a project or task and poor verification after completion. Often times, I'll have an idea for a solution to a problem and begin trying it immediately while putting little thought into whether or not it's actually the best way to go about things or if I may be overcomplicating it or not. This often leads to poorly effective first drafts that need to be iterated on repeatedly. One issue that stems from the same code needing to be constantly iterated and tweaked over a long period of time is oversights where I implement a change but miss a consequence of that change that then breaks established logic. For example, an update to the score calculation resulted in an error failing to reset one part of the score upon run end because I forgot to update that part correctly. Similarly, I feel I'll often test my solution somewhat minimally before shipping it just to make sure it accomplishes the base necessities while ignoring minor issues or oversights that I still end up needing to come back to and address later. Putting off addressing the object tunneling issue in this project is an example of this, and the score calculation error could have been caught earlier with better testing. Overall, I feel that I am spending too much time per task revisiting old code to fix issues or improve efficiency. If possible, I'd like to improve on these areas of my process and better the efficiency of my work, getting to the high quality product faster. Of course, I understand that iteration and practice are necessary for high quality work and the work process, but I feel as though I can definitely improve in areas I don't enjoy as much, and thusly focus on less, to better and quicken my overall process.

Demo of Fixed Touch Inputs

    Another challenge faced this sprint was our first internal playtest, and making the build for it. This was the main first time our team put together our work to be integrated, and it was an interesting experience. The difficulty was exacerbated by our previous switch between Unity versions, leaving one teammate still working in the previous version and having stalled the integration itself, meaning more work had been completed separately without updating each other. Once we'd successfully pushed and updated everyone, integrating each others' work to get ready for the build, we immediately faced an issue where the project failed to build. We believed this error stemmed from past work, specifically in the old version, having utilized some of Unity's old input system which then collided with the new input system used in the rest of the work, throwing an error. Ultimately, we decided to exclude that work from the build for the time being and successfully got a build we could upload to Google Play and playtest. Of course, as time for the playtest came, we discovered another issue: one of the obstacle's collision was broken, exploiting a design oversight that resulted in the player being pushed offscreen during play. This was easily fixed after the fact, but still caused issues and added friction for the playtest.

Demo of Boost Powerup

Work Completed

    As I mentioned, I spent a lot of time in this sprint restructuring old work. I simplified the player and grapple controllers by cutting out the state machines for both of them, almost completely decoupling the grapple from the player. I similarly decoupled the grapple object from the player object inside the scene, which allowed me to change the way I was performing and detecting collisions for the grapple, fixing the object tunneling issue.

    I also reworked the terrain generation, cutting out the object pool in favor of simply destroying and instantiating each chunk. I had implemented the object pool to avoid the heavier processing cost of individually destroying and instantiating anew every single chunk. However, seeing as there are only ever roughly ten chunks in the scene at one time, and new ones are only spawned roughly once per second, I felt this save on cost was not enough to warrant the many issues the object pool introduced in turn, as I discussed in my last blog post.

    Of course, I didn't spend all of my time fixing old code. The main feature I implemented this sprint was the powerup system. I created a flexible system to easily make new powerups and worked out the player's interaction logic. With the powerup system I implemented a shield and invincibility boost powerups. The shield turns on a visual shield model for feedback and allows the player to take an extra hit before the run ends. The invincibility boost similarly turns on a feedback visual and makes the player invincible and much faster for a short duration, essentially giving them a free ride for a few seconds.

Planned Work

    At the start of Sprint 4, I'm planning on spending a lot of time rounding out the final aspects of the MVP and finally implementing the main roguelite elements. Specifically, I have a stat system planned that will form the backbone of the shop system as well as a save system to allow the player to actually carry over game data between play sessions. I've never made any kind of save system like this before so I'm quite excited to figure out something new like this and broaden my skillset. I'm similarly excited to get more into the general systems and backend side of the game, such as saves and settings, as I've mostly worked on core gameplay features or proof of concept demos throughout my career so far.