I've held two internships at Ohhh during the summers of 2022 and 2023. During my first internship, I was put onto an existing game project in Unity. I refactored the player character, enemy, weapons, health and damage, level, and game state systems; developed various unique weapons and enemy types; and learned Unity's rigging, IK, and AI tools.
Also in my first internship, I prototyped a first-person virtual art gallery viewer in PlayCanvas. By the time I had come back for my second internship, this prototype had been transformed into a flagship product.
The following is an overview of my work on the art gallery viewer along with lessons learned from development.
During my first internship, the features I implemented included navigating the gallery via joystick or by clicking on the ground, clicking on painting frames to move the user's camera to the painting, and cycling through the paintings. I also did some preliminary work regarding baking lightmaps. Most of my development was driven by a list of features decided at the start of development; and I worked autonomously. The major challenges with this part of the internship were learning Javascript and PlayCanvas.
During my second internship, my tasks were a lot more direct; I worked with another engineer on UI issues off of a kanban. We implemented windows for uploading artwork, editing galleries, and accessing and modifying user profile information. We also handled some of the backend with AWS. The major challenges for the second internship were coming up with a reusable, generic, and extensible architecture for UI elements, and learning AWS.
The following is a sample of the UI elements I implemented during the second internship. My coworker and I implemented some of the backend for these windows in AWS.
Prior to finishing my first internship at Ohhh, I documented much of the art gallery viewer with comments in my code. Upon returning for the second internship, I learned that these comments were not sufficient.
Comments around code are really good for explaining the implementation or purpose of functions or code snippets. However, comments in code do not tell a developer who is unfamiliar with your system how to interface with it, where to start looking at documentation, or what the architecture of your system looks like overall. When all you have is code comments, often the only way to get a grasp of these concepts is by recursively digging through functions and classes and creating a mental map of a system. This is frustrating, error-prone, encourages short-term hacky solutions or redundant functions, and is an enormous waste of time given that there's already an engineer who understands the architecture of the system: the engineer who implemented the system.
After my second internship at Ohhh, when I started working on my Capstone project, Ivorfall, one of the first things I did was write a documentation plugin to put READMEs directly into our Unreal project. The motivation behind these READMEs is that they would be an explicit starting point for engineers and designers who need to understand the systems I write. In other words, these READMEs are an example of centralized documentation.
Though this plugin was promising at first, and initially received positive feedback from a couple teammates, it ultimately did not stick for two reasons. The first is that people don't like reading walls of text. Walls of text take a long time to read, and they "tell" not "show," so they are not as engaging as mediums like images, videos, or interactive demos. The second reason is the maintenance cost of the READMEs. READMEs take a long time to write - especially with the minimalist editor I created for the plugin - so between updating a README and implementing a new feature, engineers are incentivized to go with the latter. This leads to outdated READMEs which are at best uninformative, and at worst spread misinformation.
On Ivorfall, I ended up using tutorial videos as centralized documentation for designers. Though they were also long, time consuming to create, and outside the Unreal project, they seemed to garner more engagement. For documentation for engineers, I did not find a convenient solution. This resulted in many of the previous problems from a lack of centralized documentation popping up once again.
Looking forward, it's evident that documentation needs to be quickly digestible, inexpensive to maintain, and centralized. Perhaps a more involved plugin with automatic visual generation (like UML diagrams) or editor-input recording and playback (to record how to use systems in-engine) is a solution; and I suspect that there exist tools that already handle functionalities like these, or at least parts of these functionalities.