Author: by Benj Edwards

Gears of War. Unreal Engine. Journalists commonly use these two phrases to quickly encapsulate the history of Epic Games, a highly successful video game developer based in Cary, North Carolina.

And why not? The Gears of War franchise has sold gazillions of copies, and the Unreal Engine commonly powers blockbuster titles like BioShock. Both successes have made the gaming industry look up and take notice. But to stop with those platitudes is to ignore a much deeper and richer past.

Epic Games, founded by Tim Sweeney in 1991, has a much bigger gaming footprint than most people realize. When I hear "Epic," I think back to a time in the early 1990s when I was deeply involved in my local computer bulletin board system (BBS) scene. BBSes were early dial-up online services that provided message boards, primitive online games, and numerous free files to download.

At that time, Epic MegaGames -- as Sweeney's company was then called -- published some of the world's most popular and successful shareware games. Games like Jill of the Jungle, Jazz Jackrabbit, Epic Pinball, and others could be found in nearly every BBS file section across the U.S.

And the game that started it all for Sweeney was ZZT. Released in 1991, ZZT is a text-based action/adventure/puzzle shareware title with a built-in game editor and scripting language. Think LittleBigPlanet in text. Sweeney's experiences with ZZT led directly to Epic's success with Unreal Engine, which inseparably integrates game engine and editor much in the same way ZZT did.

Sweeney -- now CEO and technical director of Epic -- is probably a genius, and he's definitely a geek. But he's not a geek in your standard "never leave the basement" sense. Although soft-spoken, Sweeney is quietly confident, and he possesses a keen business instinct that is rare in an analytical genius of his caliber. That instinct for business led him (and Epic) directly where they are today.

Earlier this year, I met with Sweeney to discuss his personal history over lunch. With so much press coverage overlooking Epic's early days, he was happy to oblige. During our one and a half hour conversation, we talked in earnest about Sweeney's early programming days, the story behind ZZT, the origins of Epic, the '90s shareware business, and even a bit about the future as well:

The Early Years

Where did you grow up, and where were you born?

Tim Sweeney: I grew up in Maryland in a little town called Potomac. It's where my parents live. My father started out working for the government. He worked for the Defense Mapping Agency creating maps from satellite imagery long before that was commonplace.

Do you mind if I ask you when you were born?

TS: 1970. That makes me 38 now. Scary. That's really old. For a long time -- this shows how old Epic is -- I was a really young guy running a game company. That was kind of unusual. The funny thing, though, is you see that happening throughout the whole industry. People really started getting into game development in a big way in the early-mid 1990s, so the industry's grown that much older.

Everybody's growing up together.

TS: Yeah. Back then, your typical developer was in his twenties; now, he's in his thirties. Most developers have a family -- wife and kids -- so the industry's really changed a lot.

What was the first computer you ever used?

TS: I started out with an Apple II. Which was a good computer to learn with because it had absolutely no hardware accelerated graphics or anything like that. It was just a little 6502 processor, so you had to do absolutely everything yourself. Of course, you learned things the hard way, and you basically learned about computer science rather than "how to use a Commodore 64 light-blinking flashing effect."

Did you program assembly on that, or did you just stick to BASIC?

TS: I started out with BASIC and then I learned machine language. I didn't know assemblers existed at that point, so I just learned the hex op codes and typed them into the little debugger manually. I'd write some fairly complicated assembly programs, manually assembled. That was a crazy time.

A lot of game developers actually started out that way. When I was out at Richard Garriott's new start-up, which is now NCSoft Austin, he had an Apple II sitting out, so we're like, "Oh wow!" I sat down, and I could still type the crazy assembly codes into it.

Yeah. That was my first computer as well -- an Apple II+. It was already pretty old when I got it, but I learned how to program BASIC on it.

TS: The great thing about that computer -- I just bought one about a year ago to go back and use it. The thing that strikes me is the first thing that starts up when you boot it. You're in a programming language. Try to find a programming language in Windows. Your computer's a million times faster, but you can't do a damn thing with it.

What was the first video game or computer game you remember playing?

TS: I used to play the early arcade games. You know, there's Pac-Man, Defender... there's this one I was addicted to for a while, Space Firebird. It was this little Galaxian-style game with a bunch of things flying around. I was never really a serious gamer that way, but I'd go to the arcades a lot and play them.

I guess when I was about eight or nine, the Atari 2600 came out, and it was a really sucky game machine. It was obvious even at the time that it was sucky relative to what the arcades could do. It was disappointing.

After that, I got the Apple II, and I really missed out on all of the game consoles after that. I missed out on the early Nintendo and Sega Genesis. I ended up basically being a generation ahead of CliffyB -- you know, the guys who got into computers and did gaming the computer route rather than going into the game consoles. You end up with a very different perspective that way.

Sounds like it. So you started programming on the Apple II. Did you move on from there to a PC?

TS: I got a PC in 1989. The Apple II is a great machine, but the problem was that, by the late 1980s, there was really no market around it anymore. There weren't games being actively developed, all of the bulletin board systems and developer forums had moved on to IBM-based development.

I moved, kinda begrudgingly, 'cause it was a pretty complicated and messy machine at the time, you know, with DOS and early Windows. I got that in 1989; I started writing random little programs for it.

I'd written maybe several hundred programs for the Apple, including maybe fifty little games. Some of them were pretty extensive, but I'd never released anything until ZZT, which I started in 1990 and then released in early 1991 sometime.

Did you make any games like ZZT for the Apple II?

TS: Yeah. So I guess I was 11. The first serious game I wrote for the Apple II was -- the Apple II had this low resolution graphics mode, it was like 40 dots by 24 dots. But you had 16 colors to work with, which was just a huge number of colors.

So I made this game in the style of Atari's Adventure: you are a dot and you move the dot around the screen and you pick up different items and go between rooms, so I learned most of the basic programming techniques back then.

I started out writing one program for each room in the game world. So I'd write my own little input loop for each room, and then I realized, "Oh wow, there are subroutines, so I can call a subroutine to do an input." And that generalized everything.

Then I realized I could store the game board procedurally rather than writing a program to draw them and then reading the frame buffer to go from there. So I learned a huge amount of programming techniques that way. I was probably 12 or so, in probably 1982 or '83 when I wrote that.

