Who Owns the Design When Two Studios Build One Game: Saros’ Credit Split, Fuse Games’ Co-Development Framework, and the Line Miyamoto Still Draws

Evidence note: this article reads four published announcements and interviews side by side — a developer interview hosted by the engine maker, a trade-press breakdown of one studio’s co-development framework, a platform-holder development blog, and two industry interviews published by outlets. Every substantive claim below traces to exactly one of those publications, and none of them has been independently corroborated by a second source or tested here. Nothing in this article rests on a test, benchmark, or measurement produced for it; where an experiment would settle a question, it is named as a proposal and nothing more.

Four announcements that describe the same thing: who did which half of the work

Four recent pieces of games-industry communication have very little in common on the surface — a Star Wars racing game, a PlayStation action roguelite, a quarter-century-old role-playing sequel, and two publishing-side interviews. Read as credit ledgers rather than as news, they all answer one question: when more than one party builds a game, who is recorded as the author of which part?

That question is no longer a studio-scale question only. A solo developer or a three-person team routinely runs the same arrangement in miniature: a human lead plus contract help, plus an assistant that writes code, art, or copy. The structural problem is identical and the margin for error is worse, because a two-person team cannot rebuild a wrongly delegated system twice.

The useful finding is not that studios draw a vision-versus-implementation line. It is that the line, as drawn in these announcements, leaks — and it leaks at a specific, nameable place.

Fuse Games names its split — a co-development framework presented as a model

Game Developer has published a breakdown in which Fuse Games’ chief executive describes a co-development framework used on Star Wars: Galactic Racer and frames it as a model for distributed development (Game Developer’s interview with the studio’s CEO). That characterisation — both the framework’s existence and the claim that it is offered as a general model — rests on that single interview and has not been corroborated elsewhere; readers should treat the "model for distributed development" framing as the studio’s own positioning rather than as an established industry practice.

Taken at face value, it is the cleanest statement of the conventional split available in this set of sources: one party holds the design, partners execute against it. That is also the framing most likely to be adopted by a small team writing its first delegation plan, which is why it is worth checking against another studio’s published credits before relying on it.

What the engine is said to have supplied on Star Wars: Galactic Racer

A developer interview hosted by Epic’s Unreal Engine site covers the same project from the technical side. In it, Fuse Games is reported to have used Unreal Engine 5’s Lumen, Nanite, and World Partition to build the game’s visuals (the engine maker’s own developer interview with the studio). Those three named systems — a dynamic global illumination solution, a virtualised geometry system, and a level-streaming system for large worlds — appear in the interview as the studio’s account of its own pipeline; the specific attribution of each feature to each visual outcome is single-source and not independently verified.

The interview is also reported to position that visual work as serving two goals at once: the game’s gameplay design, described as a roguelite take on racing, and its worldbuilding. That dual framing is the studio’s stated intent as published, not a verified outcome, and no third-party analysis in the material available tests whether the shipped game delivers it.

Why this matters for the ledger question: engine features are the least ambiguous entry on any delegation list. Nobody claims authorship of global illumination as a creative act. The hard entries sit elsewhere.

The Saros ledger, side one: vision, world, combat language, and bullet-hell DNA

On 23 October 2026, the PlayStation Blog published a development piece on Saros covering the creation of its large-scale boss encounters (the platform blog’s post on the game’s set-piece overlords). The post describes the game as the product of close collaboration between Housemarque and Nixxes, including on those set pieces. That collaboration account comes from the one post and has not been confirmed by an independent source.

As reported there, the side of the ledger assigned to Housemarque reads: the creative vision, the world, the combat language, visual concepts, and the studio’s signature bullet-hell design DNA. Every item on that list is an authorship item in the ordinary sense — the things a studio is recognised for, and the things a successor project would be expected to inherit. This attribution is single-source and should be read as the published credit, not as a verified division of labour inside the production.

The Saros ledger, side two: encounter design, animation, environments, lighting, implementation

The same post, as reported, assigns to Nixxes the realisation of those bosses: encounter design, animation, environments, lighting, and technical implementation. Again, this is one post’s account and is not independently corroborated.

Four of those five entries sit comfortably on an implementation partner’s list. Animation, environment construction, lighting, and technical implementation are craft disciplines with enormous skill ceilings and no claim on the game’s identity. A small team delegating any of them — to a contractor, to an asset pipeline, or to a generative tool — is delegating execution.

The one entry that does not belong on an implementation partner’s list

Encounter design is the outlier.

If Housemarque holds the combat language, then the grammar of what a player may do, and at what cost, is authored on side one. Encounter design is the composition written in that grammar: which overlord opens with which pattern, how far the safe window shrinks, what the player is being taught to read. On the published ledger, that composition sits on side two.

