Week 4: Architecture

Hello there!

We are back with a new update on our process. After our presentation last Friday in class, we learned some things about successful structuring of game code, so for this week's blog post, we decided to talk about our findings in the code of Fall into Blue.

In detail, we learned about XR best practices. If you don't know, what that is, check out this for a more detailed explanation. In short, it's a collection of guidelines to help you keep your code easy to read and, by that, helps you to avoid mistakes.
We were very happy to find, that we implemented most of it already. We have different folders to organize the code for separate functions, including a trial folder, that just gives us a space to mess around without potentially messing up the scenes that end up in the game.

We could go a little further and create extra classes for each kind of moving that can occur, like skiing on the ground, in-air-movements etc., but those extra classes might come with some downsides. The extra classes would mean more code that has to be compiled and executed, which might cost performance. Since VR games are already heavy in computation and we are planning to release on a standalone device, that could be noticeable! We'll have to test that thoroughly. On the upside, the extra classes might make changing the code easier in the future. Currently, we make do with the extremely helpful feature of headers and regions in a class, as well as comments. We will definitely keep you posted.

Update: We decided to use Unitiy's event system to create our own custom onGround and inAir Event. Then we put all our different functions into single classes to be more in line with the SOLID principles. The single classes are therefore listening to the single events.

We are also planning to introduce more advanced architectures and design principles, like scriptable object or object pooling for the stuff that we haven't implemented yet, like for e.g. the coin collection or the game manager.