Part 2 of “Building World-class Art Tools” from Develop 08
I’d like to take you back in time momentarily, to older games. The further back you go, the less significance content creation held – far enough, and the very term “content creation” presumably didn’t exist. Limited storage space on the hardware must have played a role, and the limited graphical fidelity of those machines limited the value of content in any case. The consumer market may have been a limiting factor too.
Fast forward to today, and thanks to Moore’s law, we have space to store a massive amount of game content. The graphical effects we can achieve mean artists have the ability to bring their dreams to life; meanwhile, our mass-market consumers will pay for this stuff. Content is hugely important, and your game’s budget probably reflects that. MMOs push the trend even further, with the need to provide fresh content as a service to your paying customers.
I don’t see any limit in sight for this trend. In the long run, it’s pretty obvious that underlying technology will become commoditised, standardised and open-sourced as techniques become well-known. This has already happened throughout much of the software world: just look at Linux, Firefox, Open Office and Apache, to name but a few examples. Constantly-shifting hardware has helped to protect the world of proprietary game technology, but this can’t last forever. I think we may have already reached the point where new hardware advances are going to gradually lose their significance; the DS and Wii have proved that you don’t need cutting-edge technology to be commercially and critically successful any more, and I observed at Dare to be Digital that students can make surprising progress with current open source game engines. I’m not saying that cutting-edge game technology will stop advancing, but that the general trend will be more games based on content, less technology.
This trend should lead to positive reasons for building in-house tools. If content, not technology, becomes the key differentiator and competitive advantage of one game over another, then the means of producing that content will become of critical interest to any developer. It’s a big if, but if you can create in-house tools that improve the content you’re able to build, then you get away from the “good enough” problem I described last time. Such tools will be important enough to your business to be worth polishing and perfecting. They will be better than “good enough”.
If you’re a tools programmer, you should be thinking constantly about how you can help your content creators. As a programmer, this should come naturally – it’s like optimising code, only applied to the content production process. As with code optimisation, start with measurements. Hopefully there’s schedule data available to help you do this; talking to the artists should help too. Uncover bottlenecks, and you’ll know where resources should be focussed.
Of course, your production and art teams are probably already analysing the content production process this way, and the answer to fixing bottlenecks is frequently not building in-house tools (other possible answers include buying commercial tools, outsourcing content production and hiring more artists). But as a tools programmer, you’re uniquely qualified to know what’s possible to build, and to spot opportunities for tools to solve problems.
This is just one example of how all programmers should be thinking about the wider context of their work, and how to help the project as a whole. Adding breadth in this way is by far the easiest way to get better at your job, because at a certain point, simply getting better and better at programming has its limits.
Next time, I’ll look specifically at how in-house tools can help content creators.