/
• Blog
/
• Game Co Development

Game Co-Development: What It Is, How It Works, and When to Use It

A game studio does not always need to build a larger permanent team or hand an entire project to an external company to increase production capacity.

There is another model: game co-development.

Instead of working separately from the internal studio, a co-development partner joins the production process and takes responsibility for an agreed part of the project. This can mean adding specialists to an existing team, assigning an external team to a production stream, or giving a partner ownership of a particular feature or area of the game.

The important difference is integration. Co-development works when internal and external teams operate within a connected production system rather than two isolated pipelines.

This guide explains how that model works, what can be co-developed, how external teams integrate into an existing pipeline, and when co-development makes more sense than traditional outsourcing.

What Is Game Co-Development?

Game co-development is a production model in which an external studio works alongside an internal development team and takes responsibility for specific parts of a game's production.

The exact scope can vary significantly.

One project might add several external engineers or artists to an existing internal department. Another might assign an entire feature, environment pipeline, art stream, or technical system to a dedicated external team.

Large co-development providers demonstrate how broad this model can become. Keywords Studios, for example, describes co-development across programming, testing, art, audio and game design, including responsibility for areas such as levels, AI and combat systems. Sumo Digital similarly describes models ranging from specialist support to development of specific sections or modes of a game.

This means co-development is not defined by a particular discipline. It is defined primarily by how the external team participates in production.

A co-development partner can provide additional capacity, bring expertise that is missing internally, or take ownership of a defined production area. In all three cases, the partner needs enough context and access to work within the larger project rather than treating each task as an isolated deliverable.

Game Co-Development vs. Outsourcing: What's the Difference?

Both models involve external teams, so the terminology can become confusing.

The practical distinction is usually the level of integration and production responsibility.

Traditional game development outsourcing works particularly well for clearly defined deliverables. A studio might outsource a set of 3D props, character models, animations, localization work, QA passes, or another production package with established specifications.

The internal team defines the requirements, the external team produces the deliverables, and the work goes through an agreed review and acceptance process.

Co-development is generally more connected to ongoing production.

Instead of receiving a fixed brief and working largely around it, the external team may need access to changing project context, shared production tools, builds, repositories, documentation and regular decisions from internal leads.

That makes it more suitable for work where requirements are expected to evolve during production. This distinction is also reflected in current industry descriptions of co-development, which emphasize shared production context, integration, onboarding and responsibility rather than simply external delivery.

The distinction is not absolute. A long-term outsourcing relationship can become highly integrated, while a co-development engagement can still have clearly defined boundaries.

The useful question is therefore not Which model is better?

It is:

How much production context does the external team need in order to own the result?

If the answer is very little, traditional outsourcing may be enough. If the work depends continuously on the rest of the game, a co-development structure can make more sense.

What Can a Game Co-Development Partner Handle?

Co-development can cover one discipline or several. The appropriate scope depends on the project's needs and the partner's actual capabilities.

Game Art Production

Game art production is one of the areas that can be integrated into a co-development model.

An external art team may support:

• concept and visual development;
• 2D assets and illustrations;
• 3D characters and creatures;
• environments and props;
• animation;
• VFX;
• UI/UX;
• technical art;
• world building and game-ready asset production.

The production structure also changes significantly depending on whether a project relies on 2D or 3D game art.

Instead of commissioning 20 isolated props against a fixed specification, for example, a studio might give an external environment team responsibility for a particular location or content stream. That team then needs to understand not only the visual target but also technical budgets, modular systems, naming conventions, engine requirements, level-design constraints and dependencies with other departments.

The production problem becomes broader than creating individual assets.

Engineering and Technical Production

Co-development can also cover engineering.

Depending on the studio and project, external developers may contribute to gameplay systems, tools, platform work, engine-related tasks, feature implementation and other technical areas.

Some established co-development providers structure multidisciplinary teams around entire parts of a game rather than individual engineering tickets. Keywords Studios, for example, lists work ranging from programming support to NPC AI, combat integration and weather systems.

The important question is again ownership.

If external developers are responsible for a feature that interacts with internal systems, they need clearly defined interfaces, technical requirements, repositories, review processes and escalation paths.

Level and Content Production

Content-heavy games may require substantial production beyond the core systems.

An external team can support environment assembly, world building, level production, content implementation and other repeatable production streams.

This model can be particularly useful when the internal team needs to protect its capacity for core systems or creative direction while production volume increases elsewhere.

Porting and Platform Support

Platform adaptation can also sit within a broader external-development relationship.

A partner may be responsible for adapting a game to another platform, addressing platform-specific requirements, resolving technical issues and supporting testing or certification preparation.

However, this is a specialized discipline. Porting experience should be evaluated separately rather than assuming that any general development partner can handle it effectively.

LiveOps and Ongoing Production

Co-development does not necessarily end at launch.

External teams can remain involved in ongoing content, engineering, art production, events and other LiveOps requirements. Both Keywords Studios and Sumo Digital position ongoing development or LiveOps alongside their broader co-development capabilities.

For studios with a continuing release schedule, this can turn external production from a temporary capacity solution into an ongoing production stream.

How External Teams Integrate Into Your Production Pipeline

This is where co-development either becomes productive or creates additional overhead.

Adding experienced people is not enough. The external team needs to understand how work moves through the project.

Start With Ownership

Before production scales, both sides should know who owns each area.

For every major feature or production stream, establish:

• Who makes the final creative decision?
• Who owns implementation?
• Who reviews the work?
• Who approves it?
• Who is responsible for integration?
• Who resolves dependencies with other teams?
• What defines “done”?

Without these answers, external and internal teams can both complete their assigned work while the overall feature still remains unfinished.

Ownership therefore needs to describe outcomes, not just tasks.

Establish a Shared Source of Truth

Documentation should not be scattered across disconnected chats, documents and individual team members.

The external team needs to know where the current information lives:

• production documentation;
• technical specifications;
• art guidelines;
• feature requirements;
• task status;
• known issues;
• build information;
• review feedback;
• decision history.

More importantly, everyone needs to know which version is current.

This becomes particularly important when a design, technical requirement or visual target changes after external production has already started.

Align Tools and Version Control

If a partner works directly inside the project, repository and version-control practices become part of onboarding.

The team needs clear rules for branches or changelists, asset ownership, naming, submissions, reviews and conflict resolution.

This is not just an administrative concern. For example, Unreal Engine's source-control documentation explicitly supports team workflows around shared assets and code, revision history, checkouts and synchronized project changes.

For Unreal projects using binary assets, coordination can become especially important because some assets cannot simply be merged like text files. Epic's Perforce documentation notes that .uasset and .umap files are binary and are commonly locked during editing to prevent concurrent changes.

An external team therefore needs to adopt the project's actual source-control workflow rather than simply being given repository access.

Define the Review Cycle

A review process should answer more than “Who gives feedback?”

It should establish:

When is work reviewed?

Daily, during sprint reviews, at milestones, or after defined production stages?

At what stage should internal leads intervene?

Reviewing a character after final textures is very different from reviewing silhouette and proportions during blockout.

Where is feedback recorded?

Comments spread across calls and messaging apps are difficult to track.

Who can approve changes?

Conflicting feedback from multiple stakeholders can quickly slow an external team.

Good review systems catch wrong assumptions before they become expensive production work.

Match Communication to Dependencies

Not every external contributor needs to attend every internal meeting.

Communication should follow dependencies.

A team responsible for a self-contained asset stream may only need regular production reviews and access to relevant leads. A team implementing a gameplay feature that touches design, engineering, animation and UI may need much tighter communication.

The goal is not maximum communication. It is enough shared context for the external team to make correct production decisions.

Plan for Change

Co-development is often used precisely because production is not completely static.

A mechanic changes after playtesting. A platform constraint appears. A level is restructured. A new technical dependency affects existing assets.

The workflow therefore needs a clear way to communicate changes and determine what they affect.

This is one of the major differences between integrated co-development and a bounded delivery model: uncertainty exists inside the engagement, so the production system needs to accommodate it.

Common Game Co-Development Models

There is no single structure that defines every co-development project. In practice, several models are common.

Embedded Specialists

Individual external specialists join an existing internal team.

A studio might need a technical artist, gameplay engineer, animator or another specialist without building a permanent internal role immediately.

This model can work well when the internal production structure already exists and the missing requirement is expertise or capacity rather than an additional production team.

Dedicated External Team

Instead of individual contributors, a partner provides a dedicated team responsible for an ongoing stream of work.

