The Castle is a VR experience that teaches electrical engineering and STEAM learning through immersive virtual problem solving. I implemented functionality for several different learning focused puzzles that teach things like proper and safe use of a multimeter, how to test and check different types of electrical circuits, the basics of Ohm's Law, and other topics related to electrical engineering. I created core systems for realistic electrical circuitry that uses components like fuses, switches, batteries, cables, a functional multimeter and test leads with accurate voltage read outs, and more. I also created a narration system that tracks the location of the player and chooses the nearest intercom box to speak to them through, as well as a dynamic event system to streamline the implementation of new dialog.

 

I am very happy with the VR physics interactions and puzzle implementation that I did for this project using the Unity XR Interaction Toolkit. I set up lever and switch based puzzle with hinge physics that were able to trigger different outcomes based on the position of the handle. I created my own socket system that used scriptable objects to allow you to restrict what type of items can be selected by a socket. We used this to set up different puzzles like a flashlight that can only socket small batteries and a fuse box that can only socket fuses. I also created a custom XR Select Filter that checked how many volts were running through an object and if it was too many it would shock the player instead of allowing them to pick it up when they went to grab it. This in addition to the circuitry systems I created for this project allowed for the rapid prototyping and implementation of new electrical engineering puzzles.

 

One challenge I faced while working on this project had to do with the narration and intercom system I created and the way we were saving large gameplay areas as their own prefabs to allow for multiple developers to work in different parts of the same scene at the same time without merge conflicts. The issue I ran into was that I created the Narrator component as a singleton to allow for one consistent dialog queue to be shared across all intercoms in the scene. This meant that if any object wanted to add a dialog clip to the queue, it needed a cross scene reference that couldn't be saved to the prefab. This slowed down development time whenever someone had to work on adding new dialog clips. To solve this, I learned how to utilize static methods and classes. This allowed for game objects to instead reference the Narrator prefab, which would have a reference to the current Narrator instance in the scene to handle running the dialog queue. This made development noticeably smoother and better organized, as dialog changes could now be save to the gameplay area prefabs instead of the scene.

​

Overall, my major takeaways from this project were improvements to my C# coding style conventions, a better understanding of when to use static classes and methods, a better understanding of when to use interfaces and abstract classes in Unity, and a greater understanding of Unity's XR Interaction Toolkit and how to set up custom filters, interactables, interactors, and more. Working along side other talented Unity developers gave me the opportunity to learn professional code naming rules and style conventions that are used and recommended by Unity, as well as learning new ways to approach problems that I would have done completely different on my own. Lastly, gaining more experience in XR Interaction Toolkit has expanded the way I think about developing for VR, and the wide range of tools and components that are available in Unity.