Transcript of #467 – Tim Sweeney: Fortnite, Unreal Engine, and the Future of Gaming

And one of the things of one of the fun things of that time was bulletin boards. 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. And every town or city had hundreds of these bulletin boards run by different people with their own personalities and teams. 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. And so I don't know, I probably spent 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.

Each one of those provided a lesson which were later essential. 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. But this was largely just using the knowledge that I'd built up over the previous decade, just doing fun hobby projects. And if I hadn't done all of that work, there's no way I could have ever built the things that came later.

It was actually not clear as an early engineering student what you do. 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. I learned this." And so suddenly, like the karate kid, you get to paint the fence and wax the car, and suddenly you put all the pieces together into a 3D engine based on a whole lot of accumulated programming language and math knowledge, often knowledge gained without ever anticipating that I might use it in that way.

And so constantly picking up knowledge and looking for ways to put it together is the thing to do. 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. If you want to be an artist, you've got to continually draw artwork of all styles and all kinds and constantly push yourself to learn more and more. Because you never know exactly what you're going to end up doing in the long run, but the more knowledge you have and the more skills, the more chance you have putting it together and being successful.

It's valuable and it embodies the knowledge that you need as a programmer. And people often go to 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." No, that's just kind of the superficial bookkeeping of the university. The real purpose of all of this is to learn. And whether you learn formally or you learn on your own, it's the learnings that are really valuable in a career. And especially if you're going to be entrepreneur, it's really knowing the stuff that matters and not having the diplomas.

And there's ever more pressure to rebuild society more and more around credentials. Do you have the certificate? Do you have that proof? But companies that are focused on just building great products and doing great things gravitate towards people who do the great work.

And we'd have an enormous amount of freedom. And from basically being a little kid through the time I went off to college, I had an enormous amount of free time. Some people just used that and wasted it and watched TV. Some people socialized and some people really got into serious projects. So many people at all times were doing cool things. I was programming, I was learning to build things. 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.

And sometimes they were impressed and sometimes they weren't. And they'd have their own projects. And often we'd have spare-time jobs and everybody was entrepreneurial. Everybody had a side gig. Sometimes you'd go around and mow people's lawns or you'd rake the leaves up and earn money. And the freedom there and the organic learning that occurred there, I think it's something that is really critical to the American experience. I worry it's increasingly going away as society is ever more protective and sheltering and makes it harder to get these experiences.

Very, very simple iconic stuff rather than realistic graphics. And then the other game that I really got immersed in was Zork, which was a text adventure game. It would tell you where you are and what you see and you type in commands like gun north or pick up sword or open door and explore a world that way. So the game didn't have any graphics, but in your mind, you had this elaborate picture of what you were seeing there. And it really brought in inspired imagination more than other things. And playing those games led me to often want to learn to program everything that I saw there.

And that drove a lot of my programming. I learned how to move a player around the screen. I learned how to build a design tool. So I could build castles and save them off and then play them in a game. 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. And I learned all the programming techniques that supported games, how to parse text, pick up sword and go north. How do you make that sentence into an actual series of commands on the computer?

And that was really, really exciting. 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. I'd sit down when Wolfenstein came out and then Doom came out. I'd go through and look at it pixel by pixel. I'd move the mouse very slightly and look at exactly what was happening to figure out what technique was being used there. And that was puzzle solving at a grand scale and it was so fun.

You have logic to move the cursor around and let people type things and backspace and delete and do all of those mundane actions. 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." And so I made the cursor into a smiley face character and I had different characters you could place in this document perform different gameplay actions. Some would be walls and some would kill you and some would be moving objects that could fly around the screen. And so this text editor I made evolved into a little game editor. So I was building these levels for a game.

I put a lot of time into building an editor and 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. I started off just building different game levels. The idea is you'd be on a series of boards. 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. I built a solid game world around that. And this was the game that became ZZT. And I was having fun with it, building it and playing it, but I didn't know if it would really work.

So I did this experiment. I started inviting neighbors over, like some adults, some kids of all different ages, and sat them down from it and said, "Here's a game I made. Figure it out." And I had to force myself not to tell them what they needed to do, right? Because I really wanted to learn if they were able to discover it all for themselves. 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. 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.

And I put it out and released it on, well, this was before the internet, so there were board and boards. I uploaded it to a bunch of local board and boards. And from there, it started spreading because the way to build up cred for board and board users was to upload new files and to claim that, "Hey, I was the first that brought this to you." And so there was a natural tendency of the software to spread. I decided to use the sharer model. So I didn't just build this one game. I built a trilogy of three games. I released the first one for free and I said, "Hey, if you like this, buy the two sequels."

And I included my parents' mailing address and said, "Send us $30 and you can get the sequels to this game." And the check started coming in within a few days. I was making like getting three or four orders a day. I was making like $100 a day. I'm like, "Whoo, I'm rich." Because being a 20-year-old, that was like a pretty big deal.

It was just magical. And that was a new thing for software. That did not happen with mechanical devices. You manufactured one, you sold it to somebody and they had it and that was it. But software could spread. That was just really cool to see. And it made me realize there was really no upward limit on the potential for business like that. We saw Microsoft as a big juggernaut company at the time, but I was like, "Hey, you know, if Epic does games good enough, we could accomplish what they've accomplished with operating systems." And the sky was the limit. And I think this is the age we live in now.

You don't have to be an industrialist manufacturing physical products. 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.

You came to a crossroads. I mean, you built compilers, you design your own programming language, you built compilers, databases, all these things you mentioned. And you started building a text editor and then here it came to this crossroad. I'm going to make this fun. And then from there, one of the most legendary gaming companies was created. It's kind of cool. 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?

That's cool.

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. And when we got into Unreal Engine a few years later, the interplay between us building a game and us building tools that were widely used by others was a critical part of that. And I think that's the sole reason that Epic has been massively successful.

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. It's a brutal place for companies. 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. And it really set a principle in our culture that's persevered and is continually brought to the forefront.

And these were really slow. The first modem I had was 300 watts. That means 30 characters per second of data. So you're like sitting there watching a sentence like slowly emerge character by character as you're going online. But that's how we got online and we talked with each other. So you dial up to a local board and board. It'll be run by a person. Usually, they have a computer or two sitting in their kitchen or something that's running the board and board. And they have a small community of a few hundred users all competing to connect to that one phone line. It was often busy and you couldn't get in.

And the more popular board and boards were hardest to get to.

And then later in the 1990s, the internet, which had been fostered in these colleges, started opening up to the public and anybody could connect to it. And suddenly the world took on a life of its own. It became much, much easier to reach a global audience faster.

And there are horror stories about games that would sell like 100,000 copies, but have 2 million users because most people pirated it. 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. And their practices were then followed by others and the early digital industry took form.

But in the early days, what were you going through? What were the ups and downs? What did it take to sort of stay strong and persevere?

And I doubt that even if I made a successful game, that I would have made much money from it, though they might have. And so the really unique angle to Epic then was shareware. 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. It was kind of the advent of what later became free to play. And the logic of that is just as true now as it was then. If the thing is free and anybody can get into it, then it's going to 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.

So the other lesson there was just minimize the friction of people getting into your game. Make it easy to get into and make it fun. And I think the other, well, I was very fortunate. ZZT was a funny game. It was not like much like any other game. 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. They were kind of iconic representations of characters rather than real ones. And this was decades into the age of real graphical games with interesting graphics.

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 my, the three games that I'd made and shipped as a trilogy that were successful and drove the success of the product. It was the fact that I released an editor and there was a whole community around it. And you see that trend has repeated itself. Like there was ZZT was one of it. Before that, there was Bill Budge's Pinball Construction Set. That was a 1980s Apple game that let users build their own pinball tables. 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. Now, Fortnite. Creative and Unreal Editor for Fortnite. Games that become platforms for other people to build stuff was a real opportunity. I think the big thing to realize is for indie developers right now is like there's massive, massive competition in every major genre. And 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.

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.

The capital was, well, the several thousand dollars in computers I'd bought by mowing lawns. And it wasn't much risk. If that hadn't succeeded, I guess I could have figured out how people get mechanical engineering jobs and pursued that. But once it took off and once the orders started coming in and people started writing letters saying they're enjoying the game, I knew I was going to go all out and try to build a company there and succeed. And that was like going to be my big goal.

And it 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. There were a bunch of people making thousands of dollars a month while they were still students and royalties from the games that Epic was kind of producing and by coordinating with people and publishing through shareware. And that was all going great. The company had a little office and we were copying floppy disks and mailing them out. But when Wolfenstein came out, we realized the future of gaming is going to be 3D.

There had been a lot of experiments in 3D before that hadn't been great. There were 3D renderings of mazes that were not in real time and you were always looking north, south, east, or west. And then there were vector graphics with little wireframes moving around and things. But Wolfenstein was the first game that was fast enough, running at 30 frames per second that it really felt immersive. It felt like you were there. Like you were in this castle Wolfenstein fighting Nazis. And that was a really amazing and immersive experience.

3D graphics were pretty primitive then. id Software followed shockingly fast with Doom, which was a much, much more capable 3D engine, which had stairs. And though it was still what we call 2.5D, there were environments that were very realistic, textures that were very realistic, a form of lighting that was approximate, but incredibly realistic. And just such great artistry and sound effects, it fueled completely visceral and real. You might look at it today from a point of view of a modern gameplayer with 20 teraflops of computing power in your device and say, "Oh, that's not very impressive."

But it was amazing at the time.

Michael Abrash, a 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, drawing these 3D graphics on the screen. And it was actually really simple stuff. I was like, "Oh, I can do that." And so a bunch of us at Epic independently went off and started writing our own 3D graphics code to figure it out. And we found at one point we had a number of people dabbling in this, doing different parts of it.

And at that point, we decide, "Okay, 3D graphics and 3D gaming is going to completely change the world. We need to go all in on this." And so we took the best people from our best 2D game development teams and put them all together to make a 3D game. We didn't really know what we were doing at the time. 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. And it was a combination of a bunch of people who came together to make Unreal. I'd initially volunteered to make the 3D editor for the thing.

And James Schmott had made Epic Pinball. Epic Pinball. Now, that wasn't a crazy game. This was one of the 2D shareware games. He made it while he was in college and he was making like $30,000 a month from the royalties from this game because everybody had wanted an awesome pinball game. Massively successful. But he was a multidisciplinary person. He wrote the code for the game, the art for the game, and did basically everything. And the code was 30,000 lines of assembly language. 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.

It was like just a giant pile of assembly code. I was like, "Hmm, why don't I just write this myself?" And so James instead started going off and building 3D models and 3D animations using the tools at the time. And so Cliff had done a lot of design work and built the levels on Chaz Jackrabbit, went off and started learning basics of level design. And so I was writing this editor and Cliff Luzinski was customer number one for it, starting to go off and build levels. And James Schmott was building awesome creatures, sending them to me. I'd get them in, implement it in game. And then we brought in an animator to bring them into life.

And we brought in more and more people until at the peak of Unreal 1 development, we had about 20 people working on it, which was a huge team for the time. And it was really stretching Epic's finances nearly to the breaking point. We barely survived and almost ran out of money a number of times, but somehow we always pulled through. And it was a crazy project because it was three and a half years of development in a game that we always thought was six months from shipping. And it was like three and a half years of 70 or 80-hour weeks for most everybody working on the project, not even knowing what problems we'd need to solve next because we were so immersed in the current ones.

Unreal really pushed dynamic lighting much higher than anybody else had done before. I think colored dynamic lights with some shadow casting capabilities statically or moving lights without shadows. And 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. 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.

Yeah, it was really crazy. But I think most companies wouldn't have survived that, but the sheer talent of the people involved made it possible. And Epic has often done things that most companies would 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.

And so everybody was very new to this and didn't have any assumptions about how companies worked. 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. Nobody had management experience. Most people hadn't shipped a game before they worked with Epic. And we were figuring out as we went. But it was a constant iterative cycle. We'd make several new versions of the game every day. We'd new compile, introduce a new feature, or fix some bugs, get it to the artist, the artist improve their levels, continue building stuff.

And then we see what they're doing in their levels and like, "Ah, I see what you need now." We'd constantly be improving the tools. And just the iterative process and the speed at which that improves products is the critical element to success in games. The slower the iteration cycle, if you make a build every week and 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. And that was the magic that happened together. And there was really nothing but passion and everybody's individual dedication to it that made it work.