Did you ever want to show those to the world? That would be pretty amazing. If you ever wanted to release those, I could help you copy the disks into disk images -- if you still have those disks.

TS: Sadly, I don't. It just didn't seem important. Yeah, that's the tragedy. I don't have the ZZT source code either. I wish I'd saved it all.

What happened to the source code? Did you lose it accidentally or...

TS: No, I just didn't pay attention to it. There were so many other things going on at the time. It was probably lost some time when we were working on five Epic projects -- you know, working with Cliff on Jazz Jackrabbit and James Schmalz on Solar Winds, and all these other games.

There were a few years at Epic where I'd gone from being a programmer, writing all of the games, to just managing projects -- I was basically a producer for about three years before I started working on Unreal as a programmer again. And that was crazy -- that was 16-18 hours a day straight for years.

The Origins of ZZT & Epic

Did your parents have any experience with starting businesses? Is that where you got the idea to start your own company?

TS: My older brother, Steve Sweeney, who's 15 years older than me, grew up in Maryland also, but then he moved out to the west coast and got involved in a bunch of start-ups in San Diego. When I was about eleven, I went out there several times to visit him. He was my role model for a few years there, because he was still pretty young and he was working for a bunch of cool companies.

I got to see the offices where he was working. He had all sorts of computers -- he was doing crazy things for minicomputers and mainframe communication at the time, and he'd be designing software and hardware drivers to run it. And he had a cool car and he had his own little house near the beach.

That was really cool, just to see that in the computer business, you didn't need to have an ordinary job at a company -- just go wear a suit every day. You could have fun between companies doing different projects. So that really was a big influence on me in deciding to start a company.

Take me through the process of when you started making ZZT.

TS: The funny secret behind ZZT is it started out while writing a text editor. I'd used Turbo Pascal and other languages on the PC, but I didn't like any of the editors that came with them, so I started writing my own.

I got bored with that at some point and decided to make the cursor into the smiley face character, and then make different characters you could type that would block the player or move around in different ways. See, you'd use this text editor to draw the game board and then move around it and play the game. That eventually evolved into the game and the editor ZZT.

It's funny, because ZZT is one of few things that started out as a tool before it was a game. And all the gameplay evolved from just thinking of random weird things to do with the characters. There were some other games along those lines like NetHack and Kroz.

I was going to ask you about Kroz. When I first saw ZZT, I thought it was a lot like Kingdom of Kroz from Apogee. Did that inspire you in any particular way?

TS: I'd been working on ZZT for several months -- I guess it was three or four months -- before I saw Kroz or NetHack or I realized anybody else had done anything like that. So I'd come up with a bunch of ideas on my own, and then I played all of those games and saw that there were a whole lot of other ideas to draw from.

For example, Kroz had these bombs where you have this little thing that looked like a bomb on the screen, and then you touch it, it starts a countdown, explodes, and clears out some blocks. So I borrowed a bunch of ideas from it at that point.

That's kind of a common pattern in everything I do. One minute I'm completely on my own and I think, "Wow, I'm a genius, I can't believe this idea nobody else had!" And then you look at the references on it, and it turns out that a hundred other people have done the same things in the 1980s. And then you look, and you get your additional ideas from those. Between invention and stealing, you come up with a really good combination of ideas.

When you were writing ZZT, where did you live? I read that you were going to school.

TS: I was in the University of Maryland at the time. Gosh, I guess I started in 1989 -- that was crazy. At that point, I was two years into college, going to school; I was doing mechanical engineering at University of Maryland. University of Maryland is a party school unless you're in engineering, so that was really tough, actually. I learned a lot of useful math that I wouldn't have learned on my own.

I basically studied and did school work all day, then programmed all night -- working on ZZT. On the weekends, I'd come home, and I had this little shareware business I was growing after I released the game.

I'd receive a bunch of orders through the mail (people would send their checks in), then I'd copy disks on the computer and send them out. At the same time, I was working on Jill of the Jungle, the next game.

Did you live with your parents or did you have your own place?

TS: I was in a college dorm for four years there, but I was still in the same town with my parents -- I'd go back there on weekends. Mostly, I kept my computer there and did most of my work from there.

Did you ever finish your degree in mechanical engineering?

TS: Not quite. Epic was growing rapidly, and I was one credit short after four years. I didn't follow through and get the degree.

Did your college studies in mechanical engineering have any influence on your game engine design? Are the two related in any way?

TS: I've always enjoyed building things, from go-karts to programs. And I wanted to avoid undergraduate computer science studies -- the courses weren't challenging because I knew most of it from my programming work. Mechanical engineering seemed like a good alternative.

But it was somewhat disappointing, as it takes far more effort to build an interesting mechanical contraption than an equally interesting program. However, the math courses were immensely useful. There are some things you just don't know you need to know until you know them.

Where is the University of Maryland?

TS: College Park. It's close to Washington, D.C. My parents lived in Potomac, Maryland. It's a rural-looking area along the Potomac River.

So that's why you called your company "Potomac Computer Systems" first.

TS: Yeah, that's how I started out.

The name sounds almost scientific. Why did you change to Epic MegaGames?

TS: I started Potomac Computer Systems because I wanted to do computer consulting. I'd gone through this succession of jobs: I had this job at a hardware store that paid four dollars an hour -- basically minimum wage. That really sucked. It was really hard work, and I didn't make much money.

I started mowing lawns after that, and I found out that by getting a tractor and going around and being entrepreneurial, I could make about 20 dollars an hour mowing lawns. So I was thinking, "What can I do to make more than this?"

I was going to start a little computer consulting business where you create little custom databases or things for people -- but that took a lot of work, actually, and I didn't get anywhere with it. So I had all this business letterhead and business cards with "Potomac Computer Systems," and by the time I finished ZZT, I thought, "Oh, might as well just use this." I hadn't really thought of it as a game company until after releasing ZZT.

After ZZT came out, I was selling about three or four copies a day, which is a hundred dollars a day. It was income you could live on, actually. I decided I was going to try to do that full-time and make a living from it, so I started working on Jill of the Jungle, this 2D side-scrolling game.

That was early 1992, and at that point, Apogee had released a number of little 2D games, and id Software had released Commander Keen. It was clear that there was some real money to be made in that business. I was trying to grow PCS into a real company, so at that point I realized that we needed a serious name, so I came up with "Epic MegaGames" -- kind of a scam to make it look like we were a big company.

