Co-development has become increasingly popular in the video game industry in the past few years. Co-development can enable studios to pool resources, expertise, and creativity to deliver even more compelling and rich gaming experiences when it works, or it can cause delays and a disjointed final product if done poorly. Whilst the concept of co-development (affectionately referred to as co-dev by those in the know) is nothing new, the strategic importance of the model is something that does appear to be gaining quite a bit of momentum.

This may also be a trend that we see increasing in 2025 set against the backdrop of 1 in 10 games developers being laid off in 2024 according to the GDC State of Games Industry report (which surveyed over 3,000 developers). That same report found that there has been a decrease of developers working for AAA studios falling from 18% to 15% with almost half of those developers working at studios with 250+ staff.

With the industry as a whole continuing to grow year on year and few plans to slow down these statistics would indicate a move away from traditional models of massive development teams working in AAA studios to alternative models that do not involve quite so many people being employed in long term positions. Enter co-dev.

The co-development approach, while offering numerous advantages, also presents unique challenges. In this blog, we'll delve into the intricacies of co-development, explore its benefits and pitfalls, and examine examples of good practices derived from both software development in general and the video games industry.

Lessons from Software Development – this is not just outsourcing.

I have worked in the software and tech industry for many years now. It is fairly common for a software developer to effectively co-develop anything that is bespoke or heavily customised with even a non-technical client.

When developing something like a bespoke software platform for a client, it is often the case that an iterative approach will be taken, allowing for client input at various stages. Whilst many might classify this type of situation as outsourcing, as the software vendor might have a well defined brief and be working largely independently, I would instead liken this more to co-development because of the input and directive power the client has on the development process. If this was instead a completely hands-off development that had no input or direction from the client other than an initial brief and occasional service feedback I would say it’s closer to outsourcing.

Understanding Co-Development in Video Games

Co-development in the video games sector usually involves multiple studios or developers working together. This collaboration can take various forms, such as dividing different aspects of game development (e.g. art, programming, level design) among teams or having studios of varying sizes contribute to different components of a game. The ideal end-goal is to leverage the strengths of each co-partner to produce a superior final product compared to what a single studio could have produced.

The same delineation can be made within video games development as it can for software development (after all, they do often involve similar things). Whereas a developer who is “simply” porting an existing game might have a fairly straightforward and clean-cut brief as to what their objective is as an outsourced activity (to make a PC game work on console for example) a co-dev partner might be working in more discrete phases or given a larger creative brief which might necessitate a pivot down the line by other partners.

The Appeal of Co-Development

The increasing complexity of modern video games, especially AAA titles, will inevitably and necessarily in most cases lead to either a bloated studio of full time staff or a combination of specialist studios who each bring something special to the table.

An obvious issue and bugbear within the video games sector is the repeatedly publicised occurrence of studios folding and/or making sizeable chunks of their staff redundant after a development cycle is completed. This is largely often as a result of the fact that once their task is completed it is not guaranteed that there will be any further need for them after a game is launched. Very few people want to take what they believe it a long term role and find that they are out of employment after a few years.

Whilst this challenge is not limited to large studios, and does affect smaller studios working in co-development to some extent, it is more likely that an independent studio working as a co-dev partner would be able to access more IP to work on in terms of competing studios. It would not for instance ever have been expected for the likes of Ubisoft to work hand-in-glove with someone like Activision Blizzard to create a game for example, though not altogether impossible considering the times and the fact that Ubisoft acquired all of the streaming rights to Activision Blizzard’s titles back in late 2023. Licensing out valuable streaming rights is one thing, but creating a game together would be an entirely different matter. Large studios are understandably going to be concerned about protecting their valuable IP rights in games and the tools they use to want to invite their competitors to lift back the veil on those things in case they give away some valuable competitive advantage in doing so.

So then the obvious advantage to studios would be the longevity of a viable co-dev business model, given that it would potentially allow them to access and work on established IP franchises held by the largest players in the industry and hop from one to another with relative ease. Many studios aim to work on this basis in order to generate revenue to develop their own IP in good time. That is certainly a beneficial approach for studios to achieve sales separately to and much earlier than could be done following a traditional large game development cycle which can sometimes mean years before bringing in any cash and usually requires fairly significant investment to come from somewhere in order to bring the game to market in the first place.

By collaborating, studios can:

