D.I.C.E. 2008: In-house Development vs Licensing of engine technology

Carl B

Friends call me xbd
Legend
This topic has come up in various forms a number of times before in alternate threads, but the themes/discussions of late in particular seem to have been driving for a focused topic on the matter as to the pros/cons of licensing engine technology vs in-house development.

Browsing the Internet a couple of days ago I came to some DICE coverage and was surprised to find a presentation/discussion centered on just that theme; not only that, but at the center of the debate were (surpisingly/unsurprisingly) Epic and Insomniac.

There's no unified coverage of the event that I can think of, so I invite users to search out there own articles - I've read several and they all color in different aspects - but from some of the ones I've found I would throw up these quotes as encapsulating the arguments on either side:

Insomniac said:
You should invest and build your own engine," said Insomniac's Engine Director, Mike Acton. "It's an investment in your own people."

Acton opened by citing the No. 1 reason most developers choose middleware, that purchasing middleware instead of devoting programmer time to develop engine technology internally allows resources to be devoted strictly to gameplay, and then torpedoed it.

"...[Instead] you concentrate on learning how to use other people's tech."

According to Acton and Andy Burke, Insomniac's Tools Group Lead, developing technology in-house actually saves time and money, eliminates the learning curve of having to decipher someone else's code, and enables engineers to develop exactly what they want - and what the designers want - without being straight-jacketed into someone else's idea of what works and what doesn't.

"Isn't this just wanting to build it yourself because you think you can do it better than anyone else?" Acton asked, citing the No. 1 criticism of engineers who insist on developing technology in-house. "It's not. It's about responsibility." When the game doesn't ship, or ships in a bad state, the middleware vendor won't get blamed, "you will. … The only real way to take that core responsibility is to make sure it's done right and that your people are doing it."

Epic said:
"I want to give a shout out to Mass Effect, BioShock and all the games who used our tech to do great things at the awards last night," he said. BioShock won four awards, and Mass Effect brought home RPG of the year.

Capps went on to debunk the suggestion that in-house technology is easier to implement than licensed middleware, pointing to the fact that most in-house tech isn't developed from scratch, rather cobbled together from pre-existing technology. But the reason to license middleware isn't just for the cost savings. It's about testing, stability and the "ooh" factor.

It's also, according to Capps, about documentation. He says with internal tech, the long lead time between establishing technology and shipping the game isn't spent on writing documentation. It's spent on adding new features or tweaking the existing ones, all of which add more complexity, not less, increasing the need for the documentation that isn't being written. Not so with middleware.

