GDC: Getting Unreal with Epic's Mark Rein

Mark Rein: Unreal Engine 3 is progressing quite nicely. We showed it, an early version of it, last year - and obviously we've had a year more to work on it this year. We think it's the antidote to budget bloat - er, I didn't intend that to be a rhyme, it just came out as I said it! But we really do believe that. You've got big companies like EA going around trying to scare people, saying "oh, it's going to cost you $30 million to make a next generation game", and we're going "huh? What are you talking about? We're going to make our next generation games for only 50 per cent more than our last generation games..."

I guess they just don't have productive tools like we have. That's really the main focus of the technology - we just put a huge amount of effort into our tools, and that really pays off because we can build games faster, I think, than anybody else. And they look great - I'm sure you've seen some of our screenshots from Unreal Engine 3. They're quite astounding.

As for the big new features we have this year... First, we have our new Kismet visual scripting system. What's so big about Kismet is that in the past, when you wanted to set up gameplay situations, you absolutely positively had to involve programmers. You had no choice. You would create a level, put in various triggers, path points and things like that, and then a programmer would come through and they would basically have to hook everything up - writing scripts to determine what animations play, what AI behaviours happen and when, and in response to what events. It's a pretty serious amount of work.

So level designers would build a level with all this gameplay planned, and then turn around and wait for a programmer's schedule to free up to actually put it together. Then he'd see what the programmer did and he'd say, "no, that won't work - I'm going to have to change this over here, put a hallway over here, move this tree, move these rocks..." Basically, the process was obviously a lot slower because it involved two people.

What we've created now is a visual scripting system - which for all intents and purposes looks to the designer like connecting the elements of a flowchart together. That's very much what it's like - they have a whole bunch of different objects that they can put into this, and they can build their own scripts without ever having a programmer involved.

It's a huge timesaver. In the past, 100 per cent of our gameplay scripts were written by programmers. Now, maybe only five per cent will even have a programmer involved.

MR: What happens is that we have a big set of classes that we've already written, and the level designers can put those together in any level they want. They can basically create all the scripting as opposed to the actual programmers having to do it. There's already a base set - triggers, things like opening and closing doors. There's a very well defined set of Kismet objects that designers can pull from to build their scripts.

MR: Well, it's been part of the engine for about six to eight months. We've been using it internally, basically torture testing it. It hasn't been demoed publicly before, not that I'm aware of, other than very early versions of it.

I have a great quote from one of our team, actually, which describes it perfectly. He's one of our level designers who posted on a private development forum, describing what his working life is like now with Kismet.

They were talking about Unreal Engine 3, and what he said was; "Nothing to do with graphics actually - the tools just ooze creative inspiration. I've never scripted or coded in my life, but our visual scripting - which I know is not an entirely new concept - is a fucking blast to work with. I've created levels with entire mini-games in them, AI behaviours, damage systems depicting various stun events and healing, cinematics, bizarre control schemes, even physically rolling dice telling me totals based on the angle of the surfaces facing upright when the object's velocity reaches zero, which I check every 0.5 seconds."

"I've even coded a random level generator and I've needed virtually no interaction with anyone on the code side to make this work. We've had level designers implementing a fighting game in a level, a driving game with chase cam and effects, targeting systems and etc, with incredibly low learning curve. You could walk into a room in a deathmatch level and suddenly find yourself in the middle of a Dance Dance Revolution mini-game."

"Just last week a potential licensee was in-house, and described the game they wanted to build and how one of their critical game mechanics was going to work. Literally within five minutes they looked over my shoulder, I'd built that core dynamic into a level of our game. The demo went incredibly well to say the least. "

"Typically, I'll sit down with a new recruit, a designer with no scripting experience, for about two hours, and show them the basics of Kismet - how triggers work, characters, toggles, cinematic systems, conditions, variables and so on. Then I'll give them about a day to screw around with it. Within a day I'll see some absurd crap" ... Ah, I'm replacing swear words here! [laughs] "...happening in their levels that would have been an absolute nightmare to get going otherwise, even if they could describe what they were actually looking for to a programmer - and that communication would no doubt affect the outcome anyway."

