Grapple Go | Sprint 2 | 9/11-9/25

Originally Posted: Sep 28, 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 details some of my process working on the game during our Sprint 3.

Demonstration of Touch Inputs

Differences in the Process

    I think the biggest difference with this project compared to my past ones is that we're developing for mobile, specifically Android, and not simply PC. This, of course, means I need to implement different inputs and be able to test on an actual mobile device. This was the first time I had ever used Unity's simulator to emulate a phone running our game. I also figured out how to hook my phone up to my computer so I can test it on an actual device, which was thankfully a rather simple process. I've actually quite enjoyed learning all these different tools and structures. I feel like I'm really expanding my knowledge base and growing my foundation as a developer and programmer.

Demo of terrain culling

Challenges & Problems

    The largest challenge I faced during the last sprint was getting the build process working for our project, but early this sprint I addressed that problem. As I mentioned in my last blog post, we ended up having to resort to using a newer version of Unity, 6000.2.4f1, but so far it has worked great for us. Instead, this sprint I've run into the issue of my work laptop possibly dying. It's on the older side, and quite beat up, so I believe the battery has begun having issues. I already needed to keep it plugged in while I used it or else it would die in under an hour, but I think that problem has worsened. It's also charging slower, not even accepting the cable I was using previously. This would be awful since it would mean I wouldn't be able to work on the project in class without moving it back down to 2022.3.7f1 seeing as the college lab computers only have that version installed, and we can't install any others. Luckily, I have another spare charger that's working, and it still charges fast enough to not die while plugged in, so I don't think I'm at too high jeopardy, but that's something I'll need to keep my eye on.

    I'm also facing an issue with Unity collision tunneling, which you can see watching closely at either the touch input or terrain generation demos. My grapple object, the white cube, should hit the ceiling at the top of the level and completely stop moving vertically. However, if the grapple stays up there too long, it tunnels up above the ceiling entirely. I am still working on this issue and haven't been able to found any effective fixes online, so I plan to consult my professor at my next opportunity.

Demo of random terrain generation,
recorded during Sprint 3

Work Completed

    During this sprint I worked mainly on rounding out the core functions of the level, aiming towards that minimum viable product as fast as possible. The biggest thing was implementing the random terrain generation. It randomly selects a prefabbed, 10 meter long chunk and spawns it ahead of the player. As part of this I implemented a culling system to automatically delete the chunks behind the player through the use of an object pooling system. This way, chunks can be reused by being set active and inactive so the game doesn't have to go through the more processing intensive method of deleting and instantiating every single chunk. However, I've noticed a few flaws with this method. Because the player simply destroys consumables like coins or enemies upon interacting with them, chunks that include them can't be reused and still have to be destroyed. The way to fix this would most likely require individual object pools for each kind of consumable object, which would be quite complex to implement and likely not worth the effort. The level also isn't actually composed of that many chunks, only about eight or so need to be in the scene at once. This being the case, the object pool is only actually using about eight different chunks at any time, so if the first eight chunks it spawns don't have a decent variation, or we implement more than eight types of chunks in the future, that means the level is highly monotonous and repetitive, excluding whole parts of the level design.

    I also worked on implementing the aforementioned coins and a basic enemy. These were both rather simple, and the with the enemy I made a simple template to create future enemies off of. Lastly, I implemented actual touch inputs. Hold the gray button and the grapple activates.

    Frankly, I feel I am lagging a little behind in the work I've completed these past couple sprints, especially when I compare myself to what I see my classmates have completed. I think I tend to spend too long on individual tasks, usually because I am striving for flawless perfection or because I'm not thorough enough with the basics, like testing, which lead to many issues I have to then resolve later. I really want to work on this and up my efficiency for the next sprints.