MCV/DEVELOP News, events, research and jobs from the games industry
As readers of Develop will have noticed in our supplement last year, at Kuju we have a diverse set of studios developing a broad set of games. We embrace this diversity, as it’s what has made us successful in what can be a difficult market.
Historically speaking, we’ve built a lot of technology ourselves, and used it widely on many products. Our current “Heracles” 3D renderer has achieved excellent return-on-investment, to date shipping nine unique titles (such as M.A.C.H. and EA Rail Simulator), and more in the pipeline, with previous generations of our technology achieving similar coverage.
As we’ve grown, we have freed our studios to make the right technology choices for each game, rather than imposing a ‘one size fits all’ solution – and we are very committed to continuing this philosophy.
Take, for example, our use of BlitzTech on the recent highly acclaimed House of the Dead: Overkill for the Wii. Blitz Games Studios had successfully used its technology on a number of its own titles, and at around the time we were beginning this game with Sega, Blitz was looking to build on its technology’s success by licensing it out to other developers. We rapidly identified a good three-way fit between the capabilities of their technology, the requirements of this game, and the Wii expertise of our Kuju London studio (now Headstrong Games).
We worked closely with Blitz to customise their flexible technology to the game’s needs, and applied a number of our own pieces of Wii code to enhance it. For example, we integrated our established particle effect solution, added our own water rendering technology, and other custom effects such as gore decals. This has resulted in some stunning visuals in House of the Dead: Overkill, now amongst the best Wii titles on the market.
Elsewhere in the group, our Chemistry team have become experts in Unreal Engine 3. They have pushed the engine to do some surprising things – not always the expected traditional shooter elements. Our content creators love the freedom and power Unreal has given them, and are extremely productive. I genuinely look forward to the deliveries made by our Unreal based teams – the art they’ve achieved with this tech will blow you away.
We also enjoy working with other middleware providers – we can’t expect to build everything ourselves, and there are some great third party components. We’ve begun a relationship with Scaleform, providing us with its market leading GFx user interface technology. Our decision to adopt was driven by a number of factors – a high profile, big budget title deserved a correspondingly top-notch user interface. Secondly, we wanted to hit the ground running, without spending months engineering the UI (and we had typical milestone pressures). Thirdly, we were impressed by the high performance of Scaleform – we’ve attempted to implement Flash renderers in the past with mixed success, performance being a key challenge.
Then, of course, is our recently announced ‘Fabric’ technology. This is about being truly many-core; many have failed to fully use the massive processing power that’s already there (and I’m not exempting us from this in the past – we wanted to do more). Just sticking physics processing on one of the Xbox 360’s CPU cores and AI on another, or treating the PS3’s SPUs as a set of slave coprocessors for animation is not true multi-core programming. It won’t scale to many-core devices – by which we mean systems with tens or hundreds of processing cores.
Reading the coverage since our announcement, I’ve been gratified that people feel more needs to be achieved with the current generation of hardware – and moreover that they think it is actually achievable. To make this technical leap you have to take a fundamental look at how you build your code, right up to the high level game components. It entails training much of your programming staff, and getting them into a streamed, job-based mindset.
You might ask why we’re making this investment, rather than totally rely on middleware. There are lessons from history here. A number of people went down the Renderware route, and I remember people at the time saying “Why don’t we just use Renderware for everything?”
It seemed to be turning into the de-facto standard for game development. Then, for those that followed this path, the rug was pulled from under them by its removal from the market, leaving them reeling. And, to be honest, even back then when Kuju was smaller, we just didn’t believe a ‘one size fits all’ solution was sustainable or that Renderware was the panacea that some made it out to be.
It’s deeper than that though: we are utterly driven to squeeze the best performance out of the current multi-core platforms, and what’s coming on many-core in the next two years. I’m not pretending we’re alone in this drive; others will be treading this path. Right now, there just isn’t something on the market that does what we want.
To be absolutely clear, this is very much an internal project – we’re doing it to make our games better, not seeking to license it out as middleware; that just isn’t where our business focus is at. I’m looking forward to talking to people about our experiences, though.
We remain true to our diversity and policy on no central imposition – and I wouldn’t dare claim that all of our games would be using Fabric in two or three years from now. I’m sure the many far reaches of Kuju will do more specialised things that this tech isn’t the best choice for: I can easily see us continuing to use Unreal for games where it makes sense, for example.
Fabric has been co-developed by Headstrong Games, Zoë Mode and doublesix, who all see a core of common technical aims, despite their varied product line-up. Ultimately they are going to be targeting the same platforms, will hit the same performance constraints, and need to be competitive. Just wait and see what we’re going to achieve.
