Grapple Go | Sprint 4 | 10/9-10/23

    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 Sprint 4 of our development phase

Shop Demo

Challenges & Problems

    For this sprint, I didn't actually encounter too many challenges or issues with my work. Instead, however, I got sick for a little under a week, which made it way harder to focus on and complete my work for much of the sprint. This definitely led to me not completing as much work as I'd have liked. With that being the case, I'm also quite satisfied with the things I did get done, and I think I've delivered a little on the goal I set last sprint to try to produce higher quality work more efficiently and thoughtfully.

    One technical issue I did encounter this sprint was a g
ame breaking bug found during our first Alpha playtest, consequently making the playtest that much more difficult. The most consistent time I found it occurred was when the player died while activating the grapple, which I assume led to an event order error. The grapple is reset as soon as the player dies, but I think that there was a tiny moment where the grapple detected the input after the player has already died, and reset the grapple, consequently activating a flag on the grapple improperly and breaking it. This was an easy fix, just also resetting the grapple at the start of a run, but I'm still not certain that the cause I determined and addressed was the only one; I still need to test it more thoroughly. This issue re-highlighted a flaw in my work process once more for me: my hasty testing. I was only ever able to recreate the bug on a mobile device, my phone, but never with Unity's simulator on my desktop, which I of course spent most of my personal testing time on. This has hammered into me again the importance of thorough and patient testing of features which I think I'll be practicing for a while.

Save Demo

    Another challenge I've been dealing with has been my uncertainty with estimating point totals for my tasks. The way our project is organized, through Agile SCRUM, delineates tasks as either one or three points. A one point task should take no more than one day, or eight hours', worth of work, and a three point task should be any task that takes more than one day's worth of work, but no more than three days, or 24 hours. The issue I've been having is that I feel unsure of whether or not the tasks I'm undertaking should be categorized as three points or only one. I've been categorizing most all of them as one point so far, which I believe is technically correct in terms of the literal minutes I'm spending on them. However, there are cases where I feel the challenge or complexity of a task could potentially warrant three points, or even that I'm sometimes simply underestimating the amount of time I spend and some tasks are actually surpassing eight hours. The main reason I find myself struggling with this is when I compare myself and my workload to others in my class, I usually find myself behind in point totals, sometimes even when the amount of work feels comparable. I'm curious to the way others are designating their tasks and assigning points to them, and if my current process needs revision. The points are supposed to serve as a representation of the entire project's size and progress, so I'm unsure of how much I should be basing my decisions on personal circumstances as opposed to more objective or standardized measures. This is something I think largely will only improve with experience, but I find it quite frustrating now while I'm still dealing with it.

Platforms Demo

Work Completed

    As I mentioned, I didn't complete as much work this sprint as I'd of liked, but I am quite satisfied with what I did complete. The first thing I did was implement a simple stat system to build the upgrade shop off of. The current stats include things like climbing speed for the grapple and player and durations for the powerups. 

    Next, I worked on the shop itself. I blocked out all of the basic upgrades the player will be able to purchase and implemented the system to actually buy and use those upgrades. Currently, the UI doesn't scale to the size of the player's screen correctly. UI scaling is something I've not fully understood in Unity for a while, so I'm planning on visiting my professor for help with this right at the start of next sprint so I can really make sure I get it. In fact, I had planned to do so during the middle of this sprint, but got sick right before I could. As of right now, the shop does still have room for improvement. The upgrades all increase completely linearly; each upgrade improves by the
exact same amount and costs the exact same amount, which could be updated to enable exponential or similarly curved costs or returns.

Turret Enemy Demo

    The last major task I completed was the save system, which ended up being far simpler than I had expected going in. It works by storing all the saved data in a struct that is then serialized into a text file via JSON utility that can then be read to load the data. Right now, all the stats are saved inside the GameManager, but the system is quite easily expandable if we wanted to save data from any other object. The shop, for example.

    I implemented a platform for level design that the player will die if they run into the side of, but still allows them to run on or grapple onto. Lastly, I created a stationary turret enemy that will fire obstacles in the player's direction.

Planned Work

    At the start of Sprint 5, we've completed our core gameplay loop and minimal viable product. Now, I'm planning on finishing up the last of the core planned features, such as the last three powerups and audio triggers, before focusing on polishing and bug fixing.