Week 12 - Tracking Progress

Okay technically we missed a progress check-in last week, but I've been busy with job search matters so I had to put this project on the back-burner for a little bit. This past milestone has been all about our game's camera: getting it to follow the player, controlling where it can and can't go, and handling transition behaviors.

The good news here is that I learned that Godot has a lot of really nice built in camera functionality. It's got smooth follow, tracking bounds, and even built-in deadzone options.  The bad news is that it turns out I couldn't use most of these features for my purposes and had to write my own camera manager instead. So why is that? The short answer is that the default functionality of the godot camera was at odds with the camera design of Super Metroid. This was mainly evident in two areas: tracking and bounds.

For Camera Tracking, Godot has set up its cameras to use a very common design for side-scrollers known as a deadzone.  The idea is that if you are in the middle of the screen, you can move slightly to the left or right before the camera actually starts moving to follow you. This makes the camera feel more dynamic and more smooth than if it simply always tried to keep the player in the exact center. Super Metroid doesn't do that though, rather the camera moves slightly ahead of the player as they move in a particular direction, moving them to the "back" half of the screen to allow them to see farther forward. This makes sense for a game where your primary attacks are projectiles, as it gives you warning for things ahead of you so that you can better engage at range. For this purpose, I built the camera manager to have the camera track an invisible point that moves in whatever direction the player is going, up to a defined limit in each direction.

For the camera bounds, Godot has some built-in variables that you can set to tell the camera not to pan past a certain point. This works fantastically, the only problem is that if you ever try to change the bounds of the camera, say when going through a screen transition, the camera instantly snaps to be inside of the new bounds rather than transitioning to it smoothly. Technically Metroid's camera deals with this in two different ways depending on the specific trigger. Either the camera will simply do a slide transition to its new desire bounds, or the camera will have a ratchet effect applied to it, where moving closer to the bounds shifts the camera as normal, but trying to move away will have it remain in place. 

As you can see, I got it all working, it simply took a bit longer than expected. Anyway, hope you all enjoy the little primer on camera design. Next up I'll be moving on to real room transitions with all the added fun of scene/asset loading. 

See you next time.