Gamasutra: The Art & Business of Making Gamesspacer
arrowPress Releases
July 24, 2014
PR Newswire
View All
View All     Submit Event





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
How to not fail in scale
by Samuel Rantaeskola on 04/12/13 09:43:00 am   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.

 

As game teams are growing in scale there are some severe pains in coordinating these efforts. As an industry, we are quite capable and efficient at moving small scale projects from concept to a finished product. When the team sizes eclipse the century mark, many more obstacles and hindrances both seen and unseen begin to rear their ugly head. The general lack of production experience of running projects at this larger scale is handicapping us as an industry at large. 

I am not claiming that the solution I’m proposing here is rocket science in anyway, but rather these are the common pain points I see and hear continuously within the games industry. 

 1. Unify what to do and how to do it

In a small team, continually communicating the vision of the project with each member is a battletested way to keep everyone inspired, motivated and on the same page. However, solely relying on that method when working in the hundreds and adding to that having a game design document that nobody reads, is a sure path to failure. A tight connection between the game design and production plan is one way on how you can approach breaking down the game from a high level vision into actual work. In this video, I talk about a method for achieving that: http://vimeo.com/51747636

Connecting what and how will only take you half way there.  The overarching method of getting to the end goal should be basic enough to be easily explained and understood by the entire team. Within that method, the teams should be able to select the best working formula for them moving forward whilst still feeding in to the whole project.

 2. Decide on a structure

In the early phases of production, you should think of how to structure your entire project. How are you going to troubleshoot it when it’s being built? Bear in mind that it needs to scale appropriately as you will add teams to it. It is also a good idea to iron out workflows early on, instead of defining them on-demand. This process will help you plan how to track progress as you are getting into production mode.

 3. Subdivide the problem

For most in our industry this is given, but there are a lot of teams out there that are looking at the project as one gargantuan jig-saw puzzle. They spend a lot of effort trying to optimize resources and dependencies to the smallest detail and in that jungle of information it is impossible to make good decisions. The challenge is to create sub problems that are as independent as possible from each other.

 4. Build teams around the problems

Everyone seems familiar with the concept of cross functional teams in theory, but in practice evolving to a cross functional organization is extremely arduous. Historically, it has much to do with the outdated culture in the games industry, where the tradition has been to sit with peers in silence. A cross-functional organization scales nicely, and adding a team does not increase the complexity as much as in a departmentalized organization. Resolving dependencies is within the teams and the management overhead can remain fairly sparse.

 5. Decentralize decision making

Accept that you will lose control. A top down driven management style and structure “works” in small environments, but is extremely slow and error prone in large scale development ecosystems. You will quickly realize that this strategy is fraught with hazards and will need to be corrected, if not eliminated outright. Large scale development teams have a lot to learn from the casual game studios’ “shotgun approach”, in so far as, the concept of having independent teams which are the decision makers within their domain.  In this kind of environment, there are no external bottlenecks which slow down the teams’ progress. Naturally, casual games lend themselves well to this style. However, with an early sub division of the problem and delegation of ownership, it can work in more complex games as well.

 6. A team is the smallest unit

Don’t go on a duck hunt to optimize the hours. Trust your teams to make good calls within their area. Every now and then one of the guys in a team will be short on project specific tasks, because he’s waiting for the other guys in the team to finalize the level. Trust me; he can probably think of a million things that he could do that will add value to the game. After all you’re probably hiring talent.


Related Jobs

Gameloft
Gameloft — Auckland, New Zealand
[07.23.14]

GAME MONETIZATION MANAGER
Nexon America, Inc.
Nexon America, Inc. — El Segundo , California, United States
[07.23.14]

Localization Coordinator
Big Fish Games
Big Fish Games — Seattle, Washington, United States
[07.23.14]

Director of Product Management
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[07.23.14]

Software Developer PHP (m/f)






Comments


Michael Joseph
profile image
In massive projects such as Bungie's upcoming "Destiny" we hear how they've reached a playable version only relatively recently and yet they've had a massive 400 (did I remember that right?) person team for some time before that. I don't know any specifics in that regard.

Generally speaking that seems very risky, but it also seems a common strategy during AAA game creation.

Any thoughts about when to ramp up team sizes? In the indie space I know many devs will wait until the tech is ready before really getting serious about content. That has it's disadvantages too of course but it's often necessary to keep the costs down.

Samuel Rantaeskola
profile image
The discussion about when to best ramp up is good topic for a longer post. In short, I think we need to look how AAA projects starts, and how pre-production tends to lend time from production.

Kain Shin
profile image
This is a good list. Allowing oneself to lose control is always a risky trust proposition... even with established lines of accountability. But it's definitely better than becoming a bottleneck and robbing potential heroes of their own opportunities to invest.

Samuel Rantaeskola
profile image
Losing control allows you to build speed at the cost of a lack of control in direction. The trickiest thing is to find the balance between these two. In general, I think AAA productions tends to lean too much towards control and would benefit from loosening things up. As you mention, the problem is typically chain of command, delegating decision making makes you less important which is not pleasing to the typical person in a controlling position.


none
 
Comment: