Distributed Development: Is it a Buzz Word?

STRAYING FROM THE MESSAGE:

Conventional Outsourcing, and Distributed Development (The Buzz Word Version) for Game production, are progression steps leading us to “True Distributed Development”. If you can imagine game development as a pie comprised of its crust (infrastructure) and filling (asset creation resources), then up until now the majority of outsourcing in our industry has been the outsourcing of the filling. The sooner we understand this, the sooner we will progress in making changes to the way we support outsourcing.

"Distributed Development" attempts to signify progress and innovation when used like a buzzword in today's game development industry. Its purpose when used in this way is to impress, straying the message away from its actual meaning and sidetracking our industry from a very important and needed step in our evolution of True Distributed Development. Let's review the reasons and various methods, that lead us to Distributed Development and approach how we can transition away from using it as a Buzz Word.

DEMAND FOR SCALABILITY:

Today's game developers are faced with the challenge of scalability. As technology advances, so does the market’s need for better quality, more content, and speedy turnaround on products with increasing demand while expecting a reasonable price on products.

CURRENT ENGAGEMENT METHODS:

Outsourcing is one solution to this challenge and is gradually becoming an integral part of the studio game development infrastructure. Planning game production as a consolidated workforce and occasionally handing off work to an external partner is the more conventional outsourcing approach, where assets or pieces of assets are taken out of the native development environment, then outsourced without any attempt to replicate the native pipeline, and then the assets are re-integrated back.

Distributed Development on the other hand can be considered a more advance method of outsourcing with a structure that is adapted into a distributed workforce where the development environment is expanded across more than one location.

Before we understand Distributed Development and its importance, we have to understand its predecessors and their differences.

CONVENTIONAL OUTSOURCING:

Conventional Outsourcing is likely a developer’s first choice to address the issue of scale for a production team. It will involve a developer breaking down their assets into small sub pieces and offloading those bits to an external team. This is sometimes called "Over-The-Fence" Outsourcing.

You can easily recognize conventional outsourcing when external production is not integrated with the use of the internal pipeline technology. In this scenario, internal and external teams are using very different methods to create assets and often an external team will have a limited understanding of the context of assets and how they are used in the game.

Using art outsourcing as an example, the make-up of a 3D character may be comprised of multiple pieces that are grouped as a Unit. This Unit is then outsourced into sub-assets as a Character, weapons, armour pieces, etc. Often, experience shows that external partners will not be assigned greater ownership of an asset as it can be deemed too difficult or high risk. Assets are then segmented into pieces used in the asset creation pipeline and outsourced separately, limiting the team's insight into the assets they are creating. An internal artist experiences a full understanding of a unit by working with the different disciplines within the team, creating a familiarity and context to how it works for the game in a more cohesive manner. In comparison, an external resource's understanding is limited to what they have been exposed to. There is nothing wrong with this type of outsourcing, however limitations of this method become more visible when attempting to do large scale work.

More volume means more dependency on the completion of external assets, as the scope of work becomes widespread enough to impact all disciplines within an internal team. Without the developer pipeline in place at an external team, there can be be little context of game-play usage, and many tasks associated with integration fall on the internal team. This can likely cause an integration backlog of work and a lot of potential rework. At XDS 2014 I discussed how this is generally a good sign to move out of conventional outsourcing and to the next level (External Development Summit 2014 - The Metrics That Matter).

DISTRIBUTED DEVELOPMENT “The Buzz Word Version:

Distributed Development "The Buzz Word Version", is an external team with an established pipeline comprised of developer's tools, which may include game engine, export process, and version control system all setup at an external partner. This setup allows seamless integration of assets between internal and external teams, creating a closely shared working environment among the teams.

This is unlike Conventional Outsourcing, which has limited access to the developer's working environment. In this scenario, an external partner will supplement their team with additional technical resources to support the foreign pipeline (as provided by their client) into their existing production environment. Larger scope of work is possible with this method while an increase in scale doesn't impact an internal team with a backlog of game integration tasks and re-work, where conventional outsourcing likely would.

So you've now expanded your technical pipeline to an external location empowering your external team to manage more scope, and offer better context of the assets they are creating, so what else can you do to evolve production and expand scalability?

The biggest oversight we make as developers is that we don't recognize that scalability is not only about asset creating resources, but scalable infrastructure support. Many developers who engage in outsourcing have not experienced large scale production in a consolidated workforce for potentially two reasons.

Of course, there are also developers that have very large teams and have little to no outsourcing to support their scale. It's possible with the large developer there may be little potential for external scalability, as they see the limitations of scale with a Conventional Outsourcing method, but not considered the best way to go to the next step of Distributed Development.

DISTRIBUTED DEVELOPMENT “The Real Deal”:

True Distributed Development is “The Real Deal” and understands that scalability requires both asset generating resources to scale, along with scalable management and infrastructure. True distributed development considers that design, concept, programming, UI, gameplay, QA, managers, and artists are all supporting development, so why would we not consider supporting external development in a similar way.

The best example of Distributed Development can be found with externally developed level building projects where Technical resources to support the development pipeline is not enough. For an external partner involved with level building their team structure will likely comprise of a specific level producer, designer, programmer, concept artist, and art director to help support the asset creation team. This example of Distributed Development, not only includes the integration of a developer’s tech (creating a shared working environment), but many more developer disciplines and their roles are involved with the external team or those roles are replicated on the external team creating a true extension of the developer’s team environment. This is when Distributed Development no longer becomes a buzz word.

EVOLVING THE PROCESS:

Outsourcing has evolved into a means to tackle the challenges of scalability within Game Development. The future continues to push demand, and Distributed Development is a solution that allows us to scale our Outsourcing. Unfortunately, growth in Distributed Development is being confined by the misconception that the “buzz word” version has exposed us to.

True Distributed Development is the “real deal” when it expands development across distances to include scalable asset creation resources, but exposes innovation, creativity, knowledge, and familiarity of the product to external teams. Supplementing external production with the disciplines that support a developer’s asset creation pipeline, only further re-enforces the external team’s infrastructure, allowing for far more growth and scale than previously possible.

Recognizing the differences between various forms of Outsourcing and True Distributed Development, gain the Industry a considerable tool in solving the challenge of scalability and meet the ever growing demands of future game development.

Additional articles published by Dilber Mann

https://www.linkedin.com/pulse/20141021022848-7011546-distributed-development-is-it-a-buzz-word

https://www.linkedin.com/pulse/20141111034448-7011546-how-studio-culture-can-fail-in-a-distributed-workforce-structure-in-asia?trk=prof-post

https://www.linkedin.com/pulse/how-massage-changed-my-working-dilber-mann?trk=prof-post