Our goal while developing the app was to allow the player to "go wild" at a museum. Usually when we think of an exhibit, we are only allowed to watch, read and listen. We wanted the player to actually play with the exhibit, pick up and toss around objects, while looking for "easter eggs" hidden in the displays. Players were encouraged to pick up and throw everything around, as the cleanup was as simple as a buttonpress. Much faster than cleaning up such a display in real life.

One of the mechanics of the game was of course to pick up objects and toss them around, but we wanted this to also serve a purpose. Around the display we were going to hide stars, which could further unlock new parts of the displays. An example of such an unlock would be rebuilding the cathedral ruins to what it originally looked like.

To keep the displays feeling dynamic and alive, we added a couple NPCs to each of the display tables. These tiny people, or "Tiny Peeps" as we called them, can also be interacted with in the same way as the regular objects around the displays. They would waddle around points on the display tables, randomly picked from a list of preset locations. From tests we noticed players really enjoyed these Tiny Peeps, as they added some lighthearted charm and fun to each of the displays.

The only Tiny Peep that was not directly interactive was the Historian. This sharply dressed gentleman would appear when the player pressed his summon button. He would then tell the history of the display he was summoned to, which the other Tiny Peeps would gather around and listen to.

During this project, I was the project lead, lead game designer and lead programmer.

As this was an exam taking place over 5 days, I tried being as efficient as possible making each display. The first day went to creating a base interactive object which behaved as I wanted, and swap the mesh to the one needed. 

I also programmed the Tiny Peep NPCs wandering around the map, and had to figure out a way to generate paths for the NPCs when potential obstacles could move, be added or be removed during gameplay. The AI uses a nav mesh (navigation mesh) to generate paths to each location given. This nav mesh is usually baked into the walkable terrain before the game starts. As we had these movable objects, I had to regenerate these nav meshes during runtime without eating up all our performance. To make it work, I added a check which happens every second;

Each second the display checks if anything has moved from it's set position. If so, it then bakes a new nav mesh on itself, and records the moved object as no longer on the display. If an object is added back onto the display, the check records it onto the display and bakes a new nav mesh which allows the NPCs to avoid the new obstacle.

I also created a couple ingame interactive buttons which either spawn the historian or resets the display. The buttons were created to be modular, being able to have multiple actions bound to them at the same time if desired. When pressed, the buttons detect each action bound to them, and executes them in the order given.

This project was also an eye opener when it came to optimalization. One of the criteria of the exam was that the application ran at an average of 72 frames per second, or FPS. During the early stages, the app ran at a constant 36FPS, which I had to spend some time fixing. I learned alot more about material shaders, culling, texture sizes and how to use various programs to help optimize models with too high polycount. I also got to experience how inefficient and expensive mesh colliders are, and why they should be avoided.