Because "Epic" sounds big, is that what it was?

TS: "Epic ... Mega ... Games" -- yeah. Of course, it was just one guy working from his parents' house.

Did you get the name from any specific place? Did you think of other possible names first and pick one from that?

TS: Yeah, I was thinking of a bunch of names. At that point I was kinda fixated on competing with Apogee software, which later became 3D Realms. They were, by far, the number one shareware publisher at that point -- very similar to Epic in our business model.

I was trying to think of a name that would stand up well against that name. I was thinking, "Apogee... Perigee... Epic." There were a bunch of little ideas I came up with, but Epic seemed interesting for the time.

Of course, once the company became really successful after Unreal, I figured we didn't need to pretend, so we dropped the "Mega" part.

It's kinda like growing up a little bit, I guess. Your name seems more serious that way, but strangely enough, I still think of you as "Epic MegaGames."

TS: That's funny. The "Mega" didn't stand the test of time. Now it seems like a 1980s type of name. But "Epic" stands out well.

Yeah, "Epic" is a great name.

TS: Of course, now there's a resurgence in the use of the word "epic" associated with everything, and it's horribly overused, so that will probably seem a little dumb in a few years.

Does the name ZZT stand for anything?

TS: No. At that point, games were mainly distributed on bulletin board systems [BBSes] -- basically the precursor to the internet. I always wanted to run one myself, but I figured if I had done that, I probably wouldn't have had any time to develop games. So it was probably a good career move not to.

There was this scam: everybody who released shareware would rearrange their name so they would always be sorted to the top when people listed out the files available for download.

So at that top of all the file lists, there was this huge clutter of junk that you wanted to skip past. So I did the opposite and named ZZT so it would appear at the bottom of all the lists. So ZZT was just a scheme for that. It's also the cartoon sound effect.

In ZZT itself, there are a couple references to ZZT with a dot after each letter as if it were an acronym.

TS: No, it wasn't an abbreviation for anything. Some people were trying to reinvent what the name actually was. Somebody came up with "Zoo of Zero Tolerance" -- but no, it wasn't really an abbreviation. I'd actually thought of the name "ZZT" years before I created that game -- it just seemed like the right name for it then.

How long did it take to program ZZT?

TS: ZZT wasn't a very big project. It was certainly under a thousand hours. I think I spent about nine months on it just because I was working on it part time between mowing lawns in the summer and going to class in the school year. It was a relatively simple project; I think it was 20,000 lines of Pascal code.

Wow, Pascal.

TS: Yeah, it was a good language. It was more rigorous than C++. When I moved from Pascal to C++ to create Jill of the Jungle, it was a real shock that people would actually be using a programming language that was so bad for large-scale development. To think that operating systems are built in that sort of language was really terrifying.

So you think Pascal is more ideal to work in than C?

TS: It forced the programmer to be more structured and to avoid low-level hacking as much. It's not the best way to get maximum performance, but I think people tend to write much cleaner code when working in a language like Pascal than in C++. It influences your whole way of thinking about systems when you're writing code in a really structured way like that.

How many copies of ZZT did you sell?

TS: Several thousand. I'd say four or five thousand by now. I was selling three to five a day for the first several years. My father still lives at the address where Potomac Computer Systems started up, so he still gets an order every few weeks.

Does he fill them for you?

TS: Yeah, he's retired now, so he doesn't have much to do. Every week, he'll just take a stack of a few orders, put disks in them, and mail them out. So you can still buy ZZT.

That's great. I should buy a copy from him. There's a character in ZZT that my friend loves called "Jazz Man," and he sings a little tune. Is there any story behind that?

TS: Yeah, I was in high school jazz band. I was learning jazz improv -- really badly.

I just drew a bunch of random stuff in ZZT. That was the great thing about the game: the graphics were so bad that you could do whatever you wanted, and people would be forgiving of it. There's just so much bizarre stuff in ZZT that you could never do in a graphical game that had to be realistic and immersive.

I liked that about it too -- there was the talking tree.

TS: [laughs] Yeah. One of the common themes you hear from artists is that to create great artwork, you have to highly constrain yourself: limit the tools you can use, limit the media you're working with, and then just do the best thing you can do there.

ZZT is really the ultimate expression of that -- it's such a weird, constrained environment that there's a certain set of things you can do, so it's really flexible and interesting. Whereas now, you can go license a game engine like Unreal. You can build absolutely anything, so it's much, much harder to create something that's cohesive.

Distracted by Network Protocols

I ran a BBS for about five or six years, from 1992 to 1998...

TS: That was an interesting time, because '92 was before the internet had come along, so at that point there were a bunch of efforts to create some graphical protocol for communications so you could dial up into a BBS graphically.

Like RIP graphics? Stuff like that?

TS: Yeah, there was that. There were a bunch of Apple-based efforts, a bunch of IBM-based efforts, and that really seemed like a fertile area. And, at the time, if you asked me what I was going to do when I became a programmer full time in 1990 or 1989, I saw that as the key problem to solve.

I saw a hundreds-of-millions type of opportunity in that, if you could be the one to define the standard graphics protocol for communicating with stuff, then you could dominate.

I spent quite a lot of time working on communication programs before I wrote games. It's funny, because if I had pursued that, I would have gone the obvious route of just trying to create a graphical protocol for modems and missed the whole point of the internet, which is quite a lot more than that, right?

You dial up into this system, but then you can communicate with all these different computers, and they're all connected through fast back end server connections throughout the world: anybody can message anybody else, and so on.

That was an extremely interesting problem at the time. I came pretty close to starting a business and pursuing that very seriously.

I thought the same thing -- in fact, a lot of people were trying to make some sort of web-based BBS back then, but obviously it didn't matter, because other ways of communicating on the internet took over from the BBS model.

TS: When I saw the web for the first time, in 1994 or so, that was really the most important business realization I'd had in my life, 'cause I'd spent thousands of hours working on communication programs, and graphical protocols, and things like that.

I'd been fixated on the problem -- which did turn out to be the central problem of that decade -- and completely missed the point of the thing, which was that you're not just trying to create a graphical protocol, but you needed to create a system that connected all the different machines together and then communicated asynchronously, right?