"The bottom line is that engine tools dramatically affect your creative process, and our engine has been designed with far more in mind than just pretty shadows."

MR: It really is a great post, and it describes the essence of what's going on with Kismet.

MR: Yeah, that's right. Graphics are sexy - they're obviously the thing that people come to see. That said, this year, another feature we're going to show is seamless worlds. Seamless worlds is basically... Well, it's kind a misnomer, but that's what people use the technology for. Essentially what it is is background management of loading and unloading of game assets.

In the Unreal Engine now, the engine itself takes care of loading and unloading levels. We no longer have this idea of one discrete level, the way it's worked in the past - where you have a big long load at the beginning of your level, and then when you're finished that level, you wait to load another big huge level. What we do now is we have the concept of it being a world, where you start in a particular level - so the first time you load the game up, you've got a load - but from there on, the engine figures out, in conjunction with your design, where you're heading, where you're going, and determines what assets it needs to load in the background as you're moving around.

So you could build forty small levels that make up a whole countryside, or a massive city like London - you could probably build that in forty levels. Then the engine will automatically load and unload levels as necessary as you move around the world. It also manages all the interaction between objects in the various levels - it knows what stuff is in view, so if you were to fire a rocket from one side of the city to the other, for example, it's very smart about which assets need to be in memory, and which assets don't.

That's crucially important in the next generation of consoles, even more so than it is today, because we have the ability to do unbelievably insane graphics on these next-gen consoles, but we still have relatively low amounts of memory. In fact, I got a video card yesterday from NVIDIA which has probably twice as much memory as the next-generation video consoles are going to have - and that's only a video card!

That's definitely a limitation that you have to work around, so this is the absolute best way to work around it. It's not just so much what assets need to be loaded, but also what versions of those assets - for instance, if you're making a game like Grand Theft Auto, you've got a building that's half a mile away and a building that's half a block away. You wouldn't load the same detail setting of the building half a mile away as you would of the building that's half a block away. Our engine is basically going to manage all of that for you.

MR: Yes, we're going to use that ourselves. You know, that's always been a feature for us. Licencees have already created that sort of technology in the past - Lineage II is a very successful massively multiplayer game created by a Korean company, NCSoft. They've done a huge business with Lineage II in Asia, and they basically implemented a similar feature, under our advice. Tim Sweeny actually went to Korea and sat down with the programmers. They said they needed seamless loading and asked how he'd do it, and he described our architecture for it.

So it's not something that hasn't been done with our engine before by third parties, but this is the first time that we've made it a core feature of our game. That's one of the key things of our engine - every feature that's in our engine is an important feature to our games, which means that it gets torture tested as we build games. Our customers have the confidence of knowing that even if stuff looks slow and crappy today, when Epic finishes their game and ships their game, it's going to be fast. It's going to play well online, it's going to be reliable, it's going to work great, and it's going to be state of the art.

That's a confidence that people have when they license from us. You know, a large amount of the people who license from us, especially with the new technology, are coming on board in the very early days of game development - and there is a bit of a leap of faith involved, because you know, even with the technology that we'll show at GDC this week, the seamless world demo is fairly rough. It's not production, we haven't put production quality graphics into it, because we're still a ways off from shipping our game. But developers trust us and know that Epic has a lot of experience with performance and shipping great games, and making them run on a wide range of platforms. They have a confidence in us that, well, when we finish with this, it's going to be great.

MR: Absolutely. I mean, it would be very hard to just make middleware. What functions do you put in there? What functions do you skip? How do you know what's important to your customers? How do you know what's performance critical, and can you actually build a real game on it? It's very tough to make those kind of calls.

Building games is all about trade-offs, and you have to know which are the right trade-offs to make. That's crucially important. There's no perfect game, there's no game that doesn't consist of a whole bunch of elegant code and a whole bunch of crazy hacks - because when it comes to time to ship your game, it's got to be good, it's got to run well, it's got to look good and it's got to be bug free. I think that kind of experience definitely counts, from shipping games.

