Anyone who has been in the games industry for at least a project will tell you, making video games isn’t easy. As game projects have continued grow in terms of depth and fidelity, so too have the challenges and complexities of crafting them. To meet the needs of large projects and fulfill the promise of their game’s potential, many companies are turning to some form of multi-team ‘distributed development’ model to reach their targets. Whether it’s working on a discreet, easily isolated section of the game, building Games-as-a-Service events and content, or sharing systems architecture and engine features, we are seeing distributed development becoming more wide spread with every project cycle.
Pioneers in this area, such as Ubisoft and Rockstar, have been practicing distributed development for several dev cycles. It’s common for one of their Triple-A projects to be a collaboration of several studios, all building toward a shared goal. However, I’m sure that even they will agree, this is no small feat.
In a tribal industry such as games, distributed development can lead to great difficulties in managing projects. Regardless of whether the business is arranged as ‘work-for-hire’ or as a cooperation amongst equals, the challenge remains the same.
How do you create best practices and great working relationships that see all parties committed to creating something of quality and succeeding together?
Let’s explore some of the problems.
Upon switching to distributed development, there needs to be far greater emphasis on recording, storing, and sharing of what is traditionally tribal knowledge. Team members can no longer depend upon traditional means of communication, such as being able to walk around the studio and holding small casual meetings. The communication problems of working on a 100-person team pale in comparison to working with potentially several hundred people, split across different time zones. (Maybe even different countries, cultures, and languages.) Central knowledge repositories and collaboration platforms are suddenly essential components of the project. They provide developers with go-to locations for news and self-discovery. Plus, users can also find out who to reach out to and message for more specific information. However, they require dedication and discipline to keep them up to date and relevant.
Definitions of Success
One of the most frequent problems experienced is distributed development is a lack of strong definitions – both from people in management positions and members of the development teams. All parties need to have a clear grasp of what is expected from them. There can be no room for misunderstandings about time, quality, resources, etc. Expectations and deliverables must be written down and agreed upon. It sounds simple and straightforward, but it’s amazing how often teams have very different ideas of what they think they are working toward and what the quality bar is. This isn’t a ‘one and done’ situation at the signing of the contract. Frequent summaries and discussions of current and up-coming bodies of work are necessary to avoid divergence. Games are organic and can take on a life of their own during production. Therefore, continuous effort must be made to ensure teams remain aligned.
Teams often approach distributed development with exactly the same team roles and structure that they use for traditional projects. But, distributed development can mean there is great need for new roles within the teams. Key positions need to be identified and people assigned to jobs that may not have existed previously. Some examples being,
- Managing relationships
- Tracking progress between teams and solving dependencies
- Providing deep franchise or technical knowledge
- Reviewing and guiding content for consistency
- Teaching techniques used to achieve gameplay or content results
- Troubleshooting - Finding and fixing issues, before they become big problems
- Build and tools managers
Some positions will require members of the team to spend time on-site at different locations to perform work such as training others, observing day-to-day activity, or collaborating on a deeper level. Anyone in these roles must appreciate how culture differs across teams and have good ‘soft skills’. It can be easy to upset people and sour relationships without the right approach and delicate touch. Especially when difficult subjects need to be discussed, or bad news delivered. Having the right attitude is critical – people in these roles are there to provide added value and proactively engage problems. They’re not in the role to tell everyone what to do, and shape things toward their own agenda.
One of the most difficult challenges to deal with in distributed development comes from working with highly-skilled and driven people. Developers and managers alike may define a part of their success (and status) by the title they have, the power they believe they wield, or by the number of direct reports they have. Some individuals view distribution as a form of loss to their fiefdom and fight it. Others aren’t willing to give up control and will view potential collaborators as competitors that must be isolated or dominated. The worst project outcomes often arise from high-level stakeholders indulging in politics, turf wars, or indirect sabotage. They spend their time building walls around their people and areas of ownership, rather than moving the project forward. Their ‘us versus them’ mentality permeates through their direct reports and causes conflict. Such individuals must be confronted and realigned with the project goals as soon as possible. Should these individuals persist, they should be removed before they can cause irreparable harm, regardless of position held or talent.
A Lack of Empathy
Video games are such a hit-driven business, that sometimes we lose track of the human factors. Many people in games have a lot of passion and work hard. They dream big and want to make products that they’re proud to see on their resume. This can lead to a lack of empathy and understanding when progress isn’t stellar, or targets can’t be reached. While companies like Nintendo or Blizzard are able to adopt a ‘when it’s ready’ approach, most other teams are constantly pushing up against the parameters and limits they face.
Taking a step back and empathizing with what other people are struggling with is hard. This is especially true when multiple teams are collaborating on a project, as there’s not always a day-to-day relationship. Teams that are working to support the lead team can have a hard time achieving the desired level of success. They face a multitude of problems such as not being as intimate with the engine and tech, turn-around times on decisions and reviews, or time and distance issues. Because of this, it is important for the lead team to understand what they are struggling with and ensure that they are given the know-how and support they require to succeed. Once of the most naïve and least useful phrases in game development is “Well, don’t you just need to…...?” as it often reveals a lack of appreciation or understanding of a problem. A lack of empathy also often stems from making demands that are driven by needs, and not by the reality of the situation. Knowing when to push, when to pull, and when to back away before someone’s head explodes is a vital skill.
Game and Tools Deployment
Sometimes problems boil down to tech infrastructure and logistics. It can be a headache ensuring that everyone in a single studio has access to the latest game build, tools, assets, and design materials. Once multiple teams are involved, the problem can become a nightmare. Slow or irregular deployment can burn time and expensive manpower. Problems arise due to incompatibility issues between teams working on different versions, and work may grind to a halt due to dependencies. Tech stakeholders from each studio must collaborate (along with the IT department) on architecting solutions that minimize problems and allow for the most stable environment possible.
Distributed development is a unique and challenging beast. While we pour the majority of our time and talents into creating the best game possible, there still needs to be dedicated resources tasked with ensuring the best possible environment for the desired outcome. That means finding the best people, processes, and technology available, then discovering how best to apply them to your project and culture.