Gamasutra recently caught up with Epic's Tim Sweeney at the Game Developers Conference. Here, John McLean-Foreman talks with Sweeney about Unreal Tournament, his experience at GDC, and his favorite games.

Give us a quick backgrounder.

I started at Epic about nine years ago with a little shareware game called Jill of the Jungle: a little platform game. For the next few years, I was mostly managing Epic and being the producer on projects, which wasn't much fun because I'm a programmer at heart. Around 1996, I started working on Unreal with James Schmalz and Cliff Bleszinski. That was in development for a long time; that was a three-and-a-half year project. We all worked on our first major project for the first time, and learned all the ropes on how to make a 3D game. We also learned how not to make a 3D game. (laughs) But in the end it all came together, and Unreal went on to sell really well. After Unreal, we did Unreal tournament, which shipped in 1999. We did the Unreal Tournament Playstation 2 version, and now we've been working on the next generation of the Unreal technology, and started to work on our next game.

How well do you think that Unreal has ported over to the PS2?

To PS2 it did okay. With Unreal Tournament, we were aiming to make a launch title. Really, just get the game up and running and tweaked for the console, but not really take total advantage of everything that what possible, given the amount of time there was. So, it ended up being a good game, it's, I think, the number eight Playstation 2 game right now. But it's not the ultimate console first person shooter type of game. With our next project, we're really focusing on the console aspect of it from the very beginning, trying to make a good game. You know, a good PC game, a good Xbox game, as good a version on the Playstation 2. I think that kind of approach will, in the long term, work out a lot better because you can only do so much when you take a game totally designed for the PC and try to port it over. When you design it from the ground up, you have a lot more possibilities.

Will your new engine have any basis in the Unreal engine, or will it be something that we haven't seen before?

It uses the existing Unreal technology as a starting point; we've pretty much redone all of the rendering. We have an all-new polygon pipeline for rendering extremely high detail, high polygon environments. So, we've been focusing a lot on, and taking advantage of the new hardware TnL (Transform and Lighting) cards, and the NV20 [GeForce3], and all the new pixel shader and vertex shader effects that are possible. So, from a rendering point of view it's going to look all new and improved, but a lot of the tools are just incremental improvements. We spent a lot of time improving the Unreal Editor, but it's the same basic design. It's the same with the Unreal scripting language. Some parts of the engine are still very up to date and timely, so we're not going to spend another year redoing them when we don't have to.

One of the things that you've been quoted saying is: "One thing that people lose sight of when making games is that they forget to put the fun quality into it."

Yeah, I guess that's pretty typical. That's a bad thing to do when you're trying to make a game whose whole point is to be fun.

Especially when you're programming code, how do you think in terms of fun?

Well, it depends what you're working on. When you're programming graphics code you're not thinking of fun, you're thinking of fast frame rate and beautiful visuals. When you're writing gameplay code, when you're building levels, when you're doing all of that, you're thinking about the fun factor. So, different people on the team have different jobs and different focuses. With the Unreal technology, I've always been focused on the technology side of things. I mean, I play the game a lot to make sure I'm enjoying it and everything, but the graphics algorithms and design don't have much to do with fun.

How much does the Unreal community affect your decisions on how to alter the game?

That's actually been a really huge factor with Unreal Tournament. With Unreal One, we started out with the design in a vacuum, and then to our surprise, all these websites started popping up: Unreal fan sites - interviewing us, showing screen shots, and message boards talking about the game. We started following them then, but it was really Unreal Tournament where we made the community our number one focus. So, we go on the message boards constantly, see what people are saying about adjusting games, seeing what people were thinking about our screenshots. We'd invite a lot of webmasters and random gamers from all over the place over to our office to check out the game and give us some feedback. Starting with Unreal Tournament, the community has really been an integral part of our development process. If the community doesn't love the game, then we're screwed.

Do you do specific things that get them more involved in the whole process?

Well, we're really a facilitator. We don't run Unreal websites, we don't go out and try to start things or anything, but as game developers, we put a lot of influences into creating good level editing tools, a good scripting language, and really making those things approachable by users. We make good documentation for Unreal websites, we make sure it's out there. Our job there is really just to get the tools into people's hands. If they don't pick up on it on their own then there's really nothing we can do to force them.

Have you ever thought of making an official tutorial for the Unreal Editor?

We do that kind of stuff now and then, but really, the community has taken over that. There's hundreds of Unreal editing and scripting tutorials, and a few of them are really, really good and really detailed. We even point a lot of our new licensees to these community run web pages where they have tutorials on how to use the editor, for example. When we write documentation it's usually the pretty hardcore stuff, an overview of the Unreal Networking Subsystem for example, rather than tutorials. We do a lot of in person visits with Unreal technology licensees, showing them tutorials and stuff.

Everybody on the team has spent his time developing their stuff, whether they're a level designer or a programmer or whatever, part of that job includes documentation - but we don't have a full time writer or anything.

Do you foresee that you will get back to the storytelling aspects of Unreal or are you happy with the way that it's going with the multiplayer community?

Well, I can't say a lot about our next game, but we're really trying to mind the best of both worlds. What we got right with Unreal Tournament was keeping the single player and the multiplayer in the same style of gameplay. Okay, one has bots, the other has human opponents, but it's the same game. What we found extremely hard with Unreal One - we were trying to create a big story driven single player game with a completely different multiplayer. You know, with deathmatch maps and everything. We basically created two games, and that took as much time as creating any other two games. That kind of detracted from the whole project. It wasn't focused on one type of game or the other, it was doing both. We got out of that with Unreal Tournament. Unreal Tournament had very little story other than the one we made up at the last minute. In the future, what we want to do is keep the idea that the single player and multiplayer experience are the same, but really be able to integrate the detailed story with it, and give the player objectives rather than just: go shoot everybody on this level. You know, create a more in-depth type of game. Real-time strategy games have set a very good example there. You're getting the player involved with the story and not breaking the idea that single player and multiplayer are fundamentally the same kind of gameplay. We're not going to make a real-time strategy type of game, but we're going to learn that lesson from them.

There are a lot of games that have used your engine, some to greater effect than others. There is a fine line between what's going to make a story immersive and what is just going to be too much and/or boring. Have you learned that yet from watching people who have used your engine?

We always err on the side of getting the player straight into the gameplay and not bothering too much with cinematics and things. We'll keep that kind of philosophy. One thing that I've never liked is in-game cinematics where you cut out of the game and go in to a movie, and the movie is prerendered, and it looks a lot better than the gameplay itself. That jars players and makes them realize: "Gee, the game's rendering just isn't that good." What we're starting to be able to do now, especially with the next generation technologies, is do any kind of cinematics in the game, not just stop gameplay and go to a cinematic, but integrate it into the story and into the flow of the game. Half-Life was the first game that really started down that path, but it can be taken a lot further. That's my view of the ideal: to not rip the player out of the experience, but to make the story part of the gameplay.

Deus Ex uses the cutscenes within the Unreal engine, but there seems to be a random quality to it. If you went back to watch the same cutscene over again, it would be somewhat different than the first time.

They did an amazing job with it. The game has a lot of different plot twists that have a significant effect on the end result. I don't know if anybody's seen the whole game because every time you play it you can do things differently and get different results. They did a great job with it. So, it depends on the type of game. You really want that with a roleplaying game, but some games, you tend to have more linear gameplay going through a set of levels. You know, whatever's appropriate.

When you are programming, what is the one thing that you try to keep foremost in your mind?

(Laughs) The one thing? It's more of a balancing act between all of the different tradeoffs. There's always the performance aspect of your code: you've got to get it running fast enough for the gameplay to work well. There's also the simplicity issue. If you can write something in 10 lines of code, or 20 lines of code and do it slightly better, it's usually best to do it in 10 lines and just take the slight penalty for it because you end up with an enormous amount of code that you have to deal with every day. Productivity becomes the limiting factor in game development. No game doesn't ship because the artists were late finishing their work.

How do you best find the bugs in your code?

You want to divide the code up into modules. There's a lot of reasons for that. One is it's easier to isolate problems. Another is it's easier to work on a project with multiple people. You can't have a bunch of programmers editing the same file - it would become a big mess where nobody remembers exactly what's happening. Our philosophy: we've always tried to keep the components of the engine clean and simple.

Does anyone help you program the core engine and the scripting language? Do you find it difficult to delegate?

Well, with Unreal One, I was pretty hardcore about keeping all that to myself just because, at that point, we only had one other awesome programmer at Epic: Steve Polge doing all the AI and gameplay code, me doing all the engine stuff. That worked out okay for Unreal One, but with UT, we wanted to have a lot more features and do a lot more stuff. We didn't want to spend three-and-a-half years developing a game. So, since then we've really learned to work well with multiple programmers. Nowadays, we have six programmers working on the engine, and everybody has their piece of the engine. A lot of other people are helping out with various aspects of the rendering code and the gameplay code. Everything is really well divided up. It's not like a master programmer and a bunch of assistants. Everybody, in their own section of the code, they're the architect, the programmer and the bug fixer.

Are you taking any tutorials at the GDC this year?

(Laughs) I haven't had any time to go into the tutorials. Mostly I'm here, meeting with guys, showing the technology, talking about stuff, doing the occasional interview and seminar here and there.

Would you find anything helpful by going to the seminars?

Yeah, there are a number of seminars that I'd really be interested in going to. There are some incredibly smart people here, but there's also a lot of noise in proportion to that signal. There's definitely a lot of good stuff to learn here. If you go down to a presentation, like, there was one on rendering multiple resolution meshes, you know, level of detail - Stan Melax spent the last few years working on that. That's way more focused than any of us could afford to put into any particular task. That kind of knowledge sharing is very useful. Then there's some marketing guys talking about "how to make your game sell a million copies," and that's a waste of time. (laughs) Like any marketing guy knows how to do that.

Do you think that there is any accuracy to the predictions that the PC is going to die out?

Well, I see the PC games business increasing and not decreasing nowadays. You used to have this fact of life in the PC market, probably 95% of games don't make a profit - they lose money, and probably 80% of them just completely bomb, and are gigantic losses for the publishers. Because you see a lot of crappy games coming out, a lot of clones, where somebody identifies a great game like Command and Conquer, and then tries to make a crappy clone with an inexperienced team on a quarter of the budget. Of course it sucks and nobody buys it. Then those publishers are the same guys who are saying, "Oh! PC gaming is dead!" If you look at the guys who are creating the really good games, you can reliably ship good games and have them sell well as long as you're smart about it, and you're realistic about your strengths and limitations.

Apart from the fact that an inexperienced team worked on them, why do you think that the majority of the clones are terrible? Do you think that there are other aspects to it that makes them bad?

Cloning games fundamentally works sometimes. If you look at any major genre, there's always at least two games - you could even say that Unreal One was an attempt to make a Quake clone. The game was very successful on it's own because it wasn't just a clone, it added a lot of new features to the genre, some really nice new visual effects, a lot of new editing tools that the community picked up on… It was adding a lot of things. You see a lot of clone games come out now that don't add anything to the genre, and just subtract by not having as good artwork, and not having as good gameplay, and being rushed out to market. The PC market has always been sick like that.

If every publisher was required by law to drop 80% of their games and only focus on the remaining 20%, I think that you'd see a lot more games coming out. I think that you'd see the industry sales increase overall even with far fewer games coming out because those games that do get completed would be a lot better. But, you know, publishers don't do it that way. They're always out for the quick buck. Every publisher has at least one major success, and they say, "Oh wow! Look at all this money we made from this one game. Now, if we make five more like it, we'll be making five times more money!" That's the big thing about the game business: it's not scalable at all. Development teams aren't scalable. A team that's created one good game isn't going to be able to split into two teams and create two good games. They're probably going to be able to create two mediocre games, or something like that. It's this lack of scalability that nobody seems to realize and recognize formally. It's very weird because companies like Id Software have always been focused on staying small, and making a good game, and have been able to do well repeatedly, game after game after game. It seems like a lot of companies don't look around and notice that. They just think: "We can be more profitable by becoming bigger." Just the opposite happens.