Gentlemen, Start Your Engines

As technology progresses and expectations similarly increase, the barrier to creating impressive titles becomes ever more daunting. If you’re a developer without much of a technological framework to speak of, licensing a third-party engine can appear the best way to develop your game in time and on budget.

It’s a decision that comes with its own perks and pitfalls. Usually the perceived greatest benefit that a pre-built engine brings is that of cost: it’s cheaper to buy a solution that has already been written than to spend the time doing so yourself. If you’ve been given a certain amount of money to make a game, how happy will your publisher be to learn that you’re using their time and money on the development of your in-house technology? No matter which way you look at it, time and resources are being diverted from other areas that may need it more.

ENGINE TROUBLES
And it’s a timely issue to discuss, given the on-going lawsuit between Silicon Knights and Epic, where the former is suing the latter over perceived lack of support for Unreal Engine 3 that resulted in SK building a bespoke engine for its new game Too Human.

John O’Neill, business director at Vicious, the developers of the Vicious Engine, boils down the decision to two choices: you either invest in your technology or you invest in your game – and it’s clear which he thinks is more important. “Given current game development requirements, if a company is founded on the business goals of making games – any type of games – then they should be focusing on building the game content itself.”

For Epic VP Mark Rein, though, it’s important that developers realise the benefits of having pre-built tools. While your art teams may have Max and Maya to work with, if they’re doing so while your toolchain is still in a state of flux, the pipeline for getting that content into the engine is either a blocking point – or could, with just a simple change of functionality, force changes that require assets to be re-worked and re-exported.

“However, if you licence an engine,” he says, “you have the ability to get up and running early in the project. You’ll probably still need to spend some time modifying the engine to suit the specifics of your game, but you should at least be able to start to build content and test your ideas.”

Gameplay programmers can be working on scripts and level designers can be working in the mapping tools from day one. And it’s this saving of time that can make all the difference, says Rein: “Being able to start earlier leaves more time for polishing and fine-tuning – the stuff that distinguishes a good game from a great one.”

DECISION TREE
Of course, even if you decide to look to external technology, there’s still the choice of which engine to use. How do you cut through the marketing and ensure that you pick the engine that best fits your company?

“My main piece of advice would be to undertake thorough evaluations of several competing technologies to work out which would be best suited for the project in hand,” says Mike Gamble, business development director at Instinct, creators of the Instinct Studio engine.

“Don’t just try out the technology itself – include a wider trawl of the internet forums and ask other users to try and get a clear picture of the engine’s real capabilities.”

Using the free trial to accurately determine actual performance is something Rebellion CTO Chris Kingsley is adamant studios should do.

“Make sure you do your homework. Don’t just believe what people tell you about their middleware – demand to see it running on the platforms you need it to run on, and get hands on with the code.”

While it’s important to keep in mind the requirements of your game while evaluating engines, it’s also important to evaluate the company behind it.

“Choosing your middleware provider is more like choosing a development partner – one that is responsible for a sizeable portion of your code,” says Gavin Longhurst, director of business management at MMO engine company Bigworld.

“Studios should also look closely at training, documentation and developer support.”

Support, of course, is a large issue: if you’re banking a big part (or even all of) your company on someone else’s technology, you need to be sure that there’s someone on the other end to fix any problems that might crop up.

“If people have a question about a specific engine feature, they don’t want to wait a day or two for the answer – they want to call or email their middleware partner and receive an answer almost immediately,” explains Trinigy’s Richard Radmacher. “Responsive feedback and immediate bug fixes are crucial for a smooth development process without delays.”

Many of the technology companies we spoke to were in agreement on one particular point: it’s extremely important that you know exactly what you want from an engine before you go looking. And as Emergent CEO Geoffrey Selzer tells us, it’s important to not only be thinking of what you want from the engine now but your future plans for your company.

