Sunday, March 05, 2006

Ask Not for Whom the Bell Tolls

So I've been asked a few times in the last two days. 'Oi Tadhg,' goes the mail, 'Are you on that Lionhead consultation period list?'

And the answer is, sadly, yes.

Over a specific period of time in the next few weeks, a period of consultation will determine who can best be kept on and placed in one of several studios, and I shall not publicly speculate on what I may be eligible for, how many positions there are exactly, nor the fate of myself or my colleagues. This is post is not about that (though I will give credit to Lionhead in the manner in which they are handling what is a difficult situation), I'm merely using the news as a jumping off point. Which is to talk about the job culture in the industry in general.


I was down the pub with two developer friends of mine on Friday (after the bad news), having what we like to call a 'swift half' (which became a swift three) and we were talking about what a difficult place the industry is to work in. It's perrennially uncertain, but also caught half way between two problematic poles.

They are the need to have staff resources close to hand while at the same time not being able to maintain them. It's a problem that affects the whole industry once it goes beyond the 4 or 5-man team level, and the reason for the problem is that game development is basically one big game of pass the parcel.

Suppose you figure that to make a big 3D space arcade game, you're going to need 40-ish people. Those people will, very roughly, consist of 15 audiovisual people (artists, animators), 15 technical people (code, tools, scripting) and 10 design and production people (producers, lead designer/game director, designers, mission-level designers) plus maybe 1 sound guy and an indeterminate number of testers.

It stands to reason that the animators will not be busy during the early days of the project, and the engine coders will really be down to the level of fixing occasional annoying bugs toward the end. So the solution is to hire people onto the team gradually, which is what most teams do. So the teams grow slowly over time, sometimes more quickly than others depending on the production management and financial concerns, but the upshot is that at the end of the project there's usually quite a few people who've been hanging around.

In fact, my theory is that even under the most optimum conditions, no development team is operating at more that 40% busy at any one time. What is happening is that individual departments grow more busy, followed by less busy ('polish', if you like), and so the aggregate of being busy is about 40%. Which leaves a lot of people essentially hanging around.

But why have them hang around?
Why not hire them contract and let them go when they're not needed any more?
Because hiring people is actually difficult.

Suppose you are an animator being offered a six month contract at a studio in Leamington Spa through a recruiter. This involves several factors for you, the most pressing of which is that the company is asking you to move your life for a six month period. To Leamington Spa. How likely are you to do it?

You're likely to do it only in one of three conditions.

1. The first is if they offer you a LOT of money, plus moving costs and various other benefits thrown in. This makes you and your recruiter very happy.

2. The second reason is if you are green in the industry and therefore looking to cut your teeth. There are a lot more green people in the industry than veterans because of this, because veterans decide that they don't want to move house unless its for a ton of money, and developers think that maybe two students can do the same job as one veteran.

3. The third, and pretty remote, reason is if the project itself is something that the animator is genuinely passionately interested in, they may make the move. Although it has to be said that this is a pretty rare occurence.


So it would seem that the solution for the company is therefore not to make itself so difficult because of location in the first place. Actually, not so. Given that teams tend to swell as games develop and projects try to complete, the problem that developers have is facilities. The rent in an office in Leamington Spa is considerably cheaper per square foot than it is in central London, and games being as they are longer-term projects than your average piece of post-production work or TV ads, the economics come down on the wrong side for a development company. Centrally located developers tend not to last because they can't pay the rent.

The upshot is that a lot of companies big and small end up trying to hire people permanently, or on a rolling contract at the very least. Be they big publishers, or mid-size developers, the juggle between people hiring and rent keeps them in an awkward middle ground of pass-the-parcel either within teams, or between teams. It's the middle way.

The problem with the middle way is that it is not flexible. When your company is permanently committed to having a staff and possibly a tools division, requisite administration staff, and so on, it becomes a lot less flexible again. Companies of that size have to become much more formalised affairs, but at the same time the atmosphere in these companies can become like silos, as I mentioned in my last article.

There are several potential solutions to this problem, though each is not without its downside.