So I always needed to get sleep. But I didn't need anything else going on. So the programming itself was so energizing and thrilling. Yeah, so it was three and a half years of that during the project. Mostly spent programming. I'd say probably 60 hours a week of programming, five hours a week of coordinating with other people and iterating and sitting down with them and looking at what's going on on screen and figuring out what they needed. Maybe five hours of business stuff. And there's a good division of labor then.

Epic didn't have a big executive team, but it was like basically myself running the technical and development part of the company and Mark Rein running the business part of it, doing deals and maxing out his credit card and going around the world bringing in sources of revenue to keep the company funded.

And so almost the entirety of Unreal Engine development, about two and a half years of it, was all on C++, 32-bit, completely state of the art then. 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.

And so at that point, I realized actually spending money on getting good equipment was a good investment. And we're not talking about millions of dollars here or billions if you're building a GPU farm. We're just talking about buying some basic hardware. And so I bought the biggest CRT you could buy at the time because this was the CRT era. It was 24 inches. It weighed like 100 pounds. I had back pain for a week after I installed it, but it got me a 1920 by 1200 view.

And that was required for every pixel on the screen. And that was just enough performance to deliver that. But Dell came out with these new workstations and Intel had just launched the Pentium Pro, the first out-of-order processor. And so I basically bought the absolute maximum configuration that money can buy. It cost $7,000. I had a gigabyte of memory in 1996.

That's all written in very high-level C++ code. And maintainability is as much of a goal as performance because we had to build massive amounts of systems over time. But the one thing that was really a bottleneck was graphics. The cost of rendering a single pixel was really high. And so you had to do everything you possibly could to optimize the rendering of pixels on screen. And so we were talking about how many CPU cycles. When you say your CPU runs at a gigahertz or whatever, that's a billion instructions per second.

How many instructions do you need to run to get a pixel on screen? And so there was a constant challenge to optimize that down. And there was also a competition among all of the graphics programmers who'd often send emails bragging to each other about what new technique they've discovered to try to get the cost down. And Abrasha's original articles took like 12 CPU cycles to render a pixel. And everybody else had figured out how to get it down to six or sometimes even four cycles. And that involved lots of different trade-offs of caching and memory hierarchy and so on.

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. And that's largely lost now. When we talk about optimization and software now, it's largely about heuristics. And statistically, this memory access is likely to hit the cache. And this algorithm is faster than that algorithm. 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.

You can only manage the aggregate performance of code. And so there's kind of this lost art. 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.

And so when an object is up close to you, you want to render it with a lot more polygons than when it's far away. But one of the cool principles of mathematics is the Nyquist sampling theorem that says if you're trying to reconstruct a signal, there's a limit to the amount of data you need to bother capturing. 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. And that's called the Nyquist limit. 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, 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.

And with geometry, the idea is that if you render two triangles per pixel, you should get an image that is indistinguishable from thousands of triangles per pixel. If you render less than two triangles per pixel, you're going to start to see visible artifacts of the loss. And GPUs have this amazing hardware in a lot of different pipelines, but it's all very fixed function. There's pixel shader hardware, there's geometry processing hardware, and then there's triangle rasterization hardware. One of the limits of GPUs is that the triangle rasterizers are built for pretty large triangles.

If you're building a triangle or rendering a triangle with 10 pixels, that's pretty efficient. But if you're building or rendering a triangle with one pixel, it's very inefficient. 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 geometry intersection calculations done in a pixel shader. So instead of using the triangle pipeline, we're just using the pixel pipeline and getting a better result.

And everything else, including due to distance, can have less geometry and less texture, less information in it.

And then, you know, it just takes you back to that feeling I had with Wolfenstein, but like more. And you can completely lose yourself in that world and you would forget that this real world exists. What is the real world anyway? You know, so it's that coupling of great engineering and great storytelling in terms of just feeling is super cool. It's great to know. It's great to know that there's these teams behind it. 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. So Unreal Engine is this fascinating creation. It's a big, bold, crazy bet that you made. Maybe it's good to actually explain what Unreal Engine is for people sort of outside this world. I would say it transformed the gaming industry. But that was a big bet in 1995 that most of the effort would be on creating the gaming engine, not the game.

It's used by architects to preview buildings before they're made and industrial designers of all sorts. 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. And it supports a huge variety of styles, from Pixar-stylized movies to cell shading, to photorealism. And it can be used for anything that needs real-time 3D graphics.

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. 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 future video games. So how do you go about it? What are you thinking? And that, I should sort of linger on that. That is a crazy bet that we're going to build an engine as a company.

And as we began marketing the game, thinking it was six months away, we were constantly releasing screenshots and things like that. Other companies started calling us and saying they wanted to build 3D games too, but they didn't have the expertise for that and they wanted to license our 3D engine. And this was one of the coolest pivots in Epic's history. MicroProse called up Mark Rein, our vice president and longtime business guy, and said they wanted to license our engine. Mark Rein was like, "Well, what?

You want to license what? An engine? What engine?" And they explained to them what they wanted to license. He's like, "Oh, that engine. Yeah, yeah, that's very expensive." But this was one of the critical things that kept Epic going through that three and a half years. We were starting to license our engine out to other developers. MicroProse took two licenses and we got in half a million dollars from that. And company GT Interactive licensed our engine to build another game and we got paid for that. And so we had this revenue stream funding the development of Unreal Engine from other games that were being built by other developers.

And because they were the lifeline for the company, we took the engine business very seriously from the start. We set up mailing lists so that our partners could ask us questions. And all the developers and artists working on our games were participating and helping customers. Everybody took that very seriously because it was our funding source. 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. It's continued onward and just grown over time.

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. It sure would be easier if you could just start with a wall and subtract the door out. 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. And this is something that I'd been anticipating was possible for a long time, but when I finally got around to it, 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.

But in the course of 30 hours, I got constructive solid geometry up and running. I started doing a, like handed it to James Schmotz the next time we were together. And it's like, "Okay, I think you're cheating here." 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. He was like, "Whoa, I can't believe this." It's like, "Yeah, we figured it out." And that was cool to see for the first time.

It was probably the first time somebody had done constructive solid geometry in real time. But it was also a really useful artist tool that all the artists appreciated and immediately began making use of.

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. And you probably, like, using some crappy editor. I mean, there's just a lot of, like, friction here. So the 30-hour session is one that's probably rough. It's a rough one.

And I'd picked up on that. And Unreal Engine was using this technique for all of its graphics and rendering, but it was just additive geometry everywhere. And it had a lot of overlapping polygons and was pretty inefficient. So I had the idea that if we had a BSP tree, there was a really efficient way to do constructive solid geometry. And to do that, you had to break down the ways that different pieces of geometry can fit together. I broke it down into like 14 different cases. And most of them are pretty simple. I cranked them out. Anyways, I got towards the end, there were some pretty complicated things like, well, how do you deal with co-planar polygons that are in the same plane and pointing in the same direction versus the other direction?

In what cases should you keep them? In what cases should you eliminate them? And so on and so on to create really efficient geometry output. And, you know, just plowing through it eventually through mostly deduction, but some trial and error too, like sometimes you just have to try the possibilities and see what works. You know, I cranked it out and it worked. And the next day I came in like kind of weary and I was like, "Oh, wow, this actually did work. It wasn't just a dream."

We were at a six-cycle texture mapper and we couldn't afford 30 more cycles for lighting. And so the answer had to be some approximation. And the one that Carmack had picked up on in the Quake engine was light mapping. If we, instead of calculating all the lighting on every pixel, what if we made a big texture that we placed over all of the walls in the scene that was like wallpaper? 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?

And then if we, what if we just linear interpolate that over the course of it? You know, you get a lighting solution that actually works pretty well and is fast enough to work. And so a lot of Unreal Engine's lighting techniques were based on light mapping. We introduced colored lighting. As you could have colored light sources, 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. 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.

And like pulsing lights and blinking lights and everything else and created a system, I created a system for compositing them together. So if you had an arbitrary number of light sources, they could all do that.

It was like, someday computers will be fast enough for this, but not today. So I made a non-real-time version that pre-calculates all the lighting and realized, oh wait, if you pre-calculated the shadowing in an object, you can still apply the lighting dynamically as long as the light's not moving. So you could do torch flickering with shadows. And I figured out all the cases of dynamic and static lighting that were actually practical on a computer at the time and exposed them to artists. And this was the wonderful thing. I was just typing in these all features, exposing them to artists. And every day they'd find like a dropdown with some more lighting options available to them.

And they'd start using them and they'd do things that I never thought possible. And this was always the coolest thing. As a programmer building an engine, you might think you know the implications of the feature you're building, but artists are so clever that you always find that you've built the capability of doing vastly more than you ever anticipated as they start to use combinations of features together in concert to do ever more amazing things.

And you have a bunch of colored lights overlapping together in a space like that. The effect is just absolutely magical. Like being out on a foggy light with street lamps above. It's something that's surreal and just beautiful. So I was like, oh my God, they figured out how to do real-time volumetric fog. I have to figure it out myself. And so that was another like 30-hour coding session.

And so, well, you know, I'd studied that in mechanical engineering without even knowing it. That's the line integral. You have an integral over a line of some function. Well, this is exactly what it's for. It's for accumulating values of a function over a continuous space and time. And I did a bunch of math and realized that, oh wow, the integral, and then I looked in a reference book of all of the integrals and thankfully people had solved them all and realized the integral of this transformed one over R squared turns out to be solved by the arc tangent of R.

And so, you know, if you calculate some parameters based on the position of the eye and the position of the surface point you're ultimately seeing, then you calculate exactly how much fog you can accumulate from that. Of course, you can't do that per pixel because that's hundreds of cycles of CPU time. And so what we had to do is calculate volumetric fog on something equivalent to a light map, but calculating fog every square meter in the world. And so, you know, we had enough performance for that, built volumetric lighting and gave it to the artists and they started building magically detailed levels with volumetric fog in real time.

And then decades later, I was talking to one of the engineers who'd worked on that hardware and asked about their volumetric fog and told him how it inspired me to figure out how to do it in real time myself. He was like, oh no, we cheated. We just rendered it out of 3D Studio Max.

And I think that stands as a lesson for every programmer to pick up on. When something is really, really important, its performance is absolutely critical to the product or its quality or its capabilities. Just iterate on it until you've achieved perfection and don't settle for the first or second solution is good enough.

And there's all these kinds of optimization, like you mentioned. Maybe you can speak to that Unreal Engine 1 journey from 1 to 5.5 or 0.6 now, what for 30 years you've been creating virtual worlds. What's it like evolving a game engine for those 30 years when the hardware under you is improving exponentially? What are some things that changed and what are some universal truths that have not changed?

Just about every generation of Unreal, we've replaced most of the rendering code. And the different leaders in different points in times and the different luminaries have built systems that were absolutely rethought and optimized for the latest generation of hardware. Unreal Engine 1 was built for software rendering and then the Voodoo 1 came along late in the cycle and we had support for it, but it wasn't fully capable and utilized. Unreal Engine 2 was about bringing all the latest GPU hardware acceleration features to the engine and keeping forward and building some new features like vehicles and a few other capabilities.

And this was in the early GPU era before GPUs had really broken out of everybody's expectations of more as all. But that breakout occurred with DirectX 9 and the capabilities of programmable shaders. Once you had control of writing code running on the GPU that could color every pixel on the screen. And that GPU code was literally a factor of 100 times faster than the equivalent code I wrote a few years earlier on the Pentium 90. And so that DirectX 9 generation was a godsend.

And Andrew Scheidrcker, a longtime Epic Luminari, wrote the core of the Unreal Engine 3 render around real-time pixel shading, real-time lighting, being able to do dynamic shadows using several different techniques, and multi-thread the render to support bits of the early dual core CPUs that were starting to show up at the time. And it was a massive, massive graphical upgrade. Unreal Engine 4 made a number of improvements and just continued to add features to make more and more, give artists more and more options for lighting and for geometry that created realism.

But then I think probably our biggest single level of leap came with Unreal Engine 5 with the Nanite micro-polygon geometry solution and with Lumen, the global illumination lighting solution, which I think really bridged the gap from game-ish computer graphics to total observable photo realism for artists who wanted to create that. And so that's been the evolution and the progress on the graphics side is absolutely astonishing, as it is on the audio side in a number of other areas.

