Epic's core philosophy — building both awesome entertainment and awesome tools, and sharing those tools with everybody — is the sole reason the company survived and succeeded through every financial downturn.

(00:00:00) The following is a conversation with Tim Sweeney, a legendary video game programmer, founder, and CEO of Epic Games, that created many incredible games and technologies, including the Unreal Engine and Fortnite, which both revolutionized the video game industry and the experience of playing and creating video games. (00:00:23) And now a quick few second mention of each sponsor. (00:00:26) Check them out in the description. (00:00:27) It's the best way to support this podcast. (00:00:30) We got Notion for AI-fueled note-taking, Masterclass for learning, Shopify for selling stuff, AG1 for nutrition, and Element for electrolytes. (00:00:40) Choose wisely, my friends. (00:00:42) I'm doing these ad reads all in one place, so hopefully that makes it easy for you to skip them if you don't want to listen to them, but I do try to make them interesting and personal, often related to stuff I'm reading or thinking about. (00:00:55) But if you do skip them, please still check out the sponsors. (00:00:57) Sign up, get their stuff. (00:00:59) I enjoy it. (00:00:59) Maybe you will too. (00:01:00) Also, if you want to get in touch with me for whatever reason, go to lexfreeman.com slash contact. (00:01:05) There you can fill out a survey, which gives me feedback, or you can submit questions for an AMA, or if you want to work with us, (00:01:12) so you can apply. (00:01:14) Or if you just want to grab a coffee somewhere in the middle of nowhere as I travel the world. (00:01:19) All right, now on to the full ad reads. (00:01:22) Let's go. (00:01:23) This episode is brought to you by Notion, a note-taking and team collaboration tool. (00:01:29) Obviously, we talk a lot with Tennis Sweeney in this episode about the incorporation of sort of AI-like semi-autonomous (00:01:37) human in the loop type technology in the creative process, in computer graphics process, in lighting the scene, in lighting the human face, and bringing object in these worlds to life. (00:01:50) I think it's true that a lot of that is ultimately about creating beautiful worlds. (00:01:55) But I think the deeper thing in video games, in movies, is storytelling. (00:02:00) I really think it boils down back to text. (00:02:04) I generate, (00:02:05) I don't know how many pages, probably 10 plus pages of notes a day. (00:02:08) A lot. (00:02:10) I'm a very bullet point, nested bullet points guy. (00:02:15) And a lot of that I use Notion for, and they incorporate AI really, really well into the note-taking process, into the team collaboration process, project management process. (00:02:26) Really nice. (00:02:28) Try Notion AI for free when you go to notion.com/lex, that's all lowercase notion.com/lex to try the power of Notion AI today. (00:02:36) This episode is also brought to you by a masterclass where you can watch over 200 classes from the best people in the world in their respective disciplines. (00:02:44) I watch countless of their courses in full, and sometimes I do partial courses just if a topic really grabs me. (00:02:53) And it's not always about the information conveyed. (00:02:57) It's the implicit, the unstated, just the aura of mastery, because these are not just teachers or instructors. (00:03:07) These are masters of their craft. (00:03:10) Many of the folks that have masterclass, I've interviewed, and it is a very fundamentally different thing. (00:03:18) I think both are very useful. (00:03:21) I think of a masterclass as a kind of concise, crisp preview (00:03:27) of this human being's mind. (00:03:29) And a 3, 4, 5 hour podcast, it's a kind of random walk through the edges, the details, the depths. (00:03:41) Anyway, above all else, it's just inspiring to see these masters speak and get excited about the thing they've mastered. (00:03:49) Get unlimited access to every masterclass and get additional 15% off an annual membership at masterclass.com/lexpod. (00:03:56) That's masterclass.com/lexpod. (00:04:00) This episode is also brought to you by Shopify, a platform designed for anyone to sell anywhere with a great online store. (00:04:07) I've used it to put up some shirts on, I think, lexfreeman.com/store. (00:04:11) So Metcalfe's Law that I think comes up in this conversation. (00:04:16) states that the value of a network scales with the square of its connected users, n squared. (00:04:22) Now, in some sense, it's a pretty simplistic graph theoretic concept, but it also happens to be a thing that explains a lot of the internet, that there is quite a lot of incredible value from scale. (00:04:37) This applies for e-commerce, like with Shopify, it applies to social media. (00:04:41) It applies to gaming ecosystems, like Tim talked about. (00:04:47) It's really interesting, the power of groups. (00:04:50) As you go from two people to three people to four people to five people, with digital technology that removes the friction of physical communication, weird stuff emerges. (00:05:02) Revolutions, memes, ideas, (00:05:07) can spread virally, take over the whole world, and then disappear the next day. (00:05:12) It's so fascinating. (00:05:13) There's dangers to that. (00:05:15) But there's also a possibility of figuring some shit out at a human civilization level in that. (00:05:22) Anyway, sign up for a $1 per month trial period at shopify.com/lex. (00:05:26) That's all lowercase. (00:05:27) Go to shopify.com/lex. (00:05:28) Take your business to the next level today. (00:05:32) This episode is brought to you by AG1, an all-in-one daily drink to support better health and peak performance. (00:05:39) This makes you think about the sheer complexity of the gut microbiome. (00:05:43) Trillions of bacteria, fungi, and viruses influencing every aspect of the digestion, the immune system, the neurotransmitter production, the gut-brain connection, all of that. (00:06:00) It's a well-oiled machine, but unlike a machine, everything is squishy. (00:06:06) Everything is a robust, resilient mess, not designed to be perfect and clean, designed to be distributed, imperfect, but resilient and adaptable to whatever the hell you do to it. (00:06:24) It's quite incredible. (00:06:27) Anyway, AG1 will give you a one month supply of fish oil when you sign up at drinkag1.com/lex. (00:06:33) This episode is brought to you by Element, my daily zero sugar and delicious electrolyte mix. (00:06:38) One of my favorite courses that I took, or a set of courses, I took neuroscience in college, and I also, I believe, took anatomy and physiology in high school, and also biology. (00:06:51) Anytime any of those courses touch upon the nervous system. (00:06:56) The neurobiology of the nervous system, the chemistry of the nervous system is so fascinating. (00:07:02) The way charge travels across a neuron, across the nervous cell membrane, driven entirely by sodium and potassium ion flow through voltage-gated channels. (00:07:15) Those gates, both the pictures in biology and neuroscience books (00:07:23) and the very concept itself that evolution developed it is just fascinating because that very mechanism at the chemical level, at the biological level, is the basis of thought. (00:07:35) Think about that. (00:07:37) Think about it. (00:07:38) As you think about that, think about all the electrical signal traveling inside your brain, fueled by element. (00:07:46) How this relates to element? (00:07:47) I don't know. (00:07:47) Oh yeah, sodium and potassium. (00:07:49) That's right. (00:07:50) That's right, folks. (00:07:51) Element is the foundation of thought. (00:07:54) Get a sample pack for free with any purchase. (00:07:56) Try it at drinkelement.com/lex. (00:08:00) This is the Lex Friedman podcast. (00:08:02) To support it, please check out our sponsors in the description. (00:08:06) And now, dear friends, here's Tim Sweeney. (00:08:26) When did you first fall in love with computers and maybe with programming? (00:08:30) I had a brother, Steve Sweeney, who is 16 years older than me. (00:08:35) At some point when I was a little kid, he went off to work in California for a tech company, and he'd gotten one of the first IBM PCs. (00:08:42) And so for one summer, I think I was about 11, I went to visit him in California. (00:08:46) It was my first trip away from my family just to hang out with him. (00:08:49) And he had this brand new IBM computer, and I learned to program over the course of a few days in BASIC. (00:08:55) I was just blown away with the capabilities of computers at the time. (00:08:58) It was unbelievable what they could accomplish, and I was hooked from that point onward and very much wanted to be a programmer. (00:09:06) Do you remember what you wrote in BASIC? (00:09:08) Is it video game type things? (00:09:10) Is it like for loop, some numerical thing? (00:09:13) Do you remember? (00:09:14) Yeah, it's funny. (00:09:15) I have a perfectly vivid memory of all of the first things I learned to program. (00:09:20) Okay. (00:09:20) I have a hard time remembering people's names, but code really sticks with me. (00:09:25) Every step and every challenge, there were lessons learned. (00:09:28) Some of which I've come to realize were just like me. (00:09:31) getting over some learning hurdles, but other things were actually shortcomings of programming languages and the realization that there are actually better ways. (00:09:39) And when a programmer is learning to program for the first time, a lot of what they're facing isn't the challenge of learning a new art. (00:09:46) It's the friction introduced by failures of programming language design. (00:09:50) And so I've constantly come back to those early lessons there as I've progressed and done more and more things, including building programming languages. (00:09:58) Yeah, the friction and the pain. (00:10:01) is the guide to learning in programming. (00:10:05) Like if I were to describe programming journey, that would be marked by pain. (00:10:11) And that pain, you shouldn't escape the pain. (00:10:13) The pain is instructive for you to understand programming languages. (00:10:16) But do you remember what kind of stuff you were writing at that time? (00:10:21) Just the early programs? (00:10:22) Yeah, in the early days, I wrote a little bit of everything. (00:10:25) I wrote some games. (00:10:26) The first game I wrote on the Apple II was (00:10:29) Since I only knew how to program in text mode, the computer would throw asterisks across the screen, they'd flow from left to right, and you'd have a parenthesis on the right-hand side of the screen, and it looks like a baseball mitt, and you're supposed to catch the asterisks. (00:10:42) That was my very first game. (00:10:43) It took about a couple hours to build and tune, and I went from there, but I built a lot of things. (00:10:49) I built... (00:10:50) databases at different points. (00:10:51) I built a programming language and a full compiler for a language like Pascal, because I didn't know where you went to buy one of those. (00:10:58) So I made my own. (00:11:00) And one of the fun things of that time was bulletin boards. (00:11:04) Before we had the internet in the hands of consumers, you used your modem and you dialed into a local phone number and connected to whoever was running the computer there. (00:11:14) And every town or city had hundreds of these bulletin boards run by different people with their own personalities and themes. (00:11:20) And so I spent a lot of time building a bulletin board program and learning how to deal with database management and user interface and dealing with multiple users concurrently and things. (00:11:28) And so I don't know, I probably found about 10 or 15,000 hours writing code just on my own as a kid between age 10 and age 20 before I actually shipped a program to the outside world. (00:11:43) 10 to 15,000 hours. (00:11:46) What was the value of the hours as a kid you put in in programming that led to the success you've had in later life? (00:11:53) Maybe this is by way of advice to younger people in terms of how they allocate the hours of their early life. (00:12:00) Yeah, you know, it's not just hours, it's really striving to learn, to understand what knowledge you have, what knowledge you lack, and to continually do experiments and work on projects that improve your knowledge base. (00:12:14) And I didn't do this with a great amount of structure or planning. (00:12:17) I was rather just going from project to project, doing things that I thought would be fun and cool. (00:12:21) And with each project, I learned new things. (00:12:24) Learning about how to store and manage data, learning how to deal with advanced data structures, how to write complex programs that have deeply nested data and control flow. (00:12:35) Each one of those provided a lesson which (00:12:39) were later essential. (00:12:39) In 1991, I released my first game, and over the course of that decade, we went from zero commercial releases to the first generation Unreal Engine. (00:12:51) But this was largely just using the knowledge that I'd built up over the previous decade, just doing fun hobby projects. (00:12:58) And if I hadn't done all that work, there's no way I could have ever built the things that came later. (00:13:02) All the experimentation and all the exploration somehow (00:13:08) contributed somehow made sense later on. (00:13:10) Like all of that is integrated somehow in the stuff you build. (00:13:13) It's funny how life works. (00:13:14) Like the pieces kind of come together eventually. (00:13:19) Yeah, you know, there are definitely karate good moments because all this time I was learning math in high school and in college. (00:13:27) I studied mechanical engineering. (00:13:28) And so you learn all kinds of math, vector calculus and vector math and matrices and (00:13:37) all these related fields, physics and stress and strain and how to deal with complex physical systems. (00:13:44) And yeah, I wasn't really sure how engineers would actually make use of that knowledge. (00:13:49) Do you just like forget about it when you actually go off to do work or is it, do you write down equations on paper? (00:13:54) It was actually not clear as an early engineering student what you do. (00:13:59) But when I started writing the first generation Unreal Engine and I was dealing with 3D math, I was like, wait, I know this stuff. (00:14:03) I learned this. (00:14:05) And so suddenly like the karate kid, you get to paint the fence and wax the car and suddenly put all the pieces together into a 3D engine based on a whole lot of accumulated programming language and math knowledge. (00:14:18) Often knowledge gained without ever anticipating that I might use it in that way. (00:14:24) Also, I think what's useful is over and over learning a hard thing and then showing to yourself, (00:14:34) that you can do it, that you can learn a hard thing. (00:14:37) So then when you come to having to write a 3D engine that in ways that haven't been done before, you're like, I've been here. (00:14:47) I've been here in this experience. (00:14:49) I don't know what to do, but we'll figure it out. (00:14:51) We'll learn. (00:14:52) I'll learn all the necessary components. (00:14:53) So just not being afraid of something new. (00:14:57) That's right, and constantly striving to make connections between these fields and look for their applications. (00:15:03) Long after I chipped on Unreal Engine, it was like going back through an engineering textbook and looking at, yeah, I used that, I used that, I used that. (00:15:09) And then I got to the section on eigenvalues. (00:15:11) I'm like, don't know what the hell this is. (00:15:14) But it turns out eigenvectors and eigenvalues were the critical breakthrough that made the Google search engine technology work and stand apart from the rest, because they found if you threw all of the... (00:15:24) links that exist in the web and links from and two different sites and you put them in a giant matrix and you conclude it, you found the dominant eigenvalues, then those eigenvectors described the best search results for different things. (00:15:37) And so constantly picking up knowledge and looking for ways to put it together is the thing to do. (00:15:43) And if you aspire to be a programmer, you've got to write a lot of code and you've got to continually learn new things and improve. (00:15:50) If you want to be an artist, you've got to continually (00:15:52) draw artwork of all styles and all kinds and constantly push yourself to learn more and more. (00:15:58) Because you never know exactly what you're going to end up doing in the long run. (00:16:01) But the more knowledge you have and the more skills, the more chance you have putting it together and being successful. (00:16:07) And whether you're a programmer or an artist, you should probably take linear algebra, even though it doesn't make sense at the time. (00:16:12) I found getting an engineering degree and then never working in an engineering field, just being a computer programmer, was immensely valuable. (00:16:22) I went to the University of Maryland, which, for some disciplines, it's kind of known as a party school, but they worked the engineers to death, worked really hard, and if you learn any engineering discipline, you learn massive amounts of math and you learn the rigor of problem solving, not just... (00:16:37) what you find from the Wikipedia article, but going through all of the exercises of solving complex problems and building up series of solutions to derive an answer, it's valuable and it embodies the knowledge that you need as a programmer. (00:16:51) And people often go to the university and think, okay, my goal here is to get good grades so I get a diploma and I prove to an employer that I'm valuable. (00:16:58) No, that's just kind of the superficial bookkeeping of the university. (00:17:02) The real purpose of all of this is to learn. (00:17:05) And whether you learn formally or you learn on your own, it's the learnings that are really valuable in a career. (00:17:11) And especially if you're going to be an entrepreneurial, it's really knowing the stuff that matters and not having the diplomas. (00:17:17) And yeah, there's ever more pressure to make a rebuild society more and more around credentials. (00:17:23) Do you have the certificate? (00:17:24) Do you have that proof? (00:17:26) But companies that are focused on just building great products and doing great things gravitate towards people who do the great work. (00:17:35) Yeah, one of the great things about youth is there's more freedom, there's just more time to learn. (00:17:44) And people, when they go to high school, they sometimes think, Well, I can't wait to get out of this and be an adult and be free. (00:17:50) But it's not quite freedom. (00:17:52) When you get a job, (00:17:54) You start a family, all wonderful things. (00:17:56) We get more and more busy in less and less time to learn in the general sense. (00:18:02) Learn whatever the hell you want. (00:18:04) And that is a wonderful time in life, the teenage years, the early 20s, the 20s, when you could just learn random shit. (00:18:13) Yeah, you know, I think this is something that's kind of changing in America. (00:18:17) So much focus on grades and homework and structure around kids' lives. (00:18:21) When I was growing up, my mom would feed me and my neighbors, my neighbors and moms would feed them breakfast and... (00:18:28) They'd be like, Well, be back by dark. (00:18:32) And we'd go out and we'd play, and we'd do all sorts of things. (00:18:35) We'd explore the woods, we'd build go-karts, we'd salvage old pieces of electronics and build what we thought were our spacecraft control panels for the fake spaceships we were building as play. (00:18:48) And we'd have an enormous amount of freedom. (00:18:51) And from basically being a little kid through the time I went off to college, (00:18:58) It had an enormous amount of free time. (00:19:01) Some people just used that and wasted it and watched TV. (00:19:03) Some people socialized. (00:19:05) And some people really got into serious projects. (00:19:08) So many people at all times were doing cool things. (00:19:11) I was programming. (00:19:12) I was learning to build things. (00:19:14) Before I was releasing games to the world, I'd be having neighborhood folks over to play the things I was working on and check them out. (00:19:21) And sometimes they're impressed and sometimes they weren't. (00:19:24) And they'd have their own projects and often we'd have spare time jobs and everybody was entrepreneurial. (00:19:29) Like everybody, had a side gig. (00:19:31) Sometimes you'd go around and mow people's lawns or you'd, rake the leaves up and, earn money. (00:19:37) And the freedom there and the organic learning that occurred there, I think it's something that is really critical to the American experience. (00:19:46) I worry is increasingly going away as society is ever more protective and sheltering and makes it harder to get these experiences. (00:19:54) So on the video game side, when did you first fall in love with video games? (00:20:01) I've had a funny relationship with games because my real aspiration has always been to program cool stuff. (00:20:09) I get more enjoyment of programming than anything else in the world. (00:20:13) And so, you know, my first really too formative experience with games were playing (00:20:20) This game called Adventure for the Atari 2600 was like, you moved this dot around the screen and picked up objects like swords and fought dragons and invaded castles and solved puzzles. (00:20:31) Very, very simple, iconic stuff, rather than realistic graphics. (00:20:35) And then the other game that really got immersed in was Zork, which was a text adventure game. (00:20:40) It would tell you where you are and what you see, and you'd type in commands like go north or pick up sword or open door and explore a world that way. (00:20:48) So the game didn't have any graphics, but in your mind, you had this elaborate picture of what you were seeing there. (00:20:53) And it really brought in inspired imagination more than other things. (00:20:58) And playing those games led me to go off and want to learn to program everything that I saw there. (00:21:03) And that drove a lot of my programming. (00:21:04) I learned how to move a player around the screen. (00:21:07) I learned how to (00:21:09) build a design tool so I could build castles and save them off and play them in a game. (00:21:13) And I realized there was a separation between the tools that you use to build a game and the game itself, and that the more powerful tools you had, the more creativity you could unleash in yourself or others. (00:21:23) And I learned all the programming techniques that supported games, how to parse text, pick up sword and go north. (00:21:30) How do you make that sentence into an actual series of commands on the computer? (00:21:36) And that was really, really exciting. (00:21:39) I have to say, until the time that Fortnite came out, I played video games primarily to learn what they were doing so that I could go off and do it myself. (00:21:46) I'd sit down, when Wolfenstein came out and then Doom came out, I'd go through and look at it pixel by pixel. (00:21:53) I'd move the mouse very slightly and look at exactly what was happening to figure out. (00:21:57) That's great. (00:21:58) What technique was being used there? (00:21:59) That was puzzle solving at a grand scale and it was so fun. (00:22:04) So take me there in the early 90s. (00:22:06) So you launched Epic Games in 1991. (00:22:11) So you're the writing of your first big video game, ZZT. (00:22:16) What was it like? (00:22:17) What was the technical challenges? (00:22:19) What were the psychological challenges of building that? (00:22:23) It was a funny project because I didn't start out to build a video game. (00:22:27) I'd just moved from an Apple II. (00:22:30) So my brother bought my family an Apple II right after I'd visited them in California. (00:22:33) So I'd been programming on that for a few years, learned a lot of techniques, but there weren't many Apple II users around still by the time that cycle came to an end. (00:22:43) And so I'd just gotten an IBM PC of my own. (00:22:47) I was learning to program and I realized I needed a text editor. (00:22:49) So I started writing a text editor. (00:22:52) a text editor is a program to edit text files. (00:22:55) You have logic to move the cursor around and let people type things and backspace and delete and do all of those mundane actions. (00:23:01) And one night I was like, I'd finished it up and I was like, well, okay, I have a text editor, but this is pretty boring. (00:23:06) And so I made the cursor into a smiley face character and I had the different characters you could place in this document perform different gameplay actions. (00:23:15) Some would be walls and some would kill you and some would be moving objects that could fly around the screen. (00:23:21) And so this text editor I made evolved into a little game editor, so I was building these levels for a game. (00:23:26) I put a lot of time into building an editor in a primitive set of objects, about 20 or 30 different objects, enough to build a really cool and compelling game, but not so many that players would lose track of what they're seeing. (00:23:38) I started off just building different game levels. (00:23:41) The idea is you'd be on a series of board. (00:23:43) They'd be connected by going north past the end of the current board would take you to a new one if it was open, or maybe it was blocked and you couldn't go there. (00:23:51) I built the sole game world around that. (00:23:53) And this was the game that became ZCT. (00:23:56) And I was having fun with it, building it and playing it, but I didn't know if it would really work. (00:24:00) So I did this experiment. (00:24:02) I started inviting neighbors over, like some adults, some kids, all different ages, and sat them down from it and said, like, here's a game I made. (00:24:09) Figure it out. (00:24:10) And I had to force myself not to tell them what they need to do, right? (00:24:14) Because I really wanted to learn if they were able to. (00:24:18) discover it all for themselves. (00:24:20) Today we would call this a user experience test, and there's a whole field of research around user experience research, but back then it was just inviting some kids over to play the game. (00:24:29) I took notes about what they got stuck on and what they enjoyed and where they felt bored, and just iteratively polished the game until I felt it was good. (00:24:37) And I put it out and released it on, well, this was before the internet, so there were bulletin boards. (00:24:42) I uploaded it to a bunch of local bulletin boards. (00:24:45) From there, it started spreading because the way to build up cred for bulletin board users was to upload new files and to claim that, hey, I was the first that brought this to you. (00:24:54) And so there was a natural tendency of the software to spread. (00:24:57) I decided to use the sharer model. (00:24:59) So I didn't just build this one game. (00:25:01) I built a trilogy of three games. (00:25:04) And I released the first one for free. (00:25:06) And I said, hey, if you'd like this, buy the two sequels. (00:25:09) And I included my parents' mailing address and (00:25:13) said, send us $30 and you can get the sequels to this game. (00:25:17) And the check started coming in within a few days. (00:25:20) And I was making like, getting three or four orders a day, I was making like $100 a day. (00:25:24) I'm like, woo, I'm rich. (00:25:26) Because being a 20-year-old, that was a pretty big deal. (00:25:30) What did that feel like, just getting money and probably feeling this immense success from something you've created? (00:25:39) I looked at money always just as a tool to help you fund accomplishing cool things. (00:25:45) And, having enough to do the things you want to do is the critical thing. (00:25:50) It's always been just very utilitarian. (00:25:52) But the knowledge that other people all around the country and then, a month later, all around the world were playing the game, that was mind-boggling. (00:26:00) You know, that me, like this little kid who'd put out a game on a local bulletin board, could be doing international business and chipping disks all over the world. (00:26:09) to players, because the software was spreading on its own. (00:26:11) It was just magical. (00:26:13) And that was a new thing for software. (00:26:15) That did not happen with mechanical devices. (00:26:18) You manufactured one, you sold it to somebody, and they had it, and that was it. (00:26:21) But software could spread. (00:26:22) That was just really cool to see, and it made me realize there's really no upward limit on the potential for a business like that. (00:26:29) We saw Microsoft as a big juggernaut company at the time, but I was like, hey, you know, (00:26:34) If those games good enough, we could accomplish what they have accomplished with operating systems. (00:26:38) And the sky was the limit. (00:26:40) And I think this is the age we live in now. (00:26:43) You don't have to be an industrialist manufacturing physical products. (00:26:47) Anybody who builds anything digitally, if it's good enough, you can reach the entire world and build the next Microsoft or Meta or Apple or Google or Epic Games. (00:26:59) It's such a cool origin story though. (00:27:00) You start out building a text editor. (00:27:03) So you're looking at this project, you're playing around with it, you're building up the tools. (00:27:08) It's such an inspiring moment because a lot of us start out building a project and allow yourself to see the potential. (00:27:21) pivots, the potential trajectories that can go is really nice to sit back, allow yourself to be bored and like, I'm going to go this way. (00:27:29) I mean, that's like a crossroads. (00:27:31) You came to a crossroads. (00:27:33) I mean, you built, you know, compilers, you design your own programming language, you build compilers, databases, all these things you mentioned. (00:27:42) And you started building a text editor. (00:27:45) And then here it came to this crossroad, I'm going to make this fun. (00:27:50) And then from there, one of the most legendary gaming companies was created. (00:27:54) It's kind of cool. (00:27:55) Like that, that's an inspiring thing for sort of developers, like be open to the possibility of creating something you didn't plan to create and just go with it, right? (00:28:06) That's cool. (00:28:07) Yeah, and it was a bunch of learnings emerged really quickly there. (00:28:11) The neat thing I did with ZZT was I didn't just release the game, I also released the editor with it. (00:28:16) I built this tool so I could make these ZZT boards that people could play, but I also gave it to all of the players themselves. (00:28:22) And like 30 years later, I still run into people. (00:28:25) When I go to a game industry event, it was like, I grew up playing ZZT. (00:28:30) And here's an adult who grew up playing my game. (00:28:34) And it was because it enabled anybody to become a creator, too. (00:28:36) It had this little board editor, and it also had a little scripting language, so you could learn a little bit of programming in it, too. (00:28:41) And it kind of impressed, and it really set a formative principle of Epic, which was that the company's mission is to make awesome entertainment, but also awesome tools, and to share those tools with everybody so that they can build their own amazing things, too. (00:28:57) And when we got into Unreal Engine a few years later, (00:29:02) The interplay between us building a game and us building tools that were widely used by others was a critical part of that. (00:29:08) And I think that's the sole reason that Epic has been massively successful. (00:29:12) And actually, the reason that we've survived all of this time is that by serving both creators and gamers, we've been able to weather the ups and downs of the game industry. (00:29:21) It's a brutal place for companies. (00:29:25) We've been able to survive every financial downturn, and sometimes the engine's been funding the business because we didn't have a game, and sometimes the games have been funding the business. (00:29:32) And it really set a principle in our culture that's persevered and is continually brought to their forefront. (00:29:40) But on the editor front, that's such a fascinating philosophy, that you always allow people to create their own worlds. (00:29:48) You have an engine from which you simulate the world, (00:29:53) that the game is in, you have the actual game, and you also have the freedom for creators to create various Fortnite islands of their own. (00:30:05) So it's like with everything you ship, that freedom to create is always there. (00:30:09) That's really interesting. (00:30:11) Yeah, and it's something we aim to do more and more fully over time. (00:30:15) In the course of building Fortnite, we've built a lot of other tools that are useful for us too, because it's not just a game powered by Unreal Engine, but it's also (00:30:23) a social ecosystem where people can make friends and voice chat and get together in parties. (00:30:28) We've opened up all those social features into Epic Online Services and we give them away to all developers for free because we all benefit from growth and that user base. (00:30:37) And you know, our goal is ultimately to build the company's products and the same technology that we share with everybody else and to help that foster a bigger and bigger ecosystem over time where everybody benefits. (00:30:50) If we could just linger on the 90s. (00:30:53) So you said bulletin boards. (00:30:55) Maybe you can explain what that's like and also explain the birth of the internet, what that was like. (00:31:00) What was the internet like in the 90s? (00:31:04) So the internet is a funny thing. (00:31:05) It started out as this defense department research project called the ARPANET, the Advanced Research Project Agency Network. (00:31:12) And it was kind of like this revered secret thing. (00:31:17) They became more and more open as they connected universities. (00:31:20) Universities connected to the internet in the mid-1980s. (00:31:24) And so if you were at a prestigious institution with access to computers, you could get on there. (00:31:28) But a consumer back then, we just had these modems. (00:31:31) This thing you plug into your phone line, and it dials up a phone number, and then it sends wild sound effects over the telephone line to send digital signals back and forth. (00:31:42) And these were really slow. (00:31:44) The first modem I had was 300 boards. (00:31:46) That means 30 characters per second of data. (00:31:49) So you're like sitting there watching a sentence like slowly emerge character by character as you're going online. (00:31:55) But yeah, that's how we got online and we talked with each other. (00:31:57) So you dial up to a local bulletin board. (00:31:59) It'll be run by a person. (00:32:00) Usually they have a computer or two sitting in their kitchen or something that's running the bulletin board. (00:32:05) And they have a small community of a few 100 users, all competing to connect to that one phone line. (00:32:11) It was often busy and you couldn't get in, and the more popular wooden boards were hardest to get to. (00:32:16) Nice. (00:32:16) We had all kinds of communities developed, and you could see there was the programming communities where people talked about programming. (00:32:22) There was the news and events community. (00:32:26) I lived in the outskirts of Washington, D.C., so that was a big thing. (00:32:29) But then there was the pirate community where they're sharing pirated Apple II games and very different community ethos and mantras out there, but all (00:32:39) All really nice and also very small. (00:32:41) These things, these bulletin boards couldn't grow to the size of Facebook because your phone line couldn't take that many calls. (00:32:48) And then later in the 1990s, the internet, which had been fostered in these colleges, started opening up for the public and anybody could connect to it. (00:32:57) And suddenly the world took on a life of its own. (00:32:59) It became much, much easier to reach a global audience faster. (00:33:03) And you would start shipping games to the internet, which is, (00:33:07) a bit of a crazy thing to do, because you're supposed to have like a physical copy, but to post on the internet is pretty innovative. (00:33:15) Even shareware is pretty innovative. (00:33:18) Yeah, it's been a funny transition for the game business. (00:33:21) Epic started out making shareware games distributed digitally. (00:33:24) But as the first 3D games took off, like Wolfenstein and Doom from id Software, and then Unreal from us. (00:33:32) took off, to reach a huge audience of millions of users, we had to go into retail stores. (00:33:36) So we worked with a retail publisher and they made a box and they put CD-ROMs in the box. (00:33:40) And then the world started transitioning back to digitally, like, and that transition didn't start well, right? (00:33:47) The initial transition of gaming to digital was all BitTorrent, all piracy. (00:33:52) And the other horror stories about games that would, you know, sell like 100,000 copies but have 2 million users, because most people pirated it. (00:34:02) And then Steam came along and introduced digital distribution and made digital distribution of legit games so convenient that most players moved away from piracy towards that. (00:34:15) And their practices were then followed by others and the early digital industry took form. (00:34:21) Yeah, it's fascinating. (00:34:21) I mean, pirates do lead the way for innovation. (00:34:26) The same as the story of Spotify. (00:34:28) You basically, I think most people, when they derive value from things like video games, want to pay for those video games. (00:34:36) They just want it to be easy. (00:34:38) And so that, the same thing with music with Spotify. (00:34:42) But maybe just staying in the 90s, there are going to be a lot of indie game developers who listen to us talking today. (00:34:49) Can you go back to that mindset and try to derive some wisdom and advice (00:34:55) to those folks when you were just a solo developer, maybe just a small group of people creating your early games that eventually became this huge gaming company. (00:35:08) But in the early days, what were you going through? (00:35:13) What were the ups and downs? (00:35:15) What did it take to sort of stay strong and persevere? (00:35:18) Well, (00:35:19) one of the critical things that Epic always worked hard to do was to make something different that nobody else was doing, and to try to satisfy a small audience rather than competing globally with the game juggernauts. (00:35:33) You know, back in the 1990s, Epic was new, but Electronic Arts and Activision and the other big publishers had been around for a decade, and they were huge companies that had giant retail distribution networks. (00:35:45) You know, if I tried to make a game and then convince them to publish it, I doubt (00:35:50) I could have had a chance and I doubt that even if I made a successful game that I would have made much money from it, though they might have. (00:35:58) And so the really unique angle to Epic then was shareware. (00:36:01) And that was just the idea that if we distribute our game differently, then we can reach a much larger audience than these bigger competitors by virtue of this first episode of the game being free. (00:36:11) It was kind of the advent of what later became free to play and the (00:36:16) logic of that is just as true now as it was then. (00:36:19) It's if the thing is free and anybody can get into it, then it's kind of spread from friend to friend as people bring their real world friends into the games they're playing and have the opportunity to build up a community around that. (00:36:32) So the other lesson there was minimize the friction of people getting into your game, make it easy to get into and make it fun. (00:36:39) I think the other, well, I was very fortunate. (00:36:42) ZZT was a funny game. (00:36:43) It was not like (00:36:45) much like any other game. (00:36:46) It had much worse graphics because it was all just text characters, smiley faces, and other Greek letters and things participating in this game simulation. (00:36:56) They were kind of iconic representations of characters rather than real ones. (00:36:59) And this was decades into the age of real graphical games with interesting graphics. (00:37:05) And so it wasn't even trying to compete in that area, but it was able to compete in a different area, which is that it wasn't just the three (00:37:13) games that I'd made and shipped as a trilogy that were successful and drove the success of the product. (00:37:18) It was the fact that I released an adder and there's a whole community around it. (00:37:22) And you see that trend has repeated itself. (00:37:24) Like there was, you know, ZZT was going on. (00:37:27) Before that, there was Bill Budge's Pinball Construction Set. (00:37:30) That was a 1980s Apple game that let users build their own pinball tables. (00:37:34) And since then, you've had some of the world's most successful games follow that path, like Minecraft, you can build your own stuff, Roblox, Fortnite Creative, and Unreal Editor for Fortnite. (00:37:44) Games that become platforms for other people to build stuff was a real opportunity. (00:37:49) I think the big thing to realize is for indie developers right now is there's massive, massive competition in every major genre. (00:37:58) It's very unlikely that unless you just happen to be the world's best at a particular thing, that you're going to release a game in an existing highly competitive genre and win, a much better chance of success is in releasing something that hasn't been done before, being really unique and reaching an audience, even if big or medium size or small, reaching an audience and becoming really popular with that, making some money from it and being able to reinvest and then expand towards your ultimate dream. (00:38:25) I think the one-shot go from idea to commercial success at massive scale is a lot less likely than the multi-step process of continually build better and better stuff over time until you get into a position of excellence. (00:38:41) And constantly try to do something that others aren't doing. (00:38:45) Yeah, that's right. (00:38:46) Because if you look at every market, there's a few markets where the current leader came late to the space, usually because the (00:38:55) prior leader failed so horribly. (00:38:57) But most of the time, the company that's succeeding and winning in a market is the first or second entrant there. (00:39:04) They've just continually buoyed their success. (00:39:07) Great advice and fascinating. (00:39:09) But on a human level, was it lonely? (00:39:12) Was it scary? (00:39:14) You sitting there as a developer? (00:39:17) I'd say it was the opposite of lonely because, you know, (00:39:22) The thing that spurred me to actually release this was seeing kids playing the game in my neighborhood and having fun. (00:39:27) I mean, like, this is really good. (00:39:29) And seeing them enjoying it and laughing and pointing at the screen and getting together and just wanting to play more. (00:39:34) That's awesome. (00:39:36) And the human element was always pervasive. (00:39:39) I did not only receive orders, but people would actually write letters. (00:39:42) We wrote letters back then in the 1990s. (00:39:45) People would say how much they were enjoying the game and how their kids were playing the game and so on and so on. (00:39:50) So it felt very connected. (00:39:53) And I think a lot of businesses have to make scary decisions because you're spending potentially all of the money you have to. (00:40:00) take a shot at something that you're not sure will succeed. (00:40:04) I was very fortunate starting a business like this because it didn't really need any capital. (00:40:07) The capital is, well, the several thousand dollars in computers I'd bought by mowing lawns. (00:40:13) And it wasn't much risk. (00:40:15) If that hadn't succeeded, I guess I could have figured out how people get mechanical engineering jobs and pursued that. (00:40:20) But once it took off and once the (00:40:23) orders started coming in and people started writing letters saying they're enjoying the game. (00:40:27) I knew I was going to go all out and try to build a company there and succeed. (00:40:30) And that was like going to be my big goal. (00:40:35) So I'm sure people know, but Epic Games was created in 1991 and went on to transform the gaming industry several times, one of which is Unreal Engine. (00:40:48) So let's talk to the origin story of that. (00:40:50) You said that when Wolfenstein (00:40:53) And Doom came out. (00:40:54) That changed everything. (00:40:56) So take me to that moment. (00:40:58) Yeah, that was a very interesting time. (00:41:01) Epic had, after my first couple of games, had recruited developers, usually college students, high school students who are just working on their own had real skills, but didn't have an outlet for their work. (00:41:13) Epic had been matchmaking the best artists and programmers together from all over the world. (00:41:17) Chaz Jackrabbit was Cliff Lusinski, a high school kid in California, who made a (00:41:22) really cool adventure game together with Ariane Brusi, a demo coder from Holland who would make amazing graphical stuff, and had built a 2D game engine. (00:41:31) I connected them together and a musician, Robert Allen, in California, and by telephone and modem and so on, we were building these little 2D games and having quite a lot of success. (00:41:41) There were a bunch of people making thousands of dollars a month while they were still students and royalties from the games. (00:41:47) Epic was (00:41:48) kind of producing and by coordinating people with people and publishing through shareware. (00:41:54) And that was all going great. (00:41:56) The company had a little office and we were copying floppy disks and mailing them out. (00:42:01) But when Wolfenstein came out, we realized the future of gaming is going to be 3D. (00:42:08) There had been a lot of experiments in 3D before that hadn't been great. (00:42:13) There were 3D renderings of mazes that were not in real time, and you're always looking north-south, east, or west. (00:42:19) And then there were vector graphics with the little wireframes moving around and things. (00:42:23) But Wolfenstein was the first game that was fast enough (00:42:28) running at 30 frames per second, it really felt immersive. (00:42:30) It felt like you were there, like you were in this castle, Wolfenstein, fighting Nazis. (00:42:35) And that was a really amazing and immersive experience. (00:42:39) 3D graphics were pretty primitive then. (00:42:40) It software followed shockingly fast with Doom, which was a much, much more capable 3D engine, which had stairs and (00:42:49) Though it was still what we call two and a half D. (00:42:51) It was environments that were very realistic, textures that were very realistic, you know, a form of lighting that was approximate, but incredibly realistic, and just such great artistry and sound effects. (00:43:02) It filled completely visceral and real. (00:43:07) Yeah, you might look at it today from our, you know, point of view of a modern (00:43:13) game player with 20 teraflops of computing power in your device and say, oh, that's not very impressive. (00:43:18) But it was amazing at the time. (00:43:20) I mean, for me, just decided to pause on that. (00:43:23) I think Wolfenstein was one of the most amazing moments of my own life. (00:43:30) Just being able to, like you said, in real time, move about a three-dimensional world. (00:43:35) I just remember just like just moving around just in like (00:43:41) What is that feeling like? (00:43:45) I mean, you feel transported into another world. (00:43:48) You feel that you're there. (00:43:49) Yeah. (00:43:50) And especially when you turn the lights down in your room and you turn the sound up on your speakers, and it will scare you. (00:43:57) And you'll feel like that fireball that's coming at you is going to kill you. (00:44:02) That was an amazing time because we hadn't experienced that before. (00:44:05) There was nothing like that. (00:44:08) Yeah, you'd watch a movie, a scary movie, or whatever. (00:44:10) it was just this thing that was happening. (00:44:13) This was you. (00:44:14) This was you in a 3D world. (00:44:17) So how did that change Epic, this realization that the future of gaming is going to be 3D? (00:44:23) Well, at first I was really depressed. (00:44:24) I think because the wizardry of... (00:44:28) Doom especially was so incredible that I gave up on programming for like 6 months. (00:44:32) I was like, I don't ever be able to compete with this. (00:44:34) I have no idea what we're going to do. (00:44:36) We just keep making 2D games and hope that the business goes on. (00:44:39) But that was the nature of Carmack's wizardry. (00:44:42) He had done things that were like not just one innovation leap ahead, but like a dozen simultaneously interplaying in a way that you couldn't pick them apart into their component pieces. (00:44:52) But (00:44:53) Funny thing happened. (00:44:54) Michael Abrash, long-timer in computer graphics, wrote a book on the techniques for 3D graphics and texture mapping, and he wrote some articles in one of the programming magazines of the day and explained it and showed assembly code to do texture mapping, you know, drawing these 3D graphics on the screen. (00:45:13) And it was actually really simple stuff. (00:45:15) I was like, oh, I can do that. (00:45:18) And so a bunch of us at Epic independently went off and started writing our own 3D graphics (00:45:23) to figure it out. (00:45:24) And we found at one point, we had a number of people dabbling in this, doing different parts of it. (00:45:29) And at that point, we decide, okay, this is 3D graphics and 3D gaming is going to completely change the world. (00:45:35) We need to go all in on this. (00:45:37) And so we took the best people from our best 2D game development teams and put them all together to make a 3D game. (00:45:42) We didn't really know what we were doing at the time. (00:45:44) None of us had ever shipped a 3D game, and most of us were still learning, but everybody was like trying different disciplines to see what they were best at. (00:45:51) And (00:45:53) It was a combination of a bunch of people who came together to make Unreal. (00:45:56) I'd initially volunteered to make the 3D editor for the thing, and James Schmaltz had made Epic Pinball. (00:46:02) Epic Pinball. (00:46:03) Now, that wasn't a crazy game. (00:46:04) This was one of the 2D Sharer games. (00:46:06) He made it while he was in college, and he was making like $30,000 a month from, you know, the royalties from this game because everybody had wanted an awesome pinball game. (00:46:15) It was massively successful. (00:46:18) But it was (00:46:19) He was a multidisciplinary person. (00:46:21) He wrote the code for the game, the art for the game, and did basically everything. (00:46:25) And the code was 30,000 lines of assembly language. (00:46:29) And so he was initially going to write the 3D engine, and I was going to write the editor, and he sent me his code so I could integrate into the editor. (00:46:37) It was like just a giant pile of assembly code. (00:46:40) I was like, why don't I just write this myself? (00:46:43) And so James instead started going off and building 3D models and 3D animations using the tools at the time. (00:46:47) And so (00:46:49) Cliff had done a lot of design work and built the levels on Jazz Jackrat, went off and started learning basics of level design. (00:46:55) And so I was writing this editor and Cliff Blazinski was customer #1 for it, starting to go off and build levels. (00:47:00) And James Schmalz was building awesome creatures, sending them to me, get them in an implementing game. (00:47:05) And we brought in an animator to bring them into life. (00:47:07) And we brought in more and more people until at the peak of Unreal 1 development, we had about 20 people. (00:47:14) working on, which was a huge team for the time, and it was really stretching Epic's finances nearly to the breaking point. (00:47:20) We barely survived and almost ran out of money a number of times, but somehow we always pulled through. (00:47:26) And it was a crazy project because it was 3 1/2 years of development in a game that we always thought was six months from shipping. (00:47:33) And it was like 3 1/2 years of 70 or 80 hour weeks for most everybody working on the project. (00:47:42) not even knowing what problems we'd need to solve next because we were so immersed in the current ones. (00:47:47) Were there moments when you were losing hope that this might take too long and the company will run out of money? (00:47:54) We were always very financially stressed, so I was continually worried about that. (00:48:00) I had total confidence that we'd work out all the technical and artistic problems because, yeah, we knew the pieces and it was largely a matter of typing code in and solving some problems. (00:48:11) And kind of like we knew we could ship a version of it. (00:48:13) And the thing that was continually really interesting was the ongoing discovery of new techniques as we went. (00:48:24) Because at the time Quake had shipped, it had a little bit of dynamic lighting. (00:48:28) Unreal really pushed dynamic lighting much harder than anybody else had done before. (00:48:32) And colored dynamic lights with some shadow casting capabilities statically or moving lights without shadows. (00:48:41) figured out how to do volumetric fog so you could have foggy areas that were full of lights and you get the kind of glow of the lights standing out in the fog and affecting the appearance of the level. (00:48:51) A whole lot of amazing techniques came together to build a game that made a number of leaps ahead of the state-of-the-art at the time. (00:49:01) Yeah, it was really crazy, but I think most companies wouldn't have survived that, but the sheer talent of the people involved (00:49:10) made it possible. (00:49:11) And Epic has often done things that most companies will have failed at and we succeed, not because of awesome management or awesome planning or awesome financing, but because of the sheer talent and willpower of the people involved to make it happen. (00:49:25) What about the interdisciplinary aspect of it? (00:49:28) Like you said, sort of artists, engineers, or programmers, designers, all of them working together. (00:49:37) What was that, the 20 people, what was the dynamic there like working insane hours? (00:49:42) Like what was it like to sort of make a team like that work together well as an orchestra to actually deliver the game? (00:49:51) Yeah, that's one of the really unique things that exist in gaming, not in normal big tech companies, which are just engineering and business driven, but gaming really does require (00:50:03) all of the best people across all the creative disciplines working together. (00:50:08) And Epic had grown organically by recruiting people with awesome talent. (00:50:13) We always had a limited budget. (00:50:15) We could never pay to bid up people with salaries and hire them away by paying them more. (00:50:20) We just had to find awesome people who were at the beginning of their career and put them together. (00:50:26) So everybody was very new to this. (00:50:29) and didn't have any assumptions about how companies worked. (00:50:32) And so, you put all these people together and, it was really a constant interplay of talent as people were learning how to work together as a team. (00:50:41) Nobody had management experience. (00:50:43) Most people hadn't shipped a game before they worked with Epic. (00:50:46) And we were figuring out as we went. (00:50:50) But it was a constant iterative cycle. (00:50:52) We'd make several new versions of the game every day. (00:50:54) Read a new compile, introduce a new feature, or fix some bugs, get it to artists, artists improve their levels, continue building stuff, and then we see what they're doing in their levels, like, I see what you need now. (00:51:05) We'd constantly be improving the tools, and just the iterative process and the speed at which that improves products is a critical element to success in games. (00:51:14) To slower the iteration cycle, if you make a build every week, (00:51:17) And you prove you go through one iteration every week, you're going to be way, way, way worse by the end of your project than a game company that makes new stuff every day. (00:51:26) And that was the magic that happened together. (00:51:29) And it wasn't, there was really nothing but passion and everybody's individual dedication to it that made it work. (00:51:36) I heard you still program, but how much programming were you doing back then? (00:51:40) You mentioned the hours, probably insane hours. (00:51:43) So like, it'd be almost fun to talk about your setup. (00:51:47) what a day in the life of Tim Sweeney in the 90s when you were building Unreal looked like? (00:51:54) Well, we all gravitated towards a schedule, a work schedule that maximized productivity. (00:52:00) And that usually meant waking up late. (00:52:02) I'd get to, like, usually get to work around noon. (00:52:05) I usually work till like 2 A.m. (00:52:07) or so, 3 A.m. (00:52:10) sometimes. (00:52:12) And, I didn't have anything else going on in my life. (00:52:15) So it was always just work and sleep and occasional eating. (00:52:18) And I found I always need 8 or 9 hours of sleep a night. (00:52:23) Without good sleep, I would just become a zombie and wouldn't be nearly at my best. (00:52:27) I always needed to get sleep, but I didn't need anything else going on. (00:52:30) So I just, the programming itself was so energizing and thralling. (00:52:34) Yeah, so it was a, you know, 3 1/2 years of that during the project. (00:52:39) mostly spent programming. (00:52:41) I'd say probably 60 hours a week of programming, 5 hours a week of coordinating with other people and iterating and sitting down with them and looking at what's going on in screen and figuring out what they needed. (00:52:51) Maybe 5 hours of business stuff. (00:52:54) You know, there's a good division at Labor then. (00:52:57) I didn't have a big executive team, but it was like basically myself running the technical and development part of the company and Mark Raine running the business part of it, doing deals and (00:53:09) maxing out his credit card and going around the world doing, bringing in sources of revenue to keep the company funded. (00:53:14) What programming language? (00:53:15) Are we talking about C? (00:53:16) Because you mentioned there's this pile of assembly. (00:53:19) Did you choose, what was your decision in choosing the programming language that would, that Unreal Engine would be written in? (00:53:26) I'd grown up learning with Pascal as my favorite language. (00:53:30) In order to just get maximum performance and get the latest operating system features, I had to move to C. (00:53:37) for my second game, Joel of the Jungle, a little Nintendo-style platformer. (00:53:41) And so when I started Unreal Engine, it was on 16-bit Windows using the C programming language. (00:53:47) And over the course of the first year, it moved to 32-bit using these DOS extenders and then using Windows NT. (00:53:57) And I moved to the C language. (00:53:59) And just because it simplified the code so much, went from a really complicated (00:54:05) pile of code to a much simpler one, making that transition. (00:54:10) And so almost the entirety of Unreal Engine development, about 2 1/2 years of it was all on C, 32 bits, completely state-of-the-art then. (00:54:17) Like 32 bit protected mode was kind of a magical thing, having come from the days when computers were much less reliable and crashed all the time. (00:54:25) Yeah, and turned out to be a pretty good bet because C out of all those languages ended up being the dominant sort of (00:54:33) performance-oriented language that survives to this day? (00:54:38) Yeah, it's because it solves all the problems at scale, often through manual pain, but always solves them. (00:54:46) And a lot of other languages do better and a lot of theoretical aspects and are better for some usage cases, but you can't do everything. (00:54:54) And that's really, very limiting. (00:54:57) All right, so... (00:55:00) ridiculous questions, but did you have one monitor, two monitors? (00:55:05) Were you picky on the keyboard? (00:55:07) Were you picky on the chair? (00:55:09) What are we talking about? (00:55:10) Let's paint a picture. (00:55:13) Okay, I went through a big transition there. (00:55:14) So I started out being pretty lazy. (00:55:16) I had a bunch of like... (00:55:18) I bought used computers because you'd often get them at half the price of a new one. (00:55:21) They'd be good enough. (00:55:22) So I had this old 486 I was developing on. (00:55:26) I guess it was a 15-inch monitor at the time. (00:55:28) It was a poor workstation setup, but it was very economical. (00:55:32) And so as we started on Unreal, I realized that I had to write a ton of code. (00:55:37) I had to write it at absolute maximum productivity. (00:55:39) So I had to rearrange my entire life around delivering maximum output. (00:55:44) And so at that point, I realized actually spending money on getting good equipment was a good investment. (00:55:49) And we're not talking about millions of dollars here or billions if you're building a GPU farm. (00:55:53) We're just talking about buying some basic hardware. (00:55:56) And so I bought the biggest CRT you could buy at the time, because this was a CRT year. (00:56:00) It was 24 inches. (00:56:01) It weighed like 100 pounds. (00:56:04) I had back pain for a week after I installed it. (00:56:07) But (00:56:08) It got me a 1920 by 1200 view in 1996. (00:56:15) In 1996, that was pretty cool. (00:56:17) So I'd upgraded to a 90 megahertz Pentium and did a lot of programming on that. (00:56:20) It was on the 90 megahertz Pentium. (00:56:22) These were the main consumer computers at the time, and I'd optimized the Unreal Engine software render on that, which was, you know, the Pentium was the first super scalar architecture in consumer computing. (00:56:33) It could run (00:56:35) up to two instructions at a time. (00:56:36) And if you wrote your assembly code very carefully, you could get absolute maximum throughput. (00:56:42) So I'd gotten my texture mapping code down to six CPU cycles comprising 11 instructions. (00:56:50) And that was required for every pixel on the screen. (00:56:52) And that was just enough performance to deliver that. (00:56:55) But Dill came out with these new workstations. (00:56:59) And Until I just launched the Pentium Pro, the first out-of-order processor. (00:57:04) And so I basically bought the absolute maximum configuration that money can buy. (00:57:09) It cost $7,000. (00:57:10) I had a gigabyte of memory in 1996. (00:57:14) Wow. (00:57:14) And a 200 megahertz CPU. (00:57:16) So it tripled the speed of compiles and just made me massively more productive. (00:57:20) So that's why I was using throughout Unreal Engine development and shipped with that. (00:57:25) By the way, people in the 90s would have been blown away by this workstation. (00:57:29) I love it. (00:57:30) Yeah. (00:57:30) Were you in writing, were you considering the hardware much? (00:57:34) Was there a sense like, so, you know, for people who don't know, Unreal Engine rendering, I guess is all software doesn't use the hardware, but were you trying to optimize, as I understand, maybe you can correct me, but like, were you trying to optimize to the hardware at all? (00:57:49) Well, at the time, so we did most Unreal Engine development before the first real GPUs came out. (00:57:57) And the 3DFX Voodoo one, the first GPU that actually delivered serious performance compared to software rendering. (00:58:04) The first GPU that was really gainful came in the end of the development, and we supported it really quickly, but it was not the target all along. (00:58:12) And so development was focused on just building-- there are two parts of the engine, right? (00:58:16) There's all of the gameplay systems that manage the simulation and physics and so on. (00:58:21) That's all written in very high-level C++ code. (00:58:24) And maintainability is as much of a goal as performance, because we had to build massive amounts of systems over time. (00:58:33) But the one thing that was really a bottleneck was graphics, the cost of rendering a single pixel was really high. (00:58:39) And so you had to do everything you possibly could to optimize the rendering of pixels on screen. (00:58:44) And so we were talking about how many CPU cycles, you know, when you say your CPU runs at a gigahertz or whatever, that's a, you know, (00:58:52) billion instructions per second. (00:58:54) How many instructions do you need to run to get a pixel on screen? (00:58:58) And so there was a constant challenge to optimize that down. (00:59:02) And there was also a competition among all of the graphics programmers who would often send emails, like bragging to each other about what new technique they've discovered to try to get the cost down. (00:59:12) And Abrash's original articles took like 12 CPU cycles to render a pixel. (00:59:16) And everybody else had figured out how to get it down to six or sometimes even four cycles. (00:59:22) And that involved lots of different trade-offs of caching and memory hierarchy and so on. (00:59:26) It was just like a magical time where a human could actually understand exactly what the CPU was doing under the hood and could write code that exactly targeted that. (00:59:36) And that's largely lost now. (00:59:37) When we talk about optimization software now, it's largely about heuristics. (00:59:42) And statistically, this memory access is likely to hit the cache. (00:59:47) And this algorithm is faster than that algorithm. (00:59:50) Because CPUs now have such advanced out-of-order execution that you really can't micromanage what's happening on an instruction-by-instruction basis. (00:59:58) You can only manage the aggregate performance of code. (01:00:01) And so there's kind of this lost art. (01:00:03) Some people miss it, some people don't, in which the programmer had absolute control over the machine and could work miracles in special cases if you tried. (01:00:14) It seems like there's still value to that art when it comes to (01:00:18) GPUs and ASICs. (01:00:20) So basically trying to understand the nuances of the hardware and how to truly, truly optimize it, whether it's for machine learning applications or for ultra-realistic, real-time graphics applications. (01:00:34) Is that true? (01:00:36) Yeah, that's absolutely so. (01:00:39) You know, the optimization problems have just moved around. (01:00:42) And a system like Nanite, the virtualized micropolygon geometry, (01:00:47) system that Brian Karras, a brilliant engineer with Epic, built, was just one of those multi-year optimization efforts that required him understanding everything from the highest levels to the lowest levels of the hardware to figure out how to make this breakthrough technique work in a way that was actually maximally performant on GPUs. (01:01:10) And so Nanite is the system we'll jump around in time. (01:01:13) That takes us to today with Unreal Engine 5. (01:01:17) the system that does the geometry. (01:01:19) Yeah, so rendering the world sort of geometrically. (01:01:21) There's many layers to this. (01:01:22) We'll probably talk, sneak up to each of those. (01:01:26) But one, you have to actually create the geometry of the world around you and do that in real time and really efficiently. (01:01:32) There's a bunch of different ways to optimize that. (01:01:35) Can you just speak to it? (01:01:36) Yeah, with the advanced art tools we have today, it's really easy to create a scene with billions of polygons. (01:01:43) The hard part is how to render it efficiently, because you can't render billions of polygons in A-frame. (01:01:48) Basically, you want to render an image that's indistinguishable from the full detailed geometry if you rendered it at ridiculous cost. (01:01:55) And so the challenge is how to simplify every component of the rendering, the geometry, the lighting, and so on, down to real-time techniques. (01:02:04) They're efficient. (01:02:06) to capture a realistic view of what's around you. (01:02:09) And so when an object is up close to you, want to render it with a lot more polygons than when it's far away. (01:02:14) But one of the cool principles of mathematics is the Nyquist sampling theorem. (01:02:18) It says, if you're trying to reconstruct a signal, there's a limit to the amount of data you need to bother capturing. (01:02:26) If you want to render a texture at a certain resolution, then you never need more than twice the pixels than in the texture that you have on the screen. (01:02:34) And that's called the Nyquist limit. (01:02:36) And so one of the challenges of computer graphics is given the need to render objects at extreme close-up distances and extreme far-away distances. (01:02:43) You always want to be able to generate the right amount of geometry so that you have enough to be indistinguishable from reality, but not any more than necessary. (01:02:52) And with geometry, the idea is that if you render 2 triangles per pixel, you should get an image that is indistinguishable from (01:03:02) thousands of triangles per pixel. (01:03:04) If you render less than two triangles per pixel, you're going to start to see visible artifacts of the loss. (01:03:09) And GPUs have this amazing hardware in a lot of different pipelines, but it's all very fixed function. (01:03:14) There's pixel shader hardware, there's geometry processing hardware, and then there's triangle rasterization hardware. (01:03:20) And one of the limits of GPUs is that the triangle rasterizers are built for pretty large triangles. (01:03:25) If you're building a triangle or rendering a triangle with 10 pixels, that's pretty efficient. (01:03:28) But if you're building or rendering a triangle with one pixel, it's very inefficient. (01:03:33) So one of the breakthroughs Brian made was to design an entire pipeline for avoiding the rasterization hardware in the GPU and just going straight to pixels and calculating what should be done with that pixel as a result of some ray tracing and (01:03:49) geometry intersection calculations done in a pixel shader. (01:03:53) So instead of using the triangle pipeline, we're just using the pixel pipeline and getting a better result. (01:03:59) Because of the limitations of the triangle rasterizer in the GPUs. (01:04:03) That's fascinating because as you describe, you need the tiny triangles for the detail, for the stuff that's up close. (01:04:11) I mean, this might seem obvious to people, but it's not just stuff up close. (01:04:17) It's like, it depends on where you're looking. (01:04:20) Like the human eye and the human focus and the human attention mechanism defines how much detail you want to show. (01:04:29) Because the thing that the human is likely to be (01:04:32) giving attention to, you want that to be super high resolution. (01:04:36) And everything else, including due to distance, can have less geometry and less texture, less information in it. (01:04:44) Yeah, that's right. (01:04:45) But there's a lot of challenges like that. (01:04:46) It turns out it's a lot easier to render one frame that looks perfect than it is to render a series of frames in motion that look perfect. (01:04:54) A lot of the problems with the earlier algorithms that aspired to do this sort of things was popping. (01:05:00) you'd be running some number of triangles for a while and then you'd switch to a different number of triangles and you'd see a visible transition and the screen would look like it got shaken up. (01:05:10) You know, it's a disturbing artifact that distracts you from the game. (01:05:12) And so one of the magical trade-offs of Nanite was how to avoid all of the visible transitions and get them down to a point where, though they exist statistically, they're not really perceptible to a person looking at it. (01:05:26) You look at something like Nanite, (01:05:27) I mean, there's a nice blog post, there's nice descriptions about the details, but you can tell even under the details, there's just incredible engineering that goes on. (01:05:35) It's so cool. (01:05:36) It's so cool how underneath this, you know, the actual experience of beautiful detailed scenery, there's just incredible engineering to bring to you simulation, ultra realistic simulation of reality in real time, like lights changing everything. (01:05:56) And then, it just takes you back to that feeling I had with Wolfenstein, but more, and you can completely lose yourself in that world and you would forget that this real world exists. (01:06:09) what is the real world anyway? (01:06:11) So it's that coupling of great engineering and great storytelling in terms of just feeling is super cool. (01:06:19) It's great to know. (01:06:20) It's great to know that there's these teams behind it. (01:06:24) And it's cool that you're also releasing a bunch of details around it, at least for folks like me, it's inspiring to see. (01:06:32) So Unreal Engine, (01:06:34) is this fascinating creation. (01:06:36) It's a big, bold, crazy bet that you've made. (01:06:38) Maybe it's good to actually explain what Unreal Engine is for people sort of outside this world. (01:06:44) I would say it transformed the gaming industry. (01:06:48) But that was a big bet in 1995 that most of the effort would be on creating the gaming engine, not the game. (01:06:59) Yeah, Unreal Engine is a big bundle of code and tools, a huge software package that provides all the functions you need to build any sort of a 3D graphics application. (01:07:10) Game developers use it to make games, and that's the predominant use, but it's also used in Hollywood film and television production to create 3D scenery in real time for production sets, to do pre-visualization. (01:07:25) It's used by car makers to visualize their cars before they're (01:07:29) constructed or manufactured. (01:07:31) It's used by architects to preview buildings before they're made and industrial designers of all sorts. (01:07:37) And it provides all of the 3D simulation features you need, both for creating highly realistic 3D graphics, but also physics and interactions between objects and making things happen like you might see in the real world. (01:07:53) And supports a huge variety of styles from (01:07:55) Pixar stylized movies to cell shading to photorealism. (01:08:00) And it can be used for anything that needs real-time 3D graphics, including humans that populate those three-dimensional worlds. (01:08:08) And we'll probably talk a bunch of the... (01:08:12) the details involved in the process of creating ultra-realistic humans, because we humans care about how other humans look and how they convey emotion and express how they speak, all that kind of stuff. (01:08:27) But so yes, it's the 3D objects that are static, the 3D objects that are dynamic, and on the dynamic front, including humans that are ultra-dynamic. (01:08:40) So all of that, you have to create this engine that simulates that world, the world as we, this beautiful world that we know and love. (01:08:50) Okay, so that, but you know, you're early, so here you see Doom and you're trying to create this world and trying to create an engine that would not just power Unreal, the video game, but (01:09:02) future video games. (01:09:03) So how do you go about it? (01:09:05) What are you thinking? (01:09:06) And that, I should sort of linger on that. (01:09:08) is a crazy bet that we're going to build an engine as a company. (01:09:14) Yeah, well, you know, the philosophy began with ZZT and continued onward. (01:09:19) We're not just building a game for players to play. (01:09:24) We're also building tools that could be used for building that game or any other game and catering to all the artists and designers who had used the tool. (01:09:32) And so that philosophy started with the very early parts of Unreal development. (01:09:38) I was building the tools for level designers like Cliff Wazinski and artists like James Schmaltz. (01:09:45) And as we began marketing the game, thinking it was six months away, we were constantly releasing screenshots and things like that. (01:09:54) Other companies started calling us and saying they wanted to build 3D games too. (01:09:58) But they didn't have the expertise for that, and they wanted to license our 3D engine. (01:10:02) And this was one of the coolest pivots in Epic's history. (01:10:07) MicroPros called up Mark Rain, our vice president and long-time business guy, and said they wanted to license our engine. (01:10:15) And Mark Rain was like, oh, what? (01:10:17) You want to license what? (01:10:18) An engine? (01:10:18) What's the, what engine? (01:10:20) And they explained to them what they wanted to license. (01:10:22) He's like, oh, that engine. (01:10:22) Yeah, that's very expensive. (01:10:26) But this was one of the critical things that kept Epic going through that three and a half years. (01:10:30) We were starting to license our engine out to other developers. (01:10:34) MicroProse took two licenses, and we got in half a million dollars from that. (01:10:39) And the company, GTA Interactive, licensed our engine to build another game, and we got paid for that. (01:10:46) And so we had this revenue stream funding the development of Unreal Engine from other games that were being built by other developers. (01:10:53) Because they were the lifeline for the company, we took the engine business very seriously from the start. (01:10:59) We set up mailing lists so that our partners could ask us questions. (01:11:03) And all the developers and artists working on our games were participating in helping customers. (01:11:09) Everybody took that very seriously because it was our funding source. (01:11:12) And that's kind of set this dual spirit of Epic of building technology and supporting game developers simultaneous with building games and supporting gamers. (01:11:21) It's continued onward and just grown over time. (01:11:23) Can you just go back to that, you programming? (01:11:27) What are some interesting technical challenges you had to overcome? (01:11:30) You mentioned dynamic lighting. (01:11:32) Like create, you know, create this three-dimensional world and try to figure out the puzzle of how you actually do that at a time when nobody, Carmack and you, doing this kind of thing. (01:11:46) It's a totally open Wild West. (01:11:49) So what are some interesting technical challenges you had to (01:11:52) you have to try to solve. (01:11:54) There's a lot. (01:11:54) Some of them are visible on screen, and some are behind the scenes and still require a lot of innovation. (01:12:01) All the graphical techniques were really interesting challenges. (01:12:05) And Unreal Engine, in those early days, went a lot further than the Quake Engine and building environments using constructive solid geometry with a real-time editor. (01:12:16) And that was a really interesting technical challenge. (01:12:21) The idea is (01:12:23) Building is extremely tedious if you are only adding objects to the world. (01:12:28) If you want to build a door, then you need to add like a dozen different pieces of door frames and add a bunch of different walls together to fit together in the right shape. (01:12:34) It sure would be easier if you could just start with a wall and subtract the door out. (01:12:39) And so we had this way of adding geometry to the world and subtracting geometry, and the engine would perform all the calculations on that. (01:12:47) And this is something that I'd been anticipating was possible for a long time, but when I finally got around to it, took this 30-hour coding session to figure out all the special cases of the code that needed to be implemented to make that work. (01:13:00) But in the course of 30 hours, I got constructive solid geometry up and running. (01:13:05) I started doing a, like handed it to James Schwaltz the next time we were together. (01:13:10) And it's like, okay, I think you're cheating here. (01:13:12) So you create a giant torus and then add another giant torus, interlocked with it, and then subtracted a cylinder from it and created this really advanced composite object with just three operations. (01:13:24) He was like, whoa, I can't believe this. (01:13:26) It's like, yeah, we figured it out. (01:13:28) And that was cool to see for the first time. (01:13:30) It was probably the first time somebody had done constructive solid geometry in real time. (01:13:34) But it was also a really useful artist tool that all the artists appreciated and immediately began making use of. (01:13:39) Can you actually speak to that, the 30-hour session? (01:13:41) I mean, this is not, from everything I know about computational geometry, doing this kind of thing, from your perspective, that's not easy. (01:13:50) That's, what is it? (01:13:53) The uncertainty, the open questions involved, the... (01:13:59) I mean, even just on the algorithm front, how to do that efficiently. (01:14:05) And then plus the usual programming thing of debugging, like suffering through the trickiness of it. (01:14:13) And we don't have really, at that time, you don't have the tooling to really visualize everything that's going on really well. (01:14:19) And you probably like using some crappy editor. (01:14:21) I mean, there's just a lot of like friction here. (01:14:24) So the 30 hour session is one that's probably (01:14:28) Rough. (01:14:29) It's a rough one. (01:14:31) Your brain works in different ways and depending on your state, right? (01:14:36) There are some things that require really working on a problem fresh where you've put together a bunch of logical pieces and now you just need to write a whole lot of code to make it all work together and plumb a whole lot of data between a whole lot of different algorithms. (01:14:53) But you know, I think our brains have vastly more horsepower than we're able to (01:14:58) directly access by thinking of what code to type next. (01:15:02) And, after you've been working for a very long time, you can get into a sleep-deprived state where you have much, much more direct access to that low-level knowledge. (01:15:11) That's great. (01:15:13) Yeah. (01:15:13) You know, because there are symptoms that are well studied of sleep deprivation. (01:15:16) One of them is short-term memory loss. (01:15:19) And so you're working without, like, the easy recall of the code you just typed. (01:15:24) But your brain is then freed to think about other problems. (01:15:27) And (01:15:28) And I brought up this intuition over a very long period of time. (01:15:32) So the foundation for the subject is the binary space partitioning tree, this data structure invaded by a computer graphics researcher, Bruce Nailer. (01:15:41) Carmack had picked up on that and had used the technique in Doom to really great effect. (01:15:48) And I'd picked up on that. (01:15:49) And non-real engine was using this technique for all of its graphics and rendering, but it was just additive geometry everywhere. (01:15:56) And it had a lot of overlapping polygons, and it was pretty inefficient. (01:16:00) So I had the idea that if we had a BSP tree, there was a really efficient way to do constructive solid geometry. (01:16:06) And (01:16:07) To do that, you had to break down the ways that different pieces of geometry can fit together. (01:16:11) I broke it down into like 14 different cases. (01:16:14) And most of them are pretty simple, cranked them out. (01:16:17) Anyways, I got towards the end, you know, there were some pretty complicated things like, well, how do you deal with co-planar polygons? (01:16:23) They're in the same plane and pointing in the same direction versus the other direction. (01:16:27) In what cases should you keep them? (01:16:28) In what cases should you eliminate them? (01:16:30) And so on and so on to create really efficient geometry output. (01:16:34) And, you know, just (01:16:36) plowing through it eventually through mostly deduction, but some trial and error too. (01:16:41) Like sometimes you just have to try the possibilities and see what works. (01:16:45) Yeah, I cranked it out and it worked. (01:16:46) And the next day I came in like kind of weary and I was like, oh, wow, this actually did work. (01:16:50) It wasn't just a dream. (01:16:51) So you're considering the edge cases also. (01:16:53) I mean, that's the problem with geometry is like there's probably just going to be all kinds of weird polygons that you have to see. (01:16:59) You're like thinking, you're imagining the edge cases and trying to see how do (01:17:05) by not create inefficiencies in this algorithm while still considering the edge cases, allowing for the edge cases. (01:17:11) Yeah, you know, it's pretty easy to write software that's like 99% correct. (01:17:17) It's the 1% that's the really hard part and where the devil lies in the details. (01:17:22) What about like lighting? (01:17:23) Is there other interesting? (01:17:25) Well, the funny answer is like we know the laws of physics. (01:17:27) So it's actually really easy to do everything in computer graphics, but the direct solution of the laws of physics is (01:17:35) immensely so. (01:17:36) And so what we're finding are approximations rather than complete solutions. (01:17:41) Because you need something that's a million times faster than the brute force answer. (01:17:45) We should say that the physics of the scene is you just take a bunch of photons, bounce them around. (01:17:52) That's how light works. (01:17:53) That's going to be very inefficient because there's a lot of bouncing and a lot of photons. (01:17:58) Yeah, photon tracing is the subject matter that does brute force calculation of pixels on a screen from all of the light in the scene. (01:18:07) And it works and it's correct. (01:18:09) And it just is an implementation of the laws of physics. (01:18:11) And it's millions or billions of times slower than what we do. (01:18:15) But Carmack had figured out how to do really cool lighting algorithms, including real-time lighting with objects moving around. (01:18:24) And I hadn't taken it very far. (01:18:26) So with Unreal Engine, (01:18:28) I'd realized, we don't have nearly enough computing performance on our CPU to compute the light of every pixel on the screen from all of the light sources that affect it. (01:18:38) We were at a six-cycle texture mapper, and we couldn't afford 30 more cycles for lighting. (01:18:44) And so the answer had to be some approximation. (01:18:46) And the one that Carmack had picked up on in the Quake engine was light mapping. (01:18:50) If we, instead of calculating all the lighting on every pixel, what if we (01:18:55) made a big texture that we placed over all of the walls in the scene that was like wallpaper. (01:19:00) And what if we say every foot, we're going to compute a lighting value for just that one-foot grid on the object rather than computing it everywhere? (01:19:08) And then what if we just linear interpolate that over the course of it? (01:19:13) You get a lighting solution that actually works pretty well and is fast enough to work. (01:19:18) And so a lot of Unreal Engine's lighting techniques were based on light mapping. (01:19:21) We introduced colored lighting. (01:19:24) So you could have colored light sources. (01:19:25) Then we realized, oh, since we're doing this and we're doing it on light maps, we can actually do some pretty expensive calculations, hundreds of cycles, since we're only calculating it for every one foot of world space rather than every pixel. (01:19:36) And so we introduced a whole bunch of elaborate lighting effects, like torch flickering and the caustic effects of water bouncing off of a surface and so on. (01:19:48) and pulsing lights and blinking lights and everything else and created a system, I created a system for compositing them together. (01:19:53) So if you had an arbitrary number of light sources, they could all do that. (01:19:57) And then I implemented shadowing.