Per-Emil coming back at you with another rant about things and thoughts!

Last week I dived into the realm of shaders so that we would be able add visual variation to our fish and corals without having to create more 3D-models. I’m all for re-usability of assets and trying to make the “most out of the least” so to speak.

Now, shaders are a huge field in game programming and I’ve barely scratched the surface of it - but starting from the bottom and working your way upwards is always the way to go!
Visual effects have always been close to to my heart but it’s only lately that I’ve realized I can actually learn to create them myself.

Here’s a few simple ones:

Every project I’ve worked on for the past year have used different workflows when it comes to version control. There is always gonna be a difference in experience and knowledge when it comes to using git and the multitude of visual interfaces available. I am personally more used to working with SourceTree for even though I’m starting to get the hang of using command line.

When working on a team project, the use of branches is everything. It is so incredibly important to use this feature of git as it will streamline the merge cycle, minimize the risk of losing data and overall make the life easier for everyone you are working with.

If you are working with specific features (which is often the case) then you can use a branch to store your working copy of the whole project and only when the feature is finished and working as intended will it be merged into the collective mainline so to say.

For this project where work has been individual but also required several different workstations (because of the VR-kit being stationary), we decided to set up our git branches to correspond with the different workstations. This way we could be working on both environments, materials, tools and you name it along with specific features such as camera shutter effect, navigation system, or lighting without it bothering the work of others.

Keep your scene hierarchy as organized as possible, this is a very basic folder structure:

What you always want to remember though is keep test-work in a specific folder called sandbox or something along these lines, which contains all working files that is not yet officially part of the project. When you finish something, move it out of “sandbox” to where it belongs and do not leave any dependency files when you are done. The idea behind a sandbox-folder is to keep the project celan and then delete it when you build your game.

The allotted time for this project is starting to near its end and it has really been a fun journey. I will be back later this week with a final wrap-up and we will be uploading the project in its current state in the coming weeks. Until then, buh-bye!
// Per-Emil