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.

How do you put the right teams together? How do you find the people that you really want?

We hire people very slowly. Once in a while we look for somebody for a specific position, but often it takes six months before we find the right guy. Most of the people we hire aren't "Okay, we need a level designer. Let's post 'help wanted' ads, and look at the level designer resumes that we get." Mostly it's waiting around for six months, or eight months, and looking at all the level designers releasing stuff on the Internet, and picking the best one. When we see someone who is clearly way better than everybody else, we go after them really aggressively. I wouldn't say it's easy, but it's possible to hire extremely high quality people as long as you don't try to grow really fast, and as long as you're a fun, attractive company to work at. At Epic, we can pay people really well now, but even when we didn't have a successful game under our belt, and we weren't paying huge salaries or anything, we were able to attract really good people. We have a good team to work with, really well balanced developers, and the game is developed by developers - it's not controlled or dictated by marketing people or business people who are out of touch. Developers like that.

Do you think that the best games are always going to come from the smaller companies that aren't controlled by the publishers?

At least in the United States those are really the only teams who are able to create great games time after time again. It's either by having a small team that's focused and does a great job, or by having a huge team and just investing and enormous amount of money into development. If you have an 80 person team to develop a game and it's not a success, then you're guaranteed to lose money. Whereas with a 20 person team, if our game sells half of what we expect, then we're still not losing money on it, we're just not doing as well as we expected.

By making your engine so accessible to the public, do you feel that that you're increasing the amount of people who play your game or are you creating your own competition?

If we're creating our own competition… Great! We can only develop one game at a time, and that takes at least 18 months. Whereas when we work with other partners who are doing great stuff with our engine, you know, creating games like Deus Ex or Undying, those games we can really be proud of. Even though we don't develop them, we contributed to them, and we're making some money from those projects. I think that's a good way for a company like us, you know, a small focused team, to be able to do more stuff without growing big. There's always the ever-present threat, some new team that nobody's ever heard of, who's going to come along a make a game that blows us away. I think we always live in fear of that kind of scenario. We've been able to keep up so far, but we work really hard. It's not like we're resting on our laurels. We're all working the same 60-80 hours a week that we were working during Unreal One.

How do you come up with something new and innovative when so many people are creating first person shooters?

It's kind of a random thing. You always have to keep watch on what's possible with the technology, and graphics cards, and CPUs and everything. Every once in a while there is a major, fundamental change where something that was completely impractical before becomes possible. One was the switch to hardware rendering. That was a pretty obvious thing back then because everybody had so much notice. Now there's other changes too. With pixel shaders and vertex shaders, you can start doing completely accurate lining on all of your objects, and you have a whole bunch of new tradeoffs there. Most of that comes from just being flexible and being able to reinvent all of your assumptions about how you develop games every once in a while. Nowadays we're creating levels that are more than 100 times the polygon counts of Unreal Tournament levels. Our whole way of building objects and using tools has completely changed. You can no longer go through and build every little wall and floor in your entire game from scratch. You have to build big archives of different pieces of architecture, you know, doorframes, doorways, and spires, and things like that - build libraries and share them.

We're always looking at our productivity and seeing where are our bottlenecks and how can we fix them? So many companies are the master of one generation of technology or consoles or whatever. When the next generation comes along they just don't bother learning it, and they think that they can keep doing things the way they always did. It's easy to be the rebel when you're small because we can completely change direction without any big ramifications. Whenever we're ready, if we want to do something different, we can. If we wanted to make a game that's totally not a first person action game, no problem, we can do that. Six years ago, we were doing Jazz Jackrabbit, and Epic Pinball, and these 2D games. Now we're doing Unreal. What will we be doing six years from now? Well, who knows? Maybe it will be more Unreal style games, or maybe it will be completely different. I don't think that we've pigeonholed ourselves as one particular kind of game developer.

If you could make your perfect game, what would it be?

It's hard to say nowadays. I think that we're doing a pretty good job taking advantage of what the technology makes possible. Long term, there are some cool possibilities. There's this big trend towards massive multiplayer games. Of course now there's 60 teams developing massive multiplayer games, and three of them will be successful, you know, the cloning effect. The big problem with them is they look a lot like America Online, and Compuserve, and Prodigy looked like six years ago. They're totally closed systems run by some, you know… sorry, the "coolest" managers. They don't go in, and play the game, and talk to customers, and make sure they're keeping them happy. What seems really neat is to kind of take the Internet approach to that. You know, we're not going to have one central bureaucracy in charge of the thing, it's just going to be randomly distributed, and it's not going to work perfectly, but it's going to make up for it by giving everybody control to do their own thing and innovate with it. So, do a distributed massive multiplayer game where anybody can run a server, and anybody can add content to the game. I have no idea how to make that work from a gameplay point of view, but that kind of stuff sounds interesting. I don't think that closed system model that you see going with Everquest and Ultima Online, I don't think that's sustainable. I don't think those games will exist ten years from now. How are we going to make the transition? Who knows? Games, and programs, and information want to be inherently open and modifiable by users. So, you've got to get to a different system. It's hard to do also because, even first person shooters, there's not a big incentive to cheat because you just get some more frags maybe. Whereas with a massive multiplayer game, there's huge incentive to cheat. If you could cheat, you could be the most powerful person in the game, and have these huge advantages. So, you have to deal with these issues like "how to avoid cheating", and things like that. I think that we'll get there at some point. If you've seen the Freenet Project, basically, it's like Napster but with everything encrypted to the point where servers don't know what kind of information that they're sending back and forth through the network. Everybody has end to end communication, but with complete secrecy and complete lack of ability to hack the system. That kind of stuff could be applied to gaming at some point. That would be cool. I'd love to do something like that someday, but the chances are 20% that it will happen or 80% something else will happen in its place. Definitely games will get better.

What games do you play apart from Unreal?

I haven't played a lot recently; I played Undying most recently. That was very cool: very scary. Last game that really scared me when I was playing it, you know, go into your room, turn out all the lights, play the game, that was Doom, and that was very long ago. I guess some people say Unreal is scary, but when you're developing it and playing it every day, you just don't experience that. Undying really got that point across with the realistic shadows and the scary sequences.

It must be very gratifying to have put such hard work into something and have it become such a phenomenally popular product.

I guess. Some of the team members feel that way. Everything that I've done in the past, it doesn't matter because I'm working on something different now, and it's either going to be a big success or a big failure, and I don't want to screw it up. I really never have looked back. I was playing Unreal Tournament really heavily online for the first month of it shipping, and then I stopped. A lot of the guys still play it, but especially as the technology guy, I always have to be looking way ahead of the current thing towards the next thing.

Where do you get your inspiration?

It's a lot of random influences. If you go for a walk in the woods, and you look around, and you see the trees and the amount of detail there, you realize that we're still a factor of a hundred short of being able to render those kinds of scenes in real-time. So, looking at things that way, looking at real life and saying: "Okay, how far away are games from this kind of thing in terms of rendering, and behaviour, and realistic scenes, realistic lighting?" That's really interesting, to just look at that and figure out: "Okay, how can I get a rough approximation of this into the game that runs fast enough?" We play a lot of other games; most of the guys on the team are really hardcore gamers. I play other games, but I'm not that hardcore. You're much more likely to find me in the visual C++.

With Unreal One, I was in Canada, it was freezing cold, and I was walking along, and there was a heavy haze everywhere. There were these streetlights with big globes of fog illuminated around them. I was saying, "Hey! I could program that!" So, we had diametric fog as one of the big features of the Unreal One engine.