But parts of the engine also haven't changed all that much since the version I wrote and shipped in 1998. The file management system has been optimized a number of times, but it hasn't been completely rethought. And the networking system, the ways that clients and servers talk together and negotiate game state is still an evolution of the thing I wrote. And it's feeling kind of dated now. You still see networking bugs in Fortnite where for some reason when you're spectating, you're not seeing some parameters update.

Well, that's because of the lossful nature of that networking model. And the biggest limitation that's built up over time is the single-threaded nature of game simulation in Unreal Engine. We run a single-threaded simulation. If you have a 16-core CPU, we're using one core for game simulation and running with the complicated game logic because single-thread programming is orders of magnitude easier than multi-thread programming. And we didn't want to burden either ourselves or our partners or the community with the complications of multi-threading.

And over time, that becomes an increasing limitation. So we're really thinking about and working on the next generation of technology and being on your engine six. And that's the generation we're actually going to go and address a number of the really core limitations that have been with us over the history of Unreal Engine and get those on a better foundation that the modern world deserves given everything that's been learned in the field of computing in that timeframe.

But going from single-threaded to multi-threaded, oh boy, that's terrifying. And that's in part, we'll talk about it, why maybe you have to rethink even the programming language that's being used to rethink a lot of things. That's fascinating. Can we just stick on Unreal Engine 5? So I watched, I watched a bunch of stuff, but the state of Unreal in GGC 2024, I was just giggling with excitement watching some of this stuff.

So just if we can talk about different things here, just to nerd out a little bit. So people should go watch this video. They talked about the dirt. Just the ultra-realistic, and this is for Marvel 1943, which is kind of putting the Marvel universe into Nazi-occupied France in the winter. So there's snow. And that's a moment in history. That's a very intense moment in history.

And it really creates a feeling and puts you there. And there's so much to that, including the snow. But just looking at the dirt is a really nice way to show like how do you add a lot of details to a scene in real time that like gives this experience like infinite detail. Like this is real. This is super real.

And then I think in the talk, they describe like what's entailed in the generation of the geometry, what's entailed in the lighting, all that kind of stuff. Maybe can you speak about dirt? What are the components for people who might not know in like creating this ultra-realistic, the texture, the lighting, the geometry, all of that? Like how Nanite, how Lumen all come together in this beautiful orchestra to paint in real time the dirt in Nazi-occupied France in 1943.

One thing that's happening here that's really critical, oh yeah, now we're seeing it being turned off is the lighting happening. The Lumen lighting system that's powering the scene is doing different kinds of lighting calculations at different scales. This was the work of Daniel Wright following a decade of moving the state of the art of lighting forward. But his theory, which was rather controversial at the time, was that if you have enough levels of lighting calculation, then you can get everything, global illumination working everywhere from the absolute highest levels of a scene, that buildings are casting cracked shadows all the way down to details like you see on the dirt here, all working in concert and without distinguishable boundaries.

So there's a good decade of foundational work there to make the lighting work. And in particular, when you see the very detailed shadows interplaying between the ice and the dirt there, that's screen space lighting. There's actually shadow calculation going on, not based on the world, but on the pixels on the screen, because that is the only way that we could possibly do those calculations fast enough, running them in a pixel shader.

And the shadowing influences other things. There's also some really interesting things happening with the color here. And I'm not even sure what's causing, it looks like color is bleeding from some parts of the snow onto other parts of the snow. It looks like there's some subsurface scattering going on. I'm not even sure if that's being used in this scene. And then there's a material layering system for laying down layers of material, dirt and snow and other things, all making that work.

And then there's the light bouncing off of the geometry, which is another system for lighting on top of the global illumination system.

This is a lot of work from some highly skilled people, not only building out this particular scene, but in setting up the material layers so that you get the dirt with the ice layered on top and all the reflections working. And they end up making a number of technical art decisions to make this work. And if a novice who hadn't worked very hard built the kind of scene like this, it wouldn't look nearly as good. So one of the challenges we have is to make building this kind of quality level even easier and more seamless and automatic. You'd like to just build a scene and say, use this material here and have this appearance come out of it.

Like just to control how much snow is in the scene dynamically like that. That's cool.

And so you're seeing the lighting on the smoke being the really interesting thing. And there've been a lot of attempts, but this was the first demo where I felt like this kind of smoke had really no longer looked like a video game. It looked like just a burning trash can blowing out dark smoke. And it's the artist's sophistication. It's a very, very, very large part of it.

And that, I mean, that's immersion. That's like, I want to be in that. I want to sit around that trash can with the fire and the smoke and watch and maybe warm myself. Because I was also feeling cold because of the snow. You're like, you really get immersed into the thing. I mean, it's so beautiful. It's true art. It's true art. It's just really wonderfully done. But okay, so I got to ask you about the humans. We talked about what's it like to create the scenes, but creating realistic humans is really tough. Can you speak to that, how to create ultra-realistic humans?

So you have an actor behind this to convey emotion, show the nuances and the details of the faces. And maybe this is a good opportunity to also mention MetaHuman, creator that's part of Unreal Engine.

But it becomes by far the hardest problem. So the MetaHuman's effort is part of a decades-long initiative that Vlad Mastelovich, the most talented digital humans, visionary in the world, has been working on for generations and generations of games, serving individual clients around the game industry for a while and then joining Epic as part of the three-lateral team and leading now a worldwide effort to build all of the technologies required to make digital humans realistic. Okay, one part is capturing humans.

And so they've built really advanced dedicated hardware that puts a human in a capture sphere with dozens of cameras in them taking high resolution, high frame rate video of them as they go through a range of motions. And then capturing the human face is complicated because the nuanced detail of our faces and how all the muscles and sinews and fat work together to give us different expressions. So it's not only about the shape of a person's face, but it's also about the entire range of motion that they might go through. Capturing one human requires a few hours of capture work in a decade environment like that, then thousands of hours of processing work to capture a precise and real-time replicatable version of that human in the environment.

And so one of the things that's done is just capturing an actor or actress in the real world and then using them in a video game. But the much more interesting thing going on is capturing thousands of humans to form a data set whose goal is to encompass the entire range of faces in all of humanity. So going around every culture, every continent, every age, and every face variety and capturing representative people. So the entire range of faces is represented. And then being able to combine and merge those together to enable recreating an arbitrary face that the system's never seen before.

So one of the ideas is capture giant amounts of this high precision data and then you use it to reconstruct a face at a consumer level. Like maybe take an iPhone photo of somebody's face and then capture a very accurate depiction of that, not by synthesizing it then and there on that device, but by combining all the known details of human faces to accurately capture the most accurate representation of that. So that's the data problem. There's a lot of other problems of computer graphics. There's technology for rendering hair, which is really hard because you can't render every, again, we know the laws of physics.

It would be easy to just render every hair. It would just be a billion times too slow. So you need approximations that capture the net effect of hair on rendering and on pixels without calculating every single interaction of every light with every strand of hair. That's one part of it. There's detailed features for different parts of faces. There's subsurface scattering because we think of humans as opaque, but really our skin is, light travels through it. It's not completely opaque. And the way in which light travels through skin has a huge impact on our appearance.

And so like you have to compute both that, the reflection, how light interacts with the oiliness of the skin and how it is also absorbed in it. And all of that while considering all the muscles involved in making the nuanced expression, just the subtle squinting of the eyes or the subtle formation of a smile. It's a stupid annoying subtlety of human faces that you have to capture. Like the difference between a real smile and a fake smile. Man, I love human faces. I love humans in general.

But the way to show like beginning of a formation of a smile that actually reveals a deep sadness. All of that, like when I watch a human face, I can like read that. I could see that. Again, this is the engineering and the artist. You have to have the tools that in real time can render something like that. And that's incredibly difficult. Anyway, sorry. So yeah, so there's a lot of this kind of complexity in even just the lighting of a face.

Your brain doesn't really care that much. But if anything wrong with the human, it's totally jarring.

And then there's MetaHuman Animator, a tool for animating a human based on a facial capture, which can be done on a device as simple as like an iPhone and transfers the captured animation to the human you want, which is not straightforward. If the actor has one face shape and the character on screen has another face shape, the translation that needs to be done from the actor to the face is actually really sophisticated and non-obvious. And if you just applied it literally, then it would be completely wrong from your point of view. So those are the main tools that people are using now.

And then when it's in the Unreal Engine, then you have a face and you can do absolutely anything you want to it. And you could also, if you decide to go outside of the MetaHuman geometry pipeline, you could build your own face, like any creature of any sort, and then use the animation tools to animate it. But yeah, this is 30 years into a project that's probably like 50 years in total to get to absolute photorealism and controllability for absolutely everything. So there's vast amounts of work still to do. And we don't feel like we've solved the problem at all. We've just given artists a big productivity multiplier and a quality multiplier, but this is not in a state that we would say is done.

When a light hits a red wall, then most of the blue and green light is absorbed, but the red light reflects off and now is hitting other things. And so if you have a red wall with a white floor, light is bouncing off of the red wall into the floor. Now the floor is being turned red. And so the entire bouncing of light around the scene through multiple bounces is the critical challenge to solve here. And again, laws of physics are known. And so the complete solution to this, it was written down in the 1950s, I think.

The real magic here in Lumen is the system that Daniel Wright developed over the course of many years based on ideas formed over a longer period of time to calculate the way lighting bounces around at different scales, ranging from the scale of miles or kilometers down to the scale of pixels and millimeters. And to not only calculate at each level, but integrate it seamlessly at each level to give the appearance of completely seamless and accurate lighting. And previous techniques were highly specialized and artists had to make a decision for each light about exactly what it did.

The goal and a lot of the practice with Nanite now is you build a scene, you place lights in it and it just works to make it that much easier.

So you can add that to the resume. So that's huge. An Oscar-winning film made with Unreal Engine. So what do you see as the future of the use of Unreal Engine in creating stories in the film industry?

And that's a massive improvement in quality. You can recognize the old green screen movies because the lighting on the characters is just wrong. And as much as they try to fix it up, it never really works. When you're filming in front of an LED panel with LED light emitters in front of you as well, the actor not only picks up all of the lighting from the actual natural scene that they're supposed to appear in in the movie, but they also can look around and see it and they're aware of exactly what set they're acting in. And just the overall end result is that much higher. It's as much because the actors are able to do their jobs better seeing the scene they're in because the technology is enabling a better lighting calculation and a better interplay of virtual light and real-world light to make the end result awesome.

Whereas game engines have that exactly where they need to be. And so I think what we're going to see in the space of world-class high-quality productions isn't just everybody moves to AI and a large part of the human creatives contributing to that are obsolete. I think what we're going to see is AI becoming a multiplying force on the power of human creatives, making them able to create better stuff more quickly and with higher quality end results. I think unlike the fields of generative 2D art and generative text, I think the future of AI is much more complex and nuanced.

And I think your interview with Mark Zuckerberg conducted in VR was a really good first example of this. So you did this VR discussion. It was capturing your faces and then rendering a completely 3D computer graphics model of your faces. And then the end result was patched up by an AI image enhancer that was able to add an awful lot of the missing subtleties that are lost by normal computer graphics rendering. And that's a first step. You can imagine the output of Unreal Engine being enhanced by an AI pixel shading post-processor is one thing.

You can imagine creation of objects being enhanced, especially mashing up high-quality objects that have already been created. Like Epic's Quixel team went around the world and scanned tens of thousands of real-world objects at extremely high levels of quality. They have everything from rocks to trees to archaeological finds and so on, all captured there. And we have an awesome library of them on the Fab content site. What's missing is the ability to create arbitrary amounts of new content. And I think using data like that and AI to create completely new trees that meet your specification from all the knowledge that is built up of high-quality scan trees is going to be a really valuable thing.

But I don't see this reducing the need for people or the role of people. Rather, I think it actually is probably an enhancer on that. I can't help but think when I go on Amazon and Netflix to watch a movie, there's an awful lot of linear content and most of it isn't very good because of the limitations of the media and the budgets and of other things. If we can use AI as an enhancer on that, then everybody's going to have even more opportunity than they have now. And every single technological revolution that has changed the way that people work, but it's ultimately created more opportunity for people.

And there are pundits predicting that this might be the last. I think just the opposite. I'm an optimist on this and an optimist that it's going to create opportunity for everyone.

Some are like texture maps, some are sound files, some are animation files, and enormous amounts of detail all stored there in that procedural. And this precise computer graphics representation that enables rendering it from any perspective with any settings and so on. It's a completely general system that has complete context about the state of the world at any point. And so you can always precisely reproduce it. If you play the same scene 10 times in a row, it's always the same. It's never randomly changing. You're like, oh no, why did this character's face change midstream?

