Sprint 1: See, there's your problem.

     Unity confuses and terrifies me. I like languages without memory management, modern conveniences, garbage collection, and robust libraries exclusively for Game Development. I know; I picked a wonderful major. Chances are I'll never have the need to build a game engine from scratch using C, even if I'd love to walk the path of John Carmack, so, better cope with it and get used to what Unity offers.

    My role for this sprint was primarily setup. Everything has to be a good foundation for the designers; I am taking the responsibility to make sure they don't have to touch a single line of code, and have the capability to change values in a way that's easy to understand and gives them the most flexibility possible. This divides my job into three important tasks:

    - Create legible Inspector code (using headers)

    - Provide console feedback whenever something happens (or goes wrong) for the sake of easily debugging it.

    - Always keeping the code in a runnable state so that nothing has to be debugged by people who don't know how to debug.

Making a JSON reader for rapid changes; no more messing around in code guts.

 

In short, I need everything within the game to be completely understandable and provide decent feedback to designers. This is a tall order, but I owe it to my teammates to ensure that they can do their job as well as possible.

My current focus for the first two sprints has been the movement controller. While I feel bad for spending so much time on it, the movement scheme changed from when we started to when the sprint ended, and I was very proud of myself for learning how to switch action maps to accommodate the needs of our hybrid movement and jump control scheme. Previously, this game was a lot more like golf, where a player wasn't able to move aside from a limited number of strokes. This barely made it a platformer, since the player could not be expected to do any kind of advanced platforming with only six jumps and momentum to carry them through an entire level. So, we decided to include terrestrial movement too. There's just some issues...

Liftoff! Finally launched a ball up in the air.

 

Players need to not be able to move while jumping, and especially not jump again while already in the air (for now). Jumping should also be presented like it's a big deal, it's the part of the game where the most chaos happens, and it should be an event when a player decides it's time to jump. So, we set it up so that there's a change in action maps and camera position whenever the player decides to jump. Once I figure out how Cinemachine works, I'll include code to make the camera pan out and provide a wider view of the gameplay area whenever prompted. Now, we have a multi-stage control scheme that makes the player feel like they're firing a cannon instead of a fruit. It feels good, the hold and launch feels satisfying, and overall I'm very happy with how it turned out.

Still though, I feel like I'm behind compared to other coders. Seeing what other people did on their sprints was a huge kick in the ass, and gave me the drive I need to really improve my game and make something with a much better showing for the next sprint review. While I'm delayed now, I think we have the team required to make this prototype into something special. I absolutely trust Andy and Abigail to make this game work, they're skilled designers and extremely motivated, and I hope their trust in me isn't unfounded. I know we can get this game done and make it look great too.