Grapple Go | Sprint 5 | 10/23-11/6

     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 5 of our development phase.

Challenges & Problems

Dash Powerup Demo

    This sprint ended up going quite slowly, which I'm rather dissatisfied with; I only completed a few cards, albeit large ones. I think one major cause of this was that I was feeling especially frustrated and even burnt out with the project at this point, which utterly killed my motivation to work on it. I was feeling very frustrated with myself and my work largely because of how frequently I was facing major issues and getting partway through a task only to realize my solution to the problem wouldn't work and then needing to restart. This was happening rather often, and I ended up changing and reiterating things completely multiple times.

    For example, the infinite movement worked previously by keeping the level in place and moving the player, grapple, and camera forward, with a rigidbody component on the player for physics. As I worked on the dash powerup, I couldn't figure out a satisfactory way to keep the camera correctly tracking the player as a physics force was applied, so I decided I needed to change the movement to make the environment move and dash while the player and camera could remain stationary. This swap wasn't too difficult for just the movement, but the complexity jumped up wildly for the dash. If the environment was going to be applied a force for the dash, then it needed a rigidbody and physics. This, of course, caused a myriad of issues with collision and the chunks bouncing off of each other or the player not colliding with obstacles. Eventually, I was able to solve these issues by utilizing layers and excluding collision detection for different layers for different rigidbodies. Additionally, adding velocity and changing the positions of the chunks meant that the way I detected when to spawn a new chunk needed to change as well. While it did work, by the end of it the entire process had been blown far out of proportion, taking far more time and energy than anticipated, and still felt convoluted and confusing in places.

    However, I think I've learned, or at least recalled, a few things to help me remedy this issue more in the future. I think one of the biggest causes for my flawed work process lies in a lack of long term planning for my projects. For Grapple Go, I didn't draw up any class maps or even brainstorm how I would implement each feature at the beginning of the project. While I try my best to think of project cohesion, future proofing, and simplification at the start of a task, I'm immediately limited by simply the lack of time I've spent thinking and brainstorming about the problem. As consequence, I have a tendency to rush into a method or solution as soon as I feel I have a good enough idea without giving enough thought to the details or project cohesion. This in turn leads to oversights and implementing ideas I think are good at the time but have critical flaws revealed later. To supplement this I plan on dedicating time to think about the project in its entirety and cohesion between its parts before I start any work, which I previously neglected. I especially want to work on utilizing class maps to help plan out my code.

Work Completed

    As I mentioned, I got relatively little done this sprint. The first thing I worked on was, of course, the dash powerup. Next though, we had an idea that emerged quite unplanned. While discussing the project and gameplay with a friend, I expressed how I was dissatisfied with the monotony and low responsiveness of the movement: just moving up and down by button press and having to wait for the grapple to reach the top before actually moving. Oftentimes, even if the player saw an obstacle coming, there was simply no physical way to avoid it due to the limitations and slowness of the movement, which was quite frustrating. As it was, this resulted in a meta of simply hovering the grapple near the ceiling so the player could move at any time, markedly simplifying and reducing the gameplay. Hearing this, and playtesting the game for himself, my friend had the novel idea to just change how the movement itself works entirely. Specifically, letting the player move immediately upon input and giving them a bit more freedom on where in the level they could move. This conversation really opened my eyes and spurred me to immediately start brainstorming and prototyping. As one might have surmised, I have a tendency to invest in the ideas and work I've already done and focus my attention on making them better, which can lead me to neglect searching for other, and better, avenues to accomplish my goal. While I had been wanting to change and improve the movement, I was still focusing too much on tweaking what I already had and couldn't think of any good ideas, much less completely changing it. However, talking and sharing my ideas here really opened me to new possibilities and let me be more creative, which has reminded me to reach out to discuss and brainstorm with others more.

    After a short while brainstorming, I had refined the idea of letting the player move by tapping and holding on any position on the screen and then immediately grappling towards that position. This would make the movement much more responsive and dynamic, letting the player move both vertically and horizontally on the screen, shifting the focus a bit more to reaction time than strategic planning. I quickly drew up a prototype that night and showed it to my team the next morning. They all agreed this movement was better and so I immediately began converting the prototype into a polished mechanic. I'm much happier with how the movement works now and think it has majorly improved the gameplay and fun of our game.

    Ironically, letting the player move freely across the screen laterally alleviated the previous issue I'd had with struggling to keep the player in the same position on the screen during the dash. I was able to easily rework the dash back onto the player resulting in much simpler environment logic and colliders.

    Lastly, I worked on an audio system, but wasn't able to complete it until just after the sprint cutoff.

New Movement Demo