But it's also rather limited because you have to build everything manually. And that's costly and it's time-consuming and it requires expertise. And then you have this other model of the world, which is what AI sees or thinks. If we could peer into what's really happening and its parameters, there's something like the mushy connections of neurons in a brain. It has a vast amount of knowledge about the world and about graphics and about images and about people and about everything else. It's stored in a human incomprehensible form, but it can be extracted through queries, like asking it to produce an image from a prompt or a video from a prompt or whatever.

But the huge problem with that is it's very mushy data. We don't know how to give it a command that will give us a precise result. And if it produces one image one time and we change our prompt slightly, it might produce something completely different. We are unable to art direct it. And so it's this completely untamed tool. And I think when we figure out more and more ways to merge these and connect these two together, you can imagine AI enhancing the process of content creation in a traditional scene representation.

You can imagine the scene representation being shared with the AI. So the AI not only sees a prompt, but also, here's a list of all the objects in the world and their characteristics and so on. It can learn more about how those objects should move and interact. And so if you get a constant feedback cycle going back and forth between an engine and AI, then I think you can get the best of both worlds, stable scenes, but also the higher productivity of being able to get content out and the ability to select specific parts of it and art direct those and to have those art directions stick and be recognized as part of this permanent scene representation.

Are there words of hope that you could offer them?

There are similar questions about, is computer art built in Photoshop really art, or is it just goofy computer stuff? And I think nowadays digital artists have gained respect. I think if you look at just the tools that have existed in Photoshop, some of them are pretty sophisticated. And nowadays they have AI features. But I think AI is ultimately going to be another tool in the artist's tool set. And I think it's going to become a more powerful, directable, and human-serving tool in the future. And I think a lot of the alienation comes from the prompt either being immensely powerful, giving you an entire creation, but then being completely unwilling to let you control the nuances of it.

That feels alienating. You give it an image, but you're like, replace the image of, replace this part of it with this thing, or make that object green. And it just, it can't do it. Often it can't be convinced with any number of words in the prompt. And that makes it feel like the computer is taking control away from us, humans and artists, and is refusing to do what we want and has its own opinions. It feels like a competitor. I think when we have much, much, much more nuanced control of it and artists can go in and just see, let's enhance this object, do this, do that, do that, it'll feel like some of the tools that exist in Photoshop, which are in some ways compared to a paintbrush or superpowers already, AI will come to feel like that too.

And we'll increasingly serve creators creating and enhancing a work in a way that feels just a natural extension of their own bodies and minds.

So I think if you just keep being open to using the tools, constantly trying the cutting-edge tools, how they can make you more productive, how can they empower you as a creator, as an artist, or as an engineer, I think you're going to just keep winning.

And it's always been this way. And I think that there's also a lot of overhype in AI. AI is really great at spewing out code that does something that a million GitHub repositories already do because it's kind of learned the underlying pattern. It's notoriously hard to get to do something new that hasn't been done before, especially when it's a complex task. And the bigger amount of code you ask AI for, the more it leaves you with just a massive code that sort of works, right? And that's the problem with code. Like 99% works, but the 1%. It might be harder to get to 100% with AI than with hand coding.

And everybody who's looking at this topic should actually try using the coding assistants on hard problems and see how they do there.

They're actually hard problems in themselves and not just connecting other widgets.

How far away from that are we to simulate this ultra-realistic, immersive, fun reality that Earth is? What does it take?

And I think that's going to be the primary challenge of graphics development and simulation development over the coming decade.

You might have a very, very compelling human simulation going on in the next five years even. I'm not saying it's a good idea, but I think the arc of the technology is inextricably heading in that way and it's heading at a shocking, shocking rate.

I work with this amazing company called ElevenLabs that does text-to-speech well. There's companies that specialize in bringing text to life, right? That's going to increase different companies do that very well. And then all of a sudden you have this synthetically created scene where a human is speaking and you're moved to the point of tears because of the scene. Beautifully lit face in the full darkness, the emotion, the drama of the scene. Yeah, I think, so you're saying five, ten years, maybe twenty.

I don't know, the question of are we living in a simulation ourselves always boils down to, well, if we are living in a simulation, what are they living in? Because at some point there has to be some base reality. Or one of the philosophical theories that was put forth seriously was that there is no physical reality. If you have a system of equations, such as the laws of physics, then all possible evolutions of dynamical systems under those equations kind of have a physical reality. So we just are kind of a manifestation of laws of math rather than needing an actual universe around us.

I don't know, I like dabbling in that philosophy. And as we get CAI becoming smarter and smarter and we get closer and closer to really capturing the full laws of physics, these questions become quite a lot more compelling.

Maybe that is the thing. Maybe that's a thread that connects to the explanation of the mechanism, as you said, of the universe that's really important to understand and we're completely clueless about that mechanism. I mean, a lot of the religious texts sneak up on what that mechanism is, but we're still mostly clueless. We only have these like leaps of faith and believing what that mechanism might be.

You can't publish results on those topics in a respected physics journal. So I think it's kind of been set aside. But it's interesting to note that the laws of quantum mechanics themselves have a place for God or souls or whatever external source of input you might want to attach to such a thing. And that there's this idea of quantum waves function collapse that when we look at a quantum system evolving and perfect superposition of many possibilities and you go to observe it, you actually just see a specific possibility.

In the multi-slit experiment, the light ultimately ends up being observed going through one slit or the other. And that's a place where there's this random number being injected into everything around us. Trillions of trillions of trillions of times per second in everything we're observing. And if you want to attach some external input, well, there's a place.

To me, as we talked about creating ultra-realistic humans, eventually that means creating humans that can suffer, that can fall in love and experience heartbreak and loss, that can fear death. And the more you simulate that to the full reality of the human condition, the more you get to this place where you have a simulated humans that is able to suffer. And I think legally speaking, I think you have to get to a place where that's not allowed.

Like there is a line you can't cross. And that's a hard thing for humans to deal with. That's going to be some interesting Supreme Court cases. Once you create a human sufficiently realistic to where they can suffer, means that human could be tortured and do terrible things to that human that's artificial, quote unquote, but boy, that still feels wrong.

I don't know what that is, but you feel wrong to torture a simulated human. Now, when you play a video game and it's a shooter and everybody's having fun, that doesn't feel wrong. But there's a line. And that's going to be a fascinating line for the Supreme Court to explore. Oh man, what an exciting future we're living in, huh?

It really took on a new nature, which was not just like a multiplayer game with heritage from Doom, but also a true social experience between you and your friends. And Fortnite Battle Royale is just one manifestation of that. Another one is like Rec Room VR, where you're standing around in VR with friends playing billiards or shooting hoops and are doing other light entertainment things. I think every game that has a huge number of players who play together socially as part of their entertainment lives, I think, is really getting at the core essence of the aspiration for the metaverse.

And we're still in the very early days of it. I was on the internet in like 1992 or so, and it was a pretty bare-bones thing. I think when we look back at the state of gaming today, we'll realize that there's a lot further to go to get to the ultimate version of it. But I think it's all on track. And I think it was the time we released Fortnite Battle Royale and started playing together, all the people at Epic and squads and experiencing that world, that we realized that this trend was afoot and that we needed to do everything we could to bring in other creators so that anybody could pile on to the work we were doing by creating their own worlds through Fortnite Creative and UEFN and creating more games and more genres that people could play and ever expanding the repertoire of fun.

So you can actually build something pretty interesting in a week. And one of the teams built the very first version of what became Fortnite. The very first version of it had a different art style, but it had the idea at the core that you're going to build forts by day using this building system. Then night would come and you'd defend the forts against zombies. And the longer you could go, the more elaborate forts you could build and the more survival waves you could withstand, and it would get cooler and cooler with time.

That was the goal. So a few of the artists got through and defined a new art style and we moved to it. And at different points, it evolved towards being kind of like a light MMO like Destiny with rather complex RPG and stat systems. And that evolved into kind of an MMO-like tower defense game, MMO only in that persistence of items and stats, which became Fortnite Save the World mode, which we launched in early 2017, and it was a moderate success. It paid its budget and we'd come out ahead.

And then at the same time, the Battle Royale genre was booming. PUBG had just come out. Tons of people at Epic were playing that. They were like, "Oh, this would be so cool if it had Fortnite building." And so we assembled a team in a war room, like 30 people in one big room. And they worked insanely hard for four weeks to build Battle Royale. So the nice thing is all the content for Fortnite had been built over the previous seven years. They had a huge library of content, but no gameplay of the type they wanted. So they had to build it all in that four weeks and ship it. And that put Epic on an exponential growth curve where we went from 300 employees to thousands of employees and went from about $100 million in revenue to billions of dollars in revenue and kind of became the center of the gaming world at the time.

Is there something you could say to sort of like how difficult that is to pull off?

Thank God for Amazon Web Services and cloud hosting because Epic went to 15 million concurrent users without buying any server hardware. We were able to just call up Amazon and say, "We need more." And there was a period of time there where Fortnite was undergoing this exponential growth and we'd find like one week we ran out of servers in Brazil during a heavy weekend of play. And next week, we had an even heavier weekend of play and there were servers to handle it. Like somebody at Amazon had dropshipped millions of dollars of server hardware into Brazil and turned it on just in time for Fortnite to need it.

And there are a lot of unsung heroes in that story, many of whom we've never heard of.

And we went through some painful layoffs at that time. And then we stabilized and now we're spending several hundred million dollars a year more than we're making, which we can very well afford to do because we have billions of dollars in the bank, thanks to a combination of the profits we made when we were a very small company with a very big game. And because of the investment we've raised, we're not an oil well pumping oil out of the ground at where we discovered oil. We are growing to be a future technology powerhouse. And we think the 3D space and the future real-time 3D simulations is going to be one of the major facets of technology for humanity.

And we're all in investing in that.

So you have to remake all of your friends and then find different things to play. And now the controls are different. So you have to relearn how the joystick, mouse, keyboard controller works in that experience. And you have to go from place to place and you buy some stuff in Fortnite and it's really cool and you can use it anywhere in Fortnite. And then you go in Roblox and you don't have that stuff. You have to buy different stuff. And that stuff only works in Roblox. And same with Call of Duty. It's another isolated place. And same with World of Warcraft and same with League of Legends. And every place you go is its own unique place, different friends, different account names, different people.

And there's no social cohesion between them at all. And a long time ago, consoles set out to solve this problem by creating their console-wide friend system and account. So your friend on PlayStation in one game is your friends on PlayStation in another game, but only on PlayStation. If you're on Xbox, you can't see PlayStation friends. And so you have two basically orthogonal and cross-cutting divisions of the world into fiefdoms, which were not created with bad intentions, but arose and are separated, isolated islands.

One is the platforms and their social services, Xbox, PlayStation, Nintendo, Steam, Epic, if you add it to the list. And the other is these different games people play. And because of this weird historical artifact, we're left in a world where people can't seamlessly move from games to games bringing their friends and their stuff. So the solution to this is to federate and connect all of the systems together. All of the players on all the different platforms can be recognized by their name and put the @ sign in it.

So your Xbox names and your Fortnite or Epic names and your Steam names can all live together and interoperate together in a single space. So unifying the social ecosystems is one thing that needs to happen. The next and bigger challenge is to unify the economies too. Now, I'm not talking about like a sword you have in World of Warcraft should work in Fortnite. Every game is going to have its own gameplay rules. And a lot of games are going to have stuff that only works in them. But there's a huge set of games that have in common the idea of a cosmetic system that does not affect gameplay outcomes, but is purely cool looks and cool appearances.

And when you find a physical car in the world of Fortnite, if you're the first person to get into it in that session, boom, it takes on your chosen car cosmetic. And now you have a cool car that's identifiable as yours. We realized early on with Fortnite that the key to making Fortnite work as a creator economy was to open up the revenue from the item shop to all of those sources of engagement, right? There are two big things happening in Fortnite that make it work as a product and as a business. One is the game modes, Fortnite, Battle Royale, and all of the user modes and everything else are sources of engagement.

People play there because it's super fun. And because they're playing there, they're willing to buy cool stuff to make their character look cooler. And so you have all these sources of engagement, but the sources of engagement don't make money directly. You can't spend money in Fortnite, Battle Royale to buy a game item. Like everything's, the gameplay is not pay to win and it's all just a game. So we make money from the item shop. And the item shop only exists because of the sources of engagement. If you weren't playing Battle Royale, trust me, nobody would want to buy a Fortnite outfit.