The first is Don't Grow. Develop a working structure that means you simply refuse to hire new staff for almost any reason. Some jobs (like audio, or dialogue) can be contracted out ad hoc as needs be anyway, so you do that, but in the main you keep a fixed number of artists, programmers, designers and so on plus or minus the odd guy. What a company that does this is doing is creating a family environment where everyone is in it for the long haul, and such companies adopt the 'It's done when we say it's done' approach. 3D Realms, for instance, would appear to be pursuing this strategy - but it does mean Duke Nukem Forever may take an Ice Age to turn up.

The second solution is Find a Steady Income. Game development is not, by nature, a steady income business. It's a pulse-driven business, where large cash injections cover long periods of losses (if all goes well) and therefore difficult. Steady incomes do exist, however, and they are called 'subscriptions' and 'pay-to-play'. Subscription-based gaming is becoming a more and more interesting proposition as time goes on, catering as it does to loyal long-term customers and focussing on a gradual but steady wad of cash coming in the company doors. MMOGs are one example, but so too are the huge rise in the likes of poker sites, niche games like Puzzle Pirates, and accessing another world in Second Life.

The third solution is Grow Like All Crazy. Rather than remaining modest, in this strategy you hoover up investor cash, Wall Street cash, whatever you can and you create twenty teams, each passing around common resources like animators. This strategy basically demands that the developer find a usable product line that can fund such an expansion (A GTA or a FIFA), and then pour the cash into opening offices world-wide, creating large teams etc, and becoming a publisher. EA do this. Take Two have taken to doing this since they struck it lucky. Unfortunately this isn't a solution that many have the opportunity to use, but it is a solution for the lucky few. Whether it works or not is another question, as such growth tends to mean importing full corporate structure and a whole management class pretty darn quickly, and that can have devastating effects.

The fourth solution is Look To India. Outsourcing, basically, in one form or another involves trying to defray the costs of all this by getting cheapo lackeys to do it overseas where everything costs so much less and they are increasingly very well educated. It's a solution that several companies are pursuing vigorously, and one that they are also discovering is not as easy as it first looks. Outsourcing typically requires a lot of hand-holding and a heavily focussed management, and even at that is questionably reliable at best.

The fifth solution is Pay For Work, Not For Time. In this scenario, the development company stays very small, focussed on production and design and core technical staff only, and everything else is sought elsewhere. However, rather than the typical 6-month-contract staff approach, the company contacts individuals (or vice versa) and contracts them for individual pieces of work based on flat fees. Rates are negotiated as in business, and payment on completion according to strict criteria ensures work quality. This is the Stubbs the Zombie method, basically, and though Stubbs itself didn't really fly as a game, the method itself has strong potential, as it doesn't need large offices or facilities. Most everyone in game development has a home PC of their own, after all, but why oh why game development companies aren't taking advantage of that fact is a mystery.

The sixth solution is Devolution. This relatively new piece of thinking has it that the traditional silo-structure of companies doesn't really match up with the far more flexible knowledge worker of today and tomorrow. Rather than having teams where 60% of the staff are relatively idle (as an aggregate), what the development company does is split itself into several companies along discipline lines rather than project lines. So you have an audiovisual company (art and animation), a tools company, an engine company, a design company, a sound engineering company, and all these companies maintain a high degree of autonomy, though still connected to the whole through a central administration and production company. The different companies are responsible for their own profit and loss, and this means that they go out and look for work. So when the audiovisual company is not particularly busy working on the company's internal project, it can be busy working as a for-hire anim studio. Designers can consult, tools companies can make software and sell licenses to other studios, and so every discipline becomes a part of the value chain in and of itself.

The seventh solution is Game City, where the development and publishing industry centralises to the point that there is no one single developer any more. This solution is esentially like 'what would happen if al the companies devolved in the London area at once'. What would happen is that all the separate companies would become so nimble among each other that the industry would become completely broken down into sub-blocks freely moving among one another, and this is possibly what will happen by default in the long run.


Either way, I don't envy development companies one bit as things currently stand because the current way that pressures work serve to eventually drive the best and brightest out of the industry into IT, film, and any other industry where security, compensation and other factors are far better and more sensibly organised. It's a tough road ahead for many.

Particleblog's comments have moved to The Play Room.