Dev Diary 22: Camera

Currently, the state of Lab 77 is as follows:

  • 135 of 144 bugs have been squashed. Of the remaining nine, three require further work and six require more testing or minor fixes.

  • Artwork, music, sound design and voice overs are being worked on.

  • A demo for the Steam Next Fest is in the works.

Biggest news first: Lab 77 now has a Steam page! Go wishlist it now!

I finally have fixed the camera issues I have had. Annoyingly it was a very simple fix that should not have taken this long for me to find. Essentially, the issue revolved around a value in my CameraMovement script called PosDelta2DX. This value is used to allow the player character a range of free movement in the camera view without having the camera being locked to a position offset from the player position, and it is not ever meant to be more than a value of 2.0. Now, I still don’t fully know how this happened, but under an edge case where the player moved along the direction of a conveyor belt, as in moved left while on a conveyor belt that moves the player left, this value was calculated to 2.1, which stopped the CameraMovement script from calculating the camera’s position.

Now, it is important to understand that it took me over six weeks of testing and trying fixes to finally arrive at a solution. Because the solution was simply this:

As you can see in the above image, the solution was to cap the PosDelta2DX value at 2.0. Additionally, the same must be done with -2.1, capping that at -2.0. Doing that will allow the camera movement to keep calculating itself within the preset parameters, and now Lab 77 has a functioning camera again. Programming can often really be a humbling experience.

This experience does go to show how often the simple solution is the functional one. I spent quite a long time while working on this trying to implement these overly complex solutions such as creating special camera movement conditions for when the player was in contact with the conveyor belt, which only made the movement more stuttered. I also tried to implement camera movement using the Vector3.SmoothDamp() method which also made the movement very stuttered. This sent me down a rabbit hole wondering if I had to re-implement the player movement as I thought the stutter came from the camera oscillating between two instances of the player in one frame.

Of course there are not multiple instances of players in any scene. However, I thought this was something that could happen due to updating the Rigidbody2D component instead of the Transform, or vice versa. Or I thought that the movement being updated in the player controller class was not properly picked up by the camera movement due to the order of execution for event functions. This should of course not be an issue, but Unity being Unity nothing is off the table. Thankfully, I did not have to do any this in the end as that would have been a major undertaking which could have changed the characteristics of the feel of movement in the game. This would have posed an issue for me, as I am very happy with how the movement feels in game.

On a side note, I did have some fun moments in trying various fixes for this bug, one of which resulted in making a specimen rocket ship:

I have applied for Lab 77 to be in the Steam Next Fest: October 2024. This means that I will be making a demo of Lab 77 containing the first 11 levels. This demo will mainly be there to show the gameplay and some other features, but it is important to note that this demo will not show the full polished version of the game. Still, my aim is that the demo will be interesting on its own, which I will be able to do. And hopefully partaking in the Next Fest will steer more eyes towards Lab 77.

Making the demo has thankfully been a very straightforward process. Since I spent a lot of time on the underlying systems, I have been able to easily adapt the demo to include the first 11 levels without having to implement any workarounds or having to solve any other issues. Because of this, I have been able to spend some time on polishing the demo a bit which will help. Goes to show that planning is important when programming, and thinking ahead. This also means that I have had some time to try some different things, such as adding more layers to the background.

I thought this worked quite well, though it’s probably best not to do this with every level as it can get a bit busy. Also, if you want to see a full video of this you can do so here. On a side note, I do post a lot more updates and behind the scenes stuff on the Discord, which is accessible though the Patreon, and I am trying to be better about posting the same things directly to Patreon too. I have gotten into a rhythm of posting to Twitter but adding more places to post updates has somewhat thrown off that rhythm. It is unfortunately not the easiest thing to keep on top of doing effectively three full time jobs at once.

As far as the aforementioned whisky distillation management game goes, things are in a waiting state. I will provide an update when I am able, but it likely will take some time. I have also been playing around with possible ideas for an epilogue for The Story Of E. Rose, but I have not gotten this past the initial idea stage so it likely will not be made for a little while. My focus will still be on the Lab 77 demo.

That is all for this dev diary, more to come in two weeks.

- Olav

Previous
Previous

Dev Diary 23

Next
Next

Dev Diary 21: Steam!