Welcome back! :D Week 2 of ‘writing Devlogs that our team has literally no time to do but I nagged them so much they gave me what I wanted just to shut me up’!

On this week’s episode we have Filippo’s Guide to Changing a Lightbulb!

Not as easy as it sounds, since what he did was more akin to changing the foundations of a house while the house was in-use, but lightbulbs sound less scary :D

The Issue: The lighting system in Metavoidal basically became a badly constructed trifle at Christmas lunch as development went on; none of the layers are where they should to be, no-one is happy about it, and it just looked ugly.

Since the start of development we’ve used custom lighting, camera & post processing effects, and shaders to achieve even the most basic visual results in-game.

This approach, however, became extremely limiting as time went on, especially due to the extremely high amount of cameras rendering layers on top of one another, which came at both a performance, and visual fidelity cost.

Bugs started cropping up, like doors rendering in front of every other element, lighting looking flat and non-dynamic, and shadows coming out at a much lower resolution than the target rendering resolution of the game.

(That trifle metaphor is starting to make more sense now, huh?)

The Solution: Start over! No wait, that can’t be right…

After analyzing our options, which ranged from fixing the bugs in the current system all the way to re-making the rendering systems entirely, we ultimately decided it would be best to change the rendering pipeline to something already available; Unity’s URP. (More on this later!)

This pipeline would allow us more rendering flexibility, and more options to base our systems on, while also providing a good framework for making said systems better. And it gives us the ability to add things like a post-processing stack with much greater ease than coding everything from scratch months into development.

We settled on switching our entire game’s lighting system to Unity’s Universal Render Pipeline (URP), which meant essentially ripping out parts of the foundation of the game and replacing it with something completely new.

While also hoping that the new bits we added will play well with the rest of the already-built house.

No pressure? :D

The hurdle: Not breaking everything we touch.

Even though this approach would help us avoid future bugs and speed up development as the project continues, changing the rendering pipeline mid-project is extremely challenging due to how the previous rendering systems were intertwined with our game code. (<Foundation of a house analogy here>)

Another issue is the fact that working on a large-scale fundamental change while allowing the rest of the team to work on other aspects of the game without breaking the development flow can be challenging, as the switch needs to happen quickly to avoid weird conflicts and stop bugs from occurring.

Kind of like when Indiana Jones did the old switcheroo but with less certain doom. You have to do the switch fast enough to not disrupt workflow, but also well enough that a giant boulder made of the crushing weight of your failure doesn’t come after you somewhere down the line.

The Takeaway: Plan everything in advance. Everything.

And not just mechanics and systems. Plan down to the smallest visual details so that you can make the best decisions from the start, instead of having to rework the base framework of the game very late in development.

We give this experience 0/10, would not recommend. But hey! At least it can be done?

Thanks for reading! Keep an eye out for the next devlog guide coming out soon. I think that one involves the infamous in-game UI >.>

As always, you can find us on most platforms @YellowLabGames. We’d love to show you all the stuff we’ve been working on!