This might be an environment art team, an engineering group, a multidisciplinary feature team, or another unit built around the project's requirements.

The internal studio maintains overall project ownership while the external team has its own leads and production structure.

Feature or Production-Area Ownership

A partner can also take responsibility for a defined part of the game.

That boundary could be a feature, system, level, mode, art stream or another production area.

This approach can reduce the amount of task-level management required from the internal studio, but only when ownership and interfaces are clear. The external team needs enough authority to solve problems inside its scope, while internal leads need visibility into decisions that affect the rest of the project.

Hybrid Co-Development

Many projects do not fit neatly into one model.

A studio might embed several external specialists into core teams while simultaneously giving a dedicated external art team responsibility for an environment pipeline.

The structure can also change as production progresses.

What matters is not the label. It is whether responsibility, access, communication and integration match the work being assigned.

When Does Game Co-Development Make Sense?

Co-development is particularly useful when an external team needs to remain connected to ongoing production rather than deliver a completely isolated package.

When Internal Capacity Is Limited

A project may already have the right internal leadership and production structure but not enough people to execute the required volume.

A co-development team can expand capacity without requiring every role to be added permanently in-house.

When You Need Specialized Expertise

Sometimes the constraint is not headcount but experience.

A project may require expertise in a particular engine, platform, technical discipline, art pipeline or production problem.

External specialists can fill that gap while working with the people who already understand the product.

When a Production Area Needs Dedicated Ownership

Adding more individual contributors can actually increase management demands.

If the internal team does not have enough bandwidth to break down, assign and supervise every task, it may be more effective to give an external team responsibility for a defined production stream.

This moves the conversation from:

“Can you provide five developers?”

to:

“Can your team own this part of production?”

That is a much more meaningful distinction.

When Scope Is Expected to Evolve

Some work cannot be completely specified at the beginning.

Gameplay features change through testing. Art direction develops. Technical dependencies emerge. Content requirements move with design.

An integrated team is better positioned to react to those changes because it already has access to the project's context.

When Production Needs to Scale Around a Milestone

Projects rarely require exactly the same team composition throughout development.

Production requirements can increase around content-heavy stages, feature development, platform work or major milestones.

A co-development relationship can provide a structure for changing external capacity without rebuilding the collaboration model each time.

When Co-Development May Not Be Necessary

Co-development creates flexibility, but it also creates integration work.

Onboarding takes time. Access needs to be configured. Documentation has to be maintained. Internal leads still need to communicate decisions. Production managers need to coordinate dependencies.

For a small and predictable scope, that overhead may not be justified.

Consider a more traditional outsourcing model when:

• the deliverable is isolated from the rest of production;
• specifications are stable;
• acceptance criteria can be defined clearly;
• continuous access to internal context is unnecessary;
• the work can be reviewed at defined checkpoints;
• long-term integration is unlikely to provide additional value.

A batch of clearly specified props is an obvious example. If the external studio can produce them from established references and technical requirements, embedding that team deeply into the entire project may solve a problem that does not exist.

The production model should follow the shape of the work.

How to Choose a Game Co-Development Partner

A strong portfolio tells you what a studio has produced. It does not necessarily tell you how that studio will operate inside your production pipeline.

Co-development requires evaluating both.

Relevant Production Experience

Look beyond genre labels.

The useful question is whether the team has worked with similar:

• production disciplines;
• engines and tools;
• platforms;
• technical requirements;
• visual targets;
• content volume;
• team structures.

A partner does not need an identical project in its portfolio, but it should understand the production problems it is expected to own.

Technical Compatibility

Before scaling the relationship, discuss the actual production environment.

What engine and version does the project use? What source-control system? How are builds handled? What tools and plugins are involved? Are there proprietary systems? How is work reviewed and integrated?

Compatibility does not mean the external studio must already use an identical pipeline internally.

It means the team needs to be capable of operating effectively within yours.

Clear Ownership

Ask a prospective partner what they expect to own.

If every problem must be escalated back to the internal team, the relationship may create more management work than it removes.

At the same time, an external team should not make decisions outside its scope without the appropriate internal approval.

Good co-development needs a clear boundary between autonomy and authority.

Production Management

Ask how the team is structured.

Who is the producer? Who are the discipline leads? Who reports progress? Who escalates blockers? How is feedback distributed? What happens when requirements change?