If you weren't playing any Fortnite games, why would you buy Fortnite outfits? And so you have all the revenue in this item shop economy and all the engagement in this engagement economy. And the thing that magically makes the Fortnite creator economy work is revenue sharing, item shop spending according to sources of engagement by engagement. If you buy an item and you've played 40% of your time in Battle Royale and 60% of your time in these user modes, the money you spent, the portion of that that's profit can be separated out and paid out to all the different creators who participate in that economy.

And that's why Fortnite scaled up to a $400 million creator economy so far and is growing.

And revenue is shared between ecosystems as well.

And even like the other outfit, I have two outfits, this and then a black T-shirt and jeans. And it feels good to wear that. It feels like me when I look in the mirror, okay, I know that guy. And to be able to have that outfit go from game to game to game, maybe across the years, that would be wonderful. I wonder if you could just even comment, could there also be another standardization about the value sort of for more complicated items?

So take a sword from Diablo and transfer it to a gun in Fortnite, but based on the value, some generic concept of money. So the value of a thing in one game versus the value of a thing in another game where you're almost operating in the space of value versus the actual items. Or is that already getting too general?

And a lot of games have that characteristic. One funny anomaly stood out. There was this game that was one of the big breakthroughs in Fortnite, Only Up, it's a game where you're just climbing up and up by following paths of stacks of objects and things. It was just stupid fun. Everybody loved. We found people weren't spending a lot of money on outfits when they were playing Only Up. And it's kind of intuitive, actually. Like you're not seeing other players. Like if you see anything, like you're seeing their butt as you're like trying to catch up to them jumping from object to object and they're above you.

And so, you know, it wasn't a mode that showed off outfits very much, but you can determine the economic correlation between a game mode and spending.

For some, it will probably be better and for some, it will probably be worse. But certainly, there's not any set of Battle Royale players flocking to VR. And the other thing is NFT is, it's like trying to equate digital or cryptocurrency to the metaverse. It's like, well, it's just a way of denoting money or value exchange. You can do that with money or you can do it with NFTs or whatever, but there's nothing about this future digital economy that fundamentally requires cryptocurrency or whatever.

What you need is interoperability. Interoperability can happen through a blockchain. It can happen through a database. It can happen through standards bodies with defining standards and protocols. And we've been doing it for hundreds of years since the railroads were standardized. And it's not something that totally requires a novel technological solution.

That's, I mean, it sounds ridiculous to say, but it's true. That's valuable. That's like, you have like gold in the physical space. We know that holds value. How your outfit looks like in Fortnite, that, as you're saying, provably holds value. And so you want to connect like a standard definition of money value to that and not let it become this hype thing, which NFTs that you mentioned are just become that.

It quickly drifts away into the land of people trying to buy and sell and trying to make money versus like staying close to the thing that people actually value. Forget the money. It's more about exchanging valuable experiences or things of value. So you can play Fortnite and then go to another video game and continue the valuable experience and then come back to Fortnite and do that kind of thing. So you're saying there might be a way to do that and to basically create standards the way the web has different standards for displaying websites and all this kind of stuff or the communication that's required on the networking side.

So all the different standards that make the web work, there need to be those kinds of standards. Like what would those standards look like to enable the metaverse?

Large parts of this work across Unreal Engine and Unity and Blender and all of these 3D packages of different sorts. Then there's the GLTF texture format, which stores textures and geometry and other low-level data for 3D objects. When you see a Fortnite character, that file format together with the image file formats can store their static appearance, the shape of their body, even their animations and their different poses and the appearance of them. Different standard file formats could store all the sounds they make and their emotes, but we're still missing a bunch of pieces.

The biggest missing piece is a programming language that's at the center of standardizing the metaverse. Now, if you look at the web, the web is a combination of a bunch of different technologies. The two biggest ones are HTML, which describes the 2D scene graph or the 2D layout of controls and objects on the webpage. But that's just static data. It's just a non-moving, non-animating webpage. And then you have the JavaScript programming language, which is used to manipulate that, to display things to the user and to implement anything you could implement in code.

So it's a little programming language that runs in your web browser. And the metaverse needs something that performs that similar role. But the metaverse and 3D gaming in general needs something that's rather more powerful, more safe, more scalable, and more capable than JavaScript. Because the metaverse is actually a more difficult technical problem than a webpage. A webpage like an app is just a single bundle of code and content that somebody, a company, has prepared.

And they release it and it stays exactly what it is until they release a new version and it's upgraded from version to version as it goes. But the metaverse needs to be a composite of code and content built by millions of different people that could potentially form a seamless world together.

We see new genres of games that emerge that weren't possible before. And Doom ushered in the era of Deathmatch, the first time 3D multiplayer game was even possible at all. The early Battle Royale games starting about 10 years or 15 years ago only became possible back then. You couldn't have built one 20 years ago because you just couldn't have rendered an environment that's as large as a VR game with that many players, with that level of interaction and performance. It was just not possible to run it.

So you got a certain level of technical capabilities and a genre came out that proved to be by far the best shooter genre ever invented. But I think there are numerous, numerous more genres, some of which are better than any of the existing ones that will be invented as we get more and more capabilities. Some of the capabilities we're lacking now are the ability to build environments and game simulations that span more than work than a single company can possibly create. And you see kind of the birth of that idea in Fortnite and Roblox where there are tens of thousands of creators each building content and users are playing meaningful amounts of it all.

And so there's an ecosystem that's scaled larger than company, but it's still very much you go into one island and you play that creator's work. The other direction of scalability is putting more and more of people's work together in a seamless continuous play space for games where that makes sense. You can imagine a game taking place in an environment that's the size of a continent or Earth in which you can go from place to place and then see different areas which are maintained by different people. As you go into different spaces, the game rules are customized according to that and you can go from experience to experience.

And instead of having just one company's authorship ever present wherever you are, you'd see you'd be driving a car built by one person, carrying weapons built by 20 other people, and taking place in a simulation in an environment that's built by thousands of other people working for separate companies or their own entrepreneurs or indies or enthusiasts all working together simultaneously. And we totally lack the programming foundations for that. The kinds of code you would need to write now to make that happen are just not practical.

And so we're investing massively in building new programming language technologies around Verse and our proposed standards for future metaverse programming that we hope will solve those kinds of problems and make that kind of world possible.

So if you could speak to some of the technology that can enable that, you mentioned the Verse programming language. First of all, also, how legit is it for you, CEO of Epic Games, to be a co-author? The programming language theorists are losing their mind. So co-author on a paper that's describing some of the sort of nuanced details of a programming language. So maybe you could speak to this programming language called Verse. It's a functional logic language.

What are some cool features of Verse?

It might be that 1,000 player version of Battle Royale would be worse, but I bet there are 1,000, million, and tens of million player experiences that are even better than that that will yet to be discovered. And so.

And then the real knowledge comes as you learn ways to combine them to achieve bigger and bigger programs. And so there's a long history to the field of programming languages, but in the 1950s, the first programming language designers got together and built the first standardized language called Algol. And there was this meeting in 1956. Very few people even know about it, but it's where all the major foundations of modern programming languages were decided on that the C family of languages inherited. And so we're very much living in a world that was defined by them.

And thankfully, they got a whole lot of things right. They defined how functions should work, how variables should work, and how recursion should work. And thank God they got those things right, but they got a few things wrong. And Verse is trying to fix those. And that's the functional logic part of it. The interesting thing about functional logic languages is that in an old-school language, an expression produces a value. In a functional logic language, an expression can produce zero, one, or multiple values. If it produces zero values, we might say it fails.

If it produces one value, we say it succeeds. If it produces multiple values, that's kind of providing a set of values you could iterate over. And so there are a bunch of features in today's programming languages that were defined in an ad hoc way without really thinking this through, this zero, one, or many values way. And that's the problem that functional logic languages address. The most basic example is an if statement in a programming language. If some condition holds, then do this thing. Otherwise, do that thing. And in the language today, this is done with variables of type Boolean or expressions that produce Booleans.

We have Boolean variables that are either true or false. We have expressions that evaluate to Booleans. And so you can express a condition as a bunch of these features together, but you've lost any computation you've done in doing that Boolean expression evaluation. So in a functional logic language, your condition wouldn't do that. It would either succeed and produce a value, or it would fail. If it succeeds, it goes to the then branch. Your operation succeeded. Now you're running this one batch of code. And if your expression failed, then you go to the else branch.

But the exciting thing about that is your expression that succeeds or fails can produce values and bind variables that are then accessed by the then branch. So you can write a conditional where you can only get to the inside of the condition to then if a bunch of variables have successfully been bound to variables. So it lets you test if some conditions hold and then use the results of those tests. And that gives you a much higher level of reliability. And then a for loop in a traditional language, it's just a bunch of imperative code that's woven together to produce a bunch of values iteratively.

It's rather awkward to do complicated things in for loops, and so you often end up with these ever more complicated constructs built to work around that, like iterators and other things. The idea of functional logic languages is your for loop can just produce multiple values. And if it produces zero values, you go through zero iterations, and it produces a bunch of values. You go through all those as your iterations. Rather than having a bunch of nested loops, you can write arbitrary things that look like SQL queries in a condition or in a for loop that bind a bunch of variables, do a bunch of tests, produce a bunch of a series of results and in some order that you're iterating over, and then you can handle all of them and produce a result.

So you kind of gain the power of SQL queries, large complex queries over data structures in a language that is much simpler in which your code is just performing simple iterative operations. And so it kind of gives you the best of databases and of regular programming in a much more uniform way. And the power of this is now users can write functions that not only produce a value, you can write functions that might fail. And so you can write a function that answers a question. The answer can be either yes and my value is this or no.

And you can combine these together into arbitrary queries. And if you like, the funny thing is that this is not how C++ works. And so when we have Epic programmers moving over from C++ and writing their first Verse code, they try to write C++ code in Verse style, and it actually ends up being kind of convoluted code that's worse than good C++ or good Verse. When we see, but after a few months, they get up to speed and they're writing really awesome code that's tighter and more compact than before. And with users who've never programmed before but are learning programming for the first time in the context of Fortnite, it's really fascinating.

You see, these users are learning this kind of as it becomes their intuition. They just assume programming works this way, and they're writing way more advanced and interesting for loops and conditions than we're often writing internally because they've kind of grasped the core concepts.

So being able to prove the correctness of a code is basically easier to write bug-free code. Can you just speak to that and the importance of that when you're building the metaverse?

And that's essentially a type checking problem, checking that your new interface is backwards compatible with your old one. And that comes down to the type system of the language. There's been a lot of very interesting research on type systems over the years, most of which hasn't ever made it into the C++ programming language, unfortunately. But you see several branches of that whole field. One of the really interesting things that Java and C# did in the early days, and then later abandoned and didn't bother update, was defining a very rigorous set of rules for if you publish a module with one set of types today, then what changes can you make to that module for your future updates to it that don't break backwards compatibility?

And that's a problem for type checking. Like say you have a function that promises to return some integer. Well, in the future, you could say that returns some natural number because every natural number is an integer. So that's a backwards compatible change. But you can't say it returns a rational number because some rational numbers are not integers. So the system ought to reject that kind of change. But the much, much, much more interesting thing about type checking was the realization it was actually made in the 1930s that if you design a programming language type system in a very particular way, then it becomes not only useful for expressing types of variables.

The traditional thing every type system does is say like variable X is of type integer. But if you design a type system in a certain way, then your types can express theorems, like mathematical theorems. The Pythagorean theorem is a cool one. But one theorem you might have in a program is like the theorem that this function takes an array of integers and returns an array of the same integers, but the result is sorted. If you express that as a theorem and you follow this system of type theory, then you can actually require that anybody who writes that sorting function to prove that it has actually sorted its result.

And so you have types or theorems, and values constructed a certain way can be proofs of those theorems. And nowadays in mathematical literature, you see more and more theorems are being proven mechanically. Mathematicians are proving theorems in a way that is verified by computer to be a correct proof. In the old days of math, people would write down like language. If you look at all of Euclid's theorems, it was just language. It was just writing in ancient Greek to say the steps of the proof to convince the reader that the thing is true.

