From: 'Tim Sweeney'



Paritcipants:

Tim Sweeny from Epic Games

Jay Stelly from Valve

Casey Muratori from Rad Game Tools

Charles Bloom from OddWorld

The most important elements a developer should explore when looking at licensing game technology.

Tim: The proper way to choose to license an engine involves a lot of hands-on

Use and evaluation, and is hard work.  Before committing to license an engine, you should evaluate it very thoroughly and spend days or weeks looking it over, building content in its tools, and looking for limitations that might affect your game.  By the time you've finished evaluating, you should have a complete understanding of what the engine will do for you, what the engine won't do for you, and how much effort you should expect to put into extending it or working around its limitations.  In the process of evaluating the engine, you'll surely ask a lot of questions, but the hands-on impression should be the most important factor driving the decision.

Jay: In the case of a game engine, I'd first identify which fundamental technology features will be different in my game versus the reference game for the engine (assuming there is some reference game).  Then, I'd want to know if I was getting source code updates to the engine, and whether or not those updates had shipped in some product.  That would help me plan how to interface my features with the engine codebase and what source I should plan on modifying and taking ownership of (If I make changes, I'm responsible for shipping that whole module).

The last thing I'd want to do is license an engine and then rewrite it.  I'd want to be careful to choose features that added value without changing fundamental design choices of the engine.  So I'd want to get a pretty good idea up front of the fundamental design choices the developers of the engine had made.

Casey: I think the best thing you can do is be thorough in your evaluation. That's not necessarily a question, but you could phrase it that way: "is this product really going to go the distance for our game?"  There are a lot of licensable products out there that may seem useful and easy to use on topical inspection (ie., looking at their samples), but when you actually try to write a production quality game with them, they fall apart.  You have to look at a lot of things, like scalability, memory overhead, load times, throughput, and so on.  You really want to put a product through its paces, and get assurances from the developers that problems in hotspot areas will be fixed ASAP if they crop up.

Charles: What exactly are you looking for, and what are you getting.  Is licensing an engine tieing you into limitations or decisions that are not acceptable? I would encourage developers to draw up a rough schedule with and without the license and see what they're really getting out of it.

There is a perception that licensing technology can greatly shorten programming and production time.  Have you found that to be the case and in what ways?  What are the benefits and problems? What have you found to be the most important factor when using a piece of licensed technology? (Software architecture, feature match, overhead, etc)

Tim: We've worked with a lot of teams that have clearly benefitted from the engine, and produced better games more quickly and less expensively than would have been possible had they build their own.  This is certainly the motivation behind a team's decision to license.  But there have been a few teams that probably would've been better off building their own.

The teams who have achieved the most success with Unreal have been very pragmatic about the benefits of licensing an engine: you gain access to a huge amount of code that you didn't have to write or wait for.  And just as importantly the drawbacks: you need to adapt your way of building content and programming to the way the engine works, because if you try to radically change the way the engine works to suit a favored past development approach, it starts to become questionable whether the engine is actually saving you development time.

An example of a project I was really impressed with was Deus Ex.  The Ion Austin team started out with the goal of creating a realistic, modern-world RPG.  They found the engine suited their needs for environment rendering, player movement, and networking pretty well.  But they needed a better user-interface framework than we provided, required lip-synch technology, and had to significantly extend the gameplay code: inventory, AI, a conversation system, etc.  So they put some significant effort into extending the engine to do those things, but used the rest of the engine without drastic changes; most of the team's effort was focused on building The Game rather than extending the engine.  They ended up creating a great game in a reasonable amount of time.

The teams that have tried to make the most sweeping tech changes have typically gotten the least benefit from the engine.  This isn't driven so much by the style of the game, but by the team's attitude towards taking advantage of what's already there vs rewriting.  Adding a missing feature you need is a good idea, but changing a major aspect of the engine, something that currently works just fine, because the team wants it to work differently, tends to be a blackhole in terms of schedule and cost.  At some point, if you're going to make such an extensive set of changes, it would probably be more efficient to build your own engine than to license one.

Jay: The biggest impact is that a bunch of good choices have already been made.  If you license an engine that was used to ship a major game, you can duplicate the production process used for that game and save yourself a bunch of effort.  On the first day you can create working content and use that to figure out your game design right away.

 

The problem is that the design choices of an engine aren't always obvious.  An engine can be a large codebase; if you choose to make architectural changes you'll need to invest in acquiring the necessary expertise with the codebase.  This won't take anywhere close to as long as writing your own engine, but in my experience, the natural tendancy of programmers is to write code rather than read it so you have to be vigilant :)

Casey: Well, it's unclear.  Even when the licensable product is good, I don't think this necessarily means that programming and production time is shortened.  Often it just means the product has more finish, higher quality, less bugs, more content, etc.  Development times seem to stay pretty consistent, so even though good licensable products can save developers a lot of work, they don't just lop that much time off the schedule - instead, they spend it adding other things to their game.

So, good products have been a net positive, I think, but not because they've shortened dev cycles - rather because they've freed up programming resources to spend time on other aspects of the game.

Charles: The key is the fit of the product to the needs.  With a game engine, it's almost certainly not quite what you need, so you're going to have to modify it.  When you assume that licensing an engine will help dev time, don't forget to account for the process of learning to use that engine, for optimizing that engine when it doesn't meet your demands, and for modifying it to do what you want.  These things generally take much more time with a licensed engine than they would with an in-house engine.  The biggest advantage of a licensed engine is that it gives you something to start with right away.  Artists get an exporter and they can start making content.  All the modifications and optimizations can be applied later (hopefully).

What have you found to be the most important factor when using a piece of licensed technology?  (Software architecture, feature match, overhead, etc)

Tim:

 

Jay: I think this usually boils down to the same kinds of choices as developing your own engine: How are you going to differentiate your product?  What are the risks?  What are the costs? What are the system requirements and what flexibility is offered there? etc. It will save you time and get you more features for less money - especially if you're talking about a high selling title and royalty-free technology. 

Casey: Personally, I think flexibility is the most important feature for any licensable technology.  Unless your game is strictly a mod on a game already built with the technlogy, you're going to find yourself in a lot of situations where you want to add additional features unique to your game.  This can be something as simple as translucency (if the technology didn't already support it), all the way up to major architectural changes like continuous world streaming support.  Too often people find themselves in a situation where their licensable technology has boxed them in (painted them into a corner, if you will), and that's exactly the opposite of what licensable technology _should_ be doing.  It _should_ be something that accelerates your development of unique technology, not something that makes it hard or impossible for you to do so without redoing all of the technology that you _thought_ you already took care of by licensing.