• Access Specialised Expertise: Different studios may possess unique strengths, such as advanced AI programming, intricate art design, robust multiplayer infrastructure or excellent storytelling. No matter what the project is about, having a specialist provide their insight and ideas at any stage can unlock new angles for the game’s direction that might not otherwise be considered whether creatively, technically or otherwise.
  
• Accelerate Development Timelines: Sharing the workload can lead to faster development cycles, allowing games to reach the market more swiftly. This would be more true of larger project teams which may only exist in their combined state for short sprints, versus trying to get more output out of a smaller more permanent team. If executed properly, co-development could lead to a rapidly accelerated development process when compared with traditional models.
  
• Optimisation of Resource Allocation and focus on core competencies: Studios can manage resources more efficiently by distributing tasks based on each team's capabilities, and rather than pushing one team out of their comfort zone (which can lead to issues and delays and potentially require training) studios can instead choose to bring in new or more specialised talent on a more temporary basis that doesn’t expose them to significant additional overhead commitments as it might with an external head-hunted hire. Whilst this relies on good project management, the same would be true of a purely internal team. Good people will always be hard to find and retain but it makes sense to meet the talent where they are rather than insisting things have to be kept in-house.
  
• Get a new lease on life! Lost that joie de vivre? A co-dev partner could be the solution to turn that frown upside-down. Studios can sometimes feel fatigued or pressured when it comes to developing sequels or DLC in some cases. I’m not saying that you can’t make a good sequel yourself, just look at Uncharted 2 or Assassin’s Creed II – but when a series might get to game 7 or 8, or even year 2 of a live service game, you might be lacking some lustre or just struggling to come up with something new. With player retention being key to most games, having a fresh set of eyes and opinions can unlock another level, or sequel, and that is where a truly experienced and well-motivated co-dev team comes into the fore. This way, the original studio can hold on to a certain level of oversight to keep things on brand whilst injecting a bit of fresh new car smell into an existing IP.
  
• Risk Mitigation. A common tactic in business is to compartmentalise risk across business units, and sometimes this is the main reason why a company might create a holding company and subsidiary relationship. Sharing the load across a larger pool of developers might help a publisher or lead studio reduce their financial and creative risks overall.
  
• Scalability. Whilst it’s difficult to hire and fire employees at will in most cases, it is (legally at least) relatively easy to terminate a contract with a service provider even where nothing has gone wrong. It is very common for contracts to contain something called a termination for convenience clause. Therefore, co-dev introduces an element of scalability and flexibility that larger studios would struggle to replicate. If there is a particularly complex or large sprint there is nothing stopping you bringing in an extra studio for a few weeks, assuming they are happy to do that.
  
• Geographic advantages, follow the sun development. With studios based all around the world it would be possible to arrange 24/7 development on a game. Not to mention that this might aid with localisation efforts that inevitably arise at some point as local developers are likely to be familiar with the localisation requirement their jurisdiction might have.
  
• Shared learning and knowledge cascading. With more specialists involved on a project, if properly built into the services, there is nothing stopping studios from sharing their expertise and upskilling each other. This can be mutually beneficial and doesn’t necessarily result in a vampiric skill drain relationship if properly negotiated.
  
• Enhanced testing and QA. When you have multiple studios working on the same problem, issues are way more likely to be brought up earlier compared with a single team owning that process who might be more keen to keep certain bugs under the rug from the higher-ups so that they can fix them without anyone knowing. Whilst this is a pretty cynical view and I don’t base it on any particular examples, it is simply human nature to try to hide mistakes when they occur. Where multiple co-dev partners are working on something, they will be attuned to the fact that issues caused by one team are likely to knock-on to others, and so it is more likely that these issues will be brought to the fore before they snowball.
  

Challenges in Co-Development

Despite the undeniable upside, co-development comes with various challenges that may require additional management:

• Communication Barriers: Ensuring seamless communication between teams, possibly across different time zones and languages or cultures, is crucial. Whilst you’re probably still faced with some communication challenges with a large studio (especially working across offices around the world) you’re likely to be built for internal co-operation already and people might already have a shared vocabulary and knowledge of game engines and tools used internally. These things need to be taken into account and that might require some level of onboarding/familiarisation.

• Quality Assurance: Maintaining consistent quality across all components requires rigorous testing and coordination. Centralised QA might be the way to go, whether this is an external partner or kept in house, it is important to ensure that the same standards are being used across the project and that there is some sort of final QA process to ensure that everything comes together in the way it was intended at the end of the process.
  
