This past week has been a tad bit frustrating for Karl and I. We managed to get the NFC tags working in one day, but the victories stopped there. With help from Alberto, we were able to set up networking between the tablet and android phone, with the tablet as the host. However, due to the weak and infrequent network connection, we were unable to sustain the service long enough to do full tests. We also quickly ran into another problem. Our test phone, the Nexus 5, could not keep up with our huge scene. The phone repeatedly overheated, sometimes froze, and was constantly lagging. In order to secure a stable frame rate, we had to delve into mobile optimization.
This is something we really should have looked into before starting to develop an idea and the assets. Knowing the limitations of mobile beforehand would have saved us as a lot of trouble and heartache later on. So yesterday and today, Karl and I made sure to have simple colliders instead of mesh colliders, made basically everything static, and redid assets that were polygon heavy. However, as our lights are triggered by the user, we have to have dynamic lights, which mobile phones are bad at handling. What we can do, however, is paint in the shadows beforehand using images and turn off real time shadows in unity. Additionally, we are using a lot of materials, so now we will simply be using the textures instead.
We have also decided to make a major change to how the game is laid out, which Karl and I will be testing over the weekend to be sure that it is viable design. Right now the KORE lab is a huge space with everything in it all rendering at once, which creates an insane amount of triangles and vertices. Karl did some research and discovered that asynchronous loading could save us in that area. To quote the Unity manual, asynchronous loading "allows you to create a completely streaming world where you constantly load and unload different parts of the world based on the player position, without any hiccups in game play".
Basically, we will be breaking the game up into nine different pieces. Instead of one major room, we would have a small main control room with eight doorways leading to different rooms, all of which are in different scenes. The game only loads the scene the user is in and the one they are headed into. This means fewer assets, scripts, and lights will be loaded at once, which will give us a greater performance boost, and will also let us keep some of our higher polygon models. Additionally, this helps organize the play experience for the user. The first thing they will see is the main UI as well as eight passages guarded by eight different types of crystals. Therefore, they will need to know the crystal first before they can choose a room. This will help guide the user through a more logical game progression, as we give them a place to start. With one huge room, it was a bit like sensory overload.
Karl described it best as a passage tomb, such as Newgrange. So over the weekend Karl and I will be making a small prototype to ensure it works as we hope it will. We will be modeling two separate rooms and fitting them out with all the required models, textures and scripts so we can test the design.
We also had a group meeting with out supervisor, and though we can't get a Vive (awwww), we can get a newer phone such as the Google Pixel or newly released Samsung S8, which both support Google Daydream. Having a newer phone that has been designed with VR in mind will definitely help us with game performance.