The Cube - The Drive

3D Drive around the city experience made during my internship at GameLab Oost. I worked alongside 2 engineers and 2 designers. The client for this experience was Silly Productions, an animation studio. The engine used was Unity 3D.

All rights to the game are protected by Saxion University of Applied Sciences, Silly Productions and GameLab Oost. Any distribution of the game is strictly forbidden and may result in legal consequences.

The experience was made for a custom build, called The Cube. It's a 2x2m cube which is used as a simulation tool for people with disabilities so that they can experience a bit of the world as we do. The Cube was made as a collaboration of Silly Productions and Variled, and has been put in many of 's Heeren Loo's villages. The job of us interns was to create an interactive experience, where the users could use the already implemented button system to control a car driving around a city filled with animations and events.

Stakeholders

• Silly Productions
• Variled
• GameLab Oost

People worked with

• Engineer - Enes Etem
• Engineer - Dinand Meijer
  
• Designer - Matias Gomes
• Designer - Maryn Kruithof

My role

In this project my main focus was on tooling and optimization programming. I created the initial waypoint system and car AI, as well as the tooling for waypoints to allow the designers to create any kind of road systems, roundabouts and traffic light crossings. I made the animation event manager which allows for easy implementation of any new animations as well as bug fixing.

Most of my time went towards optimization. The game used four 4k beamers which meant a lot of optimization was needed. There was no creation or deletion of objects so none of the optimization techniques were for memory, but towards CPU and GPU performance optimization. 

The strategies used were:

• CPU timeslicing (cars are updated in 2 batches, as well as walking NPCs)
• Selective static batching (there were a lot of objects with same models so this made it a lot easier)
• GPU instancing (for a lot of models that had same materials)
• Occlusion culling (even though it was an open space, the size of the buildings was enough for the culling to have major effect on performance)
• Hierarchy unparenting (there was a lot of objects in the scene, on runtime most of the objects were unparented for the Unity Job System to work more effectively)

Lastly, another item I've created for this experience was a custom Python installer. We modified the current button system they had by implementing a Arduino board that can communicate with the PC the game is run on. Because we bought the wrong Arduino, the workaround was to create Python code that read the serial input from the Arduino and translated it into input for the PC. With this done, because of the amount of different libraries needed for the Python code to work, I created a Python installer that fetches the latest LTS version, as well as installs all of the necessary libraries and updates them. I made the code customizable so that in case of new libraries, they can be changed with only one line of code.