During my second stint at NeonMachine as an SDET, I built a UI-based engagement tracking tool that captured TTK, accuracy, and damage data during live playtests. The tool gave QA a way to validate per-feature balance without needing to manually scrub through replay data — cutting per-feature validation time by roughly 4 hours across 90+ features, saving an estimated 360 hours of testing effort.
This was part of a broader push I made during this contract to reduce bottlenecks — if someone on the team needed a tool or a process to do their job better, I'd rather just build it than wait for it to appear on a roadmap. This contract ran through early access launch, and I supported the product through weekly release testing cycles, surfacing critical issues as they came up.
Shrapnel was shipping with noticeable hitches caused by Pipeline State Object (PSO) cache misses — the GPU stalling while it compiled shaders on the fly. Nobody had dug into it yet, so I took the problem end-to-end: research, implementation, validation, and presenting the case to leadership.
I started by researching the problem through Unreal documentation and community resources, then coordinated the QA team to gather quantitative performance data on the hitches and collect pipeline cache files from test sessions — a process they weren't familiar with, so I walked them through it. I also coached team members on using Unreal Insights for performance profiling, so they could independently capture traces and validate results without needing engineering support.
From there, I wrote a PowerShell script to expand the collected pipeline cache files into a stable shader cache. The documented commands didn't work for our project as-is — UE5's PSO tooling is poorly documented, and I had to dig into it to find the correct parameters for our specific setup. I packaged the expanded cache into a build, had QA re-validate performance, and analyzed the before/after data.
The result: 41% fewer cache misses, 64% lower cost per miss. I wrote up the full analysis — root causes, tradeoffs between different mitigation strategies vs. ignoring the problem — and presented it to leadership so they could make an informed decision on how to proceed.
What can I say about Akiah? Singularly impressive doesn't even begin to cover it. Akiah started as a tester on my team, but it didn't take long for them to prove that... show moreWhat can I say about Akiah? Singularly impressive doesn't even begin to cover it. Akiah started as a tester on my team, but it didn't take long for them to prove that their skills and leadership extended far beyond that role.
Their ability to analyze systems, collaborate cross-discipline, and drive meaningful improvements quickly led to a well-earned promotion as an embedded Senior Tester in the studio. Once embedded, Akiah didn't just meet expectations, they redefined them. They took on additional responsibilities, demonstrated solid coding skills, and created a QA tool that became invaluable to Game Design. This tool leveraged backend playtest data to generate an overlay onto the current game level visualizing every player death: where it occurred, where the fatal shot originated, and the method of death. By providing clear insights into engagement zones, chokepoints, and level flow, Akiah's work gave designers insightful data to help them refine maps and optimize gameplay.
Beyond technical expertise, Akiah has the ability to bridge gaps between teams, QA, Engineering, UI, and Game Design; ensuring that testing isn't just about finding bugs but about elevating the entire game. Any team would be lucky to have them.
show less
I built this tool in Python using Plotly and Dash to help the design team understand what was actually happening in their levels. It overlaid 10,000+ gameplay events onto level geometry with full filtering — you could see where every player death occurred, where the fatal shot came from, and the method of death. Designers used it to identify chokepoints, dead zones, and engagement flow issues that weren't obvious from playtesting alone.
The company-specific data has been scrubbed, but I was given permission to show the anonymized version above ☺️
This project came out of my time embedded as an STE at NeonMachine, working on Shrapnel. I'd started at Lionbridge as a Game Test Associate — top bug reporter on a 20+ person team, 356 confirmed defects — and earned a promotion to Senior Test Engineer within 8 months. Once embedded at the studio, I took on everything from CI/CD pipeline management (Jenkins, Perforce, server launches) to authoring 130+ test suites and 107 pages of documentation. I also supported 3 live service releases and coordinated up to 20 testers during structured test passes.
After supporting three live releases, the team was restructured. I was given the option to move back to Idaho, but I'd grown to like Seattle too much for that 😁
Watch on Youtube: https://youtu.be/KNTVpHT-Xgk
Shrapnel Website: https://www.shrapnel.com
I built this as a prototype to test an alternative approach for enemy detection and objective signaling in Shrapnel. The existing system worked, but I thought a radar-style minimap could give players faster spatial awareness without cluttering the main viewport. I wrote a design proposal, got the go-ahead, and built the prototype in Unreal Blueprints.
The UI in the screenshot is a bit busy because it's running alongside the legacy system for comparison — but it shows the radar in action with enemy positions, objective markers, and directional indicators all feeding through the minimap.
The source files (blueprints, curves, structs, and materials) are available on GitHub. The proprietary gameplay code it references has been stripped out, but the radar system itself is all there.
GitHub: Ill-Satisfaction/Radar-Minimap-UI
Akiah is an incredible programmer, designer and developer. I had the opportunity to work with them for multiple years during their time as a student at Boise State... show moreAkiah is an incredible programmer, designer and developer. I had the opportunity to work with them for multiple years during their time as a student at Boise State University. Akiah has strong leadership skills and did a wonderful job working as a team lead for the Boise State University NASA SUITS team. The NASA SUITS challenge asks students from multiple universities to build an extended reality application to aid in research toward future spacesuit technologies used on the international space station, moon and Mars. Akiah managed a large team of students and tested the team's application in Houston in Spring 2022. Akiah is a strong learner, a team player and an all around wonderful person to work with. Any company would be lucky to work with Akiah.
show less
I spent three years on NASA's SUITS Challenge, building AR navigation and communication tools for future lunar EVA missions. The project used Unity, C#, and MRTK targeting HoloLens 2 and Quest 2. We tested in conditions that broke everything: high-reflectivity sand dunes, volcanic rock, caves with no natural lighting, and low-connectivity environments.
My first year focused on building navigation features in C#. A lot of game-style UI patterns were untested in AR, so we went about testing them. I built a 'Beacons' system and a 'Minimap' — together, they let astronauts see points of interest through terrain and obstacles, with heading and distance, and navigate to them from far away.
After my first year I took over as Team Lead. I grew the team from 6 to 15 members during COVID through targeted outreach, led design discussions to meet NASA challenge requirements, and wrote the majority of a 30-page technical proposal that was accepted by NASA and the Idaho Space Grant Consortium.
We co-published 4 research papers (HCI International, SpaceCHI/MIT Media Lab) and presented and demonstrated the system at Johnson Space Center. We discovered a lot more "it doesn't work"s than "it works"s — but hey, that's research!
The SUITS Challenge team is still operational today — something I'm quietly proud of, given that keeping a student research group alive through COVID was its own kind of engineering challenge. I remember the MRTK 2 to 3 migration throwing us into disarray, and figuring out Git LFS for binary assets being its own adventure 😆
Watch on Youtube: https://youtu.be/X4m33WfXC3w
SUITS Website: nasa.gov/learning-resources/suits
Details about the project go here...
Details about the project go here...
Details about the project go here...
Details about the project go here...
· · ·