Productions

Production 02Downtown Data Center

01 / 08

01 Live-service simulation · CHPC

Internal tool

Downtown Data Center

A live-service Unreal Engine 5 virtual twin of the University of Utah's downtown data center, used by technicians for remote monitoring, debugging and training. I co-owned it as one of two developers, owning feature scope, build releases and stakeholder communication.

Role
Graphic Software Developer (Production and Design)
Team
One of two developers · CHPC, University of Utah
Timeline
Dec 2023 – Jul 2026 (full time and on site from May 2025)
Built with
Unreal Engine 5.3 · Maya · Pixel Streaming · JIRA

I owned

  • Feature scope and build releases.
  • Stakeholder communication with the department.
  • User research, volunteer testing and feedback into releases.
  • Pipeline documentation and onboarding.

I worked with

  • One other developer: a two-person core team.
  • Engineering, for the rack-mapping data and inventory portal.
  • Data center staff, as users and volunteer testers.

Internal use only. The simulation holds sensitive infrastructure data, so there's no public build; this case study shows recordings and screenshots.

Low-poly render of rows of black server racks in a dim data center with a red-lit wall.

02 Ownership

Owning scope, releases and stakeholders

As one of two developers, I owned feature scope, build releases and stakeholder communication. Here is what each looked like.

Feature scope

Prioritized around workflows

Surveyed users to prioritize features around their workflows, and mapped the physical data center to focus on the areas staff rely on most.

Build releases

Tracked in JIRA

Tracked releases and blockers in JIRA, folded volunteer testers' feedback into releases, and fixed live bugs found in observed sessions and usage data.

Stakeholders

Presented to the department

Presented the product to the department and recruited volunteer testers from among the staff who use it.

03 User research

A tool, not a replica

The goal wasn't a photorealistic copy of the data center. It was a clear, functional tool that staff would actually use instead of falling back on older, physical methods.

  • ProblemChecking racks, alerts and jobs relied on physical methods that slowed staff down.
  • What I didSurveyed staff on the metrics they track and how they look for information, mapped the physical data center, and prioritized the areas staff rely on most.
  • What I watchedWhere physical methods slowed people down: clutter, poor visibility and hard-to-spot alerts.
  • ResultTechnicians used it for remote monitoring, debugging and training. Internal use only.

04 Testing and feedback

Testing with the people who use it

  • Presented to the department and recruited volunteer testers.
  • Folded their feedback into releases.
  • Observed user sessions and collected usage data to fix bugs in the live build.

Clarity through design

  • Low-poly environment to cut visual noise and keep performance high.
  • Visually loud alerts that stand out even across the room.
  • Browser delivery so access works on any OS with no installs.

05 Watch

Two builds, about eight months apart

A walkthrough from September 2024 and one from May 2025.

September 2024 May 2025

06 Roadmap

Three migrations to get it into a browser

Technicians shouldn't have to install anything. After evaluating WebGPU, HTML5 export and Pixel Streaming for browser delivery, I planned and sequenced three engine and platform migrations.

  1. Migration 1 · HTML5

    UE 5.3 → 4.23

    I led the migration: moved assets, optimized scenes and built supporting Blueprints to ship an internal HTML5 build.

  2. Migration 2 · Pixel Streaming

    Back to UE 5.3

    Back on 5.3 with Pixel Streaming for browser delivery, once that path proved more scalable.

  3. Migration 3 · Linux

    Rocky Linux 9

    Moved the build to a dedicated Linux server, cross-compiling with Clang and fixing the toolchain errors that came with it.

07 Documentation and onboarding

Making it repeatable

I replaced 200+ one-off server Blueprints with one data-driven pipeline, and wrote the guide new hires use to add servers on their own.

  • Wrote pipeline documentation for onboarding, and mentored new team members.
  • Tested the engineering team's rack-mapping data and caught overlaps and mismatches with the floor.
  • Reused assets from an earlier 3D touring project to move faster.

08 Production complete

← Back to productions