In-house Party

Your studio uses almost all in-house engine technology. When did you make the decision to develop your own platform?

Andrew Oliver, Blitz Games: For us, it’d be in 1999. We’d been writing games since the mid 80’s, a time when you had to write your own ‘engine’ – in fact, my twin brother Philip and I wrote a standard map editor and ‘cross platform engine’, which is how we did so many Dizzy games in those early years.

But there were a few key moments, when we had multiple teams, which pushed us towards having one internal engine and one set of engine tools all managed by a dedicated technology team. When Dragon Sword and Glover, both written on N64, got deals for being converted to PSOne, the conversions were so difficult we had to make a cross platform engine for the next set of consoles.

Also in 1999 we had five PSOne games in development, but each game team had veered its game away from a standard engine, so we found the same bugs were being fixed individually five times over. We decided we couldn’t let that happen again and that’s when we started our BlitzWare SDK.

David Braben, Frontier Developments: I’d turn the question around; we’ve been using our own engine technology since 1995 – using our own separate component-based engine – and before that we were using our own tool chain. We continually review using external technologies, especially at each new technology generation, and consider how well they will fit with our long-term plans – and on occasion we do so (for example using SpeedTree in The Outsider), but using external technologies can be a block to innovation too in some respects.

Chris Kingsley, Rebellion: We’ve been using our own engine technology and tools right from the start. Rebellion has been going for over 15 years and when we got going there really wasn’t any middleware available to speak of, so it was a natural and easy choice to create our own engine and tools. It was really a continuation of the way we had done things as freelancers in the years before setting up Rebellion.

Nowadays, I would say 99 per cent of the tech we use is our own. Along the way we’ve developed two generations of technology. The latest generation, the Asura Engine and Tools Suite is a cross-platform tech that works seamlessly on PSP, PlayStation 2, Wii, PC, Xbox 360 and PlayStation 3 (not to mention Xbox and GameCube too, if there were any demand from publishers), and we believe we’ve architected it sufficiently flexibly for future platforms.

We do use a small amount of middleware where it makes sense or where our publishers ask us. For example, we’ve used GameSpy and DemonWare for multiplayer games at our publishers’ request. We’ve also used Bink for video playback on some platforms because it does a great job of doing exactly what it promises and doesn’t try to do too much. In general, though, our philosophy is to use our own technology where possible.

Why did you choose to develop your own platform as opposed to, say, licensing components or even a whole engine?

Braben: One of the issues with licensing an engine is that it’s only a small part of the story. It’s the whole workflow that is vital – the tools for each of the disciplines, integrated with all the other processes, and our current system works well and is thoroughly integrated. Taking on someone else’s engine would mean to some degree taking on their tools, and then being beholden to a third party to support and maintain them and to add the new features you require.

For many of the early years of Renderware, it was rare you heard their name mentioned without an expletive in front of it, from developers attempting to use those tools. Eventually, it did become a very good solution, but then only a little while later, Criterion were bought by EA.

Looking at Renderware, perhaps the most successful engine solution there has been so far, it is clear that licensing an engine is likely to be a transient solution to a short term problem, rather than a long term solution, using the sort of business model that is currently on offer in that field.

Oliver: We’ve actually used external engines before – when first ventured into 3D, none of us knew much about it, so we licensed a 3D engine called ‘B-render’ from Argonaut, who was the 3D market leader in those days. While I could fault this somewhat buggy engine, it was generally good for its day – but for us it was the sudden loss of control we found we couldn’t stand. We’d always been in a position to fix our bugs, but suddenly there were bugs we couldn’t fix and had to wait on other people for. It was a massive concern for us.

Kingsley: That’s one of the critical factors for me, and one of the reasons we don’t use it. With your own code you are not dependent on any third party to implement features or fix bugs for. If your middleware vendor is small they may not have the resources to help you. If they are big then they’ve got lots of other people clamouring for features and, unless you’ve got sufficient clout, their attention is going to be much more focussed on their big clients.

Really, there’s a whole host of reasons – practical, philosophical, and moreover financial – to use your own tech.

First and foremost I feel that you reduce risk by using your own code and tools. Some middleware can get you started quickly, but pushes a lot of problems to later in a project, like a snowplough pushing snow.

I’ve heard plenty of horror stories of bugs in some middleware tripping up milestone delivery and even submissions. If it’s your own code it’s a lot easier to fix than trying to go through someone else’s code – assuming you get access to the code in the first place.

Finally, although I could certainly come up with many more reasons, some middleware has been designed for one platform and one game type and then gets ported on to another. It might be great for that platform and game type, but it can cause all sort of problems on another platform or new game type.

Middleware based on PC engines and ported to other platforms is particularly susceptible to this criticism. For console development you really need middleware that is architected right from the start for consoles. You can’t retrofit stuff in – even on the latest consoles there’s just not room.

What benefits do you get from developing your own platform that you couldn’t get from using off-the-shelf components?

Kingsley: With our own technology we get to control our own destiny. In business it is critical to not allow your business to be dependent on the whims and concerns of a third party, unless they are proven to be 100 per cent reliable and able to deliver what we need when we need it.

If we promise a publisher to deliver a game on time and to a high quality, then it is essential that we can meet our promises. I’ve heard too many stories of developers using some middleware being unable to fix critical bugs in the middleware.

We know that the investment we make in our own technology will bring dividends to us over time. It may be more expensive initially, though that isn’t always the case, but once you start to use it over a number of projects then that cost goes down proportionately, whereas middleware costs go up proportionately.

