The Stadium Project was a VR football experience that I developed independently from the initial prototype through to the full application.
I was provided with fully designed screens and an initial concept, then had responsibility for turning those designs into a working VR experience.
I was provided with fully designed screens and an initial concept, then had responsibility for turning those designs into a working VR experience.
The Prototype
I started by creating a rapid prototype using mostly built-in Unity systems, including Timeline, animation, triggers and XR Interaction Toolkit.
For the prototype, content was intentionally built directly into the application. This allowed me to concentrate on the experience and quickly iterate based on client feedback.
I also had creative freedom over parts of the presentation. One example was the introductory sequence, where I created a spline and Trail Renderer effect to introduce the experience. The client particularly liked this effect, and it became part of the final presentation.
The prototype successfully demonstrated the concept and led to the project progressing into development of the full application.
The Environment
As part of the development, I investigated several approaches for representing a football stadium in VR.
I prototyped varied levels of detail, working my way through the following ideas.
I prototyped varied levels of detail, working my way through the following ideas.
· Fully 3D pitch and stadium environments
· Baked lighting
· 3D skybox environments
· Textured stadium backgrounds
· Mixed 3D ground with a skybox stadium
The aim was to find an approach that provided the right balance between visual quality and Quest performance. At one point I offered a simple interactive football on the full 3d pitch, but unfortunately due to performance constraints on the stadium model we had this had to be dropped in favour of a lightweight 6 sided skybox environment.
Full Application
The full application required a significant change from the prototype architecture.
The prototype had used a relatively simple Timeline-driven flow. The full application needed to support a much more flexible sequence of experiences, so I rebuilt the core application flow around a non-static asynchronous state machine.
This allowed different parts of the experience to load and transition independently rather than relying on one large Timeline controlling the application.
The prototype had used a relatively simple Timeline-driven flow. The full application needed to support a much more flexible sequence of experiences, so I rebuilt the core application flow around a non-static asynchronous state machine.
This allowed different parts of the experience to load and transition independently rather than relying on one large Timeline controlling the application.
CMS integration
The final application also needed to support content downloaded from a custom CMS. The CMS was being developed at the same time as the Unity application, which meant the final API and content structure were still changing during development.
Rather than waiting for the CMS to be finished, I designed an interim system that used local copies of the expected content and emulated the CMS endpoints.
This allowed development and testing to continue against an API structure that could later be replaced with the real CMS, while keeping changes to the application itself relatively small.
Rather than waiting for the CMS to be finished, I designed an interim system that used local copies of the expected content and emulated the CMS endpoints.
This allowed development and testing to continue against an API structure that could later be replaced with the real CMS, while keeping changes to the application itself relatively small.
Building for Quest
The application was designed around standalone VR hardware, so performance was an important part of development.
I worked with Quest-specific rendering and content considerations, including:
· Optimising scene complexity
· Investigating different environment rendering approaches
· Managing 360° media
· Addressables and asynchronous content loading
· Offline content handling
· Quest 3 rendering and performance testing
The final architecture allowed the same application to move from a fixed-content prototype to a more flexible, content-driven VR application without rebuilding the project from scratch.
I worked with Quest-specific rendering and content considerations, including:
· Optimising scene complexity
· Investigating different environment rendering approaches
· Managing 360° media
· Addressables and asynchronous content loading
· Offline content handling
· Quest 3 rendering and performance testing
The final architecture allowed the same application to move from a fixed-content prototype to a more flexible, content-driven VR application without rebuilding the project from scratch.