The big thing about the web is that you download this page and you're locally navigating through it -- you know, scrolling up and down, and selecting text -- as opposed to it being like a terminal, where you're sending mouse input and receiving draw commands back.

I remember using the graphical web for the first time and thinking, "Can people watch me doing this?" I could watch my users type out stuff on a BBS, so I thought that maybe someone could watch me navigate in my browser real-time.

TS: After that realization about the web, I felt really idiotic. It forced me to be in the mindset of "Everything I do from now on needs to be thought through carefully." With every major technical problem, I didn't just look at "What is the problem I'm trying to solve?", but I took a much bigger perspective: "How can we really change the game and win this?"

When it came to developing Unreal -- I think we started that in 1994 -- James Schmalz was writing a solo assembly language 3D game with a dragon flying over a terrain, kind of a Magic Carpet knock-off. And I was tasked with writing the editor for it.

But I really thought that through in a huge amount of depth in advance -- you know, looking at what Quake did and Doom did: they had this little crappy editor with a very advanced game engine behind it. Completely separate programs.

I thought it through in a whole lot of detail, and I thought that content development was really the essential ingredient in all of that. It was important to spend even more effort on the editor and tools than the actual game itself, just to empower the artists to make a great game.

So we came up with this editor-centric approach to game development, where you had this integrated editor that used the game engine for real-time display of everything. Real-time editing of everything, and all of that. And that came from really methodically thinking through the problem of "What do you really do, and how do I not miss the point in this revolution?"

ZZT was like that too, right? It was an editor and an engine. Users could create their own content, which was my favorite part about the whole thing.

TS: I really stumbled on that idea, rather than having it in advance. It just evolved from creating this editor that turned into a game editor that turned into a game.

And throughout the whole thing, I did recognize the importance of development tools, but I really never had a conception of what the game was going to be until it approached completion, whereas with Unreal -- really, ZZT was the road map of what the thing would look like.

It's a structure that we've been copying and pasting into ever-more-advanced game engines ever since: you have this editor, you have this game runtime, they use the same display environment, same programming language.

You have a scripting language for defining game events. There's really a huge amount of similarity between ZZT and Unreal, if you look at it. Unreal is a hundred or two-hundred times more complicated with more code, but it's still very similar in structure.

So you definitely credit ZZT as the base of your Unreal Engine ideas. If you hadn't done ZZT, you probably wouldn't have thought of Unreal that way, right?

TS: Yeah. Otherwise, we could have focused on making just a game, and the editor would have sucked. We would have built everything in 3D Studio Max. We would have missed out on many of the most interesting ideas behind it. And that would have seriously been detrimental with the mod community.

Beyond ZZT

Tell me about Super ZZT. Were there any improvements in the engine that were substantial over ZZT?

TS: Super ZZT was the same basic engine, but I extended it to scroll, so now you had these boards that were -- I don't remember the size -- several thousand by several thousand, so you could go for several boards at a time just scrolling smoothly through the environment.

I thought that was a big improvement. It was kind of the ideal I was heading for. I really love the Ultima style of game where you had this expansive, seemingly-limitless landscape that you can go through.

But I never really got to that point with Super ZZT. I had this idea from the very beginning that it was going to be a streaming game world, where you could have unlimited board sizes -- you know, millions by millions if wanted -- and it would just load parts of it on demand as you go through. But I was constrained for time. I wanted to ship something, and be able to release a lot of games, so I didn't put the effort into it.

The other thing I would have really loved to do but just didn't have the time for was make it a BBS-based game, so ideally, you could have a bunch of users dialing in and playing together, each user moving independently.

I always wished for a multi-user ZZT -- like a MUD where you could build stuff in ASCII graphics and just have other people interact through that.

TS: Yeah, even better: keep it live, right? You'd be able to build things in the MMO environment while people are playing through it.

While they're playing, yeah, just like on MUSHes. I don't know if you've ever been on MUDs or variants of them where you can program in a "softcode" -- a language written within the language.

TS: I saw a MUD in the late 1980s at one point, and it was astonishing to me. I'd never had any idea that you could create a multiplayer game like that with lots of players playing together -- and this one probably had 10 or 20 playing together at a time. It was just astonishingly cool.

From that point on, I could kind of envision the whole massively-multiplayer game idea -- it was obvious that you could take those techniques and extend them to graphical games and, wherever gameplay and graphics went, you could bring that whole concept forward. So I always wanted to do that -- to create a large-scale multiplayer game. That's another thing that I've always wanted to do but haven't ever actually gotten to.

Unreal has multiplayer you can get 20 players into a server and you can get some interesting interaction, but it's never been a large-scale MMO.

How well did Super ZZT sell compared to ZZT?

TS: Super ZZT was never successful. It was... maybe a copy a day at its peak. Hard to say why. I guess that's the danger of Super ZZT. It went more in the direction of being a real game with realistic scrolling, graphics, and everything.

Did it have an editor with it? I don't ever remember using the editor in that game.

TS: Yeah, it shipped with one, but there's some stupid cheat code you had to use to get into the editor.

That was probably your problem, then.

TS: Yeah, there was a business mistake there. Kroz did the same thing. With Kroz, Apogee released game for free as shareware -- one episode of it, and you could buy the other episodes. But the editor you had to pay money to get, so most people never got the editor or never saw it. So you didn't have this sort of user community developing around the editor.

ZZT included the editor in the shareware version and everybody was able to do it whether or not they sent in money. That was a huge factor in it being successful, I think.

Just looking at our current stuff, I have to wonder how much more successful -- how much larger the mod community for Unreal or more recent games might have been if we'd given away the editor tools to everybody without any cost at all.

Without selling the game to them? Is that what you're saying?

TS: Yeah. But it's a different scale. You can't really make the business comparison, because millions of people bought Unreal, whereas several thousand bought ZZT, so it might be that buyers of a game like Unreal are enough to fully support the community.

Did you ever consider doing a version of ZZT with bitmapped sprites?

TS: When I created ZZT, it was 80x25 column, 16 color text mode, basically. I then created Super ZZT, which was lower -- it was 40-column mode, so characters were square, which was better for the movement speed and everything. I was thinking at that point of creating a graphical game, sorta like Ultima-level graphics -- still tile based, but with iconic representations of everything.

