Valve Simulation:
Valve Reset:
These are cinematic renderings of completed courses in our training platform VirtualViking
Constraints
It needs to run on the HTC Vive
It needs to display the basic functionality of a VXR system during activation and reset
A viewer should come away with an understanding of the individual components of a VXR dry system and their significance
A viewer should be able to understand how the components work together to extinguish a fire
A viewer should understand the basic steps taken to reset a VXR system after activation
Successes
When I joined Viking, the VXR courses were the first project assigned to me. The project was already partially complete, which made for an ideal onboarding experience. Well, as ideal as there can be with the little documentation existing for me at the time. The partially completed project allowed me to quickly immerse myself in the existing architecture, understand the established systems, and begin contributing meaningful improvements almost immediately.
Working within an active production environment accelerated my technical growth. Compared to earlier course builds, I significantly refined animation quality, improved interaction timing, and enhanced visual accuracy, creating a more polished and cohesive user experience. Beyond content improvements, I focused on optimizing development workflows by building more intuitive internal tools and streamlining repetitive processes.
These efficiencies not only improved my own productivity but also became standardized practices as the team expanded. By formalizing and sharing these tools and workflows, I helped establish a more scalable and maintainable production pipeline for future developers.
Flaws
Working within an established codebase also presented constraints. Maintaining continuity with previous VXR courses required adhering to architectural and artistic standards that I might not have chosen independently. For example, I would have approached certain creative decisions differently—such as incorporating a stronger establishing shot or refining the environmental lighting to enhance spatial clarity and immersion.
There were also technical conventions that I would have reconsidered. The most glaring example is the widespread use of a single interface across most blueprints. This introduced unnecessary coupling and reduced modularity. However, at this stage in my tenure at Viking, preserving architectural consistency and visual continuity was the higher priority. Refactoring core systems or redefining stylistic direction would have risked introducing regressions and disrupting the established production pipeline.
By prioritizing stability and cohesion over personal preference, I ensured that the final product aligned with existing standards while maintaining reliability. Despite the constraints and tradeoffs, I am proud of the result and the discipline it required to balance improvement with continuity.
Learnings
I have always taken pride in my ability to step into an unfamiliar codebase and quickly understand how its systems interconnect, and this project significantly sharpened those skills. Throughout its completion, I developed more systematic approaches to tracing blueprint dependencies, identifying implicit relationships between systems, and diagnosing bugs within complex visual scripting structures.
Equally important, I strengthened a nondestructive development workflow. Because even small adjustments had the potential to impact established systems, I became more disciplined in isolating changes, validating assumptions, and testing incrementally. This experience reinforced my ability to improve and extend existing software responsibly—enhancing functionality while preserving stability and architectural integrity.