“I think it really depends on whether you’re building a company or a single game. If you’re looking to make a game that’s similar to something already out there – if you want to make a jungle-based FPS and you want to ship it in 12 months – well, maybe licensing an engine like CryEngine 2 would be the best idea.

“However, if you’re building a company, you need a solid technology base, a flexible framework that you can evolve upon. In that case, you need to look at an engine that’s architected to be more general-purpose.”

MIDDLEWARY
For those developers that largely use their own in-house engines, however, this last point – the future – is something that they feel studios should be aware of. While middleware may seem the cheaper option at the moment of your decision, it’s important to think how that choice might affect your studio’s future.

If you build your own engine, you can keep building on that technology base as your studio progresses from project to project. However, if that technology base is interlinked with someone else’s engine, reusing that base will is likely to involve re-licensing – which can make that initial ‘cheaper’ decision of licensing middleware cost more money in the long run.

This cost is something Codemasters saw as it began developing its new in-house engine, Neon, which it recently debuted in Colin McRae DiRT.

“By using the technology across more products we begin to see bigger and bigger cost savings, as opposed to having to licence middleware technology for more and more titles,” says Gavin Cheshire, VP of Codemasters Studios. “You actually do save development time and hence costs by maintaining strong support for your own tech.”

Also important to factor into the cost equation is how much of the middleware is relevant to your game.

“Be realistic about how long it would take you to write what you need,” explains Andrew Oliver, chief technical officer at Blitz, which has been using its in-house developed BlitzWare platform for over seven years.

“If you want a physics engine, then it’s not a case of saying how long it would take to write Havok – it’s how long it would take to write what your game requires.”

The other problem with using an externally built engine is one of control: the code you get is written and maintained by someone else.

“We’ve used middleware before, but for us it was a sudden loss of control we couldn’t stand. We’d always been in a position to fix our bugs, but now there were fixes that we had to wait for other people to do,” says Oliver.

It’s a concern Rebellion’s CTO Chris Kingsley shares: “If we promise a publisher to deliver a game on time and to a high standard, it’s essential we can meet our promises. I’ve heard plenty of horror stories of bugs in some middleware tripping up milestone delivery and even submissions.”

MIDDLEGROUND
Having an in-house technology platform is certainly a noble goal, but it’s also one that many are aware is unfeasible in certain situations.

“The benefit is huge, but so is the investment. If you’re a new start-up studio, it’s a really tricky decision,” says Frontier’s David Braben.

Oliver agrees: “Things have changed a lot over the years. It would be massively difficult and expensive to create a competent engine from scratch now. If we were just starting out in business, I’d find myself forced to buy an engine.”

It’s important to realise, though, that while you need to consider the future implications of your decision, it doesn’t necessarily mean you’re doomed to keep following the path you’ve chosen.

When Valve had just started up and was deciding whether or not to develop its own technology, it evaluated its internal capabilities and realised that no-one on the team had experience on building an engine.

“When we did that analysis,” marketing director Doug Lombardi says, “it was fairly obvious that licensing the Quake technology was the best choice – we could make Half-Life by adding some animation and AI code and release our first product in a reasonable amount of time.”

When it came to Half-Life 2, however, Valve found itself in a more fortunate position and was able to build its own engine, Source, which it now licences out to other developers.

There is a comfortable halfway house though: so-called modular middleware, which allows you to develop the parts you feel capable of doing and licensing the others.

“Modular middleware gives developers more options,” explains Vicious’ O’Neill. “They can now license a full package and use everything that is included by default, they can buy a pre-built engine and enhance it with modular solutions from other vendors, or they can build the core engine themselves and include modular pieces as needed. It’s a great situation for developers.”

The answer to the dilemma may lie in modular middleware, but one thing is clear: the decision is not one to be taken lightly. “Not all middleware is created equal: some is great and some is fatally flawed,” concludes Kingsley. “The history of middleware is littered with promises – so beware of the hot air, and do your due diligence before you make your final decision.”