As a sidenote, this is where I spend most of my development time as well. New features are implemented relatively quickly, but a lot of extra time is spent breaking them down into parts, and making them as recombinant as possible, so that they can be used in as many ways and for as many different purposes as possible.

Charles: The most important thing in licensed technology, IMHO, is the general architecture, and the quality of the source code.  I never license a product without source code.  I consider all licensed products to be part of our code base; rather than writing the code, we have to learn it, and then we have to maintain it (optimize, bug fix, modify).  Any little missing feature, we can always add, so big feature lists don't attract me.  I want to see a solid core, a good basic structure, and clean well-documented source code.

What percentage of your programming time would you say is:

Engine enhancements? Gameplay AI - Logic? Interfacing with engine code? Other?

Tim:

Jay: For Half-Life, we spent over 50% of our time on gameplay.  The rest was mostly spent doing enhancements and developing tech or features that didn't exist in the Quake engine and tools. 

Casey: ...

Charles: Doing an in-house engine, I would say we spend about 25% of the time on the core engine and features, about 25% on exporters and tools, and about 50% on gameplay, AI, and high level controls.  There is no time "interfacing" with the engine, since the game and engine are one.

How do engine specific features like VSD, space partitioning, or other technology restrict the types of gameplay and games you can create?

Tim: That's kind of a 1999 question.  Back then we had to make very careful tradeoffs between scene size, lighting detail, and so on, because the software renderer had to be hardcoded for these tradeoffs, and 3D cards weren't prevalent enough to count on.

Now that we can count on 3D hardware with (at least) hardware T&L, we can build huge outdoor scenes, huge indoor scenes, etc., and the hardware

keeps up just fine.  Though our game happens to be a first-person shooter,

there's no reason you can't pull the camera way up above the player and point it down, and get a realtime strategy game style view of the world.  Nowadays you could totally create a great RTS in Unreal, and you would only need to change the AI and game code, not the renderer, editor, or network code.

Jay: This is a really broad question, so I'm not sure where to start :) Obviously tech features affect game design a huge amount.  There is a bunch of playing off of the constraints of the engine. 

Casey: ...

Charles: Major engine features strongly determine the type of game you make.  The engines from Id have all been "small visible area" engines lately.  If you want to make a flight simulator, or an infinite/paging landscape game (like Dungeon Siege or Jak & Daxter) you need a special engine that can handle that type of thing.  The biggest question in engine design recently has been CSG vs. "Triangle Soup".  Roughly, CSG is faster and more robust, but Triangle Soup gives the artists a lot more freedom.  I think the world is clearly headed towards Triangle Soup, since we have the CPU power to deal with it, and it allows more interesting levels.

