What an engine vendor's CTO owes studios he will never meet

Our compute bill has two very different shapes. Lighting bakes, asset processing and nightly image tests run around the clock with a floor that barely moves; model training for our animation tools and studio milestone rushes arrive in spikes. I plan the two separately. Before we bought hardware in 2023 we measured twenty-six weeks of demand by workload, hour by hour, and sized our own fleet of 128 GPU servers to the floor rather than the average. Cloud capacity absorbs everything above it. I report cost per useful GPU-hour rather than total spending, because total spending rises whenever customers use the product more, which is good news. The measures our board sees each quarter are floor utilisation, overflow hours, queue time before customer milestones and the remaining depreciation on hardware whose successor is already on sale. Owning has costs a price comparison leaves out, including nine data-centre specialists and firmware we must now patch ourselves.

Studios ship our runtime inside closed-source games on consoles, phones and computers, so a licence obligation we accept becomes theirs. Since 2022 every build produces a software bill of materials, and every dependency carries a licence classification and a named engineering owner. Our policy is simple enough for engineers to apply without a lawyer: permissive licences anywhere; weak copyleft only in tools that run on a developer's machine and never link into a shipped game; strong copyleft never in anything a customer distributes. Exceptions need my approval and our general counsel's, and there have been four. I also watch for licence changes upstream. When a project we depend on moves from an open licence to a source-available one, we decide within a month whether to pin the last open version, fund a community fork or replace it, because drifting into new terms is how a vendor surprises its customers.

Sternhollow Online carries the accounts, matchmaking, lobbies and dedicated game servers for 260 live titles, and its worst days are our customers' best: a launch, a holiday event, a free weekend. I run it on error budgets agreed with product leaders, so that when a service has spent its allowance of unreliability for the quarter, feature releases pause until it recovers. Every incident above a defined severity gets a written review within ten working days, drafted by the engineers closest to it and published internally without names attached to mistakes. We rehearse launches with each studio, including load tests that use the game's own client code, because the retry behaviour of a million clients can do more damage than any single server failure. Availability across 2025 was 99.96 per cent. The number I watch most closely is pages per on-call shift, because tired engineers cause the next incident.

A game engine is unusual software: its users build products on it that take years to finish, and they cannot upgrade in the middle without putting their release at risk. That makes compatibility a commercial commitment rather than an engineering courtesy. I run our architecture on three rules. Public interfaces change only with a dated deprecation notice and a migration path. Every major version has a supported long-term branch that receives security and platform-certification fixes for five years. And no internal rewrite ships until it passes a nightly suite built from 220 customer projects that studios have lent us under agreement. These rules make us slower than a clean rewrite would. They are also part of why our gross subscription retention was 94 per cent in 2025, and why our largest customers trust us with their projects in the first place.

If an attacker altered our build, the change would ship to thousands of studios and through them to millions of players' machines. I therefore treat our build and release pipeline as our most sensitive production system. Since 2024 builds run on short-lived machines destroyed after each job; dependencies are pinned by cryptographic hash and fetched from our own mirror; changes to build configuration need two reviewers; and release signing keys sit in hardware security modules from which no individual can export them. Our runtime binaries are now reproducible: two independent builds from the same source must match byte for byte before we sign. The editor is not there yet. I report on these controls to the Audit and Risk Committee every quarter, including the ones behind plan, and I give far less weight to counts of vulnerabilities found by scanners, which rise and fall with the scanner.

I introduced AI coding assistants as a measured trial, not an announcement. From January to June 2025, 240 engineers used them while comparable teams waited, and we tracked time from first commit to merged change, review effort, changes reverted within thirty days and defects that reached customers. The gains were real and uneven: about 11 per cent faster in editor and tools code, close to nothing in the engine's performance-critical C++. Review effort rose by roughly a fifth and fell mostly on senior engineers. We rolled the tools out to all 620 software engineers in September 2025 on two conditions: no workforce plan assumes a saving, and review capacity is planned explicitly. The tools filter suggestions that closely match public code, and anything written for the shipped runtime passes the same licence and provenance checks as every other contribution.