We don't just ship a game every three or four years, either. We push them out on a fairly regular basis. In the last five years - I'm going to count Unreal Championship 2, which is probably days away from going gold, or a week or two anyway - I think in the past five years, we've probably shipped five games. I don't remember the number, but we're certainly prolific. That's because we have great tools - and part of the reason that people license our technology is because they know that they can make games for less money than if they try to build their own or assemble parts elsewhere.

MR: A big area of focus in next-generation titles is going to be shaders. All the next-gen consoles and all the latest video cards have this concept of programmable pixel shaders, and pixel shaders are pretty much going to define what gives your game its look. It's not so much the models - everybody can make a human model, and before too long everybody's going to have a very realistic looking human model, in terms of the shape. What makes those models then look truly human is the quality of the shaders that you have on the model - the specularity, the normal mapping, the bump mapping, the diffuse textures and all the other different combinations of effects that go into making shaders.

Again, in the past, I would say that 90, probably 95 per cent of our shaders were written by programmers. So again, they required, if you look at Unreal Championship 2 for example, 95 per cent of the shaders there required some sort of programmer involvement. In the past, the available shader languages weren't so multi-purpose, or they weren't so high performance, that you could actually build complex shaders unless you poked at them directly. That's no longer the case in the next generation.

So now, again, the job of building the shaders is back in the hands of the artists. We have a visual shader development tool, which we call a materials system, It's very productive, and it's all done visually - the artists go and connect these inputs and outputs from these various shader components that are pre-built, and they can create whole new shaders. We have something like thirty pre-built components, which probably represent around ninety per cent of the components you're ever going to need for pulling off a game. There could definitely be some programmer involvement - some coders could write some new shader components really well, if that's what they want to do - but you'd be surprised at some of the shaders we can without a programmer even touching them.

We've gone from maybe 95 per cent programmer involvement, to maybe five per cent programmer involvement - and programmers are the biggest bottleneck. I mean, you want your programmers to be doing really high-level things. You want them to be building sophisticated AI, for example - AI is very specific to each game. You want them to be building the gameplay rules, the specific AI feedback system - you know, all the low level stuff, a lot of the super-important stuff that is required for a game, a lot of that needs programmer involvement.

If you take the programmer out of the artist's back yard, out of scripting and out of shaders, all of a sudden you've increased your productivity, possibly by double. Clearly you've increased the productivity of your programmers, and the artists, when they have visual tools that have a very good feedback system, they're producing stuff a lot faster than they ever were before. Our designers are able to work a lot more quickly now, because they don't have to wait for programmers to iterate their design to see if it works. They can actually do that all themselves.

You know, I used to work on Unreal, and a designer would say "hey, here's my level, and this train comes out here, and a guy jumps out here, and this big monster is here and there should be an explosion here..." He's pointing around the level, telling me all the cool things that are going to happen. "I've got this swinging hook over here, and you can jump on it and swing off it..." All these great things, and none of them are live! It's multiple days for him to go back and forth to the programmer, potentially weeks to get all that stuff up and running, to get that level finished. Now I walk into the designer's office, and he's got it all done. He's got it all up and running - oh, and he's added five other cool things. That can define the difference between a good game and a great game.

So, does it take longer to create the models? Sure, that's where this 50 per cent increase comes in. Instead of doing 8,000 polygon models, we're doing 8,000,000 polygon models. We have one model that's 14,000,000 polys! It's insane! But we have the ability to make the 14,000,000 polygons count, thanks to normal mapping and the sophisticated lighting that we have. So it won't really be 14 million polygons when it's used, but the appearance of all 14 million will be there - you will see all 14 million polygons, thanks to the power of graphics card like the NVIDIA 6800 and things like that. So it's worth it - now it's worth the investment.

It's a two pronged approach. We have tools that make us much more productive, and we've reduced the amount of involvement that programmers need in non-critical systems. The programmers are more efficient, and the artists and designers are more efficient. And yeah, we're looking to hire more artists, we're looking to hire more designers... But our biggest project - and if our publisher knew this, they'd probably be pissed, so I'm not going to say which project it is, because we have a few in development - we have only had two gameplay programmers on this project ever. That's cut down from four or five last time.