How have you handled integrating AI and physics into the game engine or your production code?  What were the issues?

Tim: Steve Polge has [designed] the AI system in the Unreal engine.  There are several layers to it. 

At the lowest level, there is a pathing system, which will tell you how to get from one place in the world to some other arbitrary place, navigating through the world geometry, and even handling obstacles like doors and elevators.  This code is appropriate to all games. 

At a higher level, there are the game rules which determine the decisions that AI opponents make during gameplay.  The more your game deviates from a deathmatch or team-oriented tactical shooter game, the more justification there is for a team rewriting the higher-level game code.  For example, if you're writing an RPG, you will probably replace most of the high-level AI framework, while making use of the existing lower-level navigation and physics.

We use the Karma physics engine for all realistic physics.  It's really great.  You can build arbitrary high-detail objects and have them move around and collide realistically.  We use this for ragdoll-style player hit animation, vehicles, and rigid-body kinematics, but it's a very general system and can meet the needs of many kinds of games.

Jay: Licensing core systems that interact with lots of other code is really difficult.  For AI we really tried to leave the engine interface intact.  We changed some things, but having a clear, stable interface helped this go smoothly.  Physics is much more difficult.  To make large changes to the physics of the Quake engine, we had to make it part of the game code first (i.e. separate it from the engine).  At this point, we weren't going to be able to integrate any engine code updates again. 

Casey: ...

Charles: Yeah.  AI's not really a problem in general, it can work with any engine, though it's nice to have certain types of line-of-sight acceleration structures and things like that.  Physics is closely tied to collision detection, so you need a collision detection system that's going to work for you.  In Munch's Oddysee we did only very primitive physics, but we still had to rewrite most of the NetImmerse collision detection pipe because it just took too much memory and was too slow.

We have seen a bunch of game engine games (mostly Quake-based) that have a huge mod community attached.  Does use of a game engine make enabling game mods easier?

Yes,

Game is more approachable to the mod community, since these engines were designed from the ground up to be highly modifyable by users

Provide a thorough set of tools -- for level building, model importing, etc. 

There's also a community of thousands of users who are experienced in using these engines.

Easier to jump into new games built with these engines. 

Documentation: In the case of Unreal, we have a gigantic web site full of documentation -- currently available only to our licensees – which will be going public in a few weeks with the release of the Unreal Tournament 2003 demo.

Jay: Sure - this is another of those things that is already figured out for you.  But it's still easy to make decisions that make supporting the original mod-oriented designs difficult or impossible.

Casey: ...

Charles: Don't know.

What's your biggest technical challenge when working on a modern 3D game title? (Graphics, collision, ai, general programming, physics, data management,  gameplay, etc)

Tim: It is all interconnected, not modular. The job of an engine is to provide a complete framework in which all of these components work well, and not only work, but also behave well and interact properly with all of the other components in an engine.

The structure of AI code is intimately related to navigation which depends on collision -- so you have to write AI code while being fully aware of all the collision ramifications of what you're doing -- both in terms of movement constrains and performance. 

Networking code, while nice and clean in the pure client/server abstraction, becomes much trickier in the world of limited bandwidth and significant latency -- so network code can not be oblivious to physics, collision, and animation, because those things need to be predicted in order to hide latency, and extrapolated to hide bandwidth limitations. 

Then you get into editing tools, where in an ideal world we'd all use Max and Maya and not write any custom editors, but in reality developers want a what-you-see-is-what-you-get view into your actual game world, with the complete ability to edit, analyze, and visualize all of the game-specific properties of objects in your world, which is intimately related to all of the subsystems in the engine.

Jay: I think the biggest challenges lately have been in AI.  It's much harder to deliver AI and behavior that matches the level of graphics, etc.  It's getting easier to make things look really photo-realistic these days, but making them act accordingly is getting harder.  If you're doing any kind of work with human characters, this is probably a big issue.  Other than that, we're managing huge amounts of data and hard drives haven't gotten significantly faster, so that's tough.  Also physics simulation is getting more complex; there are a ton of issues there even if you license third party code for the simulator.

Casey: I'm not going to answer these, because I'm too specialized to have an informed opinion here - these are more aimed at engine users... if you think there's some value I can add there, let me know where and I'll send a reply!

Charles: Time, and the size of the code base.  None of the stuff we do is particularly difficult; the problem is doing a *lot* in a small amount of time.  This is exacerbated by the fact that the hardware keeps changing, so it's hard to keep much code from project to project.  The wide disparity in platforms (compare PS2 vs. a PC with Radeon 9000, for example) is also a problem, because it makes it nearly impossible to make a cutting edge cross-platform game.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download