• Intellectual Property (IP) Rights: Clearly defining who owns what IP is always an important issue to manage. Whilst it will be easier to delineate the ownership rights in the core IP of the game, it is likely that someone will invent a new process or template or tool for something that has utility elsewhere in other projects. Contractors will be keen to retain better ways of working or better tools or templates, and it is important to have this conversation in advance to avoid dispute/disappointment later down the line. Adding to the complexity of the issue of IP ownership, many developers might use third party tools or develop their own tools for a specific job as they are likely to have specific tools that suit their niche better, it would therefore be important to ensure that if those tools are going to be required to carry out maintenance later down the line that appropriate licenses are sought at the outset to avoid potentially paying out a ransom later. If it isn’t possible to acquire rights to utilise those tools, then that is going to require a different approach and hence this needs to be considered well in advance.
• Radical revisions and changes in direction. Whilst it would be unusual for a game to need to modify its core gameplay loop as a result of porting (other than making content changes like removing dismemberment options for Japan or reducing blood and gore for Germany) this might well be necessitated in a co-development arrangement depending upon how it is structured. If one partner has a creative idea or decides to re-write an element of the story then these things are likely to have knock on effects in other areas. This kind of radical shift in priorities and development objectives would need to be accommodated for in any contract for co-development.
• Problem ownership. Ensuring that each partner has clearly defined responsibilities helps to direct solutions where required. It is therefore important not only to agree who will be responsible for something but also take into account future failures post-launch and have a mechanism which allows for some maintenance or correction if that is ever required later down the line. This might also be required for future interoperability requirements. Good documentation will never be a bad idea and it’s even more true in this scenario.
• Revenue sharing models. Whilst it would be totally fine to remunerate a co-dev partner by simply paying them for their time, things start to get a bit complicated when you introduce contingent payments or royalties etc as if you want to offer that opportunity to multiple co-dev partners you start to have to consider potentially complex formulae to determine what revenue sharing arrangements look like. You can get pretty creative here, but ultimately this might require some kind of subjective assessment of value in order to attribute a particular share and any time subjectivity is involved the potential for dispute increases. Payments will always be a key consideration in any business model, but with co-development with multiple partners it will certainly require a lot of thinking ahead to ensure that partners are treated fairly and understand how revenue might be shared depending on the variable contributions of others.

Selecting the right co-dev partners

Whilst global studios have demonstrated that AAA games can be made by several different studios working together all over the world, they’re well placed to do that because they own so many studios and can effectively operate co-development largely in-house. Smaller studios won’t have that option unless they acquire other studios, so that’s fine for Microsoft and others but less compatible with indie devs and mid-market teams. How then do you go about picking the right partner?

There are few examples to draw from that are well publicised, but I’d consider one particular example that for me really elucidates the factors that should make this sort of arrangement a successful one, and that example was actually a mod for a well-known game which you might have heard of – Fallout London. Team FOLON were behind the mod for the famous Fallout 4 game and they weren’t co-developing it with Bethseda, but if they had done it could have been even more successful for both parties. What factors made this a success? Let’s explore them.

First off, a bit of background for those who aren’t aware. The Fallout Franchise was picked up by Bethseda after Fallout 1 and 2 were developed by Black Isle Studios. Fallout 3 was the first of the Fallout games to move away from a top-down point and click model into a first person adventure RPG game. Fallout has historically been set in the United States during a post nuclear apocalypse and for many years the fans have been calling out for a version of the game set in England (or at least, English fans were keen for this). Enter Team FOLON.

What did Team FOLON have that aided their success?

1. Specialists with a passion. According to their own website, and as is clearly evident from the game, every member of the team loves Fallout. Team FOLON was made up of a number of volunteers with various expertise, all of whom had a passion for the Fallout franchise and were intimately familiar with the story and generally just massive fans of the games. Volunteering to do something is definitely different to taking a paid job, and I am not saying that paying people will demotivate them but when your motivation is making a great game and not keeping hold of an income stream – you don’t do anything “just because”, you do it because you want it to be in the game. That attitude is something that might perhaps be more lacking in larger studios sometimes. Key things people really loved were the storylines and the music, though it’s really the whole package that made it such a success.

2. British people, among other nationalities of course. With Brits on the team, they were already familiar with slang terms and various in-jokes among Brits as well as the rich history of Britain that added really deep authenticity to the game leading to greater immersion. I am not sure that a US team could have captured the essence of British culture, history and characters in quite the same way.