There were two problems: one, I was such a terrible artist; I didn't have any collaborators at the time. The other thing is, a lot of the cool constraints that made ZZT interesting really don't work when you're unconstrained graphically.

With ZZT, every character is at a particular grid location in the world, and if you have fractional movement between grid locations, you have a whole different set of obstructions and rules for movement. Animation becomes more complicated, and then you have to handle collisions between guys which are half-way between cells. So I ended up concluding that it wasn't worth creating a tile-based game with unconstrained movement.

At the same time, I started working on Jill of the Jungle, and there were these 2D platformer games. That approach seemed to work better. You still had a tile-based environment, but you had gravity, so the characters were always drawn towards the ground.

You had a really clear method of finding where a platform is that you can stand on and what kind of tiles you can go through -- it just seemed like the better approach for developing a 2D graphical game to introduce gravity and all the constraints that come with it.

Jill of the Jungle was developed similar to ZZT. It started out as an editor -- I wish I had put more time in the editor along with the game; it was kind of crappy and didn't have a scripting language. Most of the deficiencies of that game came from just wanting to ship it really quickly to be able to compete in the serious shareware business, rather than spending a lot of time to develop a good framework for future re-use.

If I had taken a slightly different approach, I think I could have built Jill of the Jungle and the engine more modularly and had an engine that could have been re-used for four or five games. That could have made a few million bucks at that point. It would have been a distraction from Unreal, ultimately, but it certainly would have been a more profitable business approach than developing a whole bunch of external games with their own engines.

There's a game called Xargon. Did that use Jill of the Jungle's engine?

TS: Yeah, that's the one game that used the Jill engine. That was built by Allen Pilgrim, who started out as a ZZT level designer. He's a really smart guy, but he had absolutely zero programming experience until he started working with ZZT.

And he created a bunch of the winning levels in the Best of ZZT contest. So I contacted him to make Xargon, and he learned to program from scratch in C++ on that project and shipped the game about a year later -- really impressive work.

But then we went to develop Jazz Jackrabbit where Arjan Brussee -- this brilliant Dutch programmer -- wrote this platform scrolling engine, and Cliff Bleszinski designed the game levels and designed the game itself.

Did Cliff design the Jazz Jackrabbit character?

TS: Yeah, the whole game design and concept for the game was Cliff's. It was loosely supposed to be an answer to Sonic the Hedgehog on PC. Previous games to that had been Mario-style games: slow character movement and cutesy characters. Jazz Jackrabbit was still a cute game, but it was more bad-ass -- much faster and more wild movement.

Did you create the Jill of the Jungle character yourself? Was that your idea?

TS: Yeah. I wanted to do a Nintendo-style game and all of the PC shareware games of the time had these heroic male characters, so I wanted to do something to distinguish the game from that.

It could have gone further than that. We could have developed 3D games along that line, kind of what Eidos did with Lara Croft, but it never became a priority.

Did you ever think of making another Jill of the Jungle?

TS: At one point, I had a grand scheme to create a second 2D side-scrolling engine -- basically everything that I had wanted to do in Jill of the Jungle but didn't have time for. To create better smooth scrolling using some of the new VGA scrolling tricks that were available, to create parallax effects.

I was also thinking of doing some sort of real physics in the game. Not the sort of physics you see in LittleBigPlanet, but something that would have been pretty beefy for the time, like suspension bridges that change shape as you move around, and real dangling vines. But I never got around to that. At that point, after I shipped Jill of the Jungle, I went into a few years of just being a producer for all these external projects.

It was a funny time. I think that by not doing that, I made a really sub-optimal short-term business decision, but the funny thing is at that point we brought in a lot of the key folks that became Epic's great developers. And if I hadn't done that, it would have been lone wolf -- I would have made a lot more money at that point, but we wouldn't have the company we have now.

Growing Epic: Programming to Managing and Back Again

In the pre-Unreal days of Epic, what was your main role in the company? Were you managing people mostly -- as a producer, like you said -- instead of programming?

TS: On ZZT and Jill of the Jungle, I was almost exclusively programming. And from 1993 to late '94, I was kind of cheerleader/producer of all the external projects. So at that point we had three to five external projects.

We had Cliffy working on Jazz Jackrabbit, James Schmalz working on Solar Winds, this fighting game called One Must Fall was in development, and there were a few other projects like Zone 66 and other work. So there was a full-time job just to manage people, just to get new builds of the games from them and test them out, give feedback, and do all the marketing and everything.

How big was the company? For example, did you have an accountant, or were you handling all the finances yourself?

TS: Well, at that point, we scaled it from one person to about eight, I think. I hired several people to take phone orders. We got a little office in Rockville, so that we wouldn't have people coming into my parents' house every day.

My old friend Carolyn Smith that I grew up with did accounting and helped out with things like that. And then Mark Rein came on in 1992. He stayed in Toronto, but he did sales, marketing, and deal-making -- he signed a lot of deals that brought us more money.

Now you've got Mike Capps as the president. How did you transition from running the company to having a dedicated management team?

TS: We were pretty loosely managed through shipping Unreal, until -- gosh -- 2003 or so. We were basically self-managed. We had a small team: during that time frame, we never got more than 25 people, so I'd be the manager of the technical folks and Cliffy was kind of the designer, producer, and manager of the creative and artistic folks. It was very loose.

The thing is, with a company that small, you don't really need a lot of management. If you hire great people, and they're all self-motivated, then you can get by without a lot of structure. But as we grew -- I guess 2004 or so, we brought on Mike Capps and started developing two projects simultaneously. That was a strategic thing: we realized that having one team was too small for a modern game company.

The problem is if you have a single team, then you have a huge team developing a project through to completion. Then it ships, and now you want to figure out what your next game is. Well, the ideal way to do that is just to have a small number of people -- like five or six people -- doing pre-production work. Just experimenting with concepts, trying to figure out what the game should be -- doing that for a year or more before they figure out the game and before you scale out to a large team.

So the ideal team size goes from 30 people at peak to five to six people at the start of a project. If you have a single large team, you're pretty much screwed: when you go back into pre-production, suddenly you have 30 people on payroll; it's expensive and you aren't able to work productively.