(The above are from here: http://www.escapistmagazine.com/articles/view/conferences/dice/2920-DICE-2008-Epic-on-the-Hot-Seat)

dsc04519.jpg


This is a topic that has come up oftentimes before in limited form, but I was just wondering what peoples thoughts on the matter were. Personally on a philosophical level I do prefer the idea of investing Unreal 3's $500k license (for example) on internal hiring/training to get the job done and increase technology competitiveness over the long-run, but at the same time it can't be denied that different dev houses have different strengths/weaknesses, and for some it might make more sense to go the licensing route if the skills of the team favor that outcome.

With high-profile cases like Silicon Knights as a sort of 'fallout' example, it's hard to know whether it was an overly reliant view of Unreal as a solve-all that led to their dilemmas, or just a general ineptitude on the part of their team as a whole. If the later, could the situation have been corrected if the investment had been made internally, or are some houses simply sick/broken in areas (technology, management, coordination, etc...) that would see them struggle regardless of the path chosen?
 
Last edited by a moderator:
Perhaps we'd benefit from those on different sides of the fence being classified by what they're creating? Insomniac are producing a AAA game and engine where they want to max the hardware. Not every developer is looking for that. I'm sure when Naked Sky Entertainment set about creating RoboBlitz they weren't looking for that kind of investment, and UE3 provided an easy platform to create their game.

We could also do with some real figures on costs in training. I agree with Mike's sentiments, but there's plenty of companies seeing UE3 as an economic choice, including Square Enix who have always created their own engines. Indeed looking at SE, they're creating their own engine for their ultimate AAA title, and using middleware for a less significant title. Both SE's engine and Insomniac's are platform specific. Creating a multiplatform engine is going to be considerably more effort and cost, where an existing solution is going to offer even better economies than usual.

Really, without numbers we can only look at the two different takes from a purely hypothetical POV. Both arguments make sense. It comes down to dollar investments, and we don't know what these things cost to implement. With hearsay of "It's cheaper to buy a platform than build one" and "we spend loads of time customizing the engine to do what we want" and all the other valid comments, we can't possibly get a good industry-wide insight into middleware versus proprietary engines.
 
There being some devs around here that have been on both sides of the coin, hopefully we'll get some insights into their own views. I completely agree that the scale of the project potentially plays a role as determiner of what path a house might likely walk. However, with the expense associated with a UE3-class license, I'm generally not thinking development efforts along indie lines as being the focus here.

I think taking some of the successful UE3 examples there have been, one of the questions I would have would be the extent to which the AAA titles shipped on UE3 in the past year benefited from use of the engine - both directly and indirectly - and whether these specific features would have been hard to address via in-house efforts. A large draw of the engine by Epic's own accounting seems to center on the artist tools, for example.

Multiplatform development strikes as one high-profile touted benefit of the use of such an engine, and as we see elsewhere Epic is committed to improving its engine throughout the generation. But I feel it's interesting to note that multiplatform development being one of the draws, I'd venture that Gears of War itself was still heavily optimized to the 360 to an extent that it was ultimately a fairly large departure from the baseline engine. I suspect this due to the fact the porting to PC process seemed rather more involved and expansive than one would think it otherwise might be if the "turn-key" aspects of cross-platform porting were generally left intact via the original development... hell it was outsourced to an extent... to say nothing of the seeming difficulty in porting to PS3 up until recently.

But of course, that could be as much a story of Unreal Engine 3.0 coming into its own as final readiness was achieved. It seems that the development of Gears itself was to an extent linked to the development of the engine, and I think we may be seeing that again in terms of UE3 improvements and the Gears 2 efforts being inherently linked.
 
Last edited by a moderator:
I thought I'd just chime in quickly and say that I agree with you xbd - the first thing that came to mind when I saw the OP was multi-platform developers. I don't know how true that is with the current consoles/PCs, but it seems like the logical answer.

It seems like developing a game is hard enough to do for one platform these days, and I guess the bottom line is that licensing an engine is supposed to make that development easier.
 
Last edited by a moderator:
Depends a lot on your expectations of the middleware.
If your creative people are willing to work entirely in the constraints of the provided midleware, then go for it. My experience with middleware hasn't been positive, I've seen middleware suck up more technical resources than wouldhave been required to write an engine from scratch. But thats a function of trying to fix the limitations of someone elses code, as opposed to modifying the design or aesthetic vision to work within them.

I've said before middleware provides you a way to start work on gameplay and prototype faster, IME it doesn't save engineering resources. As a developer you have to weigh the pros and cons and live with the decision.

Personally I'd rather live with internally developed code, but I'm old school, and it's largely because when it doesn't work I can make informed decisions about what the cost of fixing it is. And when I'm having performance problems I can usually isolate the cause and decide on a course of action without having to reverse engineer someone elses design to figure out if I can solve a problem gven the time and resource constraints.

In a lot of dev houses the use of middleware game engines or internally developed technology isn't decided by the technical people at all and this I do have an issue with.
 
I'm strongly in the internal development camp myself, but I agree with ERP with regards to being able to prototype early with middleware as a really nice benefit.

One other benefit that's mentioned but glossed over is the training/recruiting angle. If you're ramping up or simply shopping for head count, it's often easier to find people already familiar with middleware that can get up an running quicker (which is particularly beneficial if you're publisher has your 'nads in a deadline vice). Plus training a new hires on the internal tech can potentially eat into development time as they get aclimated; not to mention that having more obtuse internal technology can simply make hiring a real problem (perfect example, pre-acquisition Naughty Dog).
 
I'm all for internal development (but then I'm an engine developer), but I can see the reasons for buying in. Engines are much more than just displaying things on the screen, you need resource managers, data loaders, you need to think about things like batching, scene management, lots of other stuff. When all is considered, buying in an established third-party engine like Unreal becomes increasingly attractive.

That being said, if your game uses a purchased engine, you're adding a glass ceiling to your graphics. The engine may specialise in certain scenes which you don't really use in your game. The scenes you do use may not look or perform as well. Plus if you're not making a FPS, is Unreal going to help? For instance, almost everything in a racing game is at a sharp angle to the camera, so you need to control how road, barrier textures work when they extend into the distance. A FPS engine isn't so concerned with that.