MR: Yeah, that and the fact that the engine team is carrying more - by creating systems that allow design to do more, the engine team is taking a larger brunt of the work this time. You know, we should be charging twice as much for the engine now as we did for the last one, but we don't. [laughs] It does take twice as much of the burden off the hands of the development team. Especially things like the background loading - that's a huge feature. It's hugely important for next-generation consoles.

MR: No, we don't work that way. Epic's always been about bleeding edge. So, no. We have Unreal Engine 2 for that, and you'll see a bunch of great games coming out with our current engine - there's Star Wars: Republic Commando, there's Pariah, there's Unreal Championship 2, there's SWAT 4, Splinter Cell: Chaos Theory... There's also another really big game coming out that's never announced that it uses our engine but it does, and I think it could be a major success. So there are like six great games - Xbox, in some cases PS2, and Chaos Theory is on all platforms - great console games coming out in the first and second quarters of this year that use our current technology.

When we release Unreal Championship 2, you'll see that we've really optimised it. OXM, the American OXM gave it 9.3, the British one gave it 9.2, Maxim gave it 5/5... It's a really spectacular game, and it just shows that we've really mastered the whole console game development battle. It's the first real console game that we've done, that we can really be proud of.

MR: Obviously it uses Unreal Engine 2, which is the same engine that shipped in Unreal Tournament 2004, which won almost every multiplayer game of the year award last year. It's the same engine as that, but the game content itself, the actual game, was designed only for Xbox. It's been a good learning curve for us to find out exactly how far you can go on Xbox, and it gives us a great headstart for the next Xbox, obviously.

MR: I, um... I can't really talk about any of that. I can't even confirm what you said about the first one. We have to keep our relationships with those companies! [laughs]

We've shipped about 50 Unreal Engine games thus far, and I'm pretty sure that just in the next generation alone, there'll be 50 Unreal Engine 3 titles at least - so we've got ro make sure we respect those platform holders!

MR: Well, yeah. We're doing three speeches at GDC - we're actually doing four, but the fourth one is on cheating, so it's not really related - but our three major speeches that we're doing at GDC are all related to next-generation game development. So yeah, absolutely. There's no question that that's what's probably number one in people's minds.

Number two is probably the PSP. I think that's really going to be a hot system in the next year, so I think there'll be a lot of activity around that. All our stuff is certainly focused on next-gen, though, and I imagine that's going to be the same with all the middleware vendors.

MR: We don't know. It'll really depend on what happens game-wise. As you know, Midway is doing the next Unreal Tournament titles, and they have expressed an interest in it. We said yeah, we'd love to see it - so it's just really a matter of wait and see. Like I say, we've been talking about it, but we don't have any specific plans. I think it'd be great to get an Unreal Tournament title multiplayer on PSP. We just don't know when that would be possible. It would probably have to be handled by an outside development house.

MR: There's no question that the graphics are going to be a huge upgrade. You know, people are such snobs, with this "oh, it's not about graphics" thing. That's such nonsense. It's totally about graphics, What's the difference between the first Metal Gear Solid and the latest Metal Gear Solid? Right, it's "wow, the graphics!" There's no question, that's going to be the first thing that people see - they're going to see that the visuals are just spectacular.

Other than that... I think that games have come a long way, and they'll have more processing power in the next generation so I think they'll certainly be able to do more cool things going on at one time, so a little more interactivity. Sound as well, on these systems they're obviously going to be pushing super high-quality sound, and I think that'll be pretty significant.

The main thing, though, is that I think your games will just look a hell of a lot better. I think that Microsoft has done a phenomenal job with Xbox Live, and I'm sure that they're going to come up with even cooler things that it can do - I mean, they've already done some great stuff. You now have the ability to just turn on your Xbox and send a voice message to somebody, say "hey, you want to play this game?" or whatever, which I think is brilliant. I'm sure they're going to come up with even cooler things to do, having more processing power.

I think that the main thing is going to be the graphics, but also important is the ability to have more live things going on on the machine at one time. That's definitely going to be crucial as well. A game like Half-Life 2 that had maybe 20 guys walking around a level, maybe now you'll see 30 or 40. You have more processing power, so you can make more of your AIs smart as opposed to just throwing more dumb guys in.