For example, how do you start working on artwork and characters before you know what your game design is and what mechanics really work out? So we saw moving to two teams as the solution to that, that way you can always do projects overlapped so that one project's in pre-production with a smaller team, and another project's in full production. As one project completes, the other is ramping up.

That's a good idea. Do you still have that model?

TS: Mmm hmm. It's been more complex because, at Epic, we also have the engine team now -- it's big enough that it's managed separately, so that's an 18 person team plus...

Once you get up to 30-40 people, management becomes really important. And when you're 100-plus, if you don't have good management, your company is quickly destroyed just because there are so many different layers of communication. With 20 people, everybody knows everybody else and then talks to the people they need to for whatever they're working on.

With 100 people, now you have the engine team working with the game team, complicated sub-teams, all that; you have upward communication; and then you have external companies you need to keep informed. It's just impossible to schedule unless you have a serious structure in place with producers on projects taking responsibility for project management, leads in each area, and so on.

In the late 1990s, Epic's headquarters moved a few times. What's the story behind that?

TS: In 1997, we had started Unreal. We were well into the project, and we weren't making the progress we needed because everybody was all over the place -- it was a very complicated project.

So we got everybody together in Waterloo, Canada for a year to finish the game, since some of the guys already lived up there. It was really nice for about six months, and then it froze over and didn't thaw again for another six months, so we got really annoyed at the cold there.

After that we decided to set up a permanent office and bring everybody together so we could be a more efficient developer. We looked all over the country, decided on Raleigh, and moved here in 1998.

It was funny to relocate here because absolutely nobody working with Epic at the time had been born here. It was just a random place that we chose after looking at the cost of living here, on the west coast, and all over the country.

Do you like it now that you've been here for a while?

TS: Yeah. I'm really happy with the area. It's a good cost of living. We can hire people from all over the world, they can come here, and with a good game developer's salary, you can buy a nice house. Whereas in California, you'd be stuck with a one bedroom apartment.

Raleigh is a really nice place. There's a lot of hiking, good weather, there's the mountains, there's the beach. Lots of good things.

Inside the Shareware Business

Let's go back to the shareware days. When did you first learn about the shareware model? How did you learn about it -- was it from Apogee?

TS: Shareware had been around from the beginning. As soon as I got on BBSes, there were obvious shareware programs, but it seemed like a stupid business model, because you give out a program with all of its features and then ask people to pay you for it? It seems backwards, right?

It was Apogee that made it look like a really attractive, viable business. They released one episode of a game -- you could play through it in a few hours, and then if you wanted more, you'd buy it.

And if the games were high enough quality, that was really powerful. Their games were good enough that I actually bought them, and I hadn't done that with any previous shareware. So it was really the model that Scott Miller defined that made the whole market appear interesting.

Before that, the whole business was so daunting, and that's why I never released anything prior to ZZT. See, you put a huge amount of effort into developing a program. If you have to release it, then that's basically doubling the effort, because of all the polish and documentation that's needed. And unless you're going to make serious money from that, then it's not worth it.

Shareware for most companies wasn't possible at all at that point, and getting into retail was so daunting: then you have to negotiate a publishing deal with a huge company and it's hard to even find the contacts. It just seemed so daunting that I didn't even bother with it.

So you went the shareware route because it was easy to distribute your own games through BBSes.

TS: Yeah, and it was a business model that obviously worked, provided you came up with episodes.

How was your relationship with Apogee back then? Did you ever talk to Scott Miller? Was it a fierce competition between the two of you?

TS: It was always professional. I started out talking with Scott Miller before I even released ZZT, just trying to gather some intel on the whole business. And then after releasing it, Scott Miller was trying to recruit me to publish Jill of the Jungle through Apogee, but I decided to go it on my own.

We'd compete for shareware developers. Somebody would create a game of their own and they'd submit it to Apogee and Epic and we'd both consider them, and we sometimes ended up competing for deals. It was always professional. There wasn't any animosity.

Epic MegaGames' Jill of the Jungle

Did you ever talk to him after you got started with the business? Did you ever have to call him and say, "Hey, there's something we need to talk about."

TS: We talked. There were two ways: there were the CompuServe forums -- basically that was where all of the people in the shareware industry chatted with each other. Scott Miller was very active there, so I'd come into contact with him a huge amount through that. We'd send emails back and forth through it and engage in common discussions with other people.

And then there was this annual shareware event, the Association of Shareware Professionals -- this weird industry group -- that would have an event every year. So I got to meet everybody. I met Scott and George [Broussard] pretty early on -- I guess that was '91 or '92 -- and much of their authors, and we brought a bunch of our people out to that event, so we had a pretty in-depth relationship with them at that point.

If somebody came to you with a great game you were going to publish or distribute, what would you pay them? A lump sum or part of what they sold?

TS: It was all royalty-based. We'd negotiate deals where the developer would come to Epic with their game, and we'd offer to take care of all the marketing, distribution, sales, and all that stuff, and in exchange, pay them royalties.

It was 40% or 50% of each sale. So when a $30 game sold, the shareware developer got $15, then $5-6 went to postage and their labor costs on top of that. So it was profitable enough that we were able to grow.

That's a pretty good deal for the developers -- a large percentage.

TS: The royalties we paid out were better than all but the top several game developers can get from publishers nowadays, for example. And our business was a lot more cost-intensive back then because it was small scale. The overhead was more significant.

How did it work when you and Apogee were competing over a developer? Did you bid on them?

TS: We never really got into a bidding war about anybody. Scott Miller tended to get the people he wanted, so most of the people that came to Epic were the result of direct recruiting efforts by me or Mark [Rein].

We'd go onto the CompuServe forums and Usenet and send messages trying to get people to submit their games for publication. Then when somebody released something just as freeware or for fun, we'd try to contact them, follow them up, and bring them on board.

Around that point -- I guess it was around 1992 when Cliff had released this little adventure game on his own as shareware. He hadn't done much from it, so he submitted his next game, Dare to Dream, to Epic. Mark was visiting me for the first time in Maryland.

The day I met Mark Rein, we got this letter from Cliff at my house, and Mark called him up and went... doing the standard Mark Rein thing: "You should publish this through Epic -- you'll be a millionaire!" [laughs] You know, kind of over-selling the whole thing, and Cliff got really interested about that, so we published that game for Cliff.

