What’s going on here?
What do I mean by “modern game development”? Well, I’m talking about game development growing up and becoming serious. Not as in “serious games” (yeah, I find it hard to take the likes of “Food Import Folly” seriously too!) but as in serious development and serious business – the biggest, most complex projects in videogames – teams of 200 people with budgets measured in tens of millions of dollars. The complexity and scale of game development has always grown rapidly, but in the last 10 years we’ve crossed some kind of dividing line and entered a world of seriously tough problems.
When you look at the industry’s recent sales figures, you might be forgiven for thinking everything’s rosy (these are US retail software sales, in $billions):
These figures were taken from here. I couldn’t find the original source of the figures for all these years, but from 2002 onwards, they seem to match the figures given by NPD precisely. They’re just for US software sales at retail (i.e. no online sales or subscriptions).
This has been a golden era, financially speaking. But digging a little deeper, problems are everywhere you look – in the industry, in businesses, in teams and individuals.
Industry-wide, funding is the ultimate problem for most developers. You can struggle along for a while with a variety of other problems, but money troubles are harsh and inescapable, and unfortunately common for bottom-of-the-food-chain independent developers. The developer/publisher model has left independent developers in a constantly-precarious position: according to TIGA, the number of independent game developers in the UK fell from 400 to 150 between 2001 and 2007, through closures and buy-outs (buy-outs aren’t necessarily problematic but they are in general a symptom of the weak position of independent developers). Right here in Dundee we’ve seen 2 major closures – VIS Entertainment peaked at around 200 staff (about 20-30 in Dundee) before closing in 2005, while Visual Science shut down in 2006, laying off about 100 staff.
When an independent developer grows from 20 to 200 staff, support functions are heavily stressed. Admin, IT, finance and HR have to grow (or even be created in the first place). This type of growth is tough to anticipate and plan in advance – so it often happens in reaction to pain. Perhaps your network goes down big-time just before a milestone, or your source control server dies with no backups, before you decide to take IT support seriously.
Recruiting to grow at this rate is tough – firstly to advertise and attract applicants, then to filter applications efficiently, and finally to interview and select effectively. You can end up in the weird situation if falling behind schedule even if you’re doing development perfectly, simply because you can’t hire people in time. Then there’s office space. Your current office is unlikely to have that much expansion room, so you need to move. That can be painful in its own right. Try being behind schedule because you’ve no room to hire the people you need!
At the team level, management is a common failing. The human/social problems posed by growing from 10 to 100 people are enormous, and extremely subtle compared to technical issues. It can take quite a while to recognise root causes of problems, if you’re good enough to recognise them at all. Many big game projects in recent years have been utterly chaotic.
Do you recognise this story? Back in the old days, a smart kid turns out to be a whizz at squeezing performance out of the hardware of the day, and becomes your ‘lead programmer’. In a team of 2 or 3 coders, this means they take on some of the biggest technical challenges in the game, as well as ultimate responsibility for ensuring everything works. They become legendary for late night hacking sessions and assembly optimisation. The team grows rapidly and before you know it, in the space of 3 or 4 game projects, you have 20 or 30 programmers. ‘Lead programmer’ sounds like a management role, or at least it seems to exclude making anyone else manager of the software team. But now you realise this guy has crap people skills. He continues to spend his time on assembly optimisation and ignores the management needs of the job. Chaos reigns in the software team and late night hacking sessions are the best or only solutions he knows. This pattern must have been repeated many times in game teams around the world.
Ultimately, it’s individual developers and their lives/families that get screwed by poor management. I probably don’t need to mention ea_spouse, and there are plenty more cases. In fact I’d bet most developers have been in this type of situation at some point – some have just received more public attention than others.
Writing software in a large team is necessarily a fairly new activity for programmers who’ve always worked in games. They’ve had to adjust from a lone role, writing primarily for a machine (game development has always had a fierce focus on squeezing maximum performance from hardware) to writing for other people. Performance is still important, but programmer time has become the real bottleneck, so software engineering concerns have been thrust upon game teams in a hurry. Poor software engineering and architecture often becomes apparent only when it’s too late; teams have to battle through as best they can and try to do better next time. Problems from poor development processes and practices also manifest themselves when the project reaches its critical phase, and again it’s too late. When projects last 2-4 years by default, this feedback loop is too slow, the opportunities to reflect and change practices too infrequent. With the pace of change I’ve been describing, the next project could be an order of magnitude bigger, and lessons learned from the previous effort aren’t even enough.
There’s more, but …
I could go on and on. How can a game designer shape a game to their vision when they’re dependent on so many people to implement it? How can develoeprs take risks on unconventional game designs when development costs are so high? I haven’t mentioned the usual technical pace of change, pushing the bar on new and ever-more-complex hardware. But enough. It’s not all bad:
- Not all teams are massive; many companies are finding ways to reduce team sizes. The rise of casual gaming, and Nintendo’s recent comeback, shows that we don’t have to be in a weapons race.
- Game developers aren’t the first people to run large, complex projects – so there are plenty of solutions to be found and imitated from outside the industry.
- Fast growth is a nice problem to have – better than not growing
- Most of these problems are simply challenges and opportunities for smart developers to overcome and succeed – and the rewards for the best will be great.
I love it
At Realtime Worlds, we’re living through this growth, and doing rather well at it. It’s exhilarating to be tackling challenging, complex projects with incredibly smart people, constantly learning and improving. We’ve grown from about 10 to 200 employees, raised $80 million of investment, released a number one hit game and moved to custom-built offices. We have the best-managed projects I’ve seen or even heard of in game development, maintaining a good work/life balance for our staff. And our best times are still ahead.
So, I promise not to whine about problems, but instead talk about things we’ve solved, and discuss ideas we’re trying. My main areas of interest are software engineering, project management, education, recruitment and people management. If that interests you, stick around. This is a tremendously exciting time. Welcome to modern game development!