Further, the 'feel' of a 3D engine can vary quite a lot. There's a relationship between the scale of the world and field of view, also the polygon density, texture and rendering resolution which gives very distinct results. If you want to control this you have to write your own.
 
Appreciated insights so far from everyone. I definitely see your point Archie with regard to the potential ease of hiring someone already familiar with middleware in an instance in which the team would need expansion or a member replacement, vs training someone external to the project on internally developed tools.

In a lot of dev houses the use of middleware game engines or internally developed technology isn't decided by the technical people at all and this I do have an issue with.

I'd been wondering about that to a certain extent; i.e. the level to which internal developers might simply go unconsulted at times by non-technical senior management that has otherwise been sold on a product or service.

Another question I'd have in a similar vein is, once a team has adopted/migrated to an engine license model - in an era when team sizes and costs are increasing - to what extent are they dependent/addicted to that technology as time goes on? Would one expect the majority of UE3 licensees to stay with that engine across all projects this gen given the time & effort of familiarizing/adapting for devs and artists has already been put in, or are those sunk costs case-by-case enough that switching to a different engine for alternate projects would be viewed on its own merits within a team?
 
I favor custom engines.

Engines are a graphical floor, but the double edge of the sword is they're also a graphical ceiling. Your UE3 game will never look bad, but it will also never look as good as Killzone2. Basically you cannot push a machine to it's limits on a middleware engine.

This is something I've been aware of for a long time. Back in the heady quake 3 engine days, When I heard a certain upcoming PC game was on the quake3 engine, well I was usually actually a tad disappointed. Not that it would look bad, but it just meant it wouldn't look incredible.
 
I've been on the end of having to license third-party tech before, and the notion of a graphical ceiling is one thing, but then a feature ceiling is another. It's not just on an aesthetic level that content creators will ask "can we support blah, blah, blah", but being able to throw in a number of new features on the design/gameplay side. Most of the time, this is just a matter of work on the game code side (as well as making sure this game code can interface with the tools), but there are times when you need to do something that the engine itself is not really built to do out of the box -- I've had this experience with multiplayer capacity in a licensed engine, and pretty much had to tear down the whole thing and reconstruct it. If you actually take the time to dig deep underneath, it's often possible to break those ceilings. It's actually a pretty common story for people to take a licensed engine and just rip it to shreds and reconstruct it in a way they'd prefer. Sometimes you're a little stuck (e.g. a case where raising the graphical ceiling a generation on the runtime was doable, but not having tools source code made it pointless to try anything beyond just optimization). Sometimes you're not (e.g. new physics engine, rewriting all the FX)...

At TRI, we definitely had the issue of artist turnover rate, and since the engine was totally in-house, part of the trick to dealing with the problem of artist learning curve was to black-box as much as possible on the art pipeline. While it seems silly at the face of it to deliberately wrestle power away from content creators, it's hard to say that you could have handled things differently in the same situation. I think there was enough trouble to be had just because of things that had nothing to do with the engine specifically. Part of what happens, though, with in-house engines, is that people know the limitations and know the causes. With something coming from outside, you don't necessarily know everything right off the bat, and people will often discover problems and limitations the hard way. And even if you can find these things and know how to fix them, it's often the case that licensees are stuck flying solo once they do that. Not that the middleware providers will refuse to offer support (well, one or two of them do) if you tear something apart, but that it's not something they can really help you with anyway.

In any case, for every engine that has ever existed or will ever exist, there will always be someone using it who will say "this engine sucks" for some reason.

Here at Crystal, we've had an in-house engine that's always been completely in-house in terms of who is involved with it. Although we're only now in the position that this engine is being used at another studio who isn't working directly with us on the engine side (strictly using it for their game(s)). And in that respect, I've actually started to get a feel for the other side of the looking glass in that we're becoming a little more like a middleware developer. Compared to when every "client" was in-house, the way things happen has changed in that we're not treating the core engine/tools people like myself as "service-providers." Sure, we're always providing support for "how do I do this?" types of things, but it's becoming more about being "product-providers." Tasks rarely get done one-at-a-time, but routinely get collected and prioritized and get rolled out in chunks. It's been working out for the time being, but we'll see how it goes when there are 5 or 6 games going at once. The worst side-effect of this so far is that it's often hard to get game teams and engine teams to work in sync and often times, feature requests collide, and you end up with horrible feature creep in some places. Manageable so far, but I think it's only manageable because there's so much distinctly defined ownership around here.
 
Back
Top