October 2nd, 2014

Why the Hollywood Studio Model Doesn’t Work for Games

Kotaku mentioned an article on Slate entitled What’s Killing the Video-Game Business? The author goes onto assert that more titles should be developed externally in order to save the publishers money and is surprised that is not what EA is doing. For those in the industry, this should seem ridiculous, but I wrote an explanation of why that doesn’t make sense for the Kotaku discussion that I figured I’d repeat here if anyone was interested. So here it is with a few slight additions:

The author really doesn’t understand how the video game industry works. Making video games is NOT the same as making movies! In film, there is a standard set of tools (cameras, actors, lights, etc), but that is far from the case in the game industry. Every game development company has their own proprietary tools, pipelines and technology. These vary greatly, so there’s no way that the game industry can switch to forming a company for just one game and disbanding at the end.

On the art side of things, all game shops pretty much use Maya (and to a lesser extent 3dsmax and XSI), but artists often use proprietary world building tools for placing assets, different tools for lighting, and the pipelines can vary a great deal. (The pipeline is how the art gets into the game) The actual job that designers do varies greatly from place to place. If they do their design purely on paper, then it’s quite easy to move them from project to project. Often designers have to use world building tools and/or scripting languages to set up the gameplay. This can have a steep learning curve, so it’s difficult to move them around.

For programmers, it’s the worst. When companies find a good programmer, they want to hold onto them for life because they are hard to find, and it is very difficult for people to debug code that was written by someone else. This is a fact of any software development and something that film completely doesn’t have to deal with. Technology stays around for years (and in some case over a decade), so you need someone to maintain and modify it that is familiar with it. Whenever a new programmer is hired, there is a steep learning curve until they can get up to full speed regardless of programmer talent. The best in the industry can get up to speed quicker, but no one can ever just pick up where someone else left off. Sometimes companies even want to hang onto bad programmers when they worked on an important facet of the technology and their code is a mystery to everyone else.

The only thing analogous to video game development in the film world is the development of CG movies. CG shops have many developers working on their internal tools and technology.  Dreamworks, Pixar, and Blue Sky don’t disband after every production because they have internal software and artists trained to use them. If it doesn’t make sense for them, it certainly doesn’t make sense for games where the net product is software and not a series of static images.

Bringing more titles in house to publishers makes sense from a business perspective. Although to my knowledge, no publisher has been particularly successful at this, having one shared set of tools, pipelines and technology that they use for most if not all of their titles would give the publisher more flexibility in moving people between projects, which is important from a manpower standpoint. As well, as the cost of each art asset rises as the amount of detail is increased, more publishers will probably maintain a library of game assets to share between their internal teams. Doing more work internally is a cost saving measure. Reversing that would be a nightmare. The only caveat is outsourcing for art and animation, cutscenes and other well defined tasks is definitely going to increase, but the actual production of the game (especially the programming) is going to stay in house.

As someone who just recently started a game company, I don’t want to see all the work stay with the publishers, but from their standpoint, it makes the most sense. If publishers go out of business, that’s not going to help us either, so what is best for them fiscally is best for the industry. I only hope I can get 24 Caret Games established before it’s too late because it’s only getting harder to start a new studio as time progresses. That was one of the reasons why I decided to start it now because it seemed like it was now or never. If 24 Caret Games fails, then I may have to abandon hope of working for myself…

[In response to commentors talking about unions in the game industry] Also, unions are never going to happen. They raise the cost of development. If one did happen, that would just drive more work overseas. There is no shortage of people willing to work crazy hours in any game discipline (especially testing), so unions will never get off the ground. The only time organized labor works is when you can’t find people willing to do the job or when an existing union controls the people who do it currently. I think unions in most fields in the United States have outlived their usefulness and are driving more jobs overseas.

2 Responses to 'Why the Hollywood Studio Model Doesn’t Work for Games'

  1. 1JohnS
    March 12th, 2009 at 10:54 pm

    What about middleware? Isn’t that become a standardizing force in the industry? It seems like in the future we could have small core teams that use standard tools and then you’d easily be able to pull people (like camera operators/editors/etc. in film) that are all trained in the middleware.


  2. 2Matt
    March 12th, 2009 at 11:01 pm

    Hi JohnS!

    Unfortunately, middleware can provide standardized tools for artists and common pipelines, but in order to release a game, hundreds of thousands of lines of code need to be maintained. Sequels are a mainstay in the industry because they help keep costs down and allow iteration to improve on ideas. Middleware won’t help much when trying to get a brand new team of programmers up to speed on the code of the first game.


Leave a Response

Everything on Binary Creativity is © 2006-2010 Matt Gilgenbach. All rights reserved. | RSS | Comments RSS