3. London – the “real-life” London experience was widely praised for its immersion and novelty moving away from the US-centric franchise. Being physically located near where the game is set for the most part, is a huge advantage. It would be costly and fairly limiting to send a US development team over to London to explore it for any period of time, not least because you’ll only absorb what you observe and that misses out on a lived experience.

4. Time. There was no deadline to release the game, and whilst this isn’t a Team FOLON specific feature, it was a crucial reason as to why the final product of the game was so well polished (a few bugs excepted, which Fallout fans are more than used to at this point). Being a volunteer outfit without any pressure to deliver to a deadline for sales meant that things were ready when they were ready.

Whilst not all of these features would apply to a paid co-dev model, there is no reason why there couldn’t be room for a set of volunteers to form part of the process for any game.

I reached out to Team FOLON for their comments as to what they thought contributed to their success and CEO/Project Lead Dean 'Prilladog' Carter had this to say:

“Working on the Fallout: London mod has been an incredible journey for us all. From a game developer's perspective, what really made the project a success was a combination of passion, collaboration, and a shared vision. Everyone on Team FOLON was deeply invested, not just as developers but as fans of the Fallout universe, which gave us that extra drive to push boundaries.

One of the key factors was the strong sense of community within the team (We were a global team too!). We had people from different backgrounds - modders, artists, writers, programmers, all bringing their unique skills to the table. Communication was crucial and we basically lived in the program "Discord", we had regular check-ins, feedback loops, and a culture of openness helped us stay aligned despite the project's complexity.

Another major factor was our commitment to quality and authenticity. We didn’t just want to create another mod - we wanted to build an experience that felt like a genuine extension of the Fallout franchise, but with its own distinct identity. The setting of London allowed us to explore new lore, environments, and factions while staying true to the core themes of Fallout.

Lastly, the support from the wider modding community was invaluable. Seeing the excitement and anticipation from fans kept us motivated, and feedback from early showcases helped us refine the project further. It’s been a challenging but rewarding experience, and the success of Fallout: London is really all down to the dedication and passion of everyone involved in Team FOLON.

Dean 'Prilladog' Carter - Project Lead / CEO"

And guess what? Since developing Fallout London the Team FOLON guys have set up a company – Team FOLON Limited - and they are now looking for future projects, including the possibility of co-development, and I’m personally very excited to see what they do next.

Best Practices for Successful Co-Development

To navigate the complexities of co-development, studios would likely be wise to consider the following strategies:

• Establish Clear Communication Channels: Regular meetings, updates, and transparent communication help ensure all parties are aligned and remain aligned with the evolution of development which can often stray from the day-one brief.
• Define Roles and Responsibilities: Clearly outline each studio's tasks to prevent overlaps and gaps. Duplication of effort can be a terrible waste of limited resources, and crucially time. Ensuring that someone is responsible for project management and that such management is effective throughout the project is essential, which is a great segway into the next point…
• Implement Robust Project Management Tools: Utilising tools like Jira or Slack to track progress and facilitate collaboration can help keep things on track. Most importantly it can help other teams see what is going on in case that helps them bring ideas or new perspectives to the table.
• Foster a Collaborative Culture: Encouraging teams to view each other as partners working towards a common goal and to maintain that teamwork throughout the project is really important. If it starts to feel like “us and them” or a team feels excluded it can really affect morale across the board. With any group of individuals it is generally more productive if they act as a team, but that requires active management to form and maintain that team which can easily take a back seat to work output. Finding ways for people to connect and develop interpersonal relationships also helps to bond a team together and so it can’t just be about the work.
• Plan for Contingencies: Anticipate potential challenges and develop strategies to address them proactively. We’ve noted the issues around IP ownership and others, and it’s all about communication and consideration. Thinking ahead and stitching in time is all about long term savings, not just financially, but time and stress as well. This will require good lawyers who really understand the pressures and objectives involved (Eaton Smith LLP did someone say? – shameless plug but hey that’s what blogs are about really, isn’t it?)

Conclusion

Co-development in the video game industry offers a pathway to create richer and more diverse gaming experiences by combining the strengths of multiple studios. While it does present challenges, requires careful planning and needs clear communication, the possibilities abound. By learning from both the triumphs and setbacks of past co-development projects, studios can navigate this complex landscape to deliver exceptional games to players worldwide in a way that is perhaps more commercially responsible, sustainable, ethical and perhaps most crucially more innovative and fun.

And you should definitely come and speak to us (Eaton Smith LLP) about co-dev contracts, or if you prefer we can just have a friendly chat about video games…