Oliver: Total control. If we have an urgent bug, we can fix it. If we have a strange feature request that needs low-level intervention, we can do it. If a person is struggling using the libraries he or she can just walk through to another room and talk to the person who wrote it. Finally, it means we always maintain our position at the leading edge of games engine development.

Braben: We get the best of both worlds. We can still (and do) license components, where they make sense. We can also plan how our tools are going to develop over the long term, and the games we plan to do with them. We couldn’t do this using third party tools, as it is the tools and engine that enable new types of games.

Not only that, but we can lead with new features not available to other people. Tool chains can have a ‘look’ and that look can get tired, and the feature set can drive the games that use it down a certain common route that eventually make the games feel ‘samey’.

If you were in the position of being a start-up now and having no tech base to speak of, would you still go along the path of developing your own?

Oliver: Things have changed a lot over the years. It would be a massively difficult and expensive project to create a competent engine from scratch now – and which publisher would want to pay a developer to write all that? They just want the game!

If we were just starting out in business, I’d find myself forced to buy an engine. It would have the downside of certain parts being out of our control, but at least the top modern engines are generally well tried out.

Kinglsey: I think it’s a difficult and personal choice. Most start-ups are likely to be quite small, by necessity, and therefore it may be more appropriate for them to develop on a smaller platform – and I don’t think there’s that much middleware on smaller platforms.

If I were starting up now, I wouldn’t do anything any differently. I’d still go with my own engine tech and tools. If you want to build value for the long term, I think it is the best choice. However, that might not help in the short term – for many start-ups cash flow is the focus, and building long-term value is low down on the priority list, so for them middleware could be a good choice.

But for an existing developer with existing engine, I can see no reason to change to middleware.

Braben: The investment is huge, but so is the benefit. It is a really tricky one – perhaps the best route in is a speciality route that (initially at least) didn’t require the full tech base, or form a relationship with a company that did have.

Do you think there’ll come a time when the individual technology areas involved in game development get so big that it’s impossible for a company to maintain their own ‘all-encompassing’ solution?

Oliver: I don’t see this at the moment. We’re certainly very comfortable with our own position, and the games development industry is full of innovative and responsive people, so even smaller companies will usually evolve what they need to. Some will ‘focus’ on a specific genre or platform and aim their tools and engine at that.

Many of these companies will survive in their niche areas, the only danger being that they might get cornered, pigeon-holed or find business dries up with the sales of the console or sector they specialised in.

Braben: As with any industry, there will be the larger organisations that cover many of the bases themselves, and smaller specialists both providing services to the larger companies, and covering niche opportunities.

Kingsley: It would be sad if it became true, but I don’t think it will. If you have your own proven tech that is architected well, then you can constantly build on that tech and leverage years of previous work. Development of games has already started to become more of an incremental process for the best developers and as this trend continues it will help to make it easier to manage the complexity of future games development. It may mean that the barriers to entry become much higher to new entrants though.

I think we’ll continue to see middleware vendors come and go – from time to time one may come to dominate, but that just makes it a juicy target for an even bigger player.

Given your stance on middleware, what are your thoughts on the recent Epic Games and Silicon Knights court case?

Braben: It is sad to see developer suing developer – and it is very unlikely to help either party in the long term. I imagine there is a lot of pressure on Silicon Knights at the moment, and perhaps they saw this as a way through, but from what I’ve seen it seems like the wrong move, making any problems they may have even worse – but then again, I don’t know the details.

Certainly there will be many looking on, us included, with a view to seeing how tools licensing (from the point of view of the licensor especially) can pan out in practice.

Kingsley: It reinforces to me how crucial a decision it is whether to use middleware or to develop your own tech.

There’s no doubt that Epic is a great PC developer, but console development is very different to PC development. In particular, developing for multiple platforms requires great skill and discipline, as well as many years’ experience – things that you just can’t take for granted.

We’ve taken seven years of hard graft to develop our Asura Engine and tools to the level where we can seamlessly develop for PSP, PlayStation 2, Wii, PC, Xbox 360 and PlayStation 3 – and it reinforces to me what a great engine we have developed.

Oliver: From what I’ve seen, I think the Unreal engine is pretty good and if we needed middleware it would be one I’d certainly look at. But with huge amounts of money riding on these big games and very high pressure to get them out, lawsuits of this type are part of doing business and not really a surprise.

Finally, what would your advice be to any other independent looking to licence a third-party engine solution?

Kingsley: Make sure you do your homework! Just like a publisher doing due diligence on a developer, you must do in-depth due diligence on the middleware. 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.

Not all middleware is created equal: some is great, some is average and some is fatally flawed. 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.

Braben: Be aware that such a solution is rarely a ‘silver bullet’ that will solve all the development problems you may have now – those that are perhaps the cause of wanting to license such a tool chain – and it may create some new ones. Consider where you will be after the end of the current project – can you continue to use the code in the future, or is that subject to a difficult future negotiation?

Oliver: Evaluate all options and be realistic about how long it would take you to write what you need. If you want a physics engine, then it’s not a case of saying how long would it take to write Havok, for example. Also, think about additional middleware you might require (physics, AI etc.) if these are not part of the engine.

But be realistic. If you are starting from nothing, licensing probably makes sense! Middleware companies will always allow you a trial, so use that to look at the actual functionality of what is there, not what the company is saying will be there. If it does what you need and you’ve tested it, then there’s little risk. I guess, sometimes the only solution is middleware.