Scaling up External Development

External development has become a mainstay of video game productions. It is a way for developers to mitigate costs, increase manpower, and access skills that would otherwise be unavailable.

Scaling external development successfully is a common problem faced by many game developers. While it is relatively easy to manage 3 to 5 freelancers, it is not as easy when the external team is 50 to 100 people (sometimes larger than the internal team!).

Here are a few tips to help you successfully grow your co-development projects:

• Start Small, Scale Sensibly

Like with any relationship, start small and go from there. There are times where I have been approached by potential clients and asked if I could immediately provide 20 to 50 resources to support them with their game production. Situations like these are very tempting for both parties: immediate financial incentives for the outsourcer, and increased production speed and reduced cost for the developer. However, immediately jumping into a large scale production like this can be disastrous. It’s like trying to climb up a flight of stairs 10 steps at a time - sometimes it will work, but most likely you are going to trip and break some teeth. 

Both teams need enough time to figure out things like contracts, communications channels, workflows, tools, and production pipelines. It is much safer to start with a team of 4-10 external developers then grow it from there. Depending on the complexity of a project, training might need to be given to the external team as well. With all these things to consider, you should start looking for external partners months in advance of your production scaling up. Don’t wait till your game goes into full production and you need those 50 additional resources to start looking for a good external partner.

• Test Effectively

When looking for an external development partner, everyone already knows to start with a test. But what makes a good one?

We’ve received tests where the request is to build a singular prop (a chair, a gun, a rock). If you use this as a test, odds are you are probably going to get back 10 similar chairs from the different outsourcers. This does not provide a good frame of reference for the abilities of a company that will be a long term production partner on a large scale.

A good test should assess an external partner’s and your own team's ability to communicate, problem-solve, and integrate from a technological and creative standpoint. Our recommendation is to use something larger and more tangible as a test. For example, building out a small gameplay feature, creating a modular building set, or a full character (from concept to animation). These are still relatively self-contained tasks but will challenge both teams. The test should also reflect, as closely as possible, the actual production workflow. This means that tools, technical specifications, and approval processes should be as close to the real project as possible.

Lastly, we strongly recommend doing paid tests - these are generally more effective as both teams will be invested in the test. The internal team wants to make sure their money is put to good use and the external team wants to make sure they succeed so that they can get paid. It also helps start the conversation about actual production costs and setting expectations for both sides. No one wants to come out of a successful test only to find that the actual work is either too expensive or not worth their time.

• Scaling Management and Working with Levels of Abstraction

As external production grows, the management system that worked initially will rarely scale to match. When an external developer is only building a limited number of items at a time (say 2-5 props) it is relatively easy and efficient for you to generally be more hands-on and check-in at each phase (for example highpoly, lowpoly, texture, etc). However, when production scales (building multiple levels at a time) this is no longer feasible and both sides need to start looking at the bigger picture.

We’ve seen some game developers continue to check individual assets when there are THOUSANDS of assets in production with multiple external teams. They manage such a feat by essentially building an internal team comprised of artists and outsource managers that comb through submissions each day to check and integrate them into their game. While this approach can work, it is not necessarily the most efficient. You are now paying for a team whose job is to simply check the work of others. Furthermore, this type of work is not engaging for the members of this team as they are not able to produce their own art, instead, they spend every day fixing and integrating other people’s work.

It is actually much more cost-effective to empower the external developer to take on these responsibilities and leverage economies of scale. A well-integrated external team should be able to deliver entire stages/levels, features, and characters in-game and working to spec. It may take some time for both teams to get this a level of technical and creative understanding, but it is worth it. By investing the time to bring an external development team to this level, the internal team is free to solve bigger problems and tackle new issues, instead of micromanaging others. It also gives the external developer a bigger sense of ownership and better insight into how to author their work. While it can be scary at first for one side to relinquish control and for the other to accept the increased responsibility, this is the best way to scale up productions for both teams.

• Using the Correct Tools

Over the course of my career, I’ve used a myriad of project management and communication tools from those that are commercially available to those that were made in house by certain game developers (ourselves included). The truth is there is no one size fits all tool. Some work well for small productions, some are better for programming while others for art, some tools work better for film/animation while others work better for games. Heck, we’ve had some productions that were managed only through emails and Excel sheets.

In light of all of this, the most important thing to keep in mind is finding what works best for you and your partners, then getting both sides on the same system. A common mistake is to have the internal team on one system and communicate with the external team via a different one (for security reasons or convenience) - this only introduces more sources of error to the system and barriers to true collaboration. This is true for other software too (file repositories, game engines, modeling software, etc). It always pays to re-evaluate tools and have open discussions between partners about how to better improve communications throughout the production process.

Conclusion

External development partnerships and co-development is here to stay. It enables teams to overcome, resource, time, and expertise constraints and succeed on their products. To do so organizations must grow the relationship sustainably, test effectively for compatibility, adapt management and processes with scale, and leverage the correct tools and technology.