Starting in the 1930s, mathematicians moved towards rigorous formal proofs in which there's a series of steps that can be mechanically verified. They're proving things. And when mathematicians say they've done a computer proof of a theorem, what they really mean is they've written the program in a proof language like Lean is a theorem prover, CoQ is a theorem prover, and there are several others. It means they've written a mechanical proof in that language that a computer is checked so that it's impossible to lie. If you say that you've proven a thing and the computer verifies it, then it's definitely true.

And this is a feature of mathematical proof languages, but it's also a way that an idea that's making its way into programming languages gradually over time. And our aim for Verse is to be the first mainstream programming language that fully adopts that approach and that technique. And not only adopts it, but it adopts it in a way that's really user-friendly so you don't have to do that. And the idea of this is that you want gradually more information to be incorporated in the types of variables. The property you want of a programming language is that if your compiler accepts your program and doesn't beep and tell you there is an error, then your program should work.

Now, there are all kinds of ways humans can make mistakes there. So that we'll never achieve that ideal. But we can get closer and closer to it by having more and more language features that enable the compiler to catch more human coding errors and tell the user what went wrong. And that becomes extremely important in the metaverse. The cost of fixing a bug that's made it through to runtime and is in users' hands, the cost of fixing a bug in a shipping program is hundreds of times higher than fixing a bug that you've just observed as you're running your code yourself.

When it's running on your computer, you just fix a line of code and your bug's fixed. When you have to fix it live, you have to release a patch. You have to release patch notes. You have to test the patch. You have to check for all the other bugs that might have been introduced. And everything becomes vastly, vastly more expensive. So the real aim of the Verse program and approach is to catch all of these errors at compile time and make the metaverse a very reliable place.

But we shouldn't see this as scary. Everybody working in a typed language like C or C# or Java is proving theorems all the time. If you have a variable of type integer and you assign some value to it, you've proven to the compiler that that value was an integer because otherwise it would have rejected it. And so as we add more and more advanced proofs, we'll get compositional properties flying out of our systems that are easy to use and people prefer to use. And we might think in the future where we have AI helping us write certain kinds of code, the big problem with AI is you ask it to do something and ask you to write a fragment of code that does something.

It might give you a perfectly valid fragment of code that compiles but does the wrong thing. And if we had languages where you could say, write a function that sorts this array and prove that it did that, it could actually write the proof. And if the compiler didn't beep with it, you could trust that it was actually sorting the array. And otherwise, you could go back to the AI and say, well, that didn't work. But getting to the point where we know that our programs do what we say they're going to do or think they're going to do is a very important thing.

Like five is a proof that integers exist. So when you have something like var x int and you say x equals five, well, you're proving to the compiler that five is an integer. That comes as secondhand nature, but you can prove more advanced things. If you want to prove that a pair of things are true, that like theorem A is true and theorem B is true, then you need to provide a pair of values, one that proves theorem A and one that proves theorem B. And that's the conjunctive law of proofs. And there's a disjunctive law too. And then there's an implication law for proofs.

And it turns out that that's really satisfied by functions. When you write a function of programming language, you're saying, if you give me this thing, I will give you that thing. If you give me a parameter of type something, then I'll give you a result of some other type. And if you write that by writing that function, you're proving that given one of these things, you can produce another thing. And that's a proof of an implication. With only like seven laws, you can construct all of mathematical logic in a type system. And one of the important things for programming languages that hasn't been given enough attention is some aspects of programming languages are just subjective.

They're just machinations of the programming language designer. Guido van Rossum decided that Python should support indentation a certain way. And as long as you're dealing with things like human notation and naming of things, there's always going to be that subjective layer. But there are other parts of programming languages that are not subjective but should be fundamental. And when you look at type systems, there is a way to do type systems that gives you mathematical proofs. And every other way of type systems that doesn't give you mathematical proofs is just worse and should ultimately be rejected.

And so I think one of the jobs of computing is to identify what have we actually done right in the past and what have we done wrong. And for everything we've done wrong, actually going back and fixing it. Otherwise, we just keep accumulating so much craft that our systems eventually are crushed under their own complexity. And there have been massive announcements of horrible vulnerabilities in software and services over the past year. It turns out like some nation-state backdoored a bunch of telcos surveillance systems for wiretaps.

Like huge problem there. But ultimately, when you break it down, it's probably because of some buffer overrun in some C program. Like these decisions about programming languages have long-term implications.

We didn't really quite talk about performance. Maybe I could ask you about that in a second. Complete so that every feature of the language supports programmer abstraction over that feature, timeless, built for the needs of today and for foreseeable future needs. Yeah. And then there's some design goals that we talked about that is strongly typed. Multi-paradigm to use the best of functional programming, object-oriented programming, imperative programming. So it's as deterministic as possible. If you run it over and over, it runs in the exact same way.

Failable expressions, as you talked about, is super fascinating. There's so many cool features in this. Speculative execution, concurrency. Maybe can you talk about concurrency? Like what is it about Verse that allows for concurrency at the scale that you need?

And still, almost all concurrency in real-world programs today is achieved manually. Programmers are writing this code that might run in multiple threads very, very carefully so that they are negotiating among each thread to get access to data in a way that's going to give them predictable results. And it's incredibly hard. It's so hard that we've in five generations of Unreal Engine, every single generation decided we're not going to try to scale up all of our gameplay code to multiple threads manually.

It's just much, much, much too likely to go wrong, not only for ourselves, but for every partner company who licenses Unreal Engine and tries to use it for building a game. It's just a massive footgun. There's a variety of solutions to concurrency that are all rather suboptimal. One attempted solution was like, just don't try to solve this problem at all. Let's break our program down into microservices. And almost all online websites of massive scale like Amazons.com work with hundreds of microservices where different servers negotiate with each other by sending messages to each other.

And by programmers writing those things very carefully, they eventually get to being able to take your orders and not make a mess of them reliably. But this is totally not scalable to the metaverse where you have millions of programmers who are mostly not going to be computer scientists. They're mostly going to be hobbyists and enthusiasts and first-time programmers doing stuff for fun. That's never going to work for them because they'll never be able to envision all the different dependencies between different computations they're running in parallel. But it turns out that there was some amazing foundational work done in the 1980s that was made very real by a paper on Haskell concurrency.

Composable Memory Transactions is the name of the paper. And it describes a system for transactional updates to programs. And the idea of a transaction is a transaction is a block of code that does a bunch of operations on memory. It might read, might write. It might process an order. It might accept an order or reject an order. It might transfer money between one bank account and another. It might make conditional decisions like, oh, you asked to transfer $100 from your account to this guy's account.

We're going to see if you have $100. If you don't, we're going to reject it. And if you have $100, we're going to take $100 out of your account and add it to this other guy's account. Without transactions, if everybody's just randomly adding and subtracting each other's bank balances, then you might have somebody read a bank balance, subtract 100, and write it out. But in the meantime, somebody has written something else in the meantime. And so you might get inconsistent bank balances arising if you don't have a way of ensuring that these all run in a specific order. So the idea of transactions is its way of dividing an entire program into updates, self-contained updates that do an arbitrary amount of computation, but must run in a single-threaded manner.

And in the case of a game engine, that's a gameplay object update. When you're playing Fortnite, you see gameplay objects. Every other player is a gameplay object. Every enemy is a gameplay object. Every rocket and projectile and car and thing you see moving around and interacting. It's not just a fixed static part of the world. That's a separate game object. And each of those objects is updated at a rate of one update per frame at 60 frames per second. And so then in the course of Fortnite Battle Royale gameplay, you have tens of thousands of object updates happening every frame with 100 players.

In a simulation with billions of players, you'd have a whole lot more than that.

And they're not going to have to worry about concurrency at all. And then the system, like today, a program, a computer just runs your program. There's no amount of speculation going on at the programming language level. The idea of transactions is since we have a bunch of operations we need to know we apply, we apply a large set of them concurrently. But instead of each one reading and writing from global memory shared by all, in which case they might be reading and writing and contending with each other for the same data and might be doing contradictory things to it, we're going to track all of our writes locally.

We're not going to write data. We're not going to write changes out to global memory. We're going to keep track of it in a buffer that's just for that one transaction. So we're going to be it's going to look to that code exactly as if it's running on the global system affecting global game state. But it's going to be isolated to just that one transaction. And it's going to be set aside and buffered up for consideration later. We're going to run tens or hundreds or thousands of the updates concurrently. We're going to see which ones had read-write conflicts. Because if two transactions don't read and write any of the same data, then you could have run them in either order or simultaneously.

And it wouldn't have changed the end result.

And by doing this, like removing this from being a programming problem for the programmer to deal with to being a language problem for us language designers to deal with and removing a vast amount of pain that would be imposed on a million people instead to a vast amount of pain imposed on a small number of people have to actually make this work.

And we've been doing this experiment entirely within the world of Unreal Editor for Fortnite for now. We want to test this and iterate with Fortnite creators in just the metaverse usage case before we make it available to all of our partners using Unreal Engine for all of their projects. And the idea is to iteratively improve it and build it out. Because right now, UEFN has relatively few features for programming. It needs a lot more. And everything we add makes the world a much better place for Fortnite creators. And we're adding major, major new APIs every few months throughout the course of this year.

Whereas Unreal Engine licensees who are building standalone games already have access to the full engine through C++. They have massive, massive expectations of an API. And so we can't release this to them until we've built up all the essential features that they'll need for building their gameplay in the future. And so we have these two different tendrils of progress. There's Unreal Engine 5 for game developers. And there's Unreal Engine 5 targeting the Fortnite community. And there's different bits of development that are only in one area of it that aren't applied to both.

Not all of the Unreal Engine 5 features are actually available in Fortnite because some of them we haven't figured out or haven't gotten to the point where we can deploy them to all seven platforms in a platform-independent way. And so the place where all of these different threads of development come together is Unreal Engine 6. And it's a few years away. We don't have an exact timeframe. But we could be seeing preview versions of it perhaps two to three years from now. And we're making continuous progress towards it.

It's a really nice setup because you're both it's a testing ground of the language in Fortnite. And you're keeping an eye on what the ultimate thing will look like also necessary to deliver all the features that we mentioned. Brilliant.

And if they ship as a standalone game, they shouldn't be missing out on the open economy either. Because in this timeframe, we'll have opened up the Fortnite item economy to third-party developers of all sort. Hopefully, there is standards body, but there might be multiple phases of it so that if you choose to ship a standalone game, you can still choose to have Fortnite items work in your game and have your game items work in Fortnite and have your item economy integrated with the overall metaverse economy and solve the really core problem of the game industry that Matthew Ball has been documenting over the past few years.

He solo created this game. That's, I think, quite popular. I believe he says he used visual he didn't even use C++. He used visual scripting. He used blueprints to create it.

Having a content marketplace is a big thing. Just off-the-shelf piles of content, some free, some paid, built by other creators, can enable a small indie team to build a big game and just be able to focus on the unique content of the game, being able to write their gameplay and lay out their environments the way they want, but not have to build every tree and rock. Because somebody has already built one. And theirs is probably perfectly suitable for your game. And over time, there'll be more and more.

There's also a lot of indie developers living as content creators. They'll be releasing content on FAB Marketplace or the Unity Asset Store and earn a living for that. But specialization of labor is a really, really valuable thing. In the early days, pretty much one person would build one game. That's how a lot of the games were built in the 1980s. Over time, you had a separation where artists became specialized and then programmers and then gameplay programmers and engine programmers. Now you have technical artists. And you have dozens of different specialties contributing to a AAA 3D game now.

And the more we can modularize those bits of content so you could get something off the shelf rather than having to build it or have the engine synthesize it for you, the more we can enable creators to create stuff fast and successfully.

Anybody could make copies of that, put it in a store. They could sell it. They could build a business around it. And they were completely able to, without seeking any big tech corporation's permission, do whatever they want, even from IBM. Remember, IBM was the dominant computer company on Earth at the time that they released IBM PC as an open platform. And so it's really been firmly implanted in my mind that this was a magical and wonderful time of unmatched economic progress for technology in the entire world.

And over time, the big companies have realized that they could shut down and just block software makers from releasing software on their own and block software makers from doing business with customers directly. And I've always viewed this practice as terribly abusive. Because when you buy a computer or a phone, you spend good money on it. It's your money you spent on that phone. And now you own that phone. And there's absolutely no reason that Apple should block you from installing apps from other developers directly if you want, going to their web page or writing your own apps without their permission and running them yourself without having to get a developer account, without having to go through their bureaucracy.