It wasn't a big success, but then we hooked Cliff up with this awesome Dutch programmer, Arjan Brussee, who wrote the engine that powered Jazz Jackrabbit. And that was Epic's biggest selling game at the time: Jazz Jackrabbit.

Did they work together over the phone, over computer networks? If the guy was Dutch, was he in the Netherlands...

TS: Yeah, it was phone calls and modems. Cliff was in California at the time. That was crazy: everybody had these massive phone bills. They'd send the phone bills to me and say, "Give me some money for this."

Actually, my personal number was an 800-number, so the authors could call me without incurring phone charges. 'Cause, you know, a lot of them were just -- Cliffy was just in high school at the time, I think; he was about 15 when he created his first game and released it. And that was pretty typical at the time. Nobody had a real career or anything.

Jazz Jackrabbit was your highest selling shareware game at the time? What was your highest selling shareware game overall?

TS: Of all time? That was Epic Pinball. That was a crazy project. These developers in Finland, Future Crew -- we'd been trying to recruit them for a long time as shareware developers. They did a bunch of early 3D demos -- it was incredibly brilliant, impressive stuff. I thought they were the smartest guys in the world at that time.

So Mark Rein went out to Finland to try to recruit them, but they weren't interested. I guess they had other projects going on at the time. But what he did bring back was this pinball game that they'd been developing.

It wasn't finished, but it was a vertically-scrolling pinball game with realistic physics. We were begging and pleading with them to finish the game so we could release it and put it out as shareware, but they just didn't have the resources to take that on.

So we showed the game to James Schmalz, who'd done Solar Winds. He was this guy up in Canada -- that's why we moved to Canada for a year with Unreal. This brilliant guy -- he programmed 100% assembly language and does all art for his projects, so... brilliant artist, programmer, jack-of-all-trades, which is really uncommon in the industry at that level of competitiveness.

James saw the pinball demo and said, "Oh, yeah, I can build a game like that." So from scratch, he built a vertically-scrolling pinball game, designed six pinball tables for it and all that -- he did that while he was in college. I think he spent nine months on it in total.

Mark Rein and I were basically being cheerleaders, telling him what needed work, what need improvement, and giving him references to other pinball games, pinball rules, and things like that. So he finished the game, and over the next year, he made more than a million dollars from the shareware royalties.

Epic MegaGames' Jazz Jackrabbit

That's great. Does James Schmalz work at Epic now? What's he doing?

TS: No. After Epic Pinball, James Schmalz was the first developer on Unreal, and ended up being the co-developer on the project. Halfway through, he started Digital Extremes. The first two Unreal games were collaborations between Epic and DE, so he had about five employees at max, and we had 10 or 15.

We just worked together as an integrated team, building the game. After we released Unreal Tournament, they went off and developed games on their own while we went off with our own projects.

Did you ever have any contact with the id Software guys back then? John Carmack, John Romero -- they were developing Commander Keen, and...

TS: Not during the development of Commander Keen, but after they came out with Wolfenstein 3D, we met them all on this shareware event. It was in Indiana of all places. So it was Mark, me, and a few others -- and who from id was there? Romero was there, Jay Wilbur was there. They were the superstars of the show, and Epic was an up-and-coming game developer.

John Romero was a really outgoing guy. He was always really friendly and kept up with everything that was happening in the industry. He knew who we were, he had played Jill of the Jungle, and he was like, "Oh yeah, cool game, man!" He invited us out to dinner one night, so we had dinner with the id Software guys.

I don't think Carmack was there, but it was a really interesting conversation. Basically Mark and I were in total awe at what the guys had done, and we just talked about what happened in the industry and what we were doing.

They were really aggressive in their business: "Yeah, we're going to get out of this Apogee thing and go off on our own" -- which they did with Doom. Very successfully.

Did you think about doing a first-person shooter after their success with Wolfenstein 3D and Doom?

TS: It was funny how we got to that point. When I saw Wolfenstein for the first time, that was truly shocking. I'd never envisioned that you could do 3D in a computer game; I don't know why.

The research had indicated that you could do that for at least 15 years before that, but it was this 3D game with real-time texture mapping; you know, real-time bitmaps scaled up and displayed in 3D on the screen. It never occurred to me that you could actually write code to do that. It was just another lack of foresight there.

But seeing that for the first time, I was like, "Wow, I'm totally not worthy. I need to get out of programming now, because I'm never going to be able to compete with this." So they just basically demoralized me into becoming a manager for a few years.

Around 1994, James Schmalz had written this 3D texture-mapping code, and I was starting to think, "Hmm, maybe that's not so hard." So I started reading up on references there and experimenting with it, and it turns out that, yeah, it's just another piece of code that you can learn how to create.

Did you ever think about doing a Doom-style first-person shooter with Epic instead of a full-3D game like Unreal?

TS: It took about two years to come around to the realization that we could be a competitive game company in that business. At first, the technical problems seemed so hard that it felt like I was out of my league at that point and that all of the Epic folks were out of our league.

What id had done -- let's put it that Wolfenstein and Doom were so far ahead of everybody else's wildest dreams, that it just seemed crazy to try to compete. But it was around 1994 when I started to see that, yeah, they're actually beatable.

There were a bunch of shortcomings in the game, and there were a lot of things you could do in addition to go way beyond what they were doing -- there were different stories you could do. It was really around 1994 that we felt we could actually try to compete in that area.

Even at that point, it was daunting. We typically developed games with between one and three people -- usually a programmer, an artist, and maybe a musician. But those games took much larger teams -- up to ten or twenty people. It was really scary scaling up to the size of the project on Unreal where we went to about 20 people by the time the project shipped.

We had no experience managing projects like that, and developing that game -- the cost of it just required that Epic and Digital Extremes -- we had to spend all of the profits we'd made on all of our previous games up to that point on that one single game.

We were betting everything on that -- including our credit card balances. Mark Rein got his American Express card taken away from funding Epic at that point. We bet everything on it, and it was a success.

It's great that it worked out that way.

TS: It's fortunate. If the game had been delayed by another six months, Epic probably wouldn't be here now.

I have one last question about the shareware days. When I was downloading Epic's games from BBSes back in the day, Epic's games stood out because they had VGA graphics and Sound Blaster support. That's why they were my favorites. Was that a conscious effort on your part to always have games at a superior level of technical quality from that point on?