Sumo Digital's current co-development approach, for example, explicitly identifies onboarding, defined roles and responsibilities, agreed communication protocols and integration as parts of the service rather than treating them as secondary administrative details.

That is a useful standard when evaluating any external development team.

Scalability

If scaling is one reason for using co-development, discuss it before it becomes necessary.

How quickly can the team composition change? Which roles are realistically available? Can a small initial team grow into a larger production unit? What happens if the project needs to reduce external capacity later?

A scalable relationship needs more than access to additional people. New contributors still need onboarding, leadership and project context.

Security and IP

External teams may require access to source code, unreleased assets, builds, internal documentation and other confidential material.

Before production starts, establish appropriate agreements, permissions and access controls. Sensitive access should follow the needs of each role rather than automatically exposing the entire project.

Security should be part of the production setup, not an afterthought.

Handover and Maintainability

Co-development should not leave the internal studio unable to continue the work.

Depending on the scope, plan for:

• source files;
• code and assets;
• documentation;
• technical notes;
• known issues;
• dependencies;
• ownership transfer;
• final integration.

A feature that works only while the external team remains attached to it creates a different kind of production risk.

What to Prepare Before Starting Co-Development

You do not need every detail finalized before speaking with a potential partner.

You do, however, need enough information for the partner to understand the production environment and estimate what kind of team or ownership model is appropriate.

A useful starting brief includes:

• Project overview: What are you building and what stage is it in?
• Scope: What do you expect the external team to support or own?
• Target platforms: PC, console, mobile, web, installation hardware, or others.
• Engine and tools: Unreal Engine, Unity, proprietary technology, DCC tools and relevant plugins.
• Current pipeline: How does work currently move from production to review and integration?
• Existing team: Which internal disciplines and leads will work with the partner?
• Technical requirements: Performance targets, platform constraints, asset requirements or system dependencies.
• Quality benchmark: References, existing assets, playable builds or other examples of the expected result.
• Responsibilities: What stays internal and what moves to the external team?
• Milestones: What does the project need to achieve and when?
• Review process: Who reviews work and at which stages?
• Communication: Meetings, reporting, project management tools and escalation paths.
• Access and security: What systems, repositories, builds and documentation will the external team require?
• Expected team structure: Individual specialists, dedicated team, feature ownership, or a combination.

This does not need to become a 50-page specification.

The purpose is to give both sides enough context to design the production relationship, not just price a list of tasks.

Co-Development Beyond Traditional Games

The same model can apply outside conventional PC, console and mobile game production.

Interactive installations, branded games, exhibition experiences and event activations often involve several parties with different responsibilities.

A creative agency or brand team, for example, may own the concept, creative direction and user experience while an external production team handles game art, development, technical implementation, integration and testing.

The production requirements can also extend beyond software. Interactive projects may depend on displays, sensors, physical installations, event hardware or venue-specific constraints.

That makes clear ownership particularly important.

Who owns the concept? Who turns the mechanic into a working experience? Who integrates content? Who tests the final hardware/software configuration? Who supports installation?

Although the end product may not be a conventional commercial game, the production principle is similar: different teams contribute to one interactive experience through a shared delivery pipeline.

Working With Asterman

Asterman works with game companies and other creative teams across game art and production. Its current game-production portfolio includes concept art, 2D and 3D assets, characters, environments, animation and projects involving broader game production.

Within a co-development structure, that can mean supporting an existing internal team with a specific production discipline or taking responsibility for a broader part of the visual or interactive production pipeline.

The appropriate setup depends on the project: the existing internal team, engine and technical environment, required disciplines, scope and level of ownership all determine what the external team should look like.

Explore Asterman's game production work or contact the team to discuss the production structure behind your project.

Building the Right Co-Development Structure

Co-development is not simply a way to outsource more work.

Its value comes from giving an external team enough context, access and responsibility to contribute directly to production while keeping clear boundaries between internal and external ownership.

For some projects, that means a few embedded specialists. For others, it means a dedicated team responsible for an entire feature, art stream or production area. And sometimes a conventional outsourcing model remains the more efficient choice.

The right decision depends on the work itself: how much it changes, how closely it depends on the rest of the project, what expertise is required, and who needs to own the final result.

When those questions are answered first, co-development becomes a production structure rather than simply another name for outsourcing.

Frequently Asked Questions