And there's no reason that any consumer who gets an app shouldn't be able to do business directly with the developer of the consumer. You already bought that phone. Why should Apple be adding a 30% junk fee to all commerce you do? And why do they selectively apply it to some things and not others? I've always viewed this as deeply abusive and that it shuts down the competitive engine that once fueled the app and software economy. It's still a vibrant competitive engine on Windows and on the internet. But it's no longer with mobile apps because these stores have popped up.

And they don't provide any useful value to the user. Yes, there are search functions to find software. But there's no reason other companies couldn't build a better one. And I bet if you had Steam or if you had Valve build Steam for iPhone, I bet Steam for iPhone would be a much better app store than the iOS app store. And a lot of people would use it. And that Apple would be forced to build a better app store in competition. And everybody would improve their product as a result. But Apple and Google shutting down the competitive engine that drives the software economy has massive implications for everything.

And one of them is reshaping the nature of mobile apps to be really offensive to gamer sensibilities. If you go on console, the best console games you see listed on the storefronts, the best console games that you see reviewed are awesome games that really have a lot of creative merit. The ones that sell the best are really enormous values for their money and are the product of an immense amount of work. You don't see that on iPhone. The top apps on iPhone, the top games on iPhone at almost all times are these ridiculously greedy, high-monetizing whale games, which are pervaded with pay-to-win and loot box practices.

They have sort of a legalized form of gambling. And these games are not driven by fun. They're driven by manipulation of the players to greedy ends.

It's just inflationary as a force in the economy. That's just the first direct tax. But then to reach users, when a user searches for before Apple blocked Fortnite on iOS, when a user searched for Fortnite, the first result was always some competing game. That's utterly anti-user. You search for Steam for a game. And if that game's on Steam, it's the first result always because Steam's not getting enshitified with advertising. Apple is. And they do that so they can make even more than 30%.

So if you want to be the first search result for your game, you're probably paying more like 45%. If you want to reach users on social media, you're paying another 20%. So literally something like 70% of the revenue for your game is just going into junk fees to acquire users and get them in your game. And the money that's left over is only enough to fund these games with rather abusive practices that do not look to normal gamers like games for the most part. Now, there are some exceptions. There are some great games on iOS. And there are some games with good practices. But the engine has been really corrupted in a way that competition would fix.

If you unleashed lots of competing stores on iOS, then you'd have lots of awesome options. And you'd have much better deals and much better prices.

They're not providing the value of 30%. And even if they were, the monopolization, the centralized control without competition is wrong. Anyway, why are you fearlessly fighting Apple on this? And other companies don't seem to want to step up.

Literally, their business would be destroyed if Apple blocked access to them. And Apple is incredibly clear with developers that they're willing to deprive all users of access to any app if they get in a fight. And if you look at how they dealt with Epic, they were not just legally maneuvering with the intent of winning the court case against us. They were also sending a message to all developers in the world. We will destroy your business or we will try our best if you fight us.

And a very small number of vocal developers have been willing to speak up. And Apple was actually refrained from crushing their businesses when they weren't violating any Apple policies. And that took a bit of discipline, which I think is also an amount of calculation by Apple that they couldn't survive being seen as the company killer that if you criticize us, we'll crush your company. But the other thing that Apple has that they can and will readily deploy against every developer is soft power.

When they take 30% and advertising is so expensive, soft power by Apple, like approving your updates faster or slowing down all of your updates by a couple of weeks, can also have a dramatic effect on your ability to compete successfully. And Apple has a very long history of playing cat and mouse games with developers. It's like a developer isn't in Apple's good graces to just slow down the updates. So they've been slowing down updates for several major tech companies, sometimes for weeks, sometimes for months, without all going under the radar because everybody's afraid to challenge them publicly.

And so Apple's wielding a soft power can change a company's economics for the worse enough to deter almost any public company. And Epic is in the fight because I firmly believe that something like the metaverse will only arise at something like a billion-plus user real-time 3D social ecosystem that grows to encompass potentially all or most major games by all major developers tied together into an open economy where they all participate as peers. And they all compete to give users the best deals.

And they grow and do business with their customers directly. That thing can only exist if the Apple and Google gatekeeping monopolies are lifted. And it's not just the 30% fees. The 30% fees are economically ruinous. But they impose other levels of control. Apple prevents all web browsers on iOS from implementing web standards better than Apple does. So Apple has really limited data storage capabilities and 3D graphics capabilities on the iOS web APIs, the APIs you can access from web apps running within a web browser.

And that's to incrementally cripple those apps to ensure that they can't possibly compete with native apps. And by depriving web apps of those features, they prevent web apps from being competing with native apps. Well, Apple, if they treat the metaverse the way they treat the web, they'll say you can only use Apple's metaverse engine. Unreal Engine is disallowed. And then they can impose all of their own limitations on the metaverse to force all commerce through Apple or force it to be so uncompetitive and lousy that it can't compete.

And they have this giant array of these anti-competitive techniques that they use to disadvantage other app developers, saying only Apple can build certain kinds of apps or only Apple can integrate certain features in Europe, even where the DMA law requires Apple to allow competing stores. They say a store can only be a store. You can't build a store into Facebook. You can't build a social network into a store. A store must only be a store because a store that's more than a store might be able to compete with us more effectively. It's just a giant, to use the Soviet term, it's a defense-in-depth strategy where they've constructed a massive series of barriers.

Each are fatal to any attempt to compete so that even if one barrier is overcome, the others remain in place and shut down the whole scheme. And that's playing out in Europe where Apple has enabled us to launch the Epic Games Store but has made it so difficult and uncompetitive both for Epic and for clients who we want to do business with that it has no chance of success until the European Union starts to really enforce the DMA law and impose harsh and serious penalties on Apple to force compliance.

Open it up and win. It's going to create the right kind of competitive incentive to make the Apple Store better because they're great at creating great interfaces. But competition will sharpen the sword. I mean, it's just going to make everything much better. So I do hope there's a lot of public pressure. And I deeply appreciate that you're speaking out in this way, sort of putting that pressure and letting people know it's OK to say that this is wrong.

Epic was an awesome partner to Apple for more than a decade of demos and partnership and technology usage together. And we did amazing things together. I'd love nothing more than to have that Apple bring back Steve Wozniak's original views. The Apple II was such an amazing thing. It's a completely open platform. The manual to the Apple II included a listing for all the ROMs, the source code to the ROMs. You could understand exactly what was happening there. And you could learn from it.

It included a hardware schematic of the entire computer. So you could learn how to make a peripheral and plug it in in an open ecosystem. And that's the awesome Apple. That company would be the best company in the world again. I think the current one is just on the wrong side of history and needs to change.

OK, that said, one of the competitive pressures that Epic has created a few years ago was by launching the Epic Games Store. And instead of Steam's 30% revenue cut, you went with a 12% revenue cut, creating the competitive pressure saying, listen, this shouldn't be that high of a cut, which I thought was like amazing. This is a brilliant idea. And I think it still is a brilliant idea.

It's wonderful. Now, in preparing for this conversation, I looked on the internet. And I saw there's a lot of criticism of EGS, Epic Games Store. First of all, I should say, the internet is full of drama and criticism. There's just not enough celebrating of awesome shit. If I can ask the internet as a blob one request, can we just celebrate awesome shit and also criticize? But just like there's not enough celebration.

Anyway, the two directions of criticism is just straight up the launcher interface is clunky and lacks a lot of the features of Steam. And then the second set of criticism is the exclusive contracts, which were made with some of the games that are on Epic Games Store. So first, huge props on the 12%. Maybe you could speak to the vision of that.

And second, can you comment on those two criticisms?

And so we've had to make a lot of prioritization decisions about what do we support with the Epic Games Store and when. And a lot of the time, it's been supporting commercial features like merchandising, offering multiple versions of a game for sale, and offering upgrades from the regular edition to the deluxe edition and other things that partners work. And other priorities have been quality of life and launcher load times and other things. And we've not put enough emphasis on the quality of life features. We've recognized this very clearly multiple times. And we've gone through multiple refactorings.

But that's definitely been a disappointment to us and to a lot of users. And I think one thing we had to it took us a while to realize was it's not uniform. Depending on your proximity to a CDN and the size of your game collection, it can be either awesome or really clunky. And the users for whom it's really clunky are the people, I think, who are a large part of the complaints.

And so it's very much not our goal to mimic everything of Steam. But we do want to have all of the convenient features that makes it easy and fun to use as Steam. So there's a long journey ahead. But we continue to reinvest in it. And we're working to build a multibillion-dollar business there and think we'll succeed. Already at the Epic Games Store, it supports an immense amount of Epic Games commerce in Fortnite on PC, now on Android and iOS in the European Union too.

So it's a forever facet of the industry. And we are never losing heart in it. And we think at some point, I really feel that the benefits of the Epic Games approach are going to outweigh the benefits of the Steam approach, especially as gaming becomes multi-platform. One of the things that really sucks for all gamers is that you have a lot of friends in the real world. Everyone has different platforms. Your Steam friends aren't connected to your Xbox friends. And they're not connected to your PlayStation friends or your Nintendo friends.

And so you're very much bottling up PC gaming into kind of a hardcore group of PC-only folks and making all of the other aspects of it difficult. A lot of games have flocked towards Discord, which is a mess in itself because now your Steam name is not your Discord name. And that's not your PlayStation name. And so now you have two people in a game. And they have four different identities. And that sucks. Our aim for that is with Epic Online Services and the social systems that we built for Fortnite opened up to all developers to have cross-platform social features be super easy and free for all developers.

This is not something we're trying to gatekeep or rent-seek on or lock people into. It's just a way that we're making social gaming easier for everybody. As more and more games follow the Fortnite approach of being multi-platform, especially multiplayer games, Metcalf's law is a very real phenomenon in the industry. It's the thing that's upending some games and causing growth in other games. It is the number one trend for pervading the world of gaming today. And it says that your game is quadratically more valuable the more percentage of a user's real-world friends they can connect to.

Your game vastly benefits by connecting all of its players together and not segregating them off into different online platform populations and so on. And so I think the future trend is in that direction. I wish Valve had opened up SteamWorks to just work on all platforms. They could have easily done it. We did it. But they seem to be using it as a lever to keep people locked into the Steam PC Game Store. And that's going to be a long-running battle because there's always a very toxic group of Steam users who they even created an entire subreddit dedicated to criticizing Epic on our store.

And they create basically harassment campaigns at times against developers who use Epic Online Services. Developers do that so that they can connect their players across platforms and have friends across platforms and voices across platforms. But suddenly, that's trying to be turned into a negative.

I should give a big sort of positive thank you and props for the push to multi-platform that was always there for Fortnite, perhaps before the pressure that Epic created on breaking the barriers of Xbox and PlayStation and PC and being multi-platform. I got a chance to play with Fortnite a little bit with you and all the people in the group. By the way, awesome interface, audio chat, really fun.

But you could see a couple of PC folks, a PlayStation person, an Xbox person all together. You can't really tell what they're using except for a little icon. And it's nice. It's like all those barriers that we've created with these platforms are gone. And you creating the pressure with Epic Games Store and just everything you're doing with this Fortnite platform, it's really nice. There's no reason to create these silos because ultimately, you should put the gamer first and let everybody interact with actual real-life friends and make new friends across the entire network of humans.

So anyway, thank you for that. Thank you for creating that pressure.

It's been an absolutely wonderful relationship. And I think that stands as an awesome example of a company that, because of historic reasons, got stuck with a policy that no longer made sense for the future. And following a serious discussion with a close partner, righted it and did an awesome thing. And now Sony is much better off and Epic's better off and all game developers are better off. And the whole continental industry, I think, is a lot stronger now than it would have been if these silos had continued playing out. And despite the kind of potential concern that maybe blocking platform play with Xbox gave Sony an advantage, Sony's actually grown in market share relative to Xbox since that time.

And so you can't say that anything but goodness came of that time. And I think a better version of Apple would have received the email I sent to the senior Apple management and been like, huh, there's an issue here. We should have a discussion. We should reconsider this. We should listen. And they didn't. And that's why we're in the midst of a five-year battle with Apple. And in the hopefully still the early days of a 15-plus year partnership with Sony.

Epic has never forced any developer into any sort of exclusivity relationship. Rather, we've offered developers payment or incentives or marketing or any number of things of value to them in exchange for coming to our store exclusively. And it's their game. So it's entirely and rightfully up to them to decide how to distribute it and to make the decisions about their business. It's their game. If they want to distribute it through Steam, they can. If they want to distribute it through Epic exclusively, they can.