TS: Every project after ZZT -- with ZZT, I wasn't even trying to compete. With Jill of the Jungle, I don't know -- I was always looking at what other games had and how we could beat that. Commander Keen was an EGA game with PC speaker sound effects and AdLib music. So we went one step further and had digitized sound effects and VGA graphics.

But with everything since then, we've always put a conscious effort into thinking, "How can we beat everybody technically?" Because if you beat them technically, it gives you an opportunity to shine in all other areas. VGA graphics isn't just a technical feature -- it means you can have much better artwork than everybody else. Even if your artists are only as good as the competition's, they have more colors to work with, so they can do better work.

And that's been a big driving force with Unreal. Even nowadays, to try to stay as far ahead of the competition as possible in technical features.

Present & Future

Does it scare you when you see Crysis... or, I don't know. What's the biggest competitor in the game engine market? Is it id's stuff, or is it another company?

TS: Today, it's Crysis. Because Crysis is doing some things on high-end PCs that we're not doing ourselves. That's a tricky case though, because we could do vastly more than we're currently doing if we focused on supporting dual high-end video cards, which have about 10 times the graphics horsepower of a console today.

The thing is, that market is about 2% the size of the overall next-generation game market -- PS3, Xbox 360, and mainstream PC. So there's a real hard business decision: if you go the route that Crytek goes, you can beat us in certain areas in graphics, but you're really sacrificing the larger market.

Because you can't run that engine on the PS3 and that sort of thing.

TS: Yeah. And some of the things they're doing are just conceptually incompatible with that level of performance. Wherever you have an order of magnitude performance difference, you can't really scale.

We can scale down in performance by a factor of three by going to a low resolution, dropping some textures, and things like that. But to scale by a factor of 10 -- you can't design a game with 10 times the detail and then scale it back to something that looks decent on the consoles. You'd end up looking much worse than a console game that was just designed for the console specs. So they have real scalability difficulties there.

On another note, LittleBigPlanet reminds me of ZZT, because you can build your own levels, and people do emergent techniques with a simple set of tools. Have you played LittleBigPlanet? Do you like it?

TS: Yeah, it's brilliant. If I were creating a game with a really small team so that things like Unreal were ruled out, it's exactly the kind of game I'd want to create -- a side-scroller with really cool graphics using 3D and really cool physics -- and design it around the user community building stuff. It's a really brilliant project.

I think it's indicative of the direction in which that kind of game could go -- a sandbox game like The Sims or anything else. You can really go a long way with the simulation without creating complicated tools. It's not like there's some crazy Python scripting language in there; it's all done with really simple graphical stuff. It's a great idea.

Looking ahead, how long do you think it will be before real-time computer graphics are 100% realistic like a movie?

TS: There are two parts to the graphical problem. Number one, there are all those problems that are just a matter of brute force computing power: so completely realistic lighting with real-time radiosity, perfectly anti-aliased graphics, and movie-quality static scenes and motion.

We're only about a factor of a thousand off from achieving all that in real-time without sacrifices. So we'll certainly see that happen in our lifetimes; it's just a result of Moore's Law. Probably 10-15 years for that stuff, which isn't far at all. Which is scary -- we'll be able to saturate our visual systems with realistic graphics at that point.

But there's another problem in graphics that's not as easily solvable. It's anything that requires simulating human intelligence or behavior: animation, character movement, interaction with characters, and conversations with characters. They're really cheesy in games now.

A state-of-the-art game like the latest Half-Life expansion from Valve, Gears of War, or Bungie's stuff is extraordinarily unrealistic compared to a human actor in a human movie, just because of the really fine nuances of human behavior.

We simulate character facial animation using tens of bones and facial controls, but in the body, you have thousands. It turns out we've evolved to recognize those things with extraordinary detail, so we're far short of being able to simulate that.

And unfortunately, all of that's not just a matter of computational power, because if we had infinitely fast computers now, we still wouldn't be able to solve that, because we just don't have the algorithms; we don't know how the brain works or how to simulate it.

So you'd have to create a perfectly realistic virtual human first to have perfectly realistic graphics.

TS: Yeah, you'd have to simulate the brain and nervous system in the computer.

And circulation and everything. But that's probably going to be possible some day, don't you think?

TS: Some day, yeah. But there's no Moore's Law for that stuff, and progress is very non-linear. Somebody must have a clear understanding of how a neuron works now and how it transmits to adjacent neurons, but they have no idea how a billion neurons combine together to create a brain and what parts of our brain are basically hard-coded by evolution, and which parts are based on learning, and so on.

And if you could simulate it all, how could you train it to be realistic like a human? Those problems are probably decades away from being solved. Those are things that may not occur in our lifetimes.

Just like perfect computer speech recognition: if you look at speech recognition, it's only gotten slightly better in the past decade, just by a factor of several hundred increases in computing power. That shows that those problems are not falling to brute force.

They're not following Moore's Law acceleration. Have you ever read any Ray Kurzweil's futurism stuff?

TS: Some of it. Definitely anything like that is long-term future. It's just because we lack the algorithm and knowledge of how to model that, even given unlimited computing power.

Do you think that if the graphics were perfectly realistic that you would create a "final" version of the Unreal Engine? As in, you'd never have to make another one because you got it perfect?

TS: I don't think we'd ever be done. If you look at special effects or anything like that, even if you have perfect rendering, you might have the inner loop of the renderer which processes sub-pixel triangle primitives and generates perfectly anti-aliased graphics -- that might be completely done, but still, the tools and the functionality that lets the artist create the environment is infinitely improvable.

Currently, our approaches are somewhat primitive if you look at it. If you want to build a city for a massively multiplayer game, the artists model a single column or wall, then they copy and paste it throughout the world. You'd run really large-scale procedural tools for defining road systems and defining buildings, and the structure and architecture of buildings.

You could really do a lot more to improve productivity than any current engine or modeling tool is doing. So I see decades and decades of work there, just to make ever-better tools. And special effects as well. Particle systems are only partly limited by computing power.

The other limitation is the tools that the artists have to control what's really going to happen, and to do that productively. If you can make tools more productive so an artist can do more in an hour, then that's an improvement too.