This is where the vision-versus-implementation framing — the framing the Fuse Games interview presents as a model for distributed development — does not survive contact with Saros’ own published credits. Both characterisations are single-source, so the tension is between two reports rather than between two verified facts. But as published, one studio offers the clean split as a general model while another studio’s credits place a design discipline on the implementing side of exactly that split.

For a two-person team, the practical reading is this: "design" is not one block. A combat language and the encounters written in it are separable, and at least one shipped production appears to have separated them deliberately. Treating the whole of design as non-delegable overstates the line; treating encounter work as mere execution understates it. The boundary has to be drawn at the level of individual systems, in writing, before anything is handed over.

If design can cross the line, what screens the half that stays human

Two interviews in this set offer the only published tests for what remains on the authorship side.

Eurogamer has reported Shigeru Miyamoto arguing that even if generative AI eventually handled everything, a role would remain for human designers (Eurogamer’s report on his comments). That is a reported position from a single outlet, not a verified prediction, and the material available does not record how he defines the surviving role in operational terms. Its value here is narrow but real: it names the residual as a role, not as a task list — which is consistent with a ledger in which individual design disciplines can be delegated while authorship does not move.

From the publishing side, 80 Level has published an interview in which Raw Fury’s chief executive says the publisher looks for games that make players feel something when evaluating pitches (80 Level’s interview with the publisher’s CEO). Again, single-source and reported rather than corroborated. As a screen it is vague by construction, but it is a screen applied at the gate a small team actually has to pass, and it is applied to the whole, not to any component. Nothing on the implementation side of either ledger above would pass or fail it on its own.

Teams delegating to tools rather than to studios face the same ledger with a different partner; our report on Capcom rebuilding the RE Engine as an "AI-generation engine" notes which job categories that company’s own framing names first.

A second ledger with a toggle: a 2001 role-playing sequel returns with a Legacy mode

80 Level has reported that a Dungeons & Dragons role-playing sequel originally released in 2001 is returning to Steam with 4K support, modern controls, an improved user interface, Steam Deck compatibility, bug fixes, and an optional Legacy mode (80 Level’s report on the re-release). The feature list and the "after 25 years" framing come from that report and are not independently confirmed; the 25-year figure is consistent with a 2001 original arriving in 2026, which is a derived arithmetic check rather than a separate source.

What makes this a ledger and not a patch note is the last item. Resolution, controls, interface, platform compatibility, and bug fixes are all on the implementation side — changeable without touching authorship. The Legacy mode is the project writing its own line: a toggle that preserves the original behaviour declares, in shipping form, which part of the game the team considered theirs to modernise and which part it refused to overwrite. Small teams documenting their own practice publicly tend to be explicit in the same way; see our reading of what the public record of a small-game-development guidebook actually names.

Developer takeaway: write the ledger before you hand over the work

A delegation line that exists only as a slogan will be redrawn, silently, by whoever delivers first. The pattern visible across these four announcements suggests a concrete alternative for a team of two to four:

1. Write two columns before the handover, naming systems rather than disciplines. "Combat" is not an entry. "The cost and recovery rules for every player action" and "the opening pattern of each boss" are two entries, and the Saros credits as published put them on opposite sides.
2. Put every engine-level and craft-level system on the implementation side on purpose. Lighting, geometry, streaming, animation, resolution, input mapping, interface layout: nothing in these sources treats any of them as authorship.
3. Decide which design disciplines are delegable, and say so out loud. Encounter design appearing on an implementation partner’s credit list is permission to delegate it — but only if the grammar it is written in is specified first and held centrally.
4. Ship a reversal switch where the change touches the original. The optional Legacy mode is the cheapest available form of the statement "this part was not ours to overwrite."
5. Screen the result as a whole, not per component. The publishing-side test reported above applies to the finished thing; no delegated module passes it alone.

What the available evidence does not cover, and the follow-up proposed rather than claimed

The limits are substantial and worth stating plainly. All four ledgers above are self-reported credit, published by the parties involved or by outlets interviewing them. None has been corroborated by a second source. None discloses how the boundary was enforced in practice — no documents, no change-request process, no record of what happened when a partner’s encounter design conflicted with the lead studio’s combat rules. The two screens offered for the authorship half are both reported remarks, and neither is operationalised anywhere in this material. Nothing here speaks to whether a delegation ledger written by a three-person team behaves like one written between two established studios, and nothing speaks to generative tools as the receiving party — the AI question is raised by one reported remark about designers and otherwise untouched.

No experiment was run for this article, and none is claimed. A proposed follow-up, stated as a proposal: have a small team write the two-column ledger described above before a delegation, keep the original document unaltered, then compare it against the delivered work entry by entry and record which entries migrated across the line, in which direction, and whether the migration was noticed at delivery or later. The figure of interest is the migration count per handover. Until such a record exists, the honest claim is narrow: two published accounts of distributed development disagree about where design sits, and a team that has not written its own ledger is inheriting that disagreement by default.