‘We would rather eat rocks and drink gasoline than be split up’: Compulsion Games has completed its buyout from Xbox

When a studio declares it would "rather eat rocks and drink gasoline than be split up," it isn't just expressing loyalty it's describing a real engineering risk: the destruction of tacit knowledge, the fragmentation of a shipping team. And the collapse of a codebase that only that group understands.

Compulsion Games, the Montreal-based developer behind We Happy Few and the upcoming South of Midnight, has completed its buyout from Xbox. The studio now owns all of its intellectual property. For most headlines, that's a business story. For senior engineers and technical leaders, it's a case study in platform dependency, IP sovereignty. And the messy work of decoupling software organizations. The split matters because the real value of a game studio isn't just its franchises it's the build pipelines, asset libraries, telemetry schemas. And live-service infrastructure that make those franchises repeatable.

What the Compulsion Games Buyout Means for Engineering Sovereignty

Most coverage of the Compulsion Games buyout frames it as a financial transaction. That misses the technical layer. When a studio regains full ownership of its IP, it also regains control over source code repositories, build configurations, art asset pipelines. And backend service ownership, and those aren't legal abstractionsthey're the systems that determine whether the studio can ship a patch on a Tuesday night without asking a parent company for credentials.

In production environments, we have seen this pattern repeatedly. A startup is acquired, its GitHub org is moved under the acquirer's enterprise account. And within eighteen months the acquired team has lost admin rights to its own CI/CD runners. The code still "belongs" to the team in spirit. But in practice they can't rotate secrets, change build agents. Or patch dependencies without tickets and approvals, and engineering sovereignty erodes long before anyone noticesThe Compulsion Games buyout is essentially a reversal of that process.

The deal also highlights a distinction that technical leaders should tattoo on their whiteboards: owning the IP isn't the same as owning the toolchain. A studio can own every line of South of Midnight and still be stuck using the parent company's Perforce depot, Azure DevOps pools. And Xbox Live multiplayer services. True independence requires both legal ownership and architectural portability. Compulsion now has the chance to design for the latter.

How the 2018 Acquisition Created a Platform Dependency Trap

Microsoft acquired Compulsion Games in 2018, adding it to a portfolio that eventually became Xbox Game Studios. At the time, the move looked like platform consolidation. Compulsion gained access to Microsoft's publishing muscle, funding, and platform integrations. In exchange, it became part of an ecosystem whose services were designed to bind studios together.

That binding is the dependency trap. When a studio builds on Xbox Live, it adopts identity systems - achievement APIs, cloud save infrastructure, multiplayer session Management. And telemetry contracts that are owned by the platform. These aren't bad technologies, and they're good technologies with high switching costsMoving off them is like refactoring a monolith into microservices while the monolith is serving live traffic. Every external API call is a seam that must be redefined, retested,, and and redeployed

For South of Midnight, this meant Compulsion was likely developing against Xbox-specific services while also planning multi-platform releases on Steam and PlayStation. The engineering challenge isn't unique to games. We see the same friction when a SaaS company acquired by Salesforce tries to maintain a standalone AWS stack. Or when a mobile app absorbed into a larger portfolio discovers it has hard-coded the parent company's OAuth 2. 0 provider and analytics endpoints, and the parent platform becomes implicit architecture

IP Ownership Is an Architectural Decision, Not Just a Legal One

Lawyers care about IP because it determines who can sell the game, license the characters. And sue for infringement. Engineers should care about IP because it determines who controls the artifacts that make the game run. Source code, shader graphs, animation rigs, dialogue trees - network protocols. And save-file formats are all expressions of the same intellectual property. If a studio doesn't own them completely, it can't port, patch. Or extend them freely,

One concrete example is save-game compatibilityIf South of Midnight shipped with cloud saves tied to Xbox Live, the schema for those saves may include Xbox-specific metadata, encryption keys. Or blob storage references. After the buyout, Compulsion must decide whether to migrate historical saves, reset player progress,, and or maintain a compatibility shimEach option has engineering cost and player trust implications. We faced a similar problem during a client engagement where a mobile app's user profiles were stored in the acquirer's Firebase project; the divorce required a twelve-month data migration and a custom encryption re-keying process.

IP ownership also affects third-party licensing. Game engines, middleware, audio plugins, and font libraries often have license terms that change based on company size, revenue. Or platform. Under Microsoft, Compulsion may have benefited from enterprise-wide Unreal Engine 5 licensing or volume discounts on tools like Autodesk Maya and Substance. As an independent studio, those contracts must be renegotiated. The technical stack doesn't change overnight. But the legal and financial wrappers around it do.

Engine Portability and Reducing Vendor Lock-In After a Spinoff

South of Midnight is built on Unreal Engine 5, which is a smart portability choice. Unlike a fully custom engine, Unreal provides a stable abstraction layer across Windows, Xbox, PlayStation. And PC. That reduces the cost of multi-platform deployment after a spinoff. However, engine choice is only one layer of lock-in. The real coupling often sits in platform-specific plugins, authentication modules. And backend integrations.

To reduce vendor lock-in, engineering teams should treat platform integrations as thin adapters around a core game loop. In Unreal, that means isolating Xbox Live, Steam. Or PlayStation Network calls into plugin modules rather than scattering them through gameplay code. It means using Unreal Engine's Online Subsystem as an interface, not as the implementation. When a studio owns its own account system or uses a portable identity provider, it can move between publishers with far less trauma.

Containerization and infrastructure-as-code also help. A studio that defines its build farm in Terraform or Pulumi can recreate it under a new cloud account in hours rather than months. A studio whose build agents are manually configured Windows boxes in the parent's data center faces a much harder migration. In our experience, the studios that survive spinoffs cleanly are the ones that treated their toolchain like a product from day one: versioned, documented, and runnable by someone who joined last week.

CI/CD Pipelines and Build Infrastructure Must Survive Divorce

Game builds are some of the most complex artifacts in software. A modern AAA-style project can involve hundreds of gigabytes of assets, custom editor tools, platform-specific SDKs. And deterministic cooking processes. If the CI/CD pipeline lives inside the parent's Azure DevOps tenant or relies on the parent's Perforce depot, a buyout can halt development until the pipeline is rebuilt.

The technical separation work likely involved migrating repositories, re-creating build agents, re-establishing code signing certificates, and reconfiguring artifact storage. Code signing is especially delicate. A studio that loses access to its original certificate can't ship trusted binaries unless it re-keys. Which triggers anti-cheat and platform-distribution warnings. For live games, this is a single point of failure that most teams ignore until it becomes urgent.

Best practice here is to use independent source control, isolated CI/CD runners. And secrets management that the studio controls. GitHub Actions - GitLab CI, or self-hosted Jenkins can run on infrastructure the studio owns. Certificate chains and signing keys should be stored in hardware security modules or dedicated secret stores such as HashiCorp Vault or AWS Secrets Manager, not in a shared parent account. If your team is evaluating an acquisition, demand a prenup for your build system. DevOps and CI/CD consulting can help you design pipelines that survive organizational change,

Telemetry, Live Services,And Data Portability Under New Ownership

Modern games are live services. Even single-player titles collect telemetry, crash reports, performance metrics,, and and player behavior dataUnder Xbox, Compulsion's telemetry probably flowed into Microsoft's internal analytics stack, whether that's Azure Data Explorer, Power BI. Or a custom data lake. After the buyout, the studio must decide whether to keep feeding data into a former parent's systems or To Build It own observability plane.

Data portability isn't just an engineering preference. In jurisdictions covered by GDPR, Article 20 grants data subjects a right to data portability. And Article 17 grants a right to erasure. If player data is entangled with Microsoft's broader Xbox player graph, extracting Compulsion-specific records without violating privacy law becomes a non-trivial data engineering task. We have seen migrations stall for months because no one documented which tables contained PII or how consent flags were encoded.

Observability stacks should be treated the same way. Tools like Sentry, Datadog, Splunk, or Grafana are powerful. But they should be tied to accounts the studio controls. Log ingestion endpoints, dashboard definitions, and alert routing should be exportable. In a spinoff, the difference between a smooth transition and a blind flight is often whether the team can still see production health in real time. If you're building a live-service game, mobile and backend observability services can help you own your telemetry pipeline from the start.

The Human Factor: Why Teams Refuse to Be Split Up

The "rocks and gasoline" quote is memorable because it's rare. Most acquisitions treat teams as cost centers to be optimized. Studios are merged, duplicated roles are eliminated, and key contributors leave. Compulsion's public declaration that it would rather suffer than be divided is a statement about team cohesion as a technical asset.

In software, this is the bus factor and the knowledge-silo problem dressed in emotional language. A shipping team holds enormous tacit knowledge: why a specific asset cooking setting exists. Which build flags are safe to toggle, how the narrative scripting layer handles edge cases. Split the team and you split the runtime understanding of the codebase. And the result is not just slower developmentit's a higher defect rate, longer incident response times. And a loss of architectural coherence.

Engineering leaders can protect against this by investing in documentation, runbooks, architecture decision records, and pair programming. But no documentation fully replaces a stable team. Compulsion's choice to stay together is a decision to preserve its collective working memory that's worth more than any single IP filing. For long-running projects, we have found that teams with low turnover can ship patches an order of magnitude faster than teams rebuilt from contractors and new hires.

What This Signals About Xbox's Platform Strategy

Xbox allowing Compulsion to buy itself back is part of a larger recalibration. After years of acquiring studios to feed Game Pass, Microsoft is now trimming its first-party portfolio and allowing studios to go independent. The strategic message is that Xbox is becoming more selective about which teams it owns and which teams it simply publishes or partners with.

For engineers, this is a reminder that platform owners aren't permanent fixtures. A company that funds your studio today may divest it tomorrow. And that has implications for technology choicesIf you design your game around first-party services that only Xbox provides, you're implicitly betting that Xbox will continue to value your studio's presence. If you design around open standards and portable middleware, you retain optionality.

This mirrors broader platform dynamics in mobile and web development. Apple's App Store, Google's Play Store. And Steam all extract value from developers while controlling distribution. The studios that thrive are the ones that own their audience relationship, their account system. And their data. Compulsion's move is a vote for sovereignty in a platform economy that often discourages it. The same logic applies to enterprise software platform strategy for companies building on top of third-party ecosystems.

Lessons for Startups and Engineering Leaders Facing M&A

If you're leading engineering at a startup that might be acquired, the Compulsion Games story offers several actionable lessons. First, document your architecture and your vendor relationships before due diligence begins. A buyer will ask for this anyway, but having it ready lets you negotiate retention of critical accounts, certificates. And credentials.

Second, avoid hard coupling to the parent company's identity, analytics. And cloud systems until the strategic value of that coupling is proven. Use abstraction layers. Keep a standalone deployment path for your core product. Maintain the ability to export data in standard formats. These practices don't make you a bad acquisition target. They make you a more valuable one. Since because you reduce the buyer's integration risk and increase your own optionality.

Third, negotiate technical separation terms during the acquisition, not during the divorce. Source code escrow, data export rights, CI/CD access. And third-party license transferability should be spelled out in the purchase agreement. We have advised clients who skipped this step and later discovered they couldn't access their own Docker registries or DNS records without the acquirer's cooperation. A technical prenup is cheaper than a migration project.

Frequently Asked Questions

Why does IP ownership matter for game developers from a technical perspective?

IP ownership determines who controls the source code, art assets, build pipelines - save formats. And backend services that make a game operable. Without full ownership, a studio may be unable to port, patch, or extend its own product without negotiating with a parent company.

What platforms and tools is Compulsion Games likely using now?

South of Midnight is built on Unreal Engine 5,, and which supports multi-platform deploymentAs an independent studio, Compulsion will likely operate its own source control, CI/CD. And observability stacks rather than relying on Xbox's internal infrastructure.

How does a studio separate its cloud infrastructure from a parent company?

Separation involves migrating repositories, rebuilding CI/CD pipelines, re-establishing code signing certificates, moving telemetry and analytics to independently owned accounts. And transferring player data in compliance with privacy regulations like GDPR.

What does the buyout mean for the release of South of Midnight,

The game remains in development,And ownership has transferred to Compulsion Games. The studio now controls release timing, platform strategy, and post-launch support. Though it may still need to fulfill existing publishing obligations.

Should startups avoid being acquired by large platforms,

Not necessarilyAcquisition can provide funding, distribution. And talent. However, startups should negotiate technical sovereignty, avoid hard platform coupling, and maintain portable toolchains so they retain flexibility if the relationship changes.

Conclusion: Independence Is a Technical Design Goal

The Compulsion Games buyout is more than a business headline it's a demonstration that independence, for a modern software studio, is something you architect as much as something you negotiate. Owning your IP is the starting point. Owning your build pipelines, telemetry, player data, and team cohesion is what makes that ownership real.

For senior engineers and technical leaders, the lesson is to treat platform dependency as a risk to be managed. Use abstraction layers, own your infrastructure accounts, document your architecture, and keep your team intact. Whether you're building games, mobile apps. Or enterprise SaaS, sovereignty is cheaper when designed in from the beginning than when rebuilt during a divorce.

If your team is wrestling with platform dependency, vendor lock-in. Or preparing for an acquisition, contact Denver Mobile App Developer for an architecture review. We help engineering teams build portable, observable, and ownership-clean systems that survive organizational change,?

What do you think

Should platform owners be required to provide clean technical separation paths when divesting a studio,? Or is that the acquired team's responsibility to negotiate upfront?

What is the most underrated piece of engineering sovereignty that studios lose during an acquisition: source control, CI/CD, telemetry,? Or team cohesion?

Would you rather build on a proprietary first-party platform with better integration,? Or a portable open standard with more migration flexibility,