John Chu, now Lead Technical Program Manager in the Central Technology Online Area at Bungie, then Senior Technical Program Manager at Bungie, presented "Bringing Players Together: Building Cross-Play in Destiny 2" at GDC 2022, walking through the full production story of how Bungie shipped cross-platform play across seven platforms for one of the world's most active live-service games.

Indirectly, this highlights best practices that any game studio, big or small, can add to their multiplayer to help improve its cross-platform architecture.

[Editor's note: Given the massive scope of John's presentation, we've included specifically for this article a "Main takeaway" under each major insight to help with readability.]

Building Cross-Play in Your Own Engine Means Building Almost Everything from Scratch

Cross-platform play is an easily understood concept. You're routing players from different platforms into the same game world. But in a proprietary engine, almost nothing just works across platforms — it all has to be rebuilt.

Bungie's Tiger Engine was built for the original Destiny, with parts of the codebase reaching back to the Halo era. Every system that previously relied on platform-level APIs had to be recreated from scratch: networking, player identity, friends lists, session invites, voice chat, and text chat, all rebuilt to work across Sony, Microsoft, Valve, and Google simultaneously. As John Chu described them, these were "some of the biggest and scariest bone-breaking changes" in the engine, because networking is one of its most fundamental underlying systems.

The networking changes alone were substantial. Because Destiny 2 had been shipped and optimized separately for each platform over the years, those optimizations didn't play well together when combined. The team built a mapping layer to communicate over the network using consistent handles that could be translated to platform-appropriate ones on each side. Online sessions for Fireteams had to be restructured too, moving away from a single session hosted by one player to maintaining separate online sessions per platform.

Games using third-party engines like Unreal or Unity get a lot of this cross-platform portability already built in. Bungie did not. If you're building in your own engine, take stock of every system that touches a platform API before committing to your cross-play scope. The list will be longer than you expect.

Main takeaway: In a proprietary engine, nearly every system that touches platform-level APIs will need to be rebuilt for cross-play. Scope and timeline need to reflect that reality from the start, and third-party engine developers should audit their own platform dependencies before assuming they're covered.

Unified Player Identity Is a Prerequisite, Not a Feature

Players in Destiny 2 spend hundreds of hours building their Guardian. That Guardian is an extension of themselves, and a meaningful part of that identity is their name. Before cross-play, that name came from the platform: your gamertag, your Steam profile, your PSN handle. With cross-play, that approach breaks down immediately. The same player might be "Oryx" on PlayStation and "Savathun" on Steam, and their friends across platforms won't recognize them.

Bungie's solution was the Bungie Name: a player-chosen name combined with a four-digit unique identifier, for example "Oryx#1234." It seeds automatically from the platform name the player uses on first login, keeping onboarding seamless without adding extra steps. It appears above the player's head in-game and in the roster wherever they play, a consistent identity regardless of platform.

This is now a well-understood problem in the industry, and studios building cross-play today have options that Bungie had to build entirely themselves. Epic Online Services provides for free a cross-platform identity and social layer through its Auth Interface that works across PC, console, and mobile. brainCloud offers similar cross-platform identity and authentication infrastructure designed specifically for games, with support for merging accounts across platforms built in. LootLocker provides cross-platform player authentication and Unified Player Accounts that link multiple platform identities under a single profile. The underlying principle is the same regardless of what you use: a unified identity layer has to be treated as infrastructure, not a secondary feature to tackle after everything else.

Main takeaway: Any cross-play experience needs a platform-agnostic identity system from day one. Studios building today don't need to build it from scratch. Nowadays, services like Epic Online Services, brainCloud, and LootLocker provide this infrastructure out of the box.

Managing Interdependencies on a Large, Remote Cross-Team Project

With four teams and about 50 people working on separate parts of the experience simultaneously, interdependencies were constant. A change in the networking layer affected the session invite system. A decision about player identity rippled into the roster UI. And because the whole team was working remotely, the informal hallway conversations that typically smooth out these questions weren't happening organically.

Bungie's response was deliberate sync structures. They ran recurring meetings segmented by feature area (everyone working on friends and presence, everyone working on communication) as well as by discipline (all engineers or all testers meeting separately). This let different concerns surface in the right rooms. In one weekly sync focused specifically on friends and presence, the team realized no one had fully resolved how blocking would work in a cross-play world. Having engineers and designers together in the same meeting meant the ambiguity was addressed immediately rather than silently becoming design debt.

That said, Chu was candid about the risk of over-indexing: "Syncs to build consensus across the team come at the cost of IC time." Early in the project, too many meetings meant not enough time for individual contributors to actually build things. The team iterated on their cadence and reduced total meeting time until the overhead felt proportionate.

Main takeaway: Deliberately designed syncs segmented by feature area and discipline surface blockers and build team cohesion. But over-meeting actively hurts delivery velocity. Audit your cadence regularly and cut where you can.

Matchmaking Pools Should Reflect the Stakes of the Mode

Not every game mode carries the same competitive weight, and that distinction should drive how you structure your cross-platform matchmaking. Bungie separated competitive and cooperative modes from the start, guided by two clear principles: fairness and player protection.

For cooperative modes like Strikes, there was no meaningful platform edge. No input disparity that changes the outcome, no security difference that exposes one group unfairly to exploits. Everyone plays together regardless of platform. For competitive modes, two distinct pools were created: a console pool covering PlayStation, Xbox, and Stadia (which runs on controlled datacenter hardware unlikely to have client tampering), and a PC pool covering Steam and the Microsoft PC Store. Cross-platform Fireteams are handled by allowing console players to cross into the PC pool when grouped with a PC player, but not the reverse.

The pool system was also built to be extensible, so future modes with different imbalance risks can be handled without rearchitecting anything. Having clear guiding principles defined upfront made individual design decisions significantly easier. Studios building cross-play today can apply the same logic directly through matchmaking configuration. Edgegap's matchmaker documentation covers exactly this pattern in its competitive games example, showing how to enforce different matchmaking constraints for casual versus competitive modes, including platform and input restrictions, without building custom pool logic from scratch.

Main takeaway: Define your guiding principles before designing your pool rules. Separate pools by activity type, build the system to be extensible, and know that the right matchmaker configuration can implement this kind of logic without custom engineering.

Cross-Platform Play Introduces New Toxicity Vectors That Require Cross-Platform Solutions

When you expand a player's social surface area, you expand their exposure to bad actors. Combining platforms with different username standards, different security cultures, and different moderation histories creates forms of harassment that simply didn't exist within a single-platform ecosystem.

Bungie identified two main risks early. First, profanity and derogatory language in usernames: some platforms filter aggressively, others don't. Without their own filtering layer, inappropriate platform names would seed directly into Bungie Names. Second, platform-level blocks are siloed. A player who blocks a harasser on PlayStation can still be reached by that same person through their Steam account.

For content filtering, Bungie integrated a third-party solution with machine learning capabilities, context-aware enough to distinguish between a player insulting someone and a player expressing excitement with the same language. Building and maintaining that model across 12 supported languages in-house would have required significant specialist staffing. For blocking, the Bungie Block system was designed to span all linked accounts across all platforms. Block someone once, and every account associated with them is blocked everywhere. It was a hard requirement to ship. Chu was explicit that antagonistic behavior tends to be directed at minority and more vulnerable player populations, making proper protection non-negotiable.

Main takeaway: Blocking systems for cross-play must be cross-platform. A per-platform block that doesn't cover a player's linked accounts on other platforms is not real protection. Build this before launch.

First-Party Certification Requirements Affect Design — Start Reading Them in Pre-Production

Shipping on seven platforms means navigating seven sets of certification requirements, and many first parties have dedicated cross-play sections in their cert documentation. Going in familiar with the requirements is table stakes. The harder part is reconciling those requirements with your intended design.

Some platforms require that players on their platform be primarily identified by their own platform names, which created a direct conflict with Bungie's Bungie Name concept. Some platforms prohibit displaying other platforms' logos or icons while playing on theirs. These weren't edge cases — they were requirements that needed to be worked through before the experience could ship.

Bungie's approach was to start those conversations during pre-production, flagging conflicts early and engaging first parties to understand the spirit behind each requirement rather than just its letter. It was a long process. But starting early meant there was time to find solutions that worked for both sides. Chu acknowledged that Bungie was in a fortunate position with close existing first-party relationships. The principle applies broadly regardless of studio size: the earlier you surface these conflicts, the more room you have to solve them.

Main takeaway: Read first-party cross-play certification requirements at the beginning of pre-production, not at the end. Identifying conflicts early is what makes it possible to find a path forward before your timeline is at risk.

Be Deliberate About What You Build vs. What You Buy

Once you've catalogued all the systems that need to be rebuilt for cross-play, some of them will be genuinely hard problems that other companies have already solved well. Voice codecs that work portably across all platforms. Profanity and toxicity filtering across a dozen languages. These are not differentiating features. They are infrastructure, and they have established providers.

Bungie integrated a third-party voice solution, which freed the team to direct its attention to the parts of cross-play that only Bungie could build. For text filtering, building and maintaining a context-aware model across 12 languages in-house would have required substantial specialist staffing the project didn't have time or budget to acquire.

Text chat was the exception. Despite available options, Bungie built their own text chat service, reasoning that control over the platform offered long-term integration potential a third party couldn't match. The distinction is useful: buy where the third party is already better than you could be; build where control and deep integration matter.

Chu was direct about what buying doesn't solve, however. Integrating third-party solutions takes real engineering time, and in Bungie's case, some integrations were overscoped and had to slip to a later release. You're also tying your game to another product's release cadence and update schedule.

Main takeaway: Third-party solutions for voice, identity, and moderation can meaningfully compress scope. But integration always takes time and creates external dependencies. Treat make-vs.-buy as a scope management tool, and factor integration time into your planning from the start.

Use Incremental Releases to De-Risk Large Features in Live Games

Cross-play created more new services than anything Bungie had shipped since Destiny 2's original launch. Releasing it all in a single season meant one chance to get it right across seven platforms, with a live player base depending on the experience not breaking. That was too much risk to accept in a single shot.

Instead, Bungie spread the release across multiple seasons, front-loading the highest-risk changes first. The networking overhaul went in early, giving it months to bake and stabilize before the rest of cross-play depended on it. New UI systems and early cross-play features were introduced in a preceding season. In the season before full launch, Bungie employees were given access to cross-play features in the live retail game, playing alongside the public for months ahead of the actual release. Finally, a limited public beta enabled cross-play in a Strike playlist, stress-testing the new networking and matchmaking code at real population scale.

There were some bloopers along the way, with players occasionally stumbling into cross-play features earlier than intended. But these were treated as useful bug-surfacing events rather than failures. "We can't control our outcomes, but we can control our executions," as Chu quoted from within the studio. The incremental release strategy was an expression of exactly that.

Main takeaway: For large features in live games, spread the release across multiple updates and front-load your riskiest engine changes so they have time to stabilize. Internal alphas with real players and limited public betas are your best tools for building confidence before full launch.

This article is based on and cites the original presentation by John Chu, presented at GDC 2022. All rights in the original content are owned by their respective owners.