If they want to distribute it through both, then they could do that as well. And if we pay them money or other things of value in exchange for them coming exclusively to the Epic Games Store, I think that's their right. And this is an example of Epic, an underdog with a tiny fraction of Steam's market share, working to proactively compete with Steam by offering a better supply of games. And some consumers who prefer Steam might prefer that the game be on Steam. But the developer, in each case, has decided that they believe they would benefit more by doing this exclusive deal in exchange for benefits than by being on Steam.

And one of the key exhibits in the Epic Google trial was its opening exhibit, which was trying to point out to the jury in the trial the benefits of exclusives. Imagine a new store popping up. The store has a big sign outside of it. We're the new store. We have everything that the other store has. And it's at the same price. Are you going to go to the new store? No. Nobody's going to switch from Steam if Steam has all of the same games as the competing store and everything's priced just the same.

And so we looked at initially two ways of competing with Steam strongly. We wanted to sell games at a better price than Steam by agreeing on the amount of money we pay each game developer. If the game's going to sell for $50 and we take 12%, we'd actually lower the price and potentially even lose some money to offer a better deal. Well, we tried to pursue this. But very quickly, every developer told us that they wouldn't agree to better pricing because if they did, then Steam would stop giving them marketing featuring and benefits.

And the console makers would be mad. And all of their relationships would be harmed. So there's an undercurrent of powerful platforms and ecosystems encouraging developers not to compete on price. So not being able to compete on price, we decided to compete on supply by doing exclusive deals. And we signed a lot of them, paid developers lots and lots of money. I think we distributed over a billion dollars in net expenditures to developers beyond the money, the revenue we actually made from games in order to get a whole lot of exclusive games.

Some were successful. Some weren't. Borderlands did awesomely on the Epic Games Store. And we and Gearbox felt that it did just as well through Epic as it would have done on Steam because the players who wanted Borderlands wanted Borderlands. And they came and got it. Whereas a lot of other games, some smaller games especially, that didn't have a dedicated audience that was absolutely going to play the game typically benefited from exposure on Steam. They were reaching an audience that wouldn't have reached organically. And so some of them, in the end, we and they concluded that they did worse by being on the Epic Games Store exclusively in terms of reaching fewer customers.

And so we had these limited-time exclusives. When they ran out, they put their games on Steam. And lots of data was gathered to understand what worked. And so this worked well for some games, didn't work for other games. But companies seeking to compete, especially underdogs seeking to compete, have to offer some unique value, have to offer something that's not available through the competitors. And I get that Steam users who just prefer using Steam and buying games on Steam want to have their library in one place don't like this.

But you're never going to have competition for better deals if you don't support the competitive mechanisms that allow competitors to come about. I think if Valve were forced through Epic Games Store's success to compete with Epic Games Store, then developers would be getting a better deal. Consumers would be getting a better deal. And these 30% fees would be driven down quite a lot towards the actual costs that are required to support the stores.

Even with Joe Rogan, they let go. It's open, wide open. And instead compete on the space of just the non-clunkiness of the interface because the foundation of what Epic Games Store represent with 12% is just philosophically. So you're also competing on the sort of spiritual realm of what it stands for ethically. That's also a really powerful way to win.

So now that there's enough number of people using Epic Games Store to drift away, to move away from exclusivity, it's understandable that it's needed for the competition for the underdog to enter the scene. But it goes against the sort of the freedom, the free spirit of choice that I think you represent in a lot of the decisions you've made, which is making the games cross-platform and just, yes, giving freedom to the developers, giving freedom to the gamers to choose.

So in that way, I think exclusivity a little bit goes against that.

People would start coming here for the better deals. But I feel like Steam giving developers nasty phone calls and so on when they propose to do that prevents developers from passing on savings to consumer. Then what's the mechanism that drives users away from the incumbent store to the store that offers a better deal? If basically developers are fearful of competing on price through stores, what can possibly be done to get a dominant store with something like 90% of revenue share from among multi-publisher stores in line so that a much, much smaller store can compete?

I think some answers are required there. A better UI is great. Steam is super polished. Epic Games Store in time will hopefully be as polished. How does that overcome the fact that your entire library over the past 15 years is there? If developers have been afraid to exercise their own economic interest because it's in the developer's interest to sell on Epic and get 18% more of the revenue, I think there's a real power to incumbents that's very hard to overcome through just being there and being as good.

So anyway, I'm a big supporter. And I don't like the criticism of Epic Games Store. But I also have to say that I don't love the exclusivity. But I understand. I understand the reality of the world is that you have to have some mechanism to get people to switch or not to switch, but to at least get some of their games to try out, to experience, to allocate some of their library to the underdog. So I totally understand and hope the UI keeps improving.

And that was one of the major pieces of evidence on which the jury found their practices to be illegal and anti-competitive. And the one more data point on that, we talk about 30%. And there's always a lot of people defending Steam. Well, of course, they have more costs because they have more features than Epic. We have data on that that's very detailed. The all-in cost of operating the Google Play Store, stocking it, maintaining it, the software, the entire ecosystem is around 6% of revenue.

So in a competitive market, would a company whose cost is 6% be able to charge 30%? Absolutely not. And Apple's costs are similar. Apple runs an even more efficient and lean operation than Google. So their costs are also likely in the range of 6% all-in. They mark it up from 6% to 30%. Only a monopoly can do that. Look at competitive businesses. They have a margin of a few percentage. The numbers there are strikingly supportive of just outright anti-competitive market distortions.

There's just been a degradation of the capabilities of a lot of publishers, partly because of competition for talent. Companies with really vibrant game businesses like Epic or Riot or others are hiring the best developers and accumulating them. And big tech companies are hiring the best game developers because there's super talent there. And so in some cases, the companies aren't competing robustly. They're getting worse. They're making games that are less fun. And I think everything else that's happened is kind of a sideshow to that.

There's always political drama and so on. But I think that just the core is of failure to deliver fun. And the nature of fun is changing. It turns out that playing a game together with your friends in a really socially engaging way with voice chat is just way more fun than playing a solitary game for the most part. And there are exceptions to that. But I think we're seeing much, much more playtime shifting towards games you're playing together with your friends and not just random internet strangers who happen to play that game too, but the people actually know in the real world.

And that's certainly been the case with me and with almost everybody I know who's playing Fortnite or similar games. And that has really significant effects in reshaping the whole game business because a single-player game, if you have 20 people with 20 different opinions of which game to play, each one might buy a different single-player game. But in a multiplayer game, if there are 20 games out and each one might have their own completely individual preference and each one were independently choosing which game to play, each one might buy a different game.

But they're all realizing that they want to play together. And so what players are doing increasingly is playing a game they like and accept together with their friends, even if it's not the game that every one of them might be preferring to play themselves. And that's certainly the case in different Fortnite groups I play with from time to time. It's like one player might have been preferring to play COD. One might have been preferring League of Legends. Somebody else something completely random. But it's just so fun to play together that we're doing that.

And that means that there's really strong Metcalfe's Law effect in which games which are able to attract a large percentage of your friends are more able to attract you and not only attract but also retain. And so I think Matthew Ball's analysis of this over the years has really documented the trend towards you can call it the metaverse or you can call it large-scale multiplayer social gaming. He's really documented this trend. And over the past year or so, it's taken a really, really strong turn towards increasing rate of change, increasing numbers of players coming to Fortnite.

We hit an all-time high of 110 million monthly active users about a year ago.

And it was awesome. And it did well. But most players play it for a while and move back on. And that can be lucrative. But a business that's building that kind of games, it's going to have to build a new one every few years and build a business around that while the other games continue to create users. But when you have a large number of gamers migrating to a small number of games, the effect of that is increasing revenue for those games, increasing reinvestment. And there are things that Epic can do with a team of thousands of people building Fortnite internally and tens of thousands contributing to Fortnite as independent creators.

There are just things that can happen with that level of investment that can't happen in a smaller game. And so there is somewhat of an increasing winner-take-all dynamic where the biggest games reinvest more to make their games more fun, to gain fun at a faster rate than other games. And the industry is changing around that. And so I think the lesson for the game industry now is that there are really two big opportunities being pursued. There's big games or games that have the potential to be really big multiplayer experiences that keep players around indefinitely for very long periods of time.

And then there are just really good single-player and small-scale games that people are taking a break from their big games for. And the trend there is going to be towards efficiently developing those games. You can't build one of those games with a $300 million budget. But if you can do it with a $40 million budget, you can make a lot of money. So I think that's the main reshaping going on. And I think that it creates a rather bleak outlook for a lot of the category of single-player games that don't have a huge audience to reach.

But this is just one of the really trends of restructuring the business around the technology and changes of the day.

That was like a world that they created. Recent game, Baldur's Gate 3, that was really incredible piece of work and art and doing a lot of innovative stuff, again, in the single-player domain. Is there games like that outside the ones you've created?

So what about Breath of the Wild?

But I have a very open-minded view that the best game genre that will ever exist has not yet been invented. And as we get more technological capabilities and creative people use that and hopefully empowered by higher productivity tools and so on, that we'll see more and more cool things emerge that we'd never dreamed possible. And the idea of a world simulator is actually really interesting there. It's been tried a lot. Usually, it's extremely slow and expensive to create.

But over time, maybe we'll get better at that. And that will be a thing too.

And once you do, there's something magical about that. Once you give that attention to detail, I don't know what it is, but the love of the artist comes through somehow. And you could feel the care that they put into it.

Because even when you're eliminated in Fortnite, there's not like blood spurts and there's not gib jibs. You're just teleported out of the simulation. And often, you end up losing the game in a way that's hilarious enough that you actually are laughing at it. Or you're like, respect to that player who just won because that was clever. And it creates a very different dynamic than these other games where players tend to be very positive towards each other. One of the things I like to do in Fortnite just to kind of gauge how the game is going is I play fill squads.

You get matchmade with three other random players and play a game together. Sometimes they have voice chat. Sometimes they don't. And back when our matchmaking regions were bigger, I learned a little bit of battlefield Spanish so I could speak with the people who were down as far south as Mexico City. And the positivity of the interactions there among every kind of person you might ever meet online were really quite impressive and completely unlike what you would see in a game like Call of Duty where it's always everybody's got to be an edge lord.

What can you say about that process that you eventually were able to take Unreal to completion? If you were to look from the outside, why does it take Grand Theft Auto that long or other companies to take the games to conclusion? And I mean, just insight into what that process is like.

And often, you fix one thing and make it super realistic. And that just highlights the unrealism of other things that you then need to fix. And I think the thing that always comes to mind is that shipping a game is easy. If you don't have a high quality standard, you also won't have much success. What we've seen from Rockstar is they take a long time, but they ship amazing games. And it's worth it in the end, right? A bad game is bad forever. A late good game eventually is released and is good.

And then other lessons you can only learn live and from experience. And that means accepting a game that it's a live experience. And it's also an experiment. And it's going to continually be improving. And at any time, there are some things that some people don't like. And you learn from it. And you improve it. And you move on.

But I compare that with the good spiritedness of what's happening online when you're connected to real people, like actually playing Fortnite, playing Fortnite Fill Squads with people you've never met before, never talked to, and just judging what human connections develop there and whether they're positive. I found those to be really, really excellent and endearing. I think the lesson from all of that is that humans talking to humans and being together in a world, the real world or virtual world, is a naturally empathetic medium which naturally leads to bonding.

And though conflict sometimes occurs, it's just generally so much more promoting of our social norms and good interactions between people and positivity promoting. Whereas kind of the typing angry messages thing at each other as a self-reinforcing negative dynamic that's negative. And I think you look at social media and you look at gaming that is increasingly social. And I couldn't see a bigger divide between any two medium as I see there in terms of the actual social dynamics, one super positive, one super toxic at times.

And then the joy that's derived from the empathy comes out. And it's just a reminder that humans I don't know. That humans are good. And they want to see the good in others. They want to share the goodness. And then when they get in that group together, there's love there. Now, they might talk shit about some other group. This is the dark side of humans. But together, in terms of the dynamics of that group, is joyful. So yeah, that gives me hope as well.

And the more degree which we can create those worlds online that make it super easy for us to connect in that empathic way, the better. And I am grateful that you are pushing the boundaries of what's possible in creating such worlds. And I'm grateful that you would talk with me today, Tim. This was amazing. And it's an honor to talk to you.