Lex Fridman Podcast · 2025-04-30 · 265 min

Tim Sweeney: Fortnite, Unreal Engine, and the Future of Gaming | Lex Fridman Podcast #467

Lex FridmanTim Sweeney

YouTube ↗

TL;DR

Epic’s durable operating model is the feedback loop between its own products and the tools it gives other creators, not any single hit game. ZZT bundled an editor and scripting language; Unreal licensing then funded Epic when games did not, while games funded the company when engine revenue lagged. Sweeney calls serving both creators and players “the sole reason that Epic has been massively successful” and survived every downturn.
Fortnite converted seven years of reusable content into a four-week Battle Royale sprint, then proved Epic’s infrastructure could scale from 40,000 to 15 million concurrent users. The result took Epic from roughly 300 employees and about $100 million in revenue to thousands of employees and billions in revenue. That cash now supports a deliberate investment deficit—once more than $1 billion annually, now several hundred million—as Epic invests in Unreal Engine, Fortnite and an open 3D ecosystem.
Unreal Engine 5’s advantage comes from replacing brute-force physics with coordinated approximations that artists can direct in real time. Nanite targets roughly two triangles per pixel without visible transitions; Lumen integrates lighting from kilometer-scale geometry down to pixels and millimeters; MetaHuman combines capture, animation, hair and subsurface skin rendering. Sweeney estimates usable graphics performance increased about 10 million-fold in 30 years, producing what he calls “total observable photorealism.”
Unreal Engine 6 is a multiyear attempt to remove architectural constraints that still trace back to Unreal Engine’s early foundations. Today’s game simulation remains largely single-threaded, so Verse is being designed around functional logic, stronger compile-time verification and speculative transactions that could distribute object updates safely across cores or nodes. Epic might show UE6 previews in two to three years, but gives no exact date: “We solve hard problems.”
Sweeney expects AI to multiply creative output, but rejects the thesis that prompt-generated video will simply replace controllable 3D production. Generated media lacks stable scene knowledge and art direction; Unreal’s scene graph is precise and repeatable but costly to build, while AI representations are rich but “mushy data.” His likely convergence is AI generating or enhancing objects, animation and final pixels inside a persistent, artist-controlled world—though he warns coding models still struggle with genuinely new problems and the final 1% of correctness.
The metaverse thesis is already present in social gaming infrastructure, not dependent on VR, NFTs or cryptocurrency. Sweeney counts roughly 600–800 million monthly participants across large social games; Fortnite itself reached 100 million monthly users, about 100,000 playable islands and a $400 million creator economy. The missing layer is interoperability—cross-platform identity, portable cosmetics, shared social graphs and revenue standards—because “what you need is interoperability,” whether implemented through databases, protocols or blockchains.
Epic’s fight with Apple, Google and Valve is fundamentally about distribution economics and control over future software markets. Sweeney contrasts Apple and Google’s 30% commissions with disclosed Google Play operating costs around 6%, while Epic Games Store charges 12%; he argues the gatekeepers’ restrictions make open metaverse economics impossible. He concedes the Epic launcher “is clunky” and that some exclusives underperformed, but defends spending more than $1 billion in net expenditures beyond game revenue on exclusive deals because an entrant cannot dislodge an incumbent merely by offering the same catalog at the same prices.
Gaming is consolidating around persistent social products, leaving a narrower but still viable opportunity for efficiently produced stand-alone hits. Fortnite reached an all-time high of 110 million monthly active users, and Sweeney sees Metcalfe-style effects pushing engagement and reinvestment toward games that gather a player’s real friends. His bar remains simple—“people play games for fun”—with a plausible model of either enduring multiplayer worlds or exceptional “vacations” built for perhaps $40 million rather than an untenable $300 million.

Digest · the substance, structured for research

1. Ten thousand hours mattered because every project closed a knowledge gap

Sweeney first programmed around age 11 on his brother Steve’s new IBM PC, learning BASIC over several days and becoming “just hooked.” He remembers his earliest code more vividly than people’s names because each challenge exposed either a personal learning hurdle or genuine friction created by programming-language design.
Between roughly ages 10 and 20, Sweeney estimates he wrote code for 10,000–15,000 hours before shipping anything commercially. The output ranged from a text-mode catching game to databases, a bulletin-board system and a Pascal-like language with its own compiler—often built because he did not know where one bought the existing tool.
His correction to the familiar hours-based success story is important: “It’s not just hours.” He moved project by project toward things that seemed fun, while deliberately noticing what he knew and did not know; storage, concurrency, parsing, complex data structures and control flow later became the accumulated foundation for Epic.

2. Engineering education supplied tools whose uses appeared years later

Mechanical engineering initially felt disconnected from programming, but calculus, vectors, matrices, physics and stress analysis resurfaced while Sweeney built the first Unreal Engine. He likens that delayed integration to “Karate Kid moments”: painting the fence and waxing the car before realizing the exercises were training a coherent capability.
Sweeney treats education as knowledge acquisition, not credential bookkeeping. University grades and diplomas may signal value to an employer, but “the real purpose of all of this is to learn”; engineering’s rigor—solving whole chains of difficult problems—proved valuable even though he never practiced mechanical engineering professionally.
His PageRank example captures the broader lesson: eigenvectors seemed useless when he encountered them, yet became central to Google’s early search advantage. Programmers should write extensive code, artists should make work across styles, and both should learn mathematics because nobody knows which stored idea will unlock a future problem.

3. Unstructured childhood gave experimentation room to compound

Sweeney worries that grades, homework and tightly scheduled lives are displacing the freedom that shaped his generation. His childhood instruction was often simply “be back by dark,” leaving time to explore woods, build go-karts, salvage electronics into imagined spacecraft panels and pursue projects without an adult prescribing their purpose.
That freedom produced different outcomes—some watched television, some socialized, others built serious things—but it also made entrepreneurship ordinary. Children mowed lawns, raked leaves and tested creations on neighbors; Sweeney bought his early computers with lawn-mowing money and repeatedly watched local children play unfinished games before risking a public release.

4. Games first interested Sweeney as systems he could reverse-engineer

Atari’s Adventure and the text adventure Zork were his two formative games. Adventure turned simple icons into castles, dragons and swords; Zork generated an elaborate world in the player’s imagination through commands such as “go north” and “pick up sword,” despite having no graphics at all.
Playing quickly became an engineering curriculum: Sweeney learned to move characters, parse language, construct castles and save levels. Most importantly, he discovered the separation between a game and the tools used to build it—“the more powerful tools you had, the more creativity you could unleash in yourself or others.”
Until Fortnite, he says he generally played games to determine how they worked. When Wolfenstein or Doom appeared, he would move the mouse slightly, examine the screen “pixel by pixel” and infer the rendering technique; the entertainment was partly a grand technical puzzle he could reproduce.

5. ZZT emerged when a practical text editor became too boring

Epic’s first commercial game did not begin as a game. After moving from Apple II to IBM PC, Sweeney needed a text editor, implemented cursor movement and editing, then replaced the cursor with a smiley face and assigned gameplay behaviors to text characters—walls, hazards and moving objects—until the editor became a world-building tool.
He deliberately limited the vocabulary to roughly 20–30 objects: enough combinations to make compelling levels without overwhelming players. Connected boards became a navigable world, and the project became ZZT, released in 1991.
Before shipping, Sweeney invited adults and children from the neighborhood to “figure it out” while forcing himself not to help. He noted where they stalled, laughed or became bored and iterated accordingly—an informal version of what would now be called user-experience research.
ZZT used shareware distribution: the first of three episodes was free, while the two sequels cost $30 by mail. Three or four daily orders produced about $100 a day, but the more consequential validation was that software uploaded to local bulletin boards could propagate internationally without manufacturing or physical distribution.

6. Giving players the editor established Epic’s operating model

Sweeney shipped ZZT’s editor and scripting language alongside the game, enabling players to become creators and learn rudimentary programming. Decades later, adults still tell him they grew up making ZZT worlds; the product endured because it was not limited to the three episodes he personally authored.
That choice became Epic’s formative principle: make “awesome entertainment” and “awesome tools,” then share the tools so others can build things the company never anticipated. Unreal, Fortnite Creative, Unreal Editor for Fortnite and Epic Online Services all extend the same logic rather than representing unrelated business lines.
Sweeney describes the dual constituency as Epic’s survival mechanism. Sometimes engine licensing funded the company when it lacked a hit game; at other times games financed engine development. Serving creators and gamers together is, in his telling, “the sole reason” Epic survived the game industry’s brutal financial cycles.

7. Bulletin boards revealed both digital abundance and distribution friction

Before consumer internet access, users dialed individual computers over telephone lines. Sweeney’s first 300-baud modem transmitted about 30 characters per second, while popular bulletin boards had one contested phone line, a few hundred users and distinct communities devoted to programming, news or pirated Apple II games.
The scarcity encouraged distribution: users gained status by uploading a new file and claiming they brought it first, so ZZT spread organically between boards. When universities’ internet infrastructure opened to consumers in the 1990s, the addressable audience became global and digital delivery suddenly lost the physical constraints of retail.
Commercial games briefly moved the other direction because large 3D releases required boxed CD-ROM distribution. The initial transition to digital was dominated by BitTorrent and piracy—some games might sell 100,000 copies while reaching two million users—before Steam made legitimate downloads convenient enough that many players preferred paying to pirating.

8. Indie developers should avoid crowded genres and earn the right to expand

Epic’s early differentiation was distribution, not production scale. Shareware removed entry friction, encouraged friend-to-friend spread and reached an audience that incumbent publishers’ retail networks could not; Sweeney calls it an early version of the free-to-play logic that later transformed gaming.
ZZT also competed where established games were weak rather than matching their graphical sophistication. Its text characters looked primitive, but the editor turned it into a platform, echoing Bill Budge’s Pinball Construction Set and anticipating Minecraft, Roblox and Fortnite Creative.
Sweeney’s warning is categorical: every major genre now contains “massive competition,” making a conventional entrant unlikely to win unless it is genuinely world-class. A more plausible path is to make something nobody else offers, dominate even a small audience, generate cash and reinvest toward a larger ambition.
He favors a multistep progression over the fantasy of going directly from idea to massive commercial success. Market leaders are usually first or second entrants that continually compound their position; late winners generally appear only when an incumbent fails exceptionally badly.

9. Doom first convinced Sweeney that Epic could not compete

Wolfenstein’s 30-frame-per-second environments made 3D feel inhabited rather than merely displayed, while Doom combined texture, lighting, art and sound into something visceral. For Sweeney, John Carmack’s work appeared “not just one innovation leap ahead but like a dozen simultaneously interplaying.”
The effect was initially demoralizing, not energizing: Sweeney “gave up on programming for like six months” because he could not imagine matching Doom. Michael Abrash’s articles and assembly examples then decomposed texture mapping into understandable pieces; seeing the mechanism turned awe back into the conviction, “Oh, I can do that.”
Several Epic developers began experimenting independently before the company consolidated its strongest 2D talent around one 3D project. Nobody had shipped a 3D game, so roles were discovered in motion: Sweeney initially volunteered to build the editor, then wrote the 3D engine himself after seeing the existing assembly code; James Schmalz created creatures and Cliff Bleszinski became the editor’s first level-design customer.
Epic grew the Unreal team to roughly 20 people, enormous for the period, while continuously recruiting unusually capable students and early-career creators. It could not win salary bidding wars, so its comparative advantage was matching overlooked programmers, artists and musicians whose abilities exceeded their professional credentials.

10. Unreal survived three and a half years of being six months away

Unreal’s development lasted three and a half years, yet the team consistently believed release was roughly six months away. Most worked 70–80 hours weekly without knowing which undiscovered problem would follow the current one; Epic came close to exhausting its finances several times.
Sweeney retained confidence in the technical outcome because the pieces seemed solvable, but remained chronically worried about cash. MicroProse’s two engine licenses brought about $500,000, with GT Interactive and others adding revenue—the engine business became a lifeline before Unreal itself shipped.
That customer dependence made support culturally central. Epic created mailing lists, and its own programmers and artists answered licensees’ questions because those partners were funding development; the commercial pivot permanently joined game production with a serious third-party technology business.

11. Daily iteration beat formal management

Unreal’s cross-disciplinary team lacked experienced managers and conventional process, but generated several builds every day. Programmers exposed features, artists used them in levels, and those results immediately revealed missing tools—an iterative loop Sweeney regards as the “critical element to success in games.”
His comparison is uncompromising: a studio iterating weekly will finish “way way way worse” than one improving the playable product daily. Epic’s coordination rested less on organization charts than on individual passion, rapid feedback and talented people learning each other’s disciplines in real time.
Sweeney attributes Epic’s survival not to “awesome management or awesome planning or awesome financing,” but to “the sheer talent and willpower of the people involved.” His own schedule was roughly noon to 2 or 3 a.m., with about 60 programming hours, five coordination hours and five business hours per week.

12. C++ and expensive hardware bought programming throughput

Unreal began in C on 16-bit Windows, moved through 32-bit DOS extenders and Windows NT, then shifted to C++. Sweeney had preferred Pascal, but C++ simplified a growing pile of systems enough that the final two and a half years of development used 32-bit C++.
He still sees C++ as dominant performance infrastructure because “it solves all the problems at scale,” albeit often through manual pain. Other languages may be cleaner or stronger in particular domains, but their inability to cover every requirement becomes limiting for a general engine.
Sweeney eventually reorganized his workstation around maximum output: a 24-inch, roughly 100-pound CRT running 1920×1200, then a $7,000 Dell with a 200 MHz Pentium Pro and one gigabyte of memory in 1996. Faster compiles and a larger working surface were capital investments in developer productivity.
On a 90 MHz Pentium, he reduced texture mapping to six CPU cycles comprising 11 instructions per pixel. Programmers could then understand and micromanage the machine precisely; modern out-of-order execution has made that level of direct control largely uncommon, though similar low-level mastery survives in specialized GPU work.

13. Constructive geometry turned a 30-hour sprint into artist leverage

Unreal’s real-time constructive solid geometry let artists add and subtract shapes instead of manually assembling every doorframe or opening. Sweeney implemented the breakthrough during a single 30-hour session, then watched Schmalz interlock two giant tori and subtract a cylinder with only three operations.
The implementation rested on Bruce Naylor’s binary space partitioning trees, a technique Carmack had used, but required Sweeney to classify roughly 14 geometric cases. Coplanar polygons facing the same or opposite directions created the difficult tail: which surfaces should remain, disappear or be divided?
His summary applies far beyond graphics: “It’s pretty easy to write software that’s 99% correct. It’s the 1% that’s the really hard part.” Most cases fell to deduction, but some required trying alternatives and observing the output; after sleeping, he returned surprised that the system had genuinely worked.

14. Real-time lighting is a portfolio of controlled approximations

Sweeney’s recurring graphics principle is that “we know the laws of physics,” so correct rendering is conceptually easy and computationally impossible. Photon tracing can reproduce reality, but was millions or billions of times too slow; a six-cycle texture mapper could not absorb another 30 cycles of lighting per pixel.
Light maps supplied the compromise: calculate illumination on a coarse world-space grid, perhaps one value per foot, store it as a texture and interpolate between samples. Because the samples were sparse, Epic could afford richer effects—colored lights, flickering torches, caustics, pulses and multiple composited sources.
A ray from a light to a surface determined whether intervening geometry cast a shadow. Sweeney’s dynamic implementation managed only about half a frame per second, so he precalculated shadow relationships while retaining runtime changes for stationary sources, allowing a torch to flicker dynamically inside a fixed shadow structure.
Artists repeatedly exceeded his mental model of each feature. A programmer might expose a small dropdown option; level designers would combine it with unrelated systems and produce results “vastly more” capable than anticipated—the same relationship between constrained medium and invention that Sweeney sees in Renaissance painting.

15. A fake fog demo triggered a genuine mathematical breakthrough

After a Finnish hardware startup showed colored lights glowing through volumetric fog, Sweeney assumed it had solved the effect in real time and began another 30-hour coding session. The visual problem required accumulating illuminated fog along the line from the viewer to a visible surface.
Mechanical engineering supplied the forgotten tool: a line integral. Light falloff involved inverse-square behavior, and a reference table showed the transformed integral resolving through an arctangent; Epic sampled the result on a coarse structure analogous to a light map because per-pixel evaluation remained too expensive.
Years later, Sweeney told one of the company’s engineers how the screenshot had inspired Unreal’s real-time fog. The answer was: “Oh no, we cheated. We just rendered it out of 3D Studio Max.” Smoke and mirrors had nevertheless demonstrated a target convincing enough to produce the actual invention.

16. Carmack’s defining discipline was willingness to discard good code

Sweeney most admires Carmack’s detachment from prior work. Landmark techniques were often the seventh or eighth implementation: write it, learn, throw it away and rebuild until the result was not merely adequate but the best available solution.
The lesson is conditional rather than universal. When a subsystem’s performance, quality or capability is decisive, programmers should not settle for the first or second answer that works; iteration to near-perfection can define a product category, as Carmack’s rewrites did for real-time 3D.
Sweeney’s own fog story carries the complementary lesson: demonstrations can reveal possibility even when their underlying mechanism is false. The valuable response to apparent wizardry is to decompose it, test the assumptions and decide whether the result can be achieved through a different mechanism.

17. Unreal’s rendering has been rebuilt while old foundations accumulated debt

Across 30 years, Sweeney estimates CPU performance rose roughly 100,000-fold and net usable graphics performance about 10 million-fold—from a Pentium 90 doing approximately 90 megaflops to contemporary NVIDIA hardware around 20 teraflops. Each rendering generation therefore demanded substantial replacement rather than incremental polishing.
Unreal Engine 1 targeted software rendering and added 3Dfx Voodoo 1 support late. Unreal Engine 2 embraced GPU acceleration; DirectX 9’s programmable shaders enabled Unreal Engine 3’s pixel shading, dynamic lights, shadows and early multicore rendering; Unreal Engine 5’s Nanite and Lumen produced the largest leap.
Not everything kept pace. File management and networking remain evolutions of Sweeney’s 1998 designs, contributing to lossy state bugs, while core gameplay simulation is still largely single-threaded—even on a 16-core CPU—because parallel game logic is far harder for Epic and licensees to write safely.
Unreal Engine 6 is intended to address those inherited limits rather than merely add graphical features. Lex calls the single-to-multithreaded transition “terrifying”; Sweeney agrees that the modern foundation must incorporate what computing learned after the original architectural decisions were made.

18. Nanite spends geometry only where an image can reveal it

Modern tools can easily construct scenes containing billions of polygons; rendering all of them is the impossible part. Nanite aims to generate a frame indistinguishable from the full-detail scene while adapting each object’s geometric complexity to its apparent size.
Sweeney invokes Nyquist sampling: beyond a sufficient sampling rate, additional source detail cannot change the observable signal. In Nanite’s rough geometry formulation, about two triangles per screen pixel should be indistinguishable from thousands, whereas fewer begin exposing artifacts.
Conventional GPU triangle rasterizers perform well when a triangle covers perhaps 10 pixels but become inefficient around one pixel. Brian Karis’s breakthrough was to bypass that fixed-function triangle path for tiny geometry, calculate intersections through shader work and move more directly toward the final pixels.
A perfect still frame was not enough. Earlier level-of-detail systems visibly “popped” as geometry switched, shaking the apparent world; Nanite’s deeper engineering reduces those temporal transitions until they may exist statistically but no longer distract the moving observer.

19. Lumen makes indirect light part of the simulation

Early engines lit surfaces struck directly by a source and left the rest dark. Lumen instead models global illumination: a white light hitting a red wall loses blue and green, then reflected red light colors the nearby floor and subsequent surfaces through multiple bounces.
Daniel Wright’s controversial approach calculated different scales of illumination—from buildings casting broad shadows down to millimeter and pixel details—then integrated those layers without perceptible boundaries. The aspiration is that artists place lights and “it just works,” rather than configuring a specialized technique for each one.
Screen-space lighting handles some of the finest dirt, ice and snow shadows by inferring occlusion from visible pixels and depth. It is incomplete as physics but visually convincing, exemplifying Sweeney’s definition of graphics as “increasingly effective approximations of the laws of physics which are just totally intractable.”

20. Photorealistic worlds remain an artist achievement built from many systems

Epic’s Marvel 1943 demonstration combined geometry, Lumen, material layers, reflections, snow, dirt, fog and changing lights, but Sweeney insists “the real hero” was the production’s artists and technical artists. They drove the technology beyond what Epic itself realized it could produce.
Material layering let creators vary the accumulation of snow or ice over surfaces while the engine managed transitions. Reflections mixed captured textures, individual lights and bounce effects; skilled operators still had to select, tune and coordinate them rather than pressing a button marked photorealism.
The burning trash can combined separate fire and smoke particle systems, physics and light attenuation through the smoke. Sweeney considered it the first demo where he felt such smoke no longer resembled a video game, yet attributed the breakthrough as much to artistic sophistication as to the particle technology.
The remaining product challenge is usability: novices cannot yet construct the same scene by selecting a few materials. Epic wants the engine to absorb more technical-art decisions so creators can specify an appearance without personally mastering every rendering layer.

21. Human faces impose a higher quality threshold than the surrounding world

Humans are the hardest graphics problem because evolution trained people to infer emotion and intent from microscopic facial cues. Viewers tolerate a slightly wrong architectural shadow, but one faulty component of a face pulls attention toward “the wrong side of the uncanny valley.”
MetaHuman capture places a performer inside a sphere containing dozens of high-resolution, high-frame-rate cameras and records a wide range of motion. One person may require hours of capture and thousands of processing hours because the target is not only facial shape but interactions among muscles, sinews, fat and expression.
Epic is also capturing thousands of people across cultures, continents, ages and facial variations. The goal is a dataset broad enough to reconstruct a new face—potentially from something as accessible as an iPhone photograph—by recombining high-quality knowledge learned from representative data.
Rendering adds separate approximations for hair and subsurface skin. Every strand and photon is infeasible; skin is not opaque, so oil-surface reflections and light moving beneath it must cooperate with expression. A painted mannequin fails precisely because a solid surface cannot reproduce those optical cues.

22. MetaHuman is a multiplier, not a solved digital-person problem

MetaHuman Creator replaces sculpting every face from scratch with adjustable parameters derived from the captured facial space. Creators can bring the result into Unreal, add simulated clothing and hair, alter materials and integrate it with the rest of a real-time scene.
MetaHuman Animator transfers facial performance from capture hardware as simple as an iPhone. Retargeting is not literal: an actor’s anatomy may differ from the character’s, so the system must preserve the intended expression rather than copy muscle displacement mechanically.
Audio-only animation is harder because speech engages the entire face, not merely the lips. A generated voice requires inference about mouth motion, facial expression and intent; Sweeney says the broader effort may be “50 years in total” and is only about 30 years into the journey.

23. Virtual production improves acting and lighting simultaneously

Unreal serves games, automotive design, architecture, industrial visualization and Hollywood production because each needs interactive 3D simulation. Its range extends from photorealism to Pixar-like styling and cel shading, with physics, animation and human characters sharing the same underlying system.
In film, large LED walls increasingly replace green screens with real-time Unreal scenery. Traditional composites often reveal mismatched lighting; LED environments illuminate performers with the scene’s actual colors while letting actors see the location, orient their performance and react to what the audience will ultimately see.
Sweeney frames the opportunity as productivity constrained by cost. The Oscar-winning short WAR IS OVER! is one milestone, but the larger shift is that real-time tools reduce expensive iteration and improve the interaction between virtual scenery, physical lighting and human performance.

24. AI-generated pixels lack the continuity that production worlds require

Sweeney thinks the industry is “overly optimistic” about AI video’s progress. A model may produce an impressive image, yet fail to maintain characters, objects and story logic across shots because it lacks an explicit understanding of the scene, the surrounding world and the narrative arc.
An engine holds a scene graph: exact objects, geometry, textures, sounds, animations and state that can be rendered repeatedly from any viewpoint. AI contains broader knowledge in “mushy data,” but a small prompt change may transform the whole result, making precise art direction and reproducibility difficult.
His expected synthesis is bidirectional. AI could generate new trees from Quixel’s tens of thousands of scans, enhance objects or post-process Unreal pixels; the engine could give AI the complete object list and receive suggestions that become persistent, selectable and editable parts of the scene.
Lex’s VR conversation with Mark Zuckerberg is Sweeney’s early example: captured 3D faces supplied stable structure, while an AI image enhancer restored subtleties lost in normal rendering. Neither conventional graphics nor a prompt model alone supplied the full result.

25. AI may expand creative work while exposing weak software abstractions

Sweeney expects AI to become “a multiplying force on the power of human creatives,” not a wholesale substitute. He acknowledges uncertainty and Lex preserves the counterpoint: hype-driven implementations and layoffs cause immediate, genuine pain even if longer-run technology eventually creates more opportunities.
His historical analogies are synthesizers and Photoshop. Each was initially dismissed as not real art, then became an instrument artists controlled; AI feels alienating today because it can create an entire image yet resist a simple instruction to alter one object’s color.
Coding assistants excel when millions of repositories already contain the requested pattern but struggle with complex, original work. Their code may “sort of work” while leaving a harder 1%—the same correctness tail Sweeney encountered in computational geometry—so he urges developers to test assistants on genuinely difficult problems.
Boilerplate generation is useful but also indicts language design. Asking AI for another sorting routine creates “another sorting function that might be buggy” beside a million others; stronger modular libraries would remove the boilerplate and leave humans and AI working on the unique problems that deserve new code.

26. Near-photoreal worlds may arrive before convincing synthetic people

Asked when simulation could approach observable reality, Sweeney answers “certainly less than 20 years.” Non-human environments such as jungles and cities may be only a few years away, while faces, dialogue, intent and behavior confront much higher perceptual standards.
Ten years earlier, he believed infinite computing power would still fail because nobody possessed algorithms for realistic intelligence. Generative text changed his view: text-level human simulation is already credible enough that a compelling behavioral simulation might emerge within five years, though he explicitly adds, “I’m not saying it’s a good idea.”
Lex says current language models effectively pass the Turing test; Sweeney replies that the test is not especially useful. Their agreement is narrower: rapidly improving language, speech, emotion and digital humans could produce scenes moving enough to make viewers cry, even while consciousness remains unexplained.
On whether reality itself is simulated, Sweeney offers no conclusion. Nested simulations merely relocate the question of base reality; mathematical existence, quantum measurement and consciousness remain theological as well as scientific questions, and he says respectable physics has largely set aside such holistic investigation.

27. Greater realism creates limits Epic does not want games to cross

Sweeney distinguishes entertainment from an alternate reality designed to retain people indefinitely. Epic wants friends to play together between work and the rest of life; as simulations become more compelling, developers must ask “should we go that far?” and decide which capabilities deserve restraint.
Lex presses the sharper ethical case: sufficiently realistic synthetic humans might suffer, love, fear death or experience torture, creating a line law should prohibit crossing. Sweeney does not claim an answer, but agrees that more realistic human simulation will create difficult questions beyond today’s clearly fictional, exaggerated game violence.
His operating principle is that developers exist “to make people’s lives better” through fun, companionship and diversion—not to become too large a substitute for life. He says game developers have generally been good-spirited while acknowledging that future realism may demand explicit legal and cultural boundaries.

28. The metaverse is social gaming, not a particular headset or token

Sweeney jokes that the metaverse is “an idea whose stock price goes up and down depending on who says what on what day.” His durable definition is simpler: friends gathering in a shared 3D world and moving among experiences while remaining socially connected.
Fortnite Battle Royale captures the essence because cross-platform players can play, speak and maintain one social experience. Rec Room’s VR billiards or basketball is another manifestation, but VR is optional hardware rather than the defining layer; Battle Royale players show no general migration toward headsets.
He estimates 600–800 million people already participate monthly in large-scale multiplayer social games. Cryptocurrency and NFTs are likewise optional representations of value: “What you need is interoperability,” which can arise through blockchain, conventional databases, protocols or standards bodies.
Fortnite Creative and UEFN extend the thesis from one developer’s mode to an expanding catalog of creator-built genres. Sweeney regards today’s ecosystem as analogous to the sparse early internet—already real, but still far from its mature form.

29. Fortnite’s seven-year detour became a four-week breakout

Fortnite began during a 2011 internal one-week prototype exercise in which employees formed teams and built games. Its original loop already contained the enduring idea: construct forts by day, then defend them from zombies at night.
Over years, Epic changed the visual direction from realism toward approachable stylization and evolved the design through persistent RPG and MMO-like systems into Save the World. That mode launched in early 2017, covered its budget and produced a moderate return without becoming transformative.
PUBG’s rise then prompted the thought, “This would be so cool if it had Fortnite building.” Roughly 30 people entered a war room and built Battle Royale gameplay in four weeks, drawing on seven years of existing environments, characters and assets.
The launch moved Epic from around 300 employees to thousands and from roughly $100 million in revenue to billions. The compressed sprint was possible because the visible content already existed; the four weeks created the missing mode, not an entire production from zero.

30. Scalable foundations kept exponential demand from killing Fortnite

Since 2012, Epic had been building accounts, login and backend systems for multiplayer gaming. After launch, the online team spent roughly a year scaling from about 40,000 concurrent users to 15 million.
Fortnite divided responsibilities among 100-player game servers, account services, shared databases and hundreds of other microservices. Scaling meant locating each new bottleneck, adding redundancy and ensuring that one saturated component did not halt the whole product.
Cloud infrastructure made the response possible without Epic buying data centers. When Brazil exhausted available capacity during one weekend, Amazon appears to have shipped millions of dollars in equipment before the next surge; Sweeney’s verdict is “Thank God for Amazon Web Services” and its many unnamed operators.
He considers the original architecture existential: had the foundations not been sufficiently stable, Fortnite would simply have become unplayable during its breakout. Product quality at that scale depended as much on unseen account, database and capacity work as on the Battle Royale design.

31. Fortnite profits are financing a deliberately unprofitable transition

Fortnite generates billions of dollars annually and remains the majority of Epic revenue, alongside Unreal licensing, Rocket League, Fall Guys and marketplaces such as Fab. Epic is nevertheless spending more than it earns because it is funding a broader real-time 3D platform.
At one stage, annual spending exceeded revenue by more than $1 billion; Sweeney calls that unsustainable and links the correction to painful layoffs. The current deficit is several hundred million dollars per year, supported by billions in cash from early profits and outside investment.
His metaphor is explicit: Epic is “not an oil well pumping oil out of the ground.” It is using present cash flows to become a future technology company, accepting projects that may take three, four or five years before producing revenue—if they reach fruition at all.

32. Today’s game market fragments every identity and purchase

Sweeney begins his interoperability case with “the present of gaming and why it sucks.” Fortnite has about 100 million monthly users and roughly 100,000 islands, yet moving to Roblox, Call of Duty or League of Legends means changing applications, identities, friends, controls and owned goods.
Console-wide friend systems only solved the problem within one hardware silo. PlayStation, Xbox, Nintendo, Steam and Epic identities cut across game-specific identities, leaving players with multiple unrelated names and social graphs for the same real-world relationships.
Epic’s proposal is federation rather than one owner: Xbox, Fortnite/Epic and Steam names could live together and interoperate in a single space. Epic Online Services exposes Fortnite’s social infrastructure to other developers for free because Sweeney wants cross-platform networking to become common infrastructure rather than a new rent.
He invokes Metcalfe’s law: a multiplayer game becomes disproportionately more valuable as it connects a larger share of each user’s actual friends. That dynamic rewards games eliminating platform segregation and penalizes experiences whose communities remain trapped in isolated stores or consoles.

33. Portable cosmetics could unify economies without flattening games

Sweeney rejects the idea that a World of Warcraft sword must function inside Fortnite; gameplay rules and competitive items will remain specific to each title. Cosmetic outfits, cars and other non-pay-to-win goods are more promising because perhaps 70% of major multiplayer games share sufficiently similar representation needs.
Fortnite separates engagement from monetization. Battle Royale and creator islands generate the fun that makes players value identity, while the item shop generates revenue; “if you weren’t playing any Fortnite games, why would you buy Fortnite outfits?”
Epic attributes profitable item-shop spending back to engagement. If a player spends 40% of time in Battle Royale and 60% in creator modes, the distributable profit can follow that mix, helping Fortnite’s creator economy reach approximately $400 million and continue growing.
The Only Up mode exposed the mechanism’s nuance. Players loved climbing its stacks of objects, but cosmetic spending correlated weakly because they rarely saw other characters beyond someone’s back or “butt” above them; modes that display identity more visibly produce stronger commercial value.

34. Open standards must reach beyond files into behavior and commerce

Existing 3D standards already transfer low-level content: Pixar’s Universal Scene Description can represent a scene graph, while glTF, image and audio formats preserve geometry, texture, animation and sound across Unreal, Unity, Blender and other packages.
The missing standards describe portable outfits, permissible dimensions, capabilities and revenue sharing. If games agreed to respect compatible purchases and divide economics across ecosystems, creators could sell one identity object into a broader market without forcing every title to share gameplay rules.
Content scale could eventually reach exabytes. A high-detail Fortnite update can be around 60 GB, while that is only a small part of the Fortnite Creative ecosystem; future games therefore need standards that let work from millions of authors coexist rather than ship as one company’s fixed bundle.
Sweeney imagines continent- or Earth-scale spaces where environments, vehicles, weapons and rules come from separate creators. Players could move through regions maintained by different people without leaving a seamless simulation—the direction Fortnite and Roblox suggest but cannot yet implement at full compositional scale.

35. Verse treats failure and multiplicity as ordinary expression results

Epic is building Verse as a functional-logic language for large simulations and reusable modules. Its design follows Niklaus Wirth’s principle that power should come from a small number of composable features, not an ever-expanding list of unrelated constructs.
In conventional languages, an expression usually produces one value; in Verse’s model it may produce zero, one or many. Zero means failure, one success and many iteration, allowing conditions, variable binding and loops to share a unified mechanism instead of accumulating separate Boolean, iterator and query machinery.
A successful condition can bind values that become available inside its branch, so checking and extracting information occur together. A loop can consume any expression yielding multiple results, making database-like selection and filtering feel closer to ordinary code than to a separately embedded SQL system.
Experienced C++ developers initially write awkward C++-shaped Verse, then become more concise after months of adaptation. First-time programmers learning through Fortnite often internalize the model immediately and write surprisingly sophisticated queries because they never formed the older language intuitions.

36. Verse aims to make accepted code increasingly trustworthy

A persistent metaverse needs live upgrades from many authors without shutting down the world. New modules must remain compatible with old interfaces, turning apparently operational deployment questions into type-system questions about which changes remain backward-compatible.
Verse’s larger ambition draws on Curry–Howard correspondence: types can represent propositions and values can constitute proofs. A sorting function’s type might eventually express not only that it returns an integer array, but that it returns the same elements in sorted order.
Sweeney cites Lean and Coq as theorem provers whose accepted mechanical proofs cannot lie. Verse is meant to bring more of that rigor into a mainstream language gradually; developers need not prove everything, but cryptography, decompression and security-sensitive modules justify stronger guarantees.
The practical target is simple to state: “If your compiler accepts your program and doesn’t beep and tell you there was an error, then your program should work.” Human specification mistakes remain possible, but every property moved into compilation avoids much costlier runtime bugs, patches and security failures.

37. Transactions could turn concurrency from a creator problem into an engine problem

Unreal still updates Fortnite gameplay largely on one simulation thread. Players, enemies, rockets, cars and other objects each require updates—tens of thousands per frame in a 100-player session—so simply increasing hardware cores does not remove the architectural ceiling.
Verse’s proposed solution builds on software transactional memory. Ordinary code reads and writes as though it owns global state, while the runtime buffers each transaction’s changes, executes many updates speculatively and checks whether their reads and writes conflict.
If 9,000 of 10,000 updates are independent, the system can commit those 9,000 in any order and discard or rerun the conflicting 1,000. This moves concurrency complexity from millions of creators to Epic’s much smaller language-runtime team.
Sweeney connects this architecture to concerts or worlds containing millions of simultaneous participants. Ten million people need not consume ten million full on-screen representations—there are fewer than ten million pixels—but networking, simulation and hierarchical approximation still require foundational work.

38. Unreal Engine 6 is where separate Epic research threads converge

Verse is already shipping through UEFN in frequent backward-compatible updates, with major APIs added every few months. Epic is intentionally testing it first among Fortnite creators before offering it to standalone developers who expect access to the full breadth of Unreal’s C++ surface.
Unreal Engine 5 development therefore has two partially separate fronts: conventional licensees and the Fortnite creator environment. Some engine features cannot yet ship consistently across Fortnite’s seven supported platforms, while UEFN has programming capabilities that evolve on a different schedule.
UE6 is intended to unite those threads: simpler gameplay programming, scalable simulations and the ability to build once for a Fortnite island, a standalone release or both. Standalone titles might also opt into Fortnite-compatible items and an open shared economy.
Sweeney says UE6 is “a few years away,” without an exact schedule; preview versions might appear in two to three years. The proposed architecture is aspirational and iterative, not a promise that million-player simulations or fully verified programs already work.

39. Indie leverage comes from tools, reusable content and specialization

For solo and small-team developers, Sweeney reduces Epic’s role to productivity: creators need enough leverage to finish, ship and maintain a distinctive game within a realistic budget. Gavin Eisenbeisz’s Choo Choo Charles demonstrates that a solo developer can even rely primarily on Blueprint visual scripting rather than C++.
Marketplaces such as Fab let teams buy or freely reuse trees, rocks and other generic assets, reserving scarce labor for the game’s unique design. Other specialists can earn a living selling those components, turning modular content into its own creator economy.
The industry moved from one person doing everything toward artists, gameplay programmers, engine programmers and technical artists with narrow expertise. Sweeney wants engines and AI to modularize more of that work so a small group can assemble scale without recreating every commodity asset.

40. Epic’s Apple fight is about who controls software after the device is sold

Sweeney’s baseline comes from the Apple II and IBM PC: buyers owned machines that invited programming, installation and direct distribution without corporate permission. Apple II documentation even included ROM source listings and the hardware schematic, enabling users to understand or extend the entire system.
He views mobile gatekeeping as a reversal. A customer has already purchased the phone, yet Apple blocks outside installation and direct developer commerce while charging a “30% junk fee” selectively on digital transactions; Google imposes a similar structure.
Sweeney argues the tax reshapes product design. Once stores, search ads and social acquisition consume perhaps 70% of revenue, manipulative whale monetization and pay-to-win mechanics can outcompete games built around fun, while an ordinary developer’s profit margin cannot absorb a 30% commission.
Epic could fight because Fortnite’s largest populations were on PC and console, so losing iOS would wound rather than destroy it. Most leading mobile businesses cannot survive removal, while approval delays and other Apple “soft power” can quietly worsen economics enough to deter public opposition.

41. The metaverse cannot remain open under mobile gatekeeper rules

Sweeney sees the Apple dispute as infrastructure strategy, not merely fee negotiation. A billion-user real-time ecosystem of peer developers requires direct customer relationships, competing stores and shared economies; Apple and Google can otherwise tax or prohibit each new layer.
Web restrictions illustrate the risk: Sweeney says Apple prevents browsers on iOS from implementing web standards better than Apple does and limits storage and 3D-graphics capabilities available to web apps. He fears a metaverse policy could similarly require Apple’s engine and exclude Unreal.
Europe’s Digital Markets Act formally requires Apple to allow competing stores, yet he says Apple’s conditions make them uncompetitive—for example, insisting a store remain only a store rather than integrate social functions. He calls the layered restrictions a Soviet-style “defense in depth,” where removing one barrier leaves several fatal ones.
Lex agrees Apple’s behavior is wrong but argues openness would ultimately improve Apple. Sweeney points to Sony as precedent: after harsh 2018 cross-play negotiations, Sony changed policy, then expanded its Epic relationship across games, movies, music and Unreal adoption while gaining rather than losing market share against Xbox.

42. Epic Games Store concedes product weakness but defends 12% economics

Sweeney’s blunt admission is that people call the launcher clunky “because the Epic Games Launcher is clunky.” Performance varies by CDN proximity and library size, but Epic under-prioritized load times and quality-of-life work while implementing commercial features requested by publishers.
Epic does not intend to copy every Steam feature, such as store-specific forums when developers prefer Discord, Reddit or their own communities. It does want equivalent convenience, remains committed to a multibillion-dollar business and expects cross-platform social infrastructure to become a differentiator.
The store’s core economic offer is a 12% commission versus Steam’s 30%. Trial evidence put Google Play’s all-in operating cost near 6% of revenue, with Apple likely similar; Sweeney argues a competitive business could not sustain a fivefold markup over cost.
Lex’s preferred destination is less exclusivity, better interfaces and competition that pressures Steam’s commission downward. Sweeney accepts the destination but asks what mechanism can overcome 15 years of user libraries when publishers fear offering lower prices on Epic because incumbent platforms may withdraw promotion.

43. Exclusives were an expensive attempt to create entrant differentiation

Sweeney distinguishes coercion from negotiated exclusivity. A platform forcing developers to use its payments blocks competition; Epic offering money, marketing or other incentives for voluntary timed exclusivity is, in his framing, competition among stores for a developer who retains ownership of the game.
Epic initially wanted lower consumer prices, but publishers feared consequences from Steam and console partners. It therefore competed on supply, spending more than $1 billion net beyond game revenue on exclusive deals; an entrant offering the same games at the same price gives consumers no reason to switch.
Results varied. Borderlands performed strongly because committed fans followed it, while smaller titles often lost Steam discovery and reached fewer buyers; once limited exclusivity expired, those developers launched on Steam and both sides gained evidence about which audiences were portable.
Lex preserves the disagreement: even voluntary exclusivity conflicts with the freedom Epic champions and resembles podcast platforms buying closed distribution. Sweeney replies that incumbency cannot be challenged by polish alone, particularly when “soft power” prevents price competition; the conundrum remains unresolved.

44. Social games are concentrating attention while stand-alone hits become vacations

Sweeney’s first law of the industry is almost embarrassingly basic: “People play games for fun.” Recent failures generally did not deliver enough fun relative to alternatives, while competition for talent has weakened publishers whose best developers migrated to leading game companies or big technology firms.
Social play changes demand. Twenty friends may each prefer a different solo game, but will converge on one acceptable multiplayer title because playing together is more valuable than individual genre preference; Metcalfe-style effects then reinforce the largest communities and their reinvestment capacity.
Fortnite reached an all-time high around 110 million monthly active users, while Roblox also continued growing. Sweeney sees a winner-take-all loop: thousands of internal developers and tens of thousands of creators can improve an ecosystem at a scale inaccessible to a conventional smaller production.
Exceptional stand-alone games remain viable as “vacations” from persistent social worlds. Black Myth: Wukong is his example of a distinctive achievement players visit and then leave; a $40 million production may generate strong returns, whereas attempting the same finite experience at $300 million can destroy the economics.

45. The greatest games create worlds with a detectable soul

Sweeney is most impressed by games that feel alive beyond the player’s immediate path: The Legend of Zelda: Breath of the Wild, Skyrim and Red Dead Redemption. Lex also mentions Civilization. Lex, rather than Sweeney, relays a classmate’s observation that Red Dead’s rivers reflect plausible erosion and hydrology.
Sweeney has not designed a game since 1992 and keeps an intentionally open view: “The best game genre that will ever exist has not yet been invented.” New graphics, CPU, networking and creator capabilities repeatedly make previously impossible genres practical, as Doom did for deathmatch and later technology did for Battle Royale.
Different productions also express different souls. Fortnite’s mystery, stylization and bloodless teleportation make even defeat humorous or admirable; Sweeney contrasts that good-spiritedness with games whose tone encourages players to perform constant edginess.
Rockstar demonstrates why boundary-pushing games take years. Fixing one unrealistic system exposes another, making schedules unknowable; “a bad game is bad forever,” while a delayed game can eventually arrive excellent. Epic’s live cadence creates a different pressure, with seasons only becoming holistically judgeable in their final month.

46. Embodied cooperation gives Sweeney more hope than social-media text

Sweeney contrasts two digital worlds. Engagement-optimized social networks promote anger, politics, hustling and toxicity, while voice-connected Fortnite squads—often composed of strangers—produce interactions he finds overwhelmingly positive and endearing.
His inference is that people sharing a real or simulated space encounter one another as humans, activating empathy and social norms that text strips away. Even Discord communities can become toxic in writing; playing, speaking and solving a common problem creates a markedly different dynamic.
That difference anchors his optimism about Epic’s work. More realistic social worlds matter not because people should abandon reality, but because they can carry more of physical presence’s empathy into digital interaction: “Humans talking to humans and being together” is, for Sweeney, a naturally connective medium.

#467

Humans are by far the hardest part of computer graphics because millions of years of evolution have given us dedicated brain systems to detect patterns and faces and infer emotions and intent. Cavemen had to determine, when they saw a stranger, whether that person was likely friendly or might be trying to kill them. People have extraordinarily detailed expectations of a face, and we can notice imperfections, especially imperfections arising from computer graphics limitations.

One part is capturing humans. They built really advanced, dedicated hardware that puts a human in a capture sphere with dozens of cameras in it, taking high-resolution, high-frame-rate video as they go through a range of motions. Capturing the human face is complicated because of the nuanced detail of our faces and how all the muscles, sinews, and fat work together to give us different expressions. It's not only about the shape of a person's face, but also about the entire range of motion that they might go through. So that's the data problem.

There are a lot of other problems in computer graphics. There's technology for rendering hair, which is really hard because you can't render every hair. Again, we know the laws of physics. It would be easy to just render every hair, but it would be a billion times too slow. 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 are detailed features for different parts of faces. There's subsurface scattering, because we think of humans as opaque, but really, light travels through our skin. It's not completely opaque, and the way in which light travels through skin has a huge impact on our appearance. There's no way you can paint a mannequin to look realistic like a human. It's just a solid surface, and we'll never have the sort of detail you see.

Lex Fridman

That kind of blew my mind, thinking through that. I think I heard that the oiliness of the skin creates very specific, nuanced, complex reflections, and then some light is absorbed and travels through the skin. That creates textures that human eyes are able to perceive, and it creates the thing that we consider human, whatever that is.

All of that happens while considering all the muscles involved in making the nuanced expression—the subtle squinting of the eyes or the subtle formation of a smile. It's the subtlety of human faces that you have to capture, like the difference between a real smile and a fake smile, or the way to show the beginning of a smile that actually reveals a deep sadness. All of that—when I watch a human face, I can read that. I can see that. You have to have the tools that can render something like that in real time, and that's incredibly difficult.

#467

That's right. Getting faces right requires the interplay of literally dozens of different systems and aspects of computer graphics. If any one of them is wrong, your eye is completely drawn to that, and you find it on the wrong side of the uncanny valley.

The following is a conversation with Tim Sweeney, a legendary video game programmer, founder, and CEO of Epic Games that created many incredible games and technologies, including the Unreal Engine and Fortnite, which both revolutionized the video game industry and the experience of playing and creating video games. This is the Lex Freedman podcast. To support it, please check out our sponsors in the description. And now, dear friends, here's Tim Sweeney.

When did you first fall in love with computers and maybe with programming?

#467

I had a brother, Steve Sweeney, who was 16 years older than me. At some point, when I was a little kid, he went off to work in California for a tech company. He'd gotten one of the first IBM PCs. So, for one summer—I think I was about 11—I went to visit him in California. It was my first trip away from my family, just to hang out with him, and he had this brand-new IBM computer.

I learned to program in BASIC over the course of a few days, and I was just blown away by the capabilities of computers at the time. It was unbelievable what they could accomplish, and I was hooked from that point onward and very much wanted to be a programmer.

Do you remember what you wrote in BASIC? Was it video game-type things? Was it a FOR loop, some numerical thing? What do you remember?

#467

Yeah, it's funny. I have a perfectly vivid memory of all the first things I learned to program. I have a hard time remembering people's names, but code really sticks with me. Every step and every challenge—there were lessons learned. Some of those, I've come to realize, were just me getting over learning hurdles, but other things were actually shortcomings of programming languages. That led to the realization that there are actually better ways.

When a programmer is learning to program for the first time, a lot of what they're facing isn't the challenge of learning a new art. It's the friction introduced by failures of programming-language design. I've constantly come back to those early lessons as I've progressed and done more and more things, including building programming languages.

The friction and the pain are the guide to learning in programming. If I were to describe my programming journey, it would be marked by pain, and you shouldn't escape that pain. The pain is instructive for you to understand programming languages.

But do you remember what kind of stuff you were writing at that time, just the early programs?

#467

Yeah. In the early days, I wrote a little bit of everything. I wrote some games. The first game I wrote on the Apple II was—since I only knew how to program in text mode—the computer would throw asterisks across the screen. They'd flow from left to right, and you'd have a parenthesis on the right-hand side of the screen. It looked like a baseball mitt, and you were supposed to catch the asterisks. That was my very first game. It took a couple of hours to build and tune.

I built a lot of things. I built databases at different points. I built a programming language and a full compiler for a language like Pascal because I didn't know where you went to buy one of those, so I made my own.

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 dialed into a local phone number and connected to whoever was running the computer there. Every town or city had hundreds of these bulletin boards, run by different people with their own personalities and themes.

I spent a lot of time building a bulletin board program and learning how to deal with database management and user interfaces, multiple users concurrently, and things like that. I probably spent about 10,000 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.

What was the value of the hours you put in as a kid programming that led to the success you've had in later life? Maybe this is by way of advice to younger people in terms of how they allocate the hours of their early life.

#467

Yeah, it's not just hours. It's really striving to learn, to understand what knowledge you have, what knowledge you lack, and to continually do experiments and work on projects that improve your knowledge base. I didn't do this with a great amount of structure or planning. I was rather just going from project to project, doing things that I thought would be fun and cool.

With each project, I learned new things: how to store and manage data, how to deal with advanced data structures, and how to write complex programs that have deeply nested data and control flow. Each one of those provided a lesson, which was later essential.

In 1991, I released my first game, and over the course of that decade, we went from 0 commercial releases to the first-generation Unreal Engine. This was largely just using the knowledge that I built up over the previous decade, doing fun hobby projects. If I hadn't done all that work, there's no way I could have ever built the things that came later.

All the experimentation and all the exploration somehow contributed and somehow made sense later on. All of that is integrated somehow in the stuff you build. It's funny how life works—the pieces kind of come together eventually.

#467

Yeah, there are definitely Karate Kid moments. All this time, I was learning math in high school and in college. I studied mechanical engineering, and so you learn all kinds of math: vector calculus and vector math, matrices, and related fields—physics, stress and strain, and how to deal with complex physical systems.

I wasn't really sure how engineers would actually make use of that knowledge. Do you just forget about it when you go off to do work, or do you write down equations on paper? It wasn't actually clear as an early engineering student what you do.

But when I started writing the first-generation Unreal Engine and dealing with 3D math, I was like, “Wait, I know this stuff. I learned this.” Suddenly, like in The Karate Kid, you get to paint the fence and wax the car, and suddenly put all the pieces together into a 3D engine based on a whole lot of accumulated programming-language and math knowledge—often knowledge gained without ever anticipating that I might use it in that way.

Also, I think what's useful is repeatedly learning a hard thing and then showing yourself that you can do it—that you can learn a hard thing.

So then, when you come to having to write a 3D engine in ways that haven't been done before, you're like, “I've been here. I've been here in this experience. I don't know what to do, but we'll figure it out. We'll learn. I'll learn all the necessary components.” So, just not being afraid of something new.

#467

That's right. And constantly striving to make connections between these fields and look for their applications. Long after I shipped Unreal Engine, it was like going back through an engineering textbook and looking at, “Oh, yeah, I use that. I use that. I use that.” And then I got to the section on eigenvectors and eigenvalues, and I'm like, “I don't know what the hell this is.”

But it turns out eigenvectors and eigenvalues were the critical breakthrough that made Google's search engine technology work and stand apart from the rest. They found that if you threw all the links that existed on the web—links from and to different sites—and put them in a giant matrix, then computed it and found the dominant eigenvalues, those vectors described the best search results for different things.

So, constantly picking up knowledge and looking for ways to put it together is the thing to do. 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 you have, the more chance you have of putting it together and being successful. Whether you're a programmer or an artist, you should probably take linear algebra, even though it doesn't make sense at the time. I found getting an engineering degree and then never working in an engineering field—just being a computer programmer—was immensely valuable.

I went to the University of Maryland, which for some disciplines is kind of known as a party school, but they work the engineers to death. They worked us really hard. If you learn any engineering discipline, you learn massive amounts of math, and you learn the rigor of problem-solving—not just what you find from the Wikipedia article, but going through all the exercises of solving complex problems and building up a series of solutions to derive an answer.

It's valuable, and it embodies the knowledge that you need as a programmer. People often go to university and think, “Okay, my goal here is to get good grades so I get a diploma and 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 learning that's really valuable in a career.

And especially if you're going to be entrepreneurial, it's really knowing the stuff that matters and not having the diplomas. There's ever more pressure to rebuild society more and more around credentials. Do you have this certificate? Do you have that proof? But companies that are focused on just building great products and doing great things gravitate toward people who do great work.

#467

Yeah. One of the great things about youth is there's more freedom. There's just more time to learn. People, when they go to high school, sometimes think, “Why? I can't wait to get out of this and be an adult and be free.” But it's not quite freedom. When you get a job and start a family—all wonderful things—you get more and more busy and less and less time to learn in the general sense, to learn whatever the hell you want.

That is a wonderful time in life: the teenage years, the early 20s, the 20s, when you could just learn random shit. I think this is something that's kind of changing in America. There's so much focus on grades and homework and structure around kids' lives.

When I was growing up, my mom would feed me, and my neighbors' moms would feed them breakfast, and they'd be like, “Well, be back by dark.” We'd go out and play and do all sorts of things. We'd explore the woods. We'd build go-karts. We'd salvage old pieces of electronics and build what we thought were our spacecraft control panels for the fake spaceships we were building as play.

We'd have an enormous amount of freedom. 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 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 have neighborhood folks over to play the things I was working on and check them out. Sometimes they were impressed, and sometimes they weren't. They'd have their own projects, and often we'd have spare-time jobs. 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. The freedom there and the organic learning that occurred there, I think, is something that's 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.

So, on the video game side, when did you first fall in love with video games?

#467

I've had a funny relationship with games, because my real aspiration has always been to program cool stuff. I get more enjoyment out of programming than anything else in the world. My first 2 formative experiences with games were playing this game called Adventure for the Atari 2600. You moved this dot around the screen, picked up objects like swords, fought dragons, invaded castles, and solved puzzles. Very simple, iconic stuff, rather than realistic graphics.

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'd type in commands like “go north,” “pick up sword,” or “open door” and explore a world that way. The game didn't have any graphics, but in your mind you had this elaborate picture of what you were seeing there. It really inspired imagination more than other things.

Playing those games led me to want to learn to program everything that I saw there. That drove a lot of my programming. I learned how to move a player around the screen, and I learned how to build a design tool so I could build castles and save them off and then play them in a game.

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. I learned all the programming techniques that supported games: how to parse text, like “pick up sword” and “go north.” How do you make that sentence into an actual series of commands on the computer? That was really, really exciting.

Until Fortnite came out, I played video games primarily to learn what they were doing so that I could go off and do that myself. I'd sit down when Wolfenstein came out, and then Doom came out, and I'd go through and look at it pixel by pixel. I'd move the mouse very slightly and look exactly at what was happening to figure out what technique was being used there. That was puzzle-solving at a grand scale, and it was so fun.

So, take me there in the early 1990s. You launched Epic Games in 1991. The writing of your first big video game, ZZT—what was it like? What were the technical challenges? What were the psychological challenges of building that?

#467

It was a funny project, because I didn't start out to build a video game. I had just moved from an Apple II. My brother bought my family an Apple II right after I'd visited him in California. I'd done programming on that for a few years and learned a lot of techniques, but there weren't many Apple II users around still by the time that cycle came to an end.

So, I got an IBM PC of my own. I was learning to program, and I realized I needed a text editor. I started writing a text editor. A text editor is a program to edit text files. You have logic to move the cursor around and let people type things, backspace, delete, and do all those mundane actions.

One night, I finished it up and thought, “Well, okay, I have a text editor, but this is pretty boring.” So I made the cursor into a smiley-face character, and I had the different characters you could place in this document perform different gameplay actions. Some would be walls, some would kill you, and some would be moving objects that could fly around the screen.

This text editor I made evolved into a little game editor. 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 were 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; 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.

#467

I built this whole game world around that. This was the game that became ZZT. 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—some adults, some kids of all different ages—and I sat them down in front of it and said, “Here's a game I made. Figure it out.”

I had to force myself not to tell them what they needed to do, because I really wanted to learn if they were able to discover it all for themselves. Today we 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, what they enjoyed, and where they felt bored. I iteratively polished the game until I felt it was good.

I put it out and released it—this was before the internet, so there were bulletin boards. I uploaded it to a bunch of local bulletin boards, and from there it started spreading. The way to build up credibility for bulletin board users was to upload new files and claim that you were the first to bring them to the community, so there was a natural tendency for the software to spread.

I decided to use the shareware model, so I didn't just build this one game. I built a trilogy of 3 games. I released the first one for free and said, “Hey, if you like this, buy the 2 sequels.” I included my parents' mailing address and said, “Send us $30 and you can get the sequels to this game.” The checks started coming in within a few days. I was getting 3 or 4 orders a day and making about $100 a day. I was like, “Woo, I'm rich!” Because being 20 years old, that was a pretty big deal.

What did that feel like, just getting money and probably feeling this immense success from something you've created?

#467

I've always looked at money as a tool to help you fund accomplishing cool things. Having enough to do the things you want to do is the critical thing. It's always been just very utilitarian.

But the knowledge that other people all around the country and then, a month later, all around the world were playing the game—that was mind-boggling. That I, this little kid who'd put out a game on a local bulletin board, could be doing international business and shipping discs all over the world to players because the software was spreading on its own was just magical.

That was a new thing for software. That did not happen with mechanical devices. You manufactured one, 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 a business like that.

We saw Microsoft as a big juggernaut company at the time. But I thought, “Hey, if Epic made games good enough, we could accomplish what they'd accomplished with operating systems.” The sky was the limit. 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, can reach the entire world and build the next Microsoft or Meta or Apple or Google or Epic Games.

It's such a cool origin story, though. You start out building a text editor, so you're looking at this project, playing around with it, and building up the tools. It's such an inspiring moment, because a lot of us start out building a project, and to allow yourself to see the potential pivots, the potential trajectories that can happen, is really nice.

You sit back, allow yourself to be bored, and say, “Ah, I'm going to go this way.” I mean, that's a crossroads. You came to a crossroads. You built compilers, designed your own programming language, built databases—all these things you mentioned—and you started building a text editor. Then it came to this crossroads: “I'm going to make this fun.” From there, one of the most legendary gaming companies was created.

It's kind of cool. That's an inspiring thing for developers: be open to the possibility of creating something you didn't plan to create and just go with it, right? That's cool.

#467

Yeah. A bunch of learnings emerged really quickly there. The neat thing I did with ZZT was that I didn't just release the game. I also released the editor with it. I built this tool so I could make these ZZT boards that people could play, but I also gave it to all the players themselves.

Thirty years later, I still run into people when I go to a game industry event. They're like, “I grew up playing ZZT.” Here's an adult who grew up playing my game, and it was because it enabled anybody to become a creator, too. It had this little board editor, and it also had a little scripting language, so you could learn a little bit of programming in it, too.

It really impressed me and 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 they can build their own amazing things, too.

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. 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: 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. Sometimes the engine's been funding the business because we didn't have a game, and sometimes the games have been funding the business. It really set a principle in our culture that has persevered and is continually brought to the forefront.

But on the editor front, that's such a fascinating philosophy: that you always allow people to create their own worlds. You have an engine from which you simulate the world that the game is in, you have the actual game, and you also have the freedom for creators to create various Fortnite islands of their own. With everything you ship, that freedom to create is always there. That's really interesting.

#467

Yeah, and it's something we aim to do more and more fully over time. In the course of building Fortnite, we've built a lot of other tools that are useful for us, too. It's not just a game powered by Unreal Engine, but also a social ecosystem where people can make friends, voice chat, get together in parties, and so on.

We've opened up all of those social features in Epic Online Services, and we give them away to all developers for free because we all benefit from growth in that user base. Our goal is ultimately to build the company's products on the same technology that we share with everybody else and to help foster a bigger and bigger ecosystem over time where everybody benefits.

If we could just linger on the '90s. You said bulletin boards. Maybe you can explain what that's like and also explain the birth of the internet. What was the internet like in the '90s?

#467

The internet is a funny thing. It started out as this Defense Department research project called ARPANET, the Advanced Research Projects Agency Network, and it was like this revered secret thing. It became more and more open as universities connected to the internet in the mid-1980s. If you were at a prestigious institution with access to computers, you could get on there.

But as consumers back then, we just had these modems. This was a thing you plugged into your phone line. It dialed up a phone number, and then it sent wild sound effects over the telephone line to send digital signals back and forth.

These were really slow. The first modem I had was 300 baud. That means 30 characters per second of data. You're sitting there watching a sentence slowly emerge character by character as you're going online. But that's how we got online and talked with each other.

You'd dial up to a local bulletin board. It would be run by a person. Usually, they had a computer or 2 sitting in their kitchen or something that was running the bulletin board, and they had 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. The more popular bulletin boards were the hardest to get to.

Nice.

#467

We had all kinds of communities develop. There were programming communities where people talked about programming. There was the news and events community. I lived on the outskirts of Washington, D.C., so that was a big thing. But then there was the pirate community, where people were sharing pirated Apple II games.

There were very different community ethoses and mantras out there, but they were all really nice and also very small. These boards couldn't grow to the size of Facebook because your phone line couldn't take that many calls. Then, later in the 1990s, the internet, which had been fostered in these colleges, started opening up to the public. Anybody could connect to it, and suddenly the world took on a life of its own.

#467

It became much easier to reach a global audience faster, and you would start shipping games over the internet, which is a bit of a crazy thing to do because you were supposed to have a physical copy. To post on the internet was pretty innovative. Even shareware was pretty innovative.

It’s been a funny transition for the game business. Epic started out making shareware games distributed digitally. But as the first 3D games took off—like Wolfenstein, then Doom from id Software, and then Unreal from us—we had to go into retail stores to reach a huge audience of millions of users. So we worked with a retail publisher, and they made a box and put CD-ROMs in the box.

Then the world started transitioning back to digital, and that transition didn’t start well. The initial transition of gaming to digital was all BitTorrent, all piracy. There were horror stories about games that would sell 100,000 copies but have 2 million users because most people pirated them.

Then Steam came along, introduced digital distribution, and made the digital distribution of legitimate games so convenient that most players moved away from piracy toward that. Those practices were then followed by others, and the early digital industry took form.

Lex Fridman

It’s fascinating. Pirates do lead the way for innovation, the same as the story of Spotify. I think most people, when they derive value from things like video games, want to pay for those video games. They just want it to be easy. It’s the same thing with music and Spotify.

Maybe just staying on the ’90s, there are going to be a lot of indie game developers who listen to us talking today. Can you go back to that mindset and try to derive some wisdom and advice for those folks? When you were just a solo developer, or maybe just a small group of people creating your early games that eventually became this huge gaming company, what were you going through in the early days? What were the ups and downs? What did it take to stay strong and persevere?

#467

One of the critical things that Epic always worked hard to do was make something different that nobody else was doing. We tried to satisfy a small audience rather than competing globally with the game juggernauts.

Back in the 1990s, Epic was new, but Electronic Arts, Activision, and the other big publishers had been around for a decade, and they were huge companies. They had giant retail distribution networks. If I tried to make a game and then convince them to publish it, I doubt I could have had a chance. I doubt that, even if I made a successful game, I would have made much money from it, though they might have.

The really unique angle to Epic then was shareware. That was the idea that, if we distributed our game differently, then we could reach a much larger audience than these bigger competitors by virtue of the first episode of the game being free. It was kind of the advent of what later became free-to-play.

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.

The other lesson there was to minimize the friction of people getting into your game. Make it easy to get into, and make it fun.

I think the other thing is that I was very fortunate. ZZT was a funny game. It was not 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.

This was decades into the age of real graphical games with interesting graphics, so it wasn’t even trying to compete in that area. But it was able to compete in a different area. It wasn’t just the 3 games 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.

You see that trend repeated itself. Before ZZT, there was Bill Budge’s Pinball Construction Set. That was a 1980s Apple game that let users build their own pinball tables. Since then, you’ve had some of the world’s most successful games follow that path, like Minecraft, where you can build your own stuff; Roblox; Fortnite Creative; and Unreal Editor for Fortnite.

Games that become platforms for other people to build stuff are a real opportunity. I think the big thing for indie developers to realize right now is that there’s massive competition in every major genre. It’s very unlikely that, unless you just happen to be the world’s best at a particular thing, you’re going to release a game in an existing, highly competitive genre and win.

A much better chance of success is releasing something that hasn’t been done before, being really unique, and reaching an audience—even if it’s big, medium-sized, or small—becoming really popular with that audience, making some money from it, and being able to reinvest and then expand toward your ultimate dream.

The one-shot go from idea to commercial success at massive scale is a lot less likely than the multistep process of continually building better and better stuff over time until you get into a position of excellence. Constantly try to do something that others aren’t doing.

Yeah, that’s right. Because if you look at every market, there are a few markets where the current leader came late to the space, usually because the prior leader failed so horribly. But most of the time, the company that’s succeeding and winning in a market is the first or second entrant there. They’ve just continually built their success.

Great advice. Fascinating. But on a human level, was it lonely? Was it scary, sitting there as a developer?

#467

It was the opposite of lonely, because the thing that spurred me to actually release this was seeing kids playing the game in my neighborhood and having fun, being like, “This is really good,” and seeing them enjoying it, laughing and pointing at the screen, getting together, and just wanting to play more. That was awesome.

The human element was always pervasive. I not only received orders, but people would actually write letters. We wrote letters back then, in the 1990s. People would say how much they were enjoying the game and how their kids were playing the game, and so on and so on.

I felt very connected. A lot of businesses have to make scary decisions because you’re spending potentially all the money you have to take a shot at something that you’re not sure will succeed.

I was very fortunate starting a business like this because it didn’t really need any capital. The capital was 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 were enjoying the game, I knew I was going to go all out and try to build a company and succeed. That was going to be my big goal.

I’m sure people know, but Epic Games was created in 1991 and went on to transform the gaming industry several times. One of those transformations was Unreal Engine. Let’s talk through the origin story of that.

You said that when Wolfenstein and Doom came out, that changed everything. Take me to that moment.

#467

That was a very interesting time. After my first couple of games, Epic had recruited developers, usually college students and high school students who were just working on their own. They had real skills but didn’t have an outlet for their work.

Epic had been matchmaking the best artists and programmers together from all over the world. Jazz Jackrabbit was made by Cliff Bleszinski, a high school kid in California, together with Arjan Brussee, a demo coder from Holland who had made amazing graphical stuff and built a 2D game engine.

I connected them together with a musician, Robert Allen, in California. By telephone and modem, 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, in royalties from the games that Epic was producing by coordinating people and publishing through shareware.

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 that the future of gaming was going to be 3D.

There had been a lot of experiments in 3D before that 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. Then there were vector graphics with little wireframes moving around and things.

Wolfenstein was the first game that was fast enough—running at 30 frames per second—that it really felt immersive.

#467

It felt like you were there, like you were in Castle Wolfenstein, fighting Nazis. That was a really amazing and immersive experience. 3D graphics were pretty primitive then, but the software followed shockingly fast with Doom, which was a much, much more capable 3D engine. It had stairs, and although it was still what we call 2.5D, the environments had very realistic textures, a form of lighting that was approximate but incredibly realistic, and such great artistry and sound effects that it felt completely visceral and real.

You might look at it today from the point of view of a modern game player with 20 teraflops of computing power in your device and say, “Oh, that's not very impressive,” but it was amazing at the time.

I mean, for me, just to pause on that, I think Wolfenstein was one of the most amazing moments of my own life: just being able to, like you said, move about a three-dimensional world in real time. I remember just moving around, thinking, “What is that feeling like?” You feel transported into another world. You feel that you're there.

#467

Yeah, and especially when you turn the lights down in your room and turn the sound up on your speakers, it will scare you. You'll feel like that fireball that's coming at you is going to kill you. That was an amazing time because we hadn't experienced that before. There was nothing like that.

You'd watch a movie, a scary movie or whatever, but it was just this thing that was happening. This was you. This was you in a 3D world.

So how did that—how did that change Epic, this realization that the future of gaming is going to be 3D?

#467

Well, at first I was really depressed. I figured, because Carmack's wizardry, especially in Doom, was so incredible, that I gave up on programming for like 6 months. I was like, “I'll never be able to compete with this. I have no idea what we're going to do.” We'd just keep making 2D games and hope that the business goes on.

That was the nature of Carmack's wizardry. He had done things that were not just 1 innovative leap ahead, but a dozen simultaneously interplaying in a way that you couldn't pick them apart into their component pieces.

A funny thing happened. Michael Abrash, a longtime figure in computer graphics, wrote a book on the techniques for 3D graphics and texture mapping. He wrote some articles in 1 of the programming magazines of the day and explained it, showing assembly code to do texture mapping—drawing these 3D graphics on the screen. It was actually really simple stuff. I was like, “Oh, I can do that.”

A bunch of us at Epic independently went off and started writing our own 3D graphics code to figure it out. We found at 1 point that we had a number of people dabbling in this, doing different parts of it. At that point, we decided, “Okay, 3D graphics and 3D gaming are going to completely change the world. We need to go all in on this.” 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 trying different disciplines to see what they were best at. 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 Schmalz, who'd made Epic Pinball—this wasn't a crazy game; it was 1 of the 2D shareware games—made it while he was in college and was making like $30,000 a month from the royalties from this game because everybody had wanted an awesome pinball game. It was massively successful.

But he was a multidisciplinary person. He wrote the code for the game, the art for the game, and did basically everything. The code was 30,000 lines of assembly language, right? He was initially going to write the 3D engine, and I was going to write the editor. He sent me his code so I could integrate it into the editor. It was this giant pile of assembly code. I was like, “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. Cliff, who'd done a lot of design work and built the levels on Jazz Jackrabbit, went off and started learning the basics of level design. I was writing this editor, and Cliff Bleszinski was customer number 1 for it, starting to go off and build levels. James Schmalz was building awesome creatures, sending them to me; I'd get them in and implement them in the game, and then we brought in an animator to bring them to life.

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 really stretched 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. It was a crazy project because it was 3.5 years of development on a game that we always thought was 6 months from shipping. It was 3.5 years of 70- or 80-hour weeks for most everybody working on the project, not even knowing what problems we needed to solve next because we were so immersed in the current ones.

Were there moments when you were losing hope that this might take too long and the company would run out of money?

#467

We were—I was—we were always very financially stressed, so I was continually worried about that. I had total confidence that we'd work out all the technical and artistic problems because we knew the pieces, and it was largely a matter of typing code in and solving some problems. We knew we could ship a version of it.

The thing that was continually really interesting was the ongoing discovery of new techniques as we went. At the time, Quake had shipped; it had a little bit of dynamic lighting. Unreal really pushed dynamic lighting much harder than anybody else had done before. Then colored dynamic lights, with some shadow-casting capabilities—static or moving lights without shadows—and we figured out how to do volumetric fog.

So you could have foggy areas that were full of lights, and you'd 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.

It was really crazy, but I think most companies wouldn't have survived that. The sheer talent of the people involved made it possible, and that's something Epic has often done: things that most companies would have failed at, we succeed—not because of awesome management, awesome planning, or awesome financing, but because of the sheer talent and willpower of the people involved to make it happen.

What about the interdisciplinary aspect of it? Like you said, artists, engineers, or programmers, designers—all of them working together. What was that, the 20 people? What was the dynamic there like, working insane hours? What was it like to make a team like that work together well, as an orchestra, to actually deliver the game?

#467

That's 1 of the really unique things that exists in gaming, not in normal big tech companies, which are just engineering- and business-driven. Gaming really does require all the best people across all the creative disciplines working together.

Epic had grown organically by recruiting people with awesome talent. We always had a limited budget, but we could never pay to hire, bid up people's salaries, and hire them away by paying them more. We just had to find awesome people who were at the beginning of their careers and put them together.

Everybody was very new to this and didn't have any assumptions about how companies worked. 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 it out as we went.

But it was a constant iterative cycle. Every day we'd make several new versions of the game: build a new compile, introduce a new feature or fix some bugs, get it to artists, artists improve their levels, continue building stuff, and then we'd see what they were doing in their levels, like, “Ah, I see what you need.” We'd constantly be improving the tools.

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 1 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. That was the magic that happened together. There was really nothing but passion and everybody's individual dedication to it that made it work.

I heard you still program, but how much programming were you doing back then? You mentioned the hours, probably insane hours. It'd be fun to talk about your setup: what a day in the life of Tim Sweeney in the '90s, when you were building Unreal, looked like.

#467

Well, we'd all gravitated toward a schedule, a work schedule that maximized productivity, and that usually meant waking up late.

#467

I usually got to work around noon. I usually worked until 2:00 a.m. or so, and 3:00 a.m. sometimes. I didn't have anything else going on in my life, so it was really just work and sleep and occasional eating. I found I always needed 8 or 9 hours of sleep a night. Without good sleep, I would just become a zombie and wouldn't be nearly at my best.

I always needed to get sleep, but I didn't need anything else going on. The programming itself was so energizing and thrilling. It was 3.5 years of that during the project, mostly spent programming. I would say probably 60 hours a week of programming, 5 hours a week of coordinating with other people and iterating—sitting down with them, looking at what's going on on-screen, and figuring out what they needed—and 5 hours of business stuff.

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

What programming language are we talking about? You mentioned there's this pile of assembly. What was your decision in choosing the programming language that Unreal Engine would be written in?

#467

I'd grown up learning Pascal as my favorite language. In order to get maximum performance and the latest operating system features, I had to move to C for my second game, Jill of the Jungle, a Nintendo-style platformer. When I started Unreal Engine, it was on 16-bit Windows using the C programming language.

Over the course of the first year, it moved to 32-bit, using these DOS extenders and then Windows NT, and I moved to the C++ language. It simplified the code so much. We went from a really complicated pile of code to a much simpler one by making that transition. The entirety of Unreal Engine development—about 2.5 years of it—was all in 32-bit C++, completely state-of-the-art then.

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 it turned out to be a pretty good bet, because C++, out of all those languages, ended up being the dominant performance-oriented language that survives to this day.

#467

Yeah. It's because it solves all the problems at scale, often through manual pain, but it always solves them. A lot of other languages do better in a lot of theoretical aspects and are better for some use cases, but you can't do everything, and that's really very limiting.

All right, ridiculous questions: did you have 1 monitor, 2 monitors? Were you picky about the keyboard? Were you picky about the chair? What are we talking about? Let's paint a picture.

#467

I went through a big transition there. I started out being pretty lazy. I'd bought used computers, because you'd often get them at half the price of a new one. They'd be good enough. So I had this old 486 I was developing on with, I guess, a 15-inch monitor at the time. It was a poor workstation setup, but it was very economical.

As we started on Unreal, I realized that I had to write a ton of code and write it at absolute maximum productivity. I had to rearrange my entire life around delivering maximum output. At that point, I realized that spending money on getting good equipment was a good investment. 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.

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 1,920 by 1,200.

Wow. In 1996.

#467

In 1996. That was pretty cool. So I'd upgraded to a 90-megahertz Pentium, programming on that. These were the main consumer computers at the time. I'd optimized the Unreal Engine software renderer on that. The Pentium was the first superscalar architecture in consumer computing. It could run up to 2 instructions at a time, and if you wrote your assembly code very carefully, you could get absolute maximum throughput.

I'd gotten my texture-mapping code down to 6 CPU cycles, comprising 11 instructions. That was required for every pixel on the screen, and that was just enough performance to deliver it. Then Dell came out with these new workstations, and Intel had just launched the Pentium Pro, the first out-of-order processor. I basically bought the absolute maximum configuration that money could buy. It cost $7,000. I had a gigabyte of memory in 1996 and a 200-megahertz CPU, so it tripled the speed of compiles and just made me massively more productive. That's what I was using throughout Unreal Engine development, and it shipped with that.

By the way, people in the '90s would have been blown away by this work. I love it.

#467

Yeah, yeah.

In writing, were you considering the hardware much? Was there a sense—so, for people who don't know, Unreal Engine rendering, I guess, is all software. It doesn't use the hardware. Were you trying to optimize to the hardware at all? As I understand it—maybe you can correct me—were you trying to optimize to the hardware at all?

#467

At the time, we did most Unreal Engine development before the first real GPUs came out. The 3Dfx Voodoo 1 was the first GPU that actually delivered serious performance compared to software rendering. The first GPU that was really powerful came at the end of development, and we supported it really quickly, but it was not the target all along.

Development was focused on building the 2 parts of the engine. There were all of the gameplay systems that managed the simulation, physics, and so on. 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.

The one thing that was really a bottleneck was graphics. The cost of rendering a single pixel was really high, so you had to do everything you possibly could to optimize the rendering of pixels on-screen. We were talking about CPU cycles. When you say your CPU runs at a gigahertz or whatever, it's a billion instructions per second. How many instructions do you need to run to get a pixel on-screen? There was a constant challenge to optimize that down.

There was also a competition among all of the graphics programmers. We'd often send emails bragging to each other about what new technique we'd discovered to try to get the cost down. Abrash's original algorithm took about 12 CPU cycles to render a pixel, and everybody else had figured out how to get it down to 6 or sometimes even 4 cycles. That involved lots of different trade-offs of caching, memory hierarchy, and so on.

It was a magical time when a human could actually understand exactly what the CPU was doing under the hood and could write code that exactly targeted that. That's largely lost now. Some people miss it; some people don't. The programmer had absolute control over the machine and could work miracles in special cases if they tried.

It seems like there's still value to that art when it comes to GPUs and ASICs—basically, trying to understand the nuances of the hardware and how to truly optimize it, whether it's for machine learning applications or for ultra-realistic real-time graphics applications. Is that true?

#467

Yeah, that's absolutely so. The optimization problems have just moved around. A system like Nanite, the virtualized micropolygon geometry system that Brian Karis, a brilliant engineer with Epic, built, was one of those multiyear optimization efforts that required understanding everything from the highest levels to the lowest levels of the hardware to figure out how to make this breakthrough technique work in a way that was actually maximally performant on GPUs.

Nanite is the system—we'll jump around in time—that takes us to today with Unreal Engine 5.

That's the system that does the geometry.

#467

Yeah. So, rendering the world geometrically, there are many layers to this. We'll probably speak to each of those. But first, you have to actually create the geometry of the world around you and do that in real time and really efficiently. There's a bunch of different ways to optimize that. Can you just speak to it?

#467

With the advanced art tools we have today, it's really easy to create a scene with billions of polygons. The hard part is how to render it efficiently, because you can't render billions of polygons in a frame. Basically, you want to render an image that's indistinguishable from the full-detail geometry if you rendered it at ridiculous cost.

#467

And so, the challenge is how to simplify every component of the rendering—the geometry, the lighting, and so on—down to real-time techniques that are efficient and capture a realistic view of what’s around you. When an object is up close to you, you want to render it with a lot more polygons than when it’s far away.

One of the cool principles of mathematics is the Nyquist sampling theorem, which says that 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 as many pixels as there are in the texture that you have on the screen. That’s called the Nyquist limit.

One of the challenges of computer graphics is that, given the need to render objects at extreme close-up distances and extreme faraway 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. With geometry, the idea is that if you render 2 triangles per pixel, you should get an image that is indistinguishable from thousands of triangles per pixel. If you render fewer than 2 triangles per pixel, you’re going to start to see visible artifacts from the loss.

GPUs have amazing hardware in a lot of different pipelines, but it’s all very fixed-function. There’s pixel shader hardware, geometry-processing hardware, and triangle-rasterization hardware. One of the limits of GPUs is that the triangle rasterizers are built for pretty large triangles. If you’re building or rendering a triangle with 10 pixels, that’s pretty efficient, but if you’re building or rendering a triangle with 1 pixel, it’s very inefficient.

One of the breakthroughs Brian made was to design an entire pipeline for avoiding the rasterization hardware in the GPU and going straight to pixels, calculating what should be done with that pixel as a result of some ray tracing and geometry-intersection calculations done in a pixel shader. Instead of using the triangle pipeline, we’re just using the compute pipeline and getting a better result because of the limitations of the triangle rasterizer in GPUs.

That’s fascinating because, as you described, you need the tiny triangles for the detail, for the stuff that’s up close. This might seem obvious to people, but it’s not just stuff that’s up close. It depends on where you’re looking. The human eye, the human focus, and the human attention mechanism define how much detail you want to show, because the thing that the human is likely to be giving attention to, you want that to be super-high-resolution.

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

#467

Yeah, that’s right. But there are a lot of challenges like that. It turns out it’s a lot easier to render 1 frame that looks perfect than it is to render a series of frames in motion that look perfect.

A lot of the problems with the earlier algorithms that aspired to do this sort of thing involved popping. You’d be rendering some number of triangles for a while, and then you’d switch to a different number of triangles and see a visible transition. The screen would look like it got shaken up. It’s a disturbing artifact that distracts you from the game.

One of the magical trade-offs of Nanite was how to avoid all the visible transitions and get them down to a point where, although they exist statistically, they’re not really perceptible to a person looking at it.

When you look at something like Nanite, there’s a nice blog post and nice descriptions about the details, but you can tell that even underneath the details, there’s just incredible engineering that goes on. It’s so cool how, underneath the actual experience of beautiful, detailed scenery, there’s incredible engineering to bring you an ultra-realistic simulation of reality in real time—lights changing, everything.

It just takes you back to that feeling I had with Wolfenstein, but more. You can completely lose yourself in that world, and you would forget that this real world exists. What is the real world anyway? That coupling of great engineering and great storytelling, in terms of just feeling, is super cool.

It’s great to know that there are these teams behind it. 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.

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 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 game engine, not the game.

#467

Unreal Engine is a big bundle of code and tools, a huge software package that provides all the functions you need to build any sort of 3D graphics application. Game developers use it to make games, and that’s the predominant use, but it’s also used in Hollywood film and television production to create 3D scenery in real time for production sets and to do previsualization.

It’s used by carmakers to visualize their cars before they’re constructed or manufactured. It’s used by architects to preview buildings before they’re made, and by industrial designers of all sorts.

It provides all the 3D simulation features you need, both for creating highly realistic 3D graphics and for physics and interactions between objects, making things happen like you might see in the real world. It supports a huge variety of styles, from Pixar-stylized movies to cel shading to photorealism. It can be used for anything that needs real-time 3D graphics, including humans that populate those three-dimensional worlds.

We’ll probably talk about a bunch of the details involved in the process of creating ultra-realistic humans, because we humans care about how other humans look, how they convey emotion, and how they express themselves when they speak—all that kind of stuff. But yes, it’s the 3D objects that are static, the 3D objects that are dynamic, and on the dynamic front, humans that are ultra-dynamic.

You have to create this engine that simulates that world—the beautiful world that we know and love.

Okay, so you’re early. You see Doom, and you’re trying to create this world and an engine that would not just power Unreal, the video game, but future video games. How do you go about it? What are you thinking?

That is a crazy bet: “We’re going to build an engine as a company.”

#467

The philosophy began with ZZT and continued onward. We’re not just building a game for players to play. We’re also building tools that could be used for building that game or any other game, and catering to all the artists and designers who had used the tool.

That philosophy started in the very early parts of Unreal development. I was building the tools for level designers like Cliff Bleszinski and artists like James Schmalz. As we began marketing the game, thinking it was 6 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 wanted to license our 3D engine. 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, “Oh, you want to license what? What’s an engine? What engine?” They explained to him what they wanted to license. “Oh, that engine. Yeah, that’s very expensive.”

This was one of the critical things that kept Epic going through those 3.5 years. We were starting to license our engine out to other developers. MicroProse took 2 licenses, and we got half a million dollars from that. GT Interactive licensed our engine to build another game, and we got paid for that.

We had this revenue stream funding the development of Unreal Engine from other games that were being built by other developers. 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. That set this dual spirit of Epic: technology and supporting game developers, simultaneous with building games and supporting gamers.

It’s continued onward and just grown over time.

Can you go back to that? You were programming. What are some interesting technical challenges you had to overcome? You mentioned dynamic lighting, creating this three-dimensional world, and trying to figure out the puzzle of how you actually do that at a time when nobody knew what John Carmack and you were doing.

It was a totally open Wild West. What are some interesting technical challenges you had to try to solve?

#467

There’s a lot. Some of them are visible on screen, and some are behind the scenes and still require a lot of innovation. All the graphical techniques were really interesting challenges.

#467

Unreal Engine in those early days went a lot further than the Quake engine in building environments using constructive solid geometry with a real-time editor. That was a really interesting technical challenge. Building is extremely tedious if you're only adding objects to the world. If you want to build a door, then you need to add a dozen different pieces of door frames and a bunch of different walls to fit together in the right shape.

It would be easier if you could just start with a wall and subtract the door out. We had this way of adding geometry to the world and subtracting geometry, and the engine would perform all the calculations on that. This was something that I'd been anticipating was possible for a long time, but when I finally got around to it, it took a 30-hour coding session to figure out all the special cases of the code that needed to be implemented to make it work.

In the course of 30 hours, I got constructive solid geometry up and running. The next time we were together, I handed it to James Schmalz. He said, “Okay, I think you're cheating here. So you create a giant torus, then add another giant torus interlocked with it, and then subtract a cylinder from it, and create this really advanced composite object with just 3 operations.” He was like, “Whoa, I can't believe this.” I said, “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.

Can you actually speak to that 30-hour session? From everything I know about computational geometry, doing this kind of thing from your perspective is not easy. What is it—the uncertainty, the open questions involved? Even just on the algorithm front, how to do that efficiently, and then the usual programming thing of debugging, suffering through the trickiness of it.

At that time, we didn't really have the tooling to visualize everything that's going on very well, and you were probably using some crappy editor. There was just a lot of friction here, so the 30-hour session is probably a rough one.

#467

Your brain works in different ways depending on your state. There are some things that require really working on a problem fresh, where you've put together a bunch of logical pieces and now you just need to write a whole lot of code to make it all work together and plumb a whole lot of data between a whole lot of different algorithms.

I think our brains have vastly more horsepower than we're able to directly access by thinking of what code to type next. After you've been working for a very long time, you can get into a sleep-deprived state where you have much more direct access to that low-level knowledge.

That's great, because there are symptoms of sleep deprivation that are well studied. One of them is short-term memory loss, so you're working without the easy recall of the code you just typed. But your brain is then freed to think about other problems.

#467

I'd built up this intuition over a very long period of time. The foundation for the subject is the binary space partitioning tree, a data structure invented by computer graphics researcher Bruce Naylor. Carmack had picked up on that and had used the technique in Doom to really great effect. I'd picked up on that, and Unreal was using this technique for all its graphics and rendering, but it was just additive geometry everywhere. It had a lot of overlapping polygons and was pretty inefficient.

I had the idea that if we had a BSP tree, there was a really efficient way to do constructive solid geometry. To do that, you had to break down the ways that different pieces of geometry can fit together. I broke it down into 14 different cases. Most of them are pretty simple, so you just crank them out.

As I got towards the end, there were some pretty complicated things, like how to deal with coplanar polygons. They're in the same plane, 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, to create really efficient geometry output?

I just plowed through it, eventually, through mostly deduction but some trial and error too. Sometimes you just have to try the possibilities and see what works. I cranked it out, and it worked. The next day I came in kind of weary, and I was like, “Oh, wow, this actually did work. It wasn't just a dream.”

So you're considering the edge cases too. That's the problem with geometry: there's probably going to be all kinds of weird polygons that you have to consider. You're imagining the edge cases and trying to see how not to create inefficiencies in the algorithm while still allowing for those edge cases.

#467

It's pretty easy to write software that's 99% correct. It's the 1% that's really hard, and that's where the devil lies in the details.

What about lighting?

#467

The funny answer is that we know the laws of physics, so it's actually really easy to do everything in computer graphics. But the direct solution of the laws of physics is immensely slow. What we're finding are approximations rather than complete solutions, because you need something that's a million times faster than the brute-force answer.

We should say that the physics of the scene is that you just take a bunch of photons and bounce them around. That's how light works. That's going to be very inefficient, because there's a lot of bouncing and a lot of photons.

#467

Yeah. Photon tracing is the subject matter that does brute force calculation of pixels on a screen from all the light in the scene. It works, it's correct, and it's just an implementation of the laws of physics. It's millions or billions of times slower than what we do.

Carmack had figured out how to do really cool lighting algorithms, including real-time lighting with objects moving around. I hadn't taken it very far. With Unreal Engine, I'd realized that we didn't have nearly enough computing performance on our CPU to compute the light of every pixel on the screen from all the light sources that affect it. We had a 6-cycle texture mapper, and we couldn't afford 30 more cycles for lighting. The answer had to be some approximation.

The one that Carmack had picked up on in the Quake engine was light mapping. Instead of calculating all the lighting on every pixel, what if we made a big texture that we placed over all the walls in the scene, like wallpaper? What if we said that every foot, we're going to compute a lighting value for just that 1-foot grid on the object rather than computing it everywhere? If we just linearly interpolate that over the course of it, you get a lighting solution that actually works pretty well and is fast enough to work.

A lot of Unreal Engine's lighting techniques were based on light mapping. We introduced colored lighting, so you could have colored light sources. Then we realized that, since we were doing this on light maps, we could do some pretty expensive calculations—hundreds of cycles—since we were only calculating it for every 1 foot of world space rather than every pixel.

We introduced a whole bunch of elaborate lighting effects, like torch flickering and the caustic effects of water bouncing off a surface, as well as pulsing lights, blinking lights, and everything else. I created a system for compositing them together, so if you had an arbitrary number of light sources, they could all do that.

Then I implemented a shadowing algorithm. You cast a ray from a point on a light to a point on a surface and see whether it intersects any other geometry. If it doesn't intersect, then the light hits the object. If it does intersect, then the light hits something else first, and that pixel on the object should be dark.

I built a real-time version of this, and it ran at about half a frame a second. I was running around at half a frame a second, shooting out light projectiles and looking at dynamic lighting. It was like, “Someday computers will be fast enough for this, but not today.”

So I made a non-real-time version that pre-calculated all the lighting and realized, “Oh, wait. If you pre-calculate the shadowing for an object, you can still apply the lighting dynamically as long as the light's not moving.” You could do torch flickering with shadows. 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.

This was the wonderful thing. I was just typing in these little features and exposing them to artists. Every day they'd find a drop-down with some more lighting options available to them, and they'd start using them. They'd do things that I never thought possible.

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'll always find that you built the capability of doing vastly more than you ever anticipated. They start to use combinations of features together in concert to do ever more amazing things.

That's the genius of artists: they're given constraints, and within those constraints they create something you could have never possibly imagined given the constraints. That's such a beautiful coupling between engineering and artistry and art.

#467

That's right. And it's timeless. What did the Renaissance painters do with paints? And what did the early game artists do with early engines? Everybody's figuring out the capabilities of their medium, and you're seeing a revolution.

This is blowing my mind. This is so fun. What about fog? You mentioned fog. I don't even know how you do fog.

#467

So, you mentioned Unreal. The first version had fog. It was a funny thing. This graphics hardware company had just started up in Finland, and they released a screenshot of what their GPU was doing. They showed a scene filled with volumetric fog. You had a foggy room with some light sources in it.

When that happens in the real world, what you see are glows around the lights as the light brightens the fog around it. The brightening of the fog diminishes over time because the fog absorbs some lighting. The further you get away from the light, the more fall-off there is. You have a bunch of colored lights overlapping together in a space like that, and the effect is absolutely magical. It's like being out on a foggy night with street lamps above. It's surreal and 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." That was another 30-hour coding session.

Nice.

#467

But at the core, I realized that what's happening here is that we have this lighting function saying the light at a particular point in space is falling off with the inverse square of the distance from the light source. The inverse-square law is from Isaac Newton, which applies to lighting. What I had to realize was that the way the fog interacted with the light was that you calculate the view from your eye's position to a point on a surface in the world. It's going through fog, and you're accumulating more and more light as a function of the amount of light illuminating the fog at that point in time.

I had studied that in mechanical engineering without even knowing it. That's the line integral. You have an integral over a line of some function. This is exactly what it's for: accumulating the values of a function over a continuous space and time. I did a bunch of math and realized, "Oh, wow, the integral..." Then I looked in a reference book of all the integrals, and thankfully, people have solved them all. I realized that the integral of this transformed 1/r² turns out to be solved by the arctangent of r.

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. What we had to do was calculate volumetric fog on something equivalent to a light map, calculating fog every square meter in the world. We had enough performance for that, built volumetric lighting, and gave it to the artists. They started building magically detailed levels with volumetric fog in real time.

Decades later, I was talking to one of the engineers who had worked on that hardware. I 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."

Lex Fridman

That's awesome. That is so awesome. That is so inspiring on so many levels. You saw that maybe it was possible, even if it was kind of smoke and mirrors, and then you actually made it happen. It's so inspiring to hear these kinds of stories when there's so much uncertainty and so many constraints, and you figure out how to bring it to life in real time and create this world that Unreal did.

Maybe we could just pause, since you mentioned John Carmack a few times as a fellow pioneer in the game industry at that time. What do you admire about John?

#467

John singularly has this intense dedication to getting the best result from his code and having absolutely no attachment to past code. Some of the legendary things he did—the end result was an absolute breakthrough in real-time computer graphics—weren't his first try. They were like his seventh or eighth try, after he'd done something time and time again: tried it, found a better approach, thrown out the old one, built it again, and continually rewritten his code until he found the absolute best solution to a problem.

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 being good enough.

The result of that is that both you and him sort of define the future of gaming worlds. It's beautiful to see. It's fascinating. It's inspiring because, under so much uncertainty and so many constraints, you figure out a way. And that actually continues to this day because, yes, the hardware has improved incredibly, but in order to create an ultra-realistic, highly dynamic, real-time rendering of the world around us, it's still really, really difficult. There are all these kinds of optimizations, like you mentioned.

Maybe you can speak to that—the Unreal Engine 1 journey from 1 to 5.5 or 6 now, or whatever. 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?

#467

It's been an astonishing experience. Nobody 30 years ago had anticipated that we'd see the performance gains in hardware that we've actually seen in that time frame. It's something like 100,000 times higher CPU performance between multiple cores, higher clock rates, and more parallelism. If we had that in aviation, then we'd be taking a trip to neighboring stars off Alpha Centauri.

In graphics, it's been even more so. It's something like literally 10 million times more net usable GPU performance than we had running on a Pentium 90 CPU, all in 30 years. It's really made me appreciate that, over the generations, some areas of our engine development have absolutely kept up with that technology. The rendering team that works on Unreal Engine are the real miracle workers there.

Just about every generation of Unreal, we've replaced most of the rendering code. The different leaders at different points in time 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. We added support for it, but it wasn't fully capable or utilized.

Unreal Engine 2 was about bringing all the latest GPU hardware acceleration features to the engine and, moving forward, building some new features like vehicles and a few other capabilities. This was in the early GPU era, before GPUs had really broken out of everybody's expectations of Moore's law. That breakout occurred with DirectX 9 and the capabilities of programmable shaders.

Once you had control over writing code that ran on the GPU and could color every pixel on the screen, 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. Andrew Scheidecker, a longtime Epic luminary, wrote the core of the Unreal Engine 3 renderer around real-time pixel shading, real-time lighting, being able to do dynamic shadows using several different techniques, and multithreading the renderer to support the early dual-core CPUs that were starting to show up at the time. That was a massive graphical upgrade.

Unreal Engine 4 made a number of improvements and just continued to add features to give artists more and more options for lighting and geometry that created realism. But I think probably our biggest single leap came with Unreal Engine 5, with a Nanite micropolygon geometry solution and with Lumen, the global illumination lighting solution. I think that really bridged the gap from game-ish computer graphics to total observable photorealism for artists who wanted to create that.

That's been the evolution, and the progress on the graphics side is absolutely astonishing, as it is on the audio side and 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.

The networking system—the ways that clients and servers talk together and negotiate game state—is still an evolution of the thing I wrote. 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.

#467

Well, that's because of the lossy nature of that networking model. 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 1 core for game simulation.

Running complicated game logic with single-threaded programming is orders of magnitude easier than multithreaded programming. We didn't want to burden either ourselves, our partners, or the community with the complications of multithreading. Over time, that becomes an increasing limitation, so we're really thinking about and working on the next generation of technology. That means Unreal Engine 6, and that's the generation we're actually going to use to address a number of the core limitations that have been with us over the history of Unreal Engine and get those onto a better foundation that the modern world deserves, given everything that's been learned in the field of computing in that time frame.

That's a terrifyingly challenging engineering problem. It seems like every version of Unreal Engine, the amazing teams behind it are willing to throw away most of the code—or maybe I'm being a little too dramatic—but basically throw away the old approaches, like you mentioned with Carmack, and start again, like with Nanite and Lumen. Just keep optimizing to the current hardware, but even rethinking how it's all done.

Going from single-threaded to multithreaded—oh boy, that's terrifying. And that's in part why, we'll talk about it, 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? I watched a bunch of stuff, but the State of Unreal at GDC 2024. Thank you. I was giggling with excitement watching some of this stuff. If we can talk about different things here just to nerd out a little bit, people should go watch this video.

They talked about the dirt, just the ultra-realistic dirt, and this is for Marvel 1943, which is putting the Marvel universe into Nazi-occupied France in the winter. So there's snow, and that's a very intense moment in history, and it really creates a feeling and puts you there. There's so much to that, including the snow.

Just looking at the dirt is a really nice way to show how you add a lot of detail to the scene in real time, which gives this experience of infinite detail—this is real, this is super-real. I think in the talk they describe what's entailed in generating 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 creating this ultra-realistic texture, lighting, geometry—all of that? How do Nanite and Lumen all come together in this beautiful orchestra to paint, in real time, the dirt in Nazi-occupied France in 1943?

#467

Yeah, there's a lot happening here on screen. The real hero of this image isn't Epic; it's the artists and technical artists who worked together to build this environment, because it went way beyond what we realized the system was capable of doing, largely because of their brilliance. This is the magic of computer graphics: there's not 1 feature that makes this cool. There's a dozen technical features that each interplay, and because of the ways they interplay with each other, it's hard to actually identify the individual components.

One thing that's happening here that's really critical—oh yeah, now we're seeing it being turned off—is the lighting. 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.

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, where buildings are casting crisp shadows, all the way down to details like you see on the dirt—all working in concert and without distinguishable boundaries. So there's a good decade of foundational work there to make the lighting work.

In particular, when you see the very detailed shadows interplaying between the ice and the dirt, 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.

Yeah. Watch this. Watch when you add the objects, when you add the textures, the different layering, all the shadows that have to be computed. Shadowing is the amazing thing.

#467

The reason that works is counterintuitive. When somebody first explained it to me, I was like, "That's really clever, but I don't think that will work." But it does work, because if you observe the positions of incoming lights and the z-coordinates of the different pixels on the screen, you can figure out how your geometry there is likely to occlude other geometry. Even though it's only an approximation and isn't perfect, it looks perfectly good to the human eye and gives you the subtle shadowing that you see in a scene like this, which makes it look highly realistic.

The shadowing influences other things, too. There's also some really interesting things happening with the color here. I'm not even sure what's causing it. 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.

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 light bouncing off the geometry, which is another system for lighting on top of the global illumination system.

What about reflections, too? Does that count as the light bounce? There's light bouncing off of stuff to light it up in different interesting ways, but then there's also actual literal reflections, like we're looking at a puddle in the dirt.

#467

Yeah, that's right. The engine supports a number of different reflection techniques. One is calculating basically textures that reflect and capture all the lighting in the scene, and then bouncing that off of texture maps. So you can see different lights bouncing off of different pixels in different ways. And then there's individual lighting casting reflections off of things, too.

A lot of this is under the control of designers. One of the things that's a to-do problem for the future is that you don't just press a few buttons and have this kind of scene magically appear. This is a lot of work from some highly skilled people, not only building out this particular scene, but setting up the material layers so that you get the dirt with the ice layered on top and all the reflections working.

They had to make a number of technical art decisions to make this work. If a novice who hadn't worked very hard built a scene like this, it wouldn't look nearly as good. One of the challenges we have is to make building this kind of quality level even easier, more seamless, and more automatic. You'd like to just build a scene and say, "Use this material here," and have this appearance come out of it.

Once you create the scene, you can do things. I remember them saying, "Can you turn off the headlights?" I forget. You can control the lighting. All of this, we should say, is dynamic. You can change the position of the light, turn the lights on and off. That's incredible.

This is all real time: the geometry, the lighting, the textures, all of it. This is the power of awesome technical art, 3 decades of feature development. You have to give credit also to the 20 teraflops of graphics performance that NVIDIA is delivering. Thanks, NVIDIA. From 90 megahertz to this—90 megahertz is 90 megaflops. This is 20 teraflops. That's a big change. That's a lot.

One of the other things they talk about in the presentation is snow. If you're talking about 1943 in Nazi-occupied France in the winter, you have to create a feeling—one of which is the season, the winter, the cold. You have to cover everything in snow. Shown here is the ability to control how much snow covers the objects.

The ability for the artist to do that is incredible, to control dynamically how much snow is in the scene like that. That's cool.

#467

Yeah, that's really cool. There's a cool system for material layering and a dozen pieces coming together here. You also notice there's fogginess, and there are some hot objects emanating fog. An artist did that; that didn't just arise automatically.

So that's called material layering. An artist creates the different materials and is able to layer the scene with them.

#467

Yeah. Layer materials on top of each other and see how much of each material should be protruding in different places, with the engine handling transitions and things like that.

Lex Fridman

And that's on top of the sort of geometry that creates the structure of the scene and all the occlusions that have to be computed.

I've got to go to the other one that was just blowing my mind, which is smoke. Let me see that. Look at that. Yeah. Oh, there's a fire. There's a fire in a trash can with the smoke and the shadows, the lighting and the shadows interplaying on the smoke. Is this real time?

#467

Yeah, that's all real time.

What the hell? So, how do you do that? How do you do the smoke?

#467

Well, there's a really powerful particle system underneath. It's providing the technological foundations for this sort of thing, but there's awesome artistry on top of that, and an awesome physics engine powering it. It's hard to tell exactly which piece is doing what. But you have several different particle systems there. There's one for the fire, and then there's another one for the smoke coming out of it.

The really interesting thing happening with the smoke here is that it's occluding the light. You know, there's a calculation of how the light should diminish as it travels through smoke. And so you're seeing the lighting on the smoke being the really interesting thing. There have been a lot of attempts, but this was the first demo where I felt like this kind of smoke really no longer looked like a video game. It looked like just a burning trash can billowing out dark smoke.

And it's the artist's sophistication. It's a very, very, very large part of it. So, yeah, again, it's the interplay between the tooling and the artists. But, yeah, I could watch that for a long time.

There's something magical about sitting around a fire in real life and just watching the fire and the smoke. Humans have been doing that for, I don't know, hundreds of thousands of years, maybe. I was just staring at that, and I wish people would just stop talking so I could watch the fire infinitely. 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 up, because I was also feeling cold because of the snow. You really get immersed in the thing. I mean, it's so beautiful. It's true art. It's true art. It's just really wonderfully done.

But, okay, I've got to ask you about the humans. We talked about what it's like to create the scenes, but creating realistic humans is really tough. Can you speak to that? How do you create ultra-realistic humans? You have an actor behind this to convey emotion and show the nuances and details of the faces. Maybe this is a good opportunity to also mention MetaHuman Creator, which is part of Unreal Engine.

Tim Sweeney

Yeah, that's right. Humans are by far the hardest part of computer graphics, because millions of years of evolution have given us dedicated brain systems to detect patterns and faces and infer emotions and intent. Cavemen had to, when they saw a stranger, determine whether they were likely friendly or whether they might be trying to kill them. And so we people in the world have extraordinarily detailed expectations of a face, and we can notice imperfections, especially imperfections arising from computer graphics limitations. It becomes by far the hardest problem.

The MetaHumans effort is part of a decades-long initiative that Vladimir Mastilović, the most talented digital human visionary in the world, has been working on for generations and generations of games. He served individual clients around the game industry for a while and then joined Epic as part of the 3Lateral team, leading now a worldwide effort to build all of the technologies required to make digital humans realistic.

One part is capturing humans. They built really advanced dedicated hardware that puts a human in a capture sphere with dozens of cameras in it, taking high-resolution, high-frame-rate video of them as they go through a range of motions. Capturing the human face is complicated because of 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 also about the entire range of motion that they might go through.

Capturing 1 human requires a few hours of capture work in a dedicated environment like that, and then thousands of hours of processing work to capture a precise, real-time-replicable version of that human in the environment. One of the things that's done is 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 dataset 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, the entire range of faces is represented. Then you're able to combine and merge those together to enable recreating an arbitrary face that the system's never seen before.

Mm-hmm.

Tim Sweeney

One of the ideas is to capture giant amounts of this high-precision data and use it to reconstruct a face at a consumer level. Maybe you take an iPhone photo of somebody's face and then capture a very accurate depiction of that—not by synthesizing it 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 are a lot of other problems in computer graphics. There's technology for rendering hair, which is really hard, because you can't render every hair. 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, light travels through our skin. It's not completely opaque, and the way in which light travels through skin has a huge impact on our appearance. This is why there's no way you can paint a mannequin to look realistic as a human. It's just a solid surface, and we'll never have the sort of detail you see.

Lex Fridman

We should actually just linger on that. That kind of blew my mind, thinking through that. I think I heard that the oiliness of the skin creates very specific, nuanced, complex reflections, and then some light is absorbed and travels through the skin. Would it be fair to say that creates micro-shadows or something? It creates textures that human eyes are able to perceive, and it creates the thing that we consider human, whatever that is.

You have to compute both the reflection—how light interacts with the oiliness of the skin—and how it is also absorbed, all 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 the beginning of the formation of a smile that actually reveals a deep sadness—all of that, when I watch a human face, I can read that. I can 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. But anyway, sorry.

Tim Sweeney

So, yeah, there's a lot of this kind of complexity in even just the lighting of a face. That's right. Getting faces right requires the interplay of literally dozens of different systems and aspects of computer graphics. If any one of them is wrong, your eye is completely drawn to that, and you find it on the wrong side of the uncanny valley.

The level of perfection needed in this area is vastly, vastly higher than world rendering or grass or any of these other things. If the shadows on a work of architecture are slightly wrong, you're pretty forgiving of it, actually. Your brain doesn't really care that much. But if anything's wrong with a human, it's totally jarring.

Can you speak more to the creation of digital humans with MetaHuman, both on the editor side and sort of the bringing-it-to-life side? It seems like, because I've watched a bunch of videos of individual developers doing it, it's not too difficult to bring a human to life using the tooling that Unreal Engine Editor provides.

Tim Sweeney

There are 2 main tools. Compared to the old days, where every face was created by hand by an artist from scratch, 1 is the MetaHuman Creator tool for creating faces, where you have a huge number of parameters you can adjust to create a unique human by adjusting all the different capabilities of the character.

You can then get that out of MetaHuman Creator into Unreal Engine, and then you can add all kinds of computer graphics features in the engine. You could add clothing using the cloth simulation system, and you can adjust the hair and all these other parameters on the character.

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 an iPhone. It transfers the captured animation to the human you want, which is not straightforward. If the actor has 1 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 nonobvious.

#467

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. Within Unreal Engine, you have a face, and you can do absolutely anything you want to it. You could also, if you decide to go outside of the MetaHuman geometry pipeline, build your own face, any creature of any sort, and then use the animation tools to animate it.

But this is 30 years into a project that's probably 50 years in total to get to absolute photorealism and controllability for absolutely everything. There's vast amounts of work still to do. 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.

Nevertheless, I've seen people use it really effectively.

I've seen what seem like plugins, maybe external services, where you can get the faces to approximate the mouth movements required to speak a thing. That's a really useful feature.

#467

Yeah, that's right. When you have an artist or actor in your studio and you're recording a specific performance, you can just capture their facial motion and apply it. But if all you have is a voice recording, or you're generating a voice recording, or it's parametric, procedural, or AI-generated, then you need the system to translate that speech not only to movement of the mouth and lips, but also to facial expressions and the whole intent.

When we're speaking, it's our whole face that's active and emoting in different ways. It's not just the mechanical motion of the pieces.

So we spoke a bit about Nanite, the magic behind the virtualized geometry system. Can you speak a little bit to Lumen and, in general, what it takes to dynamically light, in all the complicated ways, the faces and scenes that we discussed? What are some interesting things to you that made the magic of it happen?

#467

Lumen is a system for global illumination, meaning it's supposed to calculate the interaction of light with the entire scene in a way that mimics reality. The first generation of engines that did lighting just said, “The light casts light, and the surfaces it hits are lit. The surfaces it doesn't directly hit are dark.” Those were all the techniques we had.

You'd have an area that wasn't hit by any light being completely black, but in reality, light bounces around the entire scene. Dynamically, when a light hits a red wall, most of the blue and green light is absorbed, but the red light reflects off and is now hitting other things. If you have a red wall with a white floor, light is bouncing off the red wall into the floor, and now the floor is being turned red. The entire bouncing of light around the scene through multiple bounces is the critical challenge to solve here.

Again, the laws of physics are known, and the complete solution to this was written down in the 1950s, I think. The real magic in Lumen is this 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.

That ranges from the scale of miles or kilometers down to the scale of pixels and millimeters. It has to calculate at each level and integrate it seamlessly at each level to give the appearance of completely seamless and accurate lighting. 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 now, is that you build a scene, you place lights in it, and it just works. That's what makes it that much easier.

I recommend people go through this blog post and look at that. Dynamically, there's the indoors and the outdoors. To be able to dynamically compute the impact of outdoor light, just look at that. Look how gorgeous that is. Just the lighting.

We're looking now at an image of a cave. External light is lighting the intricate complexity of the inside of a cave. Look at that.

#467

Light in the real world goes through a lot of bounces, and the effects of it are very subtle. But when they're not there, you miss them. Often, a person can't point out why a scene is wrong, but they know it looks wrong. It's a lack of the subtle lighting cues that we're seeing here.

For great video games, but also for great films, lighting can make a film. We're looking at a very dramatic lighting of a scene. Imagine stepping into this scene: it's exciting, it's terrifying, and all of that has to do with light—the interplay between light and darkness.

It's incredible. It's truly incredible. Light is everything. To put the power of the tooling in the hands of an artist is really special.

#467

The industry's gone through a massive evolution, with so many supporting systems to make this awesome.

And, as always, artists. We're looking at reflections on smooth surfaces. Oh boy, oh boy. Look at how gorgeous that is. Wow.

#467

You have to appreciate that the algorithms are doing quite a lot here. You can have a scene with a huge number of not just lights, but also bright objects to reflect light off of them. Every one of those has to be captured in the reflections in order for it to be realistic.

You can't calculate every photon in the scene, so you need really detailed approximations. That's the field of computer graphics: increasingly effective approximations of the laws of physics, which are just totally intractable.

The result of those graphics is a feeling, an experience by the viewer. As a fan of beauty in the world, it's exciting that we can create that synthetically, artificially, through graphics. It blows wide open the possibilities of storytelling.

Outside of video games, a lot of people are using Unreal Engine for movies and films. Big congrats—I saw WAR IS OVER!, a short film that was made with Unreal Engine, won an Oscar. You can add that to the résumé. That's huge: an Oscar-winning film made with Unreal Engine.

What do you see as the future of the use of Unreal Engine in creating stories in the film industry?

#467

Increasing capabilities and productivity. The limiting factor in every one of these businesses is cost. The more the engine can make their jobs easier, the more power that brings them.

One of the big revolutions we've seen in Hollywood is moving away from doing computer graphics integration into a human scene with green screens, and moving to these large LED wall panels displaying real-time computer graphics powered by the Unreal Engine. That's a massive improvement in quality.

You can recognize the old green-screen movies because the lighting on the characters is just wrong. 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 the lighting from the actual natural scene they're supposed to appear in, but they can also look around and see it. They're aware of exactly what set they're acting in, and 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, as 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.

There's a lot of excitement around generative AI. What do you think is the future of the interplay between what a human artist creates and what an AI system can create in Unreal Engine?

#467

I think a lot of people in the industry are overly optimistic about the rate of progress of AI for video and other things like that. The real problem is consistency. Spitting out an image that's really high quality is one thing, but with video, over the course of a scene, all the AI approaches have consistency issues going from one place to another. I don't think those issues will be remedied easily.

Fundamentally, AI just doesn't have anything resembling an understanding of the entire scene it's in, the entire arc of the movie or plot it's in, or the entirety of the world around it and how that might affect a scene. Game engines have that, exactly where they need to be.

I don't think what we're going to see in the space of world-class, high-quality productions is everybody moving to AI and a large part of the human creatives contributing to that being obsoleted. 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, with higher quality and better results.

Unlike the fields of generative 2D art and generative text, I think the future of AI is much more complex and nuanced. Your interview with Mark Zuckerberg, conducted in VR, was a really good first example of this. You did this VR discussion, capturing your faces and then rendering a completely 3D computer-graphics model of your faces. 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 through normal computer-graphics rendering.

That's a first step. You can imagine the output of Unreal Engine being enhanced by an AI pixel-shading postprocessor. You can imagine the creation of objects being enhanced, and especially the mashing up of high-quality objects that have already been created.

#467

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.

Using data like that and AI to create completely new trees that meet your specification, from all the knowledge that is built up from high-quality scanned 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 of 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, budgets, and 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.

Every single technological revolution that has changed the way that people work has ultimately created more opportunity for people, and there are pundits predicting that this might be the last. But I think just the opposite. I'm an optimist on this, and an optimist that it's going to create opportunity for everyone.

Do you think it will be possible to use generative AI to create dynamic objects, like you mentioned, trees in the Unreal Engine world? So, create meshes and textures and empower the creator to create faster, use meta-knobs like hyperparameters, versus very nuanced controls where you can control much faster the look of a face, the look of a tree, all that kind of stuff?

#467

Yeah, I think that's the central challenge of the next decade of game engines and AI for content creation of all sorts. You have 2 very different models of the world that are emerging.

There's the scene graph—the technical term we use to describe the set of all the objects in the world in a 3D world maintained by Unreal Engine or another engine. In the videos you saw, it's the rocks and the trees and the snow and the bridge and the people and all of these things. Each one has enormous amounts of data attached to it.

Some are texture maps. Some are sound files. Some are animation files. There are enormous amounts of detail all stored there in this computer-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, and 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 it's costly and time-consuming. It requires expertise.

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 in its parameters, there's something like the mushy connections of neurons in a brain. It has a vast amount of knowledge about the world, graphics, images, people, and 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.

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. If it produces 1 image 1 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.

I think when we figure out more and more ways to merge these and connect these 2 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 has 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.

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, the ability to select specific parts of it and art-direct those, and to have that art direction stick and be recognized as part of this permanent scene representation.

Yeah, I can't wait until AI can operate not in the space of pixels, but in the space of scene graphs, creating objects in the scene graph, whether it's audio, as you mentioned, or any of the things that you mentioned that empower the creator. Yeah, that's a super exciting future.

I wonder if you could speak to a fear that people have on this topic: artists and engineers fear losing their jobs, being replaced by AI. Are there words of hope that you could offer them?

#467

This is certainly the most extreme example of it because AI is just so far ahead of prior technologies. But similar fears were had in every other industry.

There's a fear that digital music synthesis would obsolete musicians, and there was a very brief period of time in which songs with digital music instruments, like early Moog and Yamaha synthesizers, weren't allowed to win certain music industry awards because they weren't considered real music. Over time, people were educated and realized, "Oh, these are just instruments people are playing and controlling the same way they did before."

There are similar questions about whether computer art built in Photoshop is really art, or is it just goofy computer stuff? I think nowadays digital artists have gained respect. 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.

I think it's going to become a more powerful, directable, and human-serving tool in the future. A lot of the alienation comes from the prompt either being immensely powerful at 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 this part of it with this thing," or, "Make that object green," and it just 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, right? It feels like a competitor.

When we have much more nuanced control of it and artists can go in and say, "Let's enhance this object. Do this, do that, do that," they'll feel it's like some of the tools that exist in Photoshop, which are, in some ways, compared to a paintbrush, superpowers already. AI will come to feel like that too and will increasingly serve creators, creating and enhancing a work in a way that feels like a natural extension of their own bodies and minds.

And of course, there is a real human price to layoffs, and there is a hype around AI. Companies might try to implement AI systems and, in so doing, lay off a bunch of folks. The pain that those folks feel is real.

I think there's always going to be pain with these kinds of transformations that are happening, and it's a terrible pain. Pain in general in the human experience is terrible. I'm personally excited by the human-AI collaboration as you've described in this whole process.

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 they can empower you as a creator, as an artist, or as an engineer, I think you're going to just keep winning.

#467

There are a lot of complicated trends underway, and it can be hard to break them down and distinguish them. I think a lot of the theories that get the biggest traction on social media often don't capture the real underlying motive forces at play there.

But yeah, I think AI involved in code production will probably create a net benefit for the need for humanity to be involved in coding. It may change parts of jobs. I don't think it's going to obsolete anybody who's willing to learn new ways of doing things. It's always been this way.

I think 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 learned the underlying pattern. It's notoriously hard to get it to do something new that hasn't been done before, especially when it's a complex task.

The bigger amount of code you ask AI for, the more it leaves you with just a mess of code that sort of works right then. That's the problem with code: it 99% works, but the 1% might be harder to get to 100% with AI than with hand-coding.

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

Yeah, for me personally, it makes it more fun and faster to generate boilerplate code, so I can focus on the harder decisions, harder big-picture decisions, and harder innovative decisions and all that kind of stuff.

#467

And it just makes programming more fun for me because I feel less lonely. Even when it gives the wrong code, I can say, “Oh, okay. Well, that’s a way to do it. That’s interesting.” Then you can talk to it.

Maybe that shows something about the programming experience: it is, in part, sometimes a bit lonely. The topic of boilerplate code is an interesting one because the mere existence of boilerplate code is a failure of programming language and of the idea of creating software modules, right? You ask AI to create a sorting function. Great. Now you have another sorting function that might be buggy alongside the million others that different people have written. It would be better to have a sorting function that’s been written, tested, and optimized, and that everybody relies on. More modular software, I think, will actually reduce the opportunity for AI, because people doing programming work will largely be solving unique problems that are actually hard problems in themselves and not just connecting other widgets.

Yeah, I think, as in many cases, AI will just help improve the human systems by shining a mirror to ourselves. I have to apologize for the pod question ahead of time, but you’ve been a big proponent of the idea of the metaverse. We’ll talk more specifically about what that means today, but we’ve been talking about simulating reality better and better and better.

So the pod question is: What does it take to simulate reality to the level we see around us today? How far away are we from simulating this ultrarealistic, immersive, fun reality that Earth is? What does it take?

#467

We’re going to get shockingly close over the coming years, certainly in less than 20 years. If you look at the progress, in the areas where we have achieved total photorealism and the areas where we fall short, we’re getting very close in all nonhuman interactions you see in the world: walking through a jungle or a city, all the lighting. It’s very close, and that might be just a few years away.

But all the problems that involve humans—human dialogue and intent—have a much, much, much higher bar that they need to meet to satisfy our brains and convince us that they’re realistic or real. I think that’s going to be the primary challenge of graphics development and simulation development over the coming decade.

So realistic humans—that’s going to be the bottom line.

#467

Yeah, visual and behavior, too—everything. I was asked about this about 10 years ago, and I said that even if you gave us an infinite amount of computing power, we couldn’t simulate realistic humans because we simply didn’t have the algorithms. We had no idea how to simulate human intelligence. That was absolutely the case then, but it’s not really true anymore.

What we’re seeing with generative text AI is at a level where you could say that it’s actually doing a pretty good job of simulating a human—at least humans at the text level. Not at the emotional level yet, but at least at the level of words spoken. If you find more and more ways of training it on more and more scenarios, you might have a very compelling human simulation going on in the next 5 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.

You know, we don’t say this enough, but the current state of LLMs—I mean, if you put Alan Turing in conversation with ChatGPT, it really passes the Turing test, almost definitively.

#467

Of course, we keep raising the bar. Well, the Turing test is not a real test. It’s not a useful test. Whatever. We just keep raising the bar for AI, so it’s always going to be seen as lesser. But you have increasingly ultrarealistic faces and bodies combined with increasingly moving and powerful forms of emotion, speech, and text.

I work with this amazing company called Level Labs that does text-to-speech. There are companies that specialize in bringing text to life, and that’s going to increase. Different companies do that very well. 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: a beautifully lit face in the full darkness, the emotion, the drama of the scene.

Yeah, I think—so you’re saying 5, 10 years, maybe 20?

#467

Yeah, absolutely. We’ll definitely see it in our lifetimes.

To increase the level of pod-ness in my question, do you think we might live in a simulation? And if we do or don’t, how hard would it be to build such a simulation where we’re fully convinced we’re in it?

#467

Well, I don’t think these questions are necessarily unanswerable. I’d like to see more actual effort to ascertain what the underlying mechanism of the universe is, and I don’t think we’re here for no reason at all. I think the world’s a pretty cool place, and the fact that we can exist, and the laws of physics—especially the Standard Model of physics—and all the parameters that lead to these atoms and life evolving in the presence of thermodynamic gradients, that’s really cool. I think it’s a worthy field to study more holistically.

I don’t know. The question of whether we’re living in a simulation always boils down to: If we are living in a simulation, what are they living in? At some point, there has to be some base reality. 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’re just a manifestation of mathematical laws rather than needing an actual universe around us.

Mm-hmm. I don’t know. I like dabbling in that philosophy. As we get AI 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. You start to think: If we’re not living in a simulation, what are the things about this reality that are not simulatable? What are the big mysteries around us?

It feels like the physics is simulatable. It feels like a lot of the incredible stuff that we talked about, while super nice, seems simulatable. But then there’s the flame of consciousness, the feeling of it, whatever that is that lights up in our eyes as humans. Maybe that’s not simulatable. Maybe that is the thing. Maybe that’s a thread that connects to the explanation of the mechanism of the universe, as you said. 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 leaps of faith in believing what that mechanism might be.

#467

So the whole idea of nested simulations, given a sufficiently advanced technology, is kind of moot, such that if you wanted to simulate another reality, you’re kind of just actually creating the reality. You’re doing quantum mechanical operations that would produce the same result anyway, and you’re running them at full performance. So it’s not really a nested simulation; it’s just another thing that’s happening in the universe.

That would be interesting, but I think it’s ultimately a theological question. Because it’s no longer cool to deal with theology as part of science, there hasn’t been much work on that. You can’t publish results on those topics in a respected physics journal. I think that’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.

There’s this idea of quantum wave function collapse: when we look at a quantum system evolving in perfect superposition of many possibilities and go to observe it, we 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. If you wanted to attach some external input, well, there’s a place, and it could be seriously accessible through the rigors of science, but we just know so little there.

Yeah, it’s funny. In that area, we know nothing more than cavemen knew whatsoever. We know the laws of quantum mechanics, and we have computers that may soon be more advanced than we are, but we just don’t have any answers to the fundamental questions about life, the universe, and everything.

Do you think, more practically, that we’ll create video games—video game worlds of the metaverse variety—in which humans will want to stay? To me, this kind of discussion of a simulated reality—the real test of immersion is a perfectly healthy, excited, normal human being choosing to stay in that world and not wanting to go back to the real world. How hard is that, do you think?

#467

Well, I think the technology is coming, and then there’s the human question: Should we go that far? Should we? Certainly, as a game developer ourselves, Epic doesn’t aspire to that. We make fun games. The ultimate manifestation that we found is fun games that people play together to have fun in between work and the other things in their real lives.

#467

But as simulations get more and more realistic and the capabilities become more and more real, I think we have to ask ourselves some hard questions about how humanity should operate in that space. What are the limits that we should go to, and what are the limits we should set?

Yeah, I think there are going to be some hard questions, and I think maybe I’m just being anthropocentric here, but there should probably be some legal bounds on 2 things. The first is not creating a reality in which humans would want to stay too long.

#467

Yeah.

Lex Fridman

The second is focusing more on the game side and, more importantly, not creating simulations of humans that could suffer. To me, as we talked about, creating ultra-realistic humans eventually means creating humans that can suffer. They can fall in love and experience heartbreak and loss. They can fear death.

The more you simulate that to the full reality of the human condition, the more you get to this place where you have simulated humans that are able to suffer. I think, legally speaking, you have to get to a place where that’s not allowed. There is a line you can’t cross, and that’s a hard thing for humans to deal with.

#467

That’s going to be some interesting Supreme Court cases. Once you create a human sufficiently realistic to the point where they can suffer, it means that human could be tortured and people could 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 it feels 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?

#467

Yeah. I think the thing to appreciate is that game developers have generally been on the good-spirited side of things. If you look at the worst things that people do in popular video games today, it’s like you rob a bank in Grand Theft Auto. It’s clearly fictional and fun and not serious and over the top.

As things get more realistic, especially simulations of humans, there are some hard questions that will have to be answered there. But I think the thing that all game developers need to remember is we’re here to make people’s lives better by entertaining them, providing them with fun and a diversion from other things, and being a part of their lives—not trying to be too big or too much, and not trying to provide an alternate to reality, but just to provide a fun source of entertainment, like the many other things that people do for fun.

So, you’ve spoken, as I mentioned, about the metaverse for many years. Let’s step back. What is the metaverse? And speaking of fun, Fortnite—hundreds of millions of people just enjoying themselves in this huge-scale social game. You could call it a metaverse. Maybe you can describe the different flavors, the layers, of how you see what the metaverse is.

#467

The metaverse is an idea whose stock price goes up and down depending on who says what on what day. Some have the ability to drive it way down by opening their mouths. But ultimately, this is about multiplayer social gaming experiences: you and your friends getting together in a 3D world and having fun together in any way you want.

If you’re playing Fortnite Battle Royale, in my view, that is capturing the essence of the metaverse. Especially in Fortnite, when we got Sony on board so that all players on all platforms in Fortnite could play together, could voice-chat together, and could be part of a single game experience, it really took on a new nature. It was not just a multiplayer game with heritage from Doom, but also a true social experience between you and your friends.

Fortnite Battle Royale is just 1 manifestation of that. Another one is Rec Room VR, where you’re standing around in VR with friends, playing billiards or shooting hoops or 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 is really getting at the core essence of the vision, the aspiration for the metaverse.

We’re still in the very early days of it. I was on the internet in 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.

I think it was at the time we released Fortnite Battle Royale and started playing together—all the people at Epic in squads and experiencing that world—that we realized 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, creating more games and more genres that people could play, and ever-expanding the repertoire.

Yeah, I would love to talk about different aspects of that a little bit more, because Epic has created a lot of amazing games: Unreal Tournament, Gears of War. But the game that I think it’s fair to say transformed the gaming industry was Fortnite, Fortnite Battle Royale especially. Can you explain the origin story of Fortnite?

#467

Well, Fortnite has humble beginnings. In 2011, we’d just been in the final days of finishing one of the Gears of War games, and we wanted to explore ideas for new games. We had a general idea that we would like to build some smaller online games in order to learn more about that space, and not just have 1 single massive game in production at all times.

Everybody in the company was given a week to form a team, work with whichever coworkers they wanted, and build a game using Unreal Engine. So you can actually build something pretty interesting in a week. 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 were going to build forts by day using this building system. Then night would come and you’d defend the forts against zombies.

Nice.

#467

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 game was in development for a very long time. We always saw the potential. Just the building aspect of it was incredibly fun, but we made different pivots at different times.

At 1 point, we moved to the current Fortnite art style, away from a more realistic style, and made it more in the Pixar vein, with cool, stylized characters.

Lex Fridman

What was that decision like? Because we should mention Gears of War is this incredible game that shows off the graphics to the fullest, different from the artistic style of Fortnite. It’s amazing that the same company would make this fun, silly graphic style of Fortnite.

#467

People come to Epic because they want to work with the best people in the world, and artists bring a lot of different personal art aspirations, style, and capabilities. Many of them are very multitalented. You can produce photorealistic content or highly stylized content, and a lot of the best artists on Fortnite were a lot of the best artists on Gears of War, too. They changed styles but continued doing awesome work.

We’d realized that Fortnite could be really mainstream and could be a game people play for a long time. Having a more visually pleasing art style that’s not as stressful as a Call of Duty game, where you’re constantly pixel-hunting a dark scene for somebody’s rifle scope—that was the goal. A few of the artists got together and defined the new art style, and we moved to it.

At different points, it evolved toward being kind of like a light MMO, like Destiny, with rather complex RPG and stat systems. That evolved into an MMO-like tower defense game—MMO only in that persistence of items and stats—which became Fortnite: Save the World mode. We launched that in early 2017, and it was a moderate success. It paid its budget, and we came out ahead.

At the same time, the battle royale genre was booming. PUBG had just come out, and tons of people at Epic were playing that. They were like, “Oh, this would be so cool if it had Fortnite building.”

So we assembled a team in a war room—about 30 people in 1 big room—and they worked insanely hard for 4 weeks to build Battle Royale. The nice thing is that all the content for Fortnite had been built over the previous 7 years. They had a huge library of content, but no gameplay of the type they wanted. So they had to build it all in those 4 weeks and ship it.

That put Epic on an exponential growth curve. We went from 300 employees to thousands of employees, and from about $100 million in revenue to billions of dollars in revenue. We became the center of the gaming world at the time.

Can you actually speak to the technical challenge of going from mostly not being an online, large-scale gaming platform to being able to support, with Battle Royale, a huge number of people playing with each other at the same exact time? What was the technical challenge of doing that in 4 weeks? What were the technical challenges that had to be overcome?

#467

Since 2012, we’d been building online backend systems to support player accounts and login and all of the different systems needed to make a multiplayer game.

#467

And we've been building them to be scalable. By some miracle, we built them stably enough that they were able to scale up. The online team responsible for patching that code spent a year of intense work getting it to scale from 40,000 concurrent users to 15 million concurrent users.

Yeah. They're scaling their scaling. That's a lot. That's immense. But they'd done such an awesome job of building the foundations that it was tractable. It was doable. If they hadn't done that, then the company would have died. Fortnite just wouldn't have been playable, and the whole thing would have failed.

There's so much detail there that makes all the difference. That's what Spotify has talked about: latency, how quickly you can deliver the song, changes the product from being this shitty thing where I'd rather pirate the songs to, "This is good enough. I really enjoy the experience. I want to use it." That's really important, to create an experience for 15 million concurrent users where it isn't lagging and actually works, right? Is there something you could say about how difficult that is to pull off?

#467

The trend nowadays for building online services is microservices. There's not one big server that handles all the interactions with Fortnite. There are game servers running 100-player game instances for each Battle Royale session. Then there's an account server and many instances of it, all talking to a shared database. There are hundreds of different microservices talking to each other.

Scaling is a matter of identifying the bottlenecks in that system and making sure that each one can scale and has enough redundancy to handle the load. 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."

There was a period of time when Fortnite was undergoing exponential growth, and we'd find that one week we ran out of servers in Brazil during a heavy weekend of play. The next week, we had an even heavier weekend of play, and there were servers to handle it. Somebody at Amazon had drop-shipped millions of dollars' worth of server hardware into Brazil and turned it on just in time for Fortnite to need it. There are a lot of unsung heroes in that story, many of whom we've never heard of.

Yeah. Behind AWS, there are many unsung heroes. So many of those folks run the modern internet. All the incredible services, games, and other services that we take for granted are currently being run on AWS, or were originally, and on Google Cloud and so on. Can you speak to how much money Fortnite made?

#467

This is one of the greatest successes in the history of video games. Fortnite makes billions of dollars a year, and that's the majority of Epic's revenue. We have a robust business around Unreal Engine licensing, Rocket League, Fall Guys, and some other tools like the Fab content marketplace, but the majority of it is Fortnite because we've chosen to reinvest heavily in building what we think is the future of technology.

We're spending more every year than we're making. For a period of time, we were spending over $1 billion a year more than we were making, and we found that to be unsustainable. We went through some painful layoffs at that time, and then we stabilized. 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 the investments we've raised.

We're not an oil well pumping oil out of the ground after we discovered oil. We are growing to be a future technology powerhouse. We think the 3D space and the future of real-time 3D simulations are going to be major facets of technology for humanity. We're all in on investing in that.

Yeah, it's exciting to see you investing in a long-term future, taking the risk of doing the research and defining the next chapter of Epic. You're using the successes of today to invest in the successes of tomorrow, which might look very different—completely different. Part of that is investing in the development, research, and innovation in Unreal Engine.

#467

That's right. We're a company that can start working on a project knowing that we won't reach fruition or make any money from it at all for 3 years, 4 years, or 5 years. We're totally okay with that. That's the cycle that's fueled our growth over time: constantly investing in the future and being a serious company that's doing serious R&D side by side with shipping and maintaining products and earning money from them.

Can you speak to—I mean, there are several directions here. One of them is the future evolution of this idea of the metaverse, potentially creating communities. Fortnite is this incredible, huge community of humans interacting, but your vision is to go outside of just one game. What are the kinds of standards that you're thinking about building, such that people can have an identity and almost travel between games and that kind of thing?

#467

Let me start with the present of gaming and why it sucks.

Sure, Fortnite is an awesome thing. You go into Fortnite, and there are 100 million monthly active users there. A huge number of your own friends are there. You can play with them and go from experience to experience seamlessly without leaving the app. There are 100,000 different islands you can play on, and some of them are really awesome. There are constantly new ones coming out and constant things to do.

If you want to play Roblox, you quit out of the Fortnite app and launch the Roblox app—different program, different friend system, different account names. Your username in Fortnite and your username in Roblox are different names, and they're not connected to each other. You have to remake all your friends and then find different things to play. Now the controls are different, so you have to relearn how the joystick, mouse, keyboard, or controller works in that experience. You have to go from place to place.

You buy some stuff in Fortnite, and it's really cool, and you can use it anywhere in Fortnite. Then you go into Roblox and you don't have that stuff. You have to buy different stuff, and that stuff only works in Roblox. The same is true with Call of Duty. It's another isolated place, and the same is true with World of Warcraft and League of Legends. 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.

A long time ago, consoles set out to solve this problem by creating their console-wide friend system and account. Your friends on PlayStation in one game are your friends on PlayStation in another game, but only on PlayStation. If you're on Xbox, you can't see PlayStation friends.

There are 2 basically orthogonal and cross-cutting divisions of the world into fiefdoms, which were not created with bad intentions but arose as separated, isolated islands. One is the platforms and their social services—Xbox, PlayStation, Nintendo, Steam, and Epic, if you add it to the list—and the other is these different games people play. Because of this weird historical artifact, we're left in a world where people can't seamlessly move from game to game, bringing their friends and their stuff.

The solution to this is to federate and connect all of the systems together. All the players on all the different platforms can be recognized by their name, and you put the @ sign in it. Your Xbox names, your Fortnite or Epic names, and your Steam names can all live together and interoperate together in a single space. Unifying the social ecosystems is one thing that needs to happen.

The next and bigger challenge is to unify the economies, too. I'm not talking about how 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 about cool looks and cool appearances.

Most of the major multiplayer games have them. If you look at games, you could probably bundle together about 70% of them and say they're similar enough that they could actually interoperate. You could own an outfit in Fortnite, own an outfit in Roblox, and own the same outfit in maybe Call of Duty and maybe 100 or 200 other games, and actually expect them to work together.

You'd find other kinds of items are probably interoperable, too. Fortnite has car outfits, so you can buy different appearances of a car. 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. Now you have a cool car. It'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 the sources of engagement. There are 2 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 the user modes and everything else—which are sources of engagement.

#467

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. 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. The gameplay is not pay-to-win; it’s all just a game.

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? You have all the revenue in this item shop economy and all the engagement in this engagement economy.

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.

That’s why Fortnite scaled up to a $400 million creator economy so far, and it’s growing. It’s amazing. One of the really critical things we aim to do in designing that is ensure it’s a creator economy that could scale to other companies and other ecosystems.

Right now, we have many industry standards bodies. One standardizes game ratings—age ratings of games. Another standardizes file formats for the web. Another standardizes file formats for 3D, like the Khronos Group and the Metaverse Standards Forum. If we had a standards body standardize portable outfits in games—game outfits that you could buy in one game that work in another—what are their dimensions and capabilities? What can you do and what can’t you do, and so on?

Then you could have an item economy where every game agrees to respect each other’s item purchases of that sort, and revenue is shared between ecosystems as well. That would be incredible.

That would be so amazing. Is there, first of all—it seems silly, maybe, for people who don’t play video games—but an outfit is important. If an outfit can be persistent across video games, I mean, what’s the purpose of life? Why do we wear clothing? It’s a part of our identity; it’s how we present ourselves to the world. I wear this stupid suit and tie. It feels good when I put it on.

Even with the other outfit, I have 2 outfits: this, and then a black T-shirt and jeans. It feels good to wear that. It feels like me when I look in the mirror. I know that guy. To be able to have that outfit go from game to game to game, maybe across years, would be wonderful.

I wonder if you could comment: Could there also be another standardization about the value, for more complicated items? Take a sword from Diablo and transfer it to a gun in Fortnite, but based on the value—some generic concept of money. The value of a thing in one game versus the value of a thing in another game, where you’re almost operating in a space of value versus the actual items. Is that already getting too general?

#467

I think this can be done. We did a lot of analysis of the Fortnite economy and found that some Fortnite experiences lead to, or correlate with, higher spending than others. Battle Royale is relatively strong in that area because you see your character from behind and see all of the other characters from the front. You have lots of opportunities to really see who you are, to emote, and to interact with other players.

A lot of games have that characteristic. One funny anomaly stood out. There’s 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 it, but we found people weren’t spending a lot of money on outfits when they were playing Only Up!

It’s kind of intuitive, actually. You’re not seeing other players. If you see anything, you’re seeing their butt as you’re trying to catch up to them, jumping from object to object, and they’re above you. It wasn’t a mode that showed off outfits very much, but you can determine the economic correlation between a game mode and spending.

That’s so fascinating. Fortnite is this gigantic economy where you could do those kinds of studies. You can understand markets—the digital markets as they emerge amongst humans—and what they value. From that value, you can probably have a very stable kind of money that emerges.

#467

Yeah, I think so. You don’t need an alternate currency system. Unfortunately, a bunch of ideas have been conflated because people are trying to hype up different things. This idea of large-scale multiplayer social gaming—the notion of the metaverse—has 600 to 800 million people playing that kind of game every month. That’s real, and that’s happening. It’s very much underway.

VR has a much smaller audience. I don’t think you need VR to have anything like this. VR is hardware that may or may not enhance the experience for some use cases. For some, it will probably be better, and for some, it will probably be worse. Certainly, there’s not any set of Battle Royale players flocking to VR.

And the other thing is NFTs. It’s like trying to equate digital or cryptocurrency to the metaverse. 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. 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, through a database, or through standards bodies defining standards and protocols. We’ve been doing it for hundreds of years, since the railroads were standardized. It’s not something that totally requires a novel technological solution.

Yeah, even on the topic of cryptocurrency, it’s very frustrating. Blockchain and crypto are really powerful technologies that I think can enable a lot of the things we’re talking about, but so many people use them to try to make money, to create these bubbles. The hype and the memecoins and so on and so forth become much less about that. They drift far away, and rapidly, from things that are actually of value, which is the experience of playing Fortnite and how you look when you play Battle Royale.

That’s valuable. It sounds ridiculous to say, but it’s true. That’s like gold in the physical space. We know that holds value. How your outfit looks in Fortnite, as you’re saying, provably holds value. You want to connect a standard definition of money value to that and not let it become this hype thing, which NFTs, as you mentioned, just become. It quickly drifts away into the land of people trying to buy and sell and trying to make money, versus staying close to the thing that people actually value.

Forget the money. It’s more about exchanging valuable experiences or things of value. You can play Fortnite, 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. All the different standards that make the web work—there need to be those kinds of standards. What would those standards look like to enable the metaverse?

#467

We need a lot of different things. The 1 area where the standards have been very successful in creating working standards implemented by all the major engines today is in low-level file formats for data interchange.

The web has PNG files for 2D images and MP3 files for audio. 3D has the Pixar USD file format, the Universal Scene Description, which is a description of the scene graph—the entire set of objects in the scene and all their parameters—so that any engine that supports those features could import that and then render the same scene as the engine they came from.

Large parts of this work across Unreal Engine, Unity, Blender, and all of these 3D packages of different sorts. There’s the glTF format, which stores textures, 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. The different standard file formats could store all the sounds they make in 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. If you look at the web, the web is a combination of a bunch of different technologies. The 2 biggest ones are HTML, which describes the 2D scene graph, or the 2D layout of controls and objects on the web page.

#467

But that's just static data. It's a nonmoving, nonanimating web page. Then you have the JavaScript programming language, which is used to manipulate that, display things to the user, and implement anything you could implement in code. It's a little programming language that runs in your web browser.

The metaverse needs something that performs a similar role. But the metaverse and 3D gaming in general need something that's more powerful, safer, more scalable, and more capable than JavaScript, because the metaverse is actually a more difficult technical problem than a web page.

A web page, like an app, is just a single bundle of code and content that a company has prepared and released. 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. Yes, fully distributed and collaborative.

First of all, there's also the amount of data. It doesn't have to be that way, but websites are showing very little information. The metaverse, even when it looks like something like Fortnite, conveys a huge amount of information in the scene graph as the individual players are collaborating. The highest-detail Fortnite updates amount to about 60 gigabytes of data. That's just a small part of what exists in the Fortnite Creative ecosystem, and if you look at what this might be in a decade, as standards emerge, you might have exabytes of data out there.

Fortnite Battle Royale is not, I don't think, the ultimate manifestation of gameplay that will ever be invented. What we've seen time and time again is that as we gain more technical capabilities, graphics get more capable, CPUs become more performant, and web services become ever more scalable, we see new genres of games emerge that weren't possible before. Doom ushered in the era of deathmatch, and it was the first time 3D multiplayer gaming was even possible at all.

The early battle royale games, starting about 10 or 15 years ago, only became possible back then. You couldn't have built one 20 years ago because you simply couldn't have rendered an environment as large as a battle royale game with that many players, that level of interaction, and that level of performance. It was just not possible to run it. So, at a certain level of technical capability, a genre came out that proved to be by far the best shooter genre ever invented.

But I think there are 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 a single company can possibly create. You see 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. So, there's an ecosystem that scales larger than a 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 see different areas that are maintained by different people. As you go into different spaces, the game rules are customized accordingly, and you can go from experience to experience.

Instead of having just one company's authorship ever-present wherever you are, you'd see yourself 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 as entrepreneurs, indies, or enthusiasts—all working together simultaneously.

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. So, we're investing massively in building new programming-language technologies around Verse and our proposed standards for future metaverse programming. We hope that will solve those kinds of problems and make that kind of world possible.

So, first of all, that's a super exciting future where it's not hundreds or thousands, but millions of creators who can create different small or big elements of a world as big as Earth. If you close your eyes and imagine that world, that's really exciting, where it's not a centralized company controlling the release of a particular island or so on. It's people constantly and dynamically modifying all the islands of reality in this digital world.

So, if you could speak to some of the technology that can enable that—you mentioned the Verse programming language. First of all, how legit is it for you, the CEO of Epic Games, to be a co-author? The programming-language theorists are losing their minds. You're a co-author on a paper describing some of the nuanced details of a programming language.

So, maybe you could speak to this programming language called Verse. It's a functional logic language. What is it? What are some cool features of Verse?

#467

Verse is a programming language that we're building for large-scale simulation programming. It's designed to make it easy for you to write code that can scale up to not only building a Fortnite island, but also building modules or components that can be used by millions of other programmers, coexist in a huge environment, and scale up to a huge-scale simulation.

Some games will be small. Battle Royale might find that 100 players is actually optimal. It might be that the 1,000-player version of Battle Royale would be worse, but I bet there are 1,000-player, million-player, and tens-of-millions-player experiences that are even better than that, which have yet to be discovered.

Wait a minute. Tens of millions of players together?

#467

Sure, we've had Fortnite events that have attracted 15 million concurrent users, but the fact that they're all divided up into servers with 100 players each for those events isn't really a positive. It's just a limitation of the technology, tracing back to Unreal Engine 1 and its single-threading decisions.

If we could build a concert where all the concert participants—potentially tens of millions of them—could participate together simultaneously, see that there's a massive crowd, and all do interesting things and interact with each other, that would be way cooler.

Sorry, I'm just loading it in. Just imagining 10 million people interacting together in one scene graph—what a cool world that is.

#467

Sure. Well, you have 10 million people, and you have less than 10 million pixels on your screen. So, what does the Nyquist sampling theorem say? It says that you don't need the full overhead for every player. You need to render the players around you in some approximation of everything else.

Yeah, but there's also a networking component. You're speaking to the rendering, but, oh boy, there's a lot of work that has to happen there.

#467

But, you know, this is what we do for a living. We solve hard problems.

I understand, because if they're easy, then other people could have solved them already. That's really cool, though. The possibility, the vision of that, is really cool. Even just 100,000 people—or bringing 10,000 together—because there's a reason in the physical world, when you go to a concert and have all those people around you, that energy, or when you go to a football game, that energy is unlike anything else. If you can bring that energy to the digital world, that's amazing.

But anyway, on the technology side of bringing that to life, on the programming-language side, can you continue, as I rudely interrupt you, talking about Verse?

#467

Verse is a functional logic language because we think that's the way to make the simplest and most powerful language simultaneously. Back in the 1970s, the programming-language designer who built Pascal, one of the early programming languages, Niklaus Wirth—or Nicholas Wirth, as Americans might call him—stated this principle: a programming language should achieve a high degree of power not by having a lot of features, but by having a small number of features that work together and can be composed together arbitrarily.

That way, you have to learn a relatively small set of things, and the real knowledge comes as you learn ways to combine them to achieve bigger and bigger programs. 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. There was this meeting in 1956 that very few people even know about, but it's where all the major foundations of modern programming languages were decided on, which the C family of languages inherited.

So, we're very much living in a world that was defined by them. Thankfully, they got a whole lot of things right. They defined how functions should work, how variables should work, and how recursion should work. Thank God they got those things right, but they got a few things wrong.

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.

#467

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, it’s providing a set of values you could iterate over.

There are a bunch of features in today’s programming languages that were defined in an ad hoc way without really thinking through this zero-, one-, or many-values approach. 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.

In languages today, this is done with variables of type Boolean or expressions that produce Booleans. We have Boolean variables that are either true or false, and we have expressions that evaluate to Booleans. You can express a condition as a bunch of these features together, but you’ve lost any computation you’ve done in evaluating that Boolean expression.

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, and now you’re running this one batch of code. If your expression failed, then you go to the else branch.

The exciting thing about that is that your expression that succeeds or fails can produce values and bind variables that are then accessed by the then branch. You can write a conditional where you can only get to the inside of the then branch if a bunch of variables have successfully been bound to values. 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.

A for loop in a traditional language is just a bunch of imperative code woven together to produce a bunch of values iteratively. It’s rather awkward to do complicated things in for loops, so you often end up with ever more complicated constructs built to work around that, like iterators and other things.

The idea of functional logic languages is that your for loop can just produce multiple values. If it produces zero values, you go through zero iterations. If it produces a bunch of values, you go through all of 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. They bind a bunch of variables, do a bunch of tests, produce a series of results in some order that you’re iterating over, and then you can handle all of them and produce a result.

You 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. It gives you the best of databases and regular programming in a much more uniform way.

The power of this is that now users can write functions that not only produce a value. You can write functions that might fail. You can write a function that answers a question, and the answer can be either yes, with my value being this, or no. You can combine these together into arbitrary queries.

The funny thing is that this is not how C++ works. When we have expert programmers moving over from C++ and writing their first Verse code, they try to write C++ code in Verse style, and it ends up being convoluted code that’s worse than good C++ or good Verse.

After a few months, they get up to speed and start writing really awesome code that’s tighter and more compact than before. With users who’ve never programmed before but are learning programming for the first time in the context of Fortnite, it’s really fascinating. These users are learning this kind of programming as their intuition. They just assume programming works this way, and they’re writing much more advanced and interesting for loops and conditions than we’re often writing internally because they’ve grasped the core concepts.

Yeah, you said a lot of really interesting stuff. First of all, it’s very interesting that there are a lot of people learning programming for the first time with Verse, which is a very different way to look at programming and, in some deep sense, a very intuitive way to learn programming.

There are a lot of properties of this being a logical language, one of which is—well, we could maybe speak about confluence, but also correctness. Being able to prove the correctness of code is basically a way to write bug-free code. Can you speak to that and the importance of that when you’re building the metaverse?

#467

Right. The challenge with the metaverse is, first of all, that it’s a huge codebase evolving over time and written by many authors. You might see a new module being updated somewhere every second, and you expect, in this live, ever-running simulation that never shuts down, for everything to upgrade live in place.

One critical component of that is the ability to release an update to something you’ve already published and be sure that it’s backwards-compatible with the one you’ve already released. That’s essentially a type-checking problem: checking that your new interface is backwards-compatible with your old one. 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. You see several branches of that whole field. One of the really interesting things that Java and C did in the early days, and later abandoned and didn’t bother updating, was defining a very rigorous set of rules for what changes you can make to a module for your future updates that don’t break backwards compatibility.

That’s a problem for type-checking. Say you have a function that promises to return some integer. In the future, you could say that it returns some natural number, because every natural number is an integer. That’s a backwards-compatible change, but you can’t say it returns a rational number, because some rational numbers are not integers. The system ought to reject that kind of change.

The much more interesting thing about type-checking was the realization, actually made in the 1930s, that if you design a programming-language type system in a very particular way, then it becomes useful not only for expressing types of variables. The traditional thing every type system does is say, “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. One theorem you might have in a program is 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 follow this system of type theory, then you can require anybody who writes that sorting function to prove that they’ve actually sorted its result.

You have types, or theorems, and values constructed a certain way can be proofs of those theorems. Nowadays, in mathematical literature, you see more and more theorems being proven mechanically. Mathematicians are proving theorems in a way that is verified by a computer to be a correct proof.

In the old days of mathematics, people would write down language. If you look at all of Euclid’s theorems, it was just language—writing in ancient Greek to explain the steps of the proof and convince the reader that the thing was true. Starting in the 1930s, mathematicians moved toward rigorous formal proofs in which there’s a series of steps that can be mechanically verified.

When mathematicians say they’ve done a computer proof of a theorem, what they really mean is that they’ve written the program in a proof language. Lean is a theorem prover, Coq is a theorem prover, and there are several others. They’ve written a mechanical proof in that language that a computer has checked, so it’s impossible to lie. If you say that you’ve proven something and the computer verifies it, then it’s definitely true.

This is a feature of mathematical proof languages, but it’s also an idea that’s making its way into programming languages gradually over time. 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 adopts it in a way that’s really user-friendly, so you don’t have to do all of that yourself.

The idea is that you want gradually more information to be incorporated into the types of variables. The property you want from a programming language is that if your compiler accepts your program and doesn’t beep and tell you there was an error, then your program should work.

There are all kinds of ways humans can make mistakes, so 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.

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 while running your code yourself. When it’s running on your computer, you just fix a line of code and your bug is fixed.

#467

When you have to fix it live, you have to release a patch, release patch notes, test the patch, and check for all the other bugs that might have been introduced. Everything becomes vastly, vastly more expensive. The real aim of the Verse programming language and approach is to catch all of these errors at compile time and make the metaverse a very reliable place.

Do you see a world where, at compile time, you could prove that the program is correct in some sense of correctness?

#467

Proving things becomes computationally harder as they get larger. The really important thing about this whole field is that you should be able to adopt these capabilities gradually and apply them where you really need them. If you're writing something like a cryptography algorithm, that's a good place to prove things. If you're writing a data decompressor that's going to be used by an entire ecosystem, proving that it doesn't overrun memory is actually really important.

A lot of the reason that security vulnerabilities happen today is because, in a different language, a compiler could have caught them, but it doesn't catch them in C because C just doesn't have this feature. We shouldn't see this as scary. Everybody working in a typed language like C, C#, or Java is proving theorems all the time. If you have a variable of type integer and assign some value to it, you've proven to the compiler that the value was an integer, because otherwise it would have rejected it.

As we add more and more advanced proofs, we'll get compositional properties emerging from our systems that are easy to use, and people will prefer to use them. We might imagine a future where we have AI helping us write certain kinds of code. The big problem with AI is that you ask it to do something and ask it to write a fragment of code that does it, and it might give you a perfectly valid fragment of code that compiles but does the wrong thing.

If we had languages where you could say, “Write a function that sorts this array and prove that it does that,” it could actually write the proof. If the compiler didn't complain about it, you could trust that it was actually sorting the array. Otherwise, you could go back to the AI and say, “Well, that didn't work.” 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.

By the way, I should mention that you sent me a note about the Curry–Howard correspondence, which I went down a rabbit hole on. That's a whole fascinating field that shows the mathematical relationship between programs and proofs.

That's right. This is a result from the 1930s. It's one of the most important results of computer science that almost nobody knows about.

#467

They did this rigorous breakdown of type systems and the 1930s formulation of programming, and established that everything you can prove in mathematical logic, you can prove within a type system if it has certain features. If you break down what a proof is, a proof that integers exist is some integer, like 5. That is a proof that integers exist.

When you have something like `var x` and say `x = 5`, you're proving to the compiler that 5 is an integer. That comes as second nature, but you can prove more advanced things. If you want to prove that a pair of things are true—that 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. That's the conjunctive law of proofs.

There's a disjunctive law, too, and then there's an implication law for proofs. It turns out that the implication law is really satisfied by functions. When you write a function in a programming language, you're saying, “If you give me this thing, I will give you that thing.” If you give me a parameter of some type, then I'll give you a result of some other type.

By writing that function, you're proving that, given one of these things, you can produce another thing. That's a proof of an implication. With only 7 laws, you can construct all of mathematical logic in a type system.

One important thing about programming languages that hasn't been given enough attention is that some aspects of programming languages are just subjective. They're machinations of the programming language designer. Guido van Rossum decided that Python should support indentation in a certain way. As long as you're dealing with things like human notation and the naming of things, there's always going to be that subjective layer.

But there are other parts of programming languages that are not subjective and should be fundamental. When you look at type systems, there is a way to do type systems that gives you mathematical proofs, and every other way of doing type systems that doesn't give you mathematical proofs is just worse and should ultimately be rejected.

I think one of the jobs of computing is to identify what we've actually done right in the past and what we've done wrong, and for everything we've done wrong, go back and fix it. Otherwise, we just keep accumulating so much cruft that our systems eventually are crushed under their own complexity. There have been massive announcements of horrible vulnerabilities in software and services over the past year.

It turns out that some nation-state backdoored a bunch of telecoms' surveillance systems for wiretaps. That's a huge problem, but ultimately, when you break it down, it's probably because of some buffer overrun in some C program. These decisions about programming languages have long-term implications.

It's really fascinating that, in building these systems that hundreds of millions of people use, you're rethinking how to actually build them from first principles.

#467

I should mention that Verse's primary design goals are that it should be simple enough to learn as a first-time programmer, general enough for writing any kind of code, and productive in the context of building, iterating, and shipping a project in a team setting. It should be statically verified to catch as many categories of runtime problems as possible at compile time, and it should be performant for real-time, open-world, multiplayer games.

We didn't really talk about performance. It should be complete, so that every feature of the language supports programmer abstraction over that feature. It should be timeless, built for the needs of today and for foreseeable future needs. It's also strongly typed and multi-paradigm, using the best of functional programming, object-oriented programming, and imperative programming.

It's as deterministic as possible. If you run it over and over, it runs in exactly the same way. Failable expressions, as you talked about, are super fascinating. There are so many cool features in this, including speculative execution and concurrency. Maybe you could talk about concurrency. What is it about Verse that allows for concurrency at the scale that you need?

This is the single biggest technical problem that we're working to solve in this generation, and that is taming concurrency so that any ordinary programmer can achieve it by just writing ordinary code. It's hard. Programming on a single-threaded computer is hard enough, but it is completely predictable.

If you have a language that's deterministic and you run the same code over and over, it's always going to do exactly the same thing, and there's no unpredictability about what might happen. You're reading and writing variables in some order, and you're always going to see it behave the same.

The problem is when you introduce multiple threads or multiple nodes in a data center, all working together on a single problem. They each want to read and write different pieces of data and change the state of the world as they go.

Still, almost all concurrency in real-world programs today is achieved manually. Programmers are writing code that might run in multiple threads very, very carefully so that they are negotiating among the threads to get access to data in a way that's going to give them predictable results. It's incredibly hard.

It's so hard that, in 5 generations of Unreal Engine, every single generation has decided we're not going to try to scale up all of our gameplay code to multiple threads manually. It's much, much, much too likely to go wrong—not only for ourselves, but for every partner company that licenses Unreal Engine and tries to use it to build a game. It's just a massive footgun.

There are a variety of solutions to concurrency that are all rather suboptimal. One attempted solution was, “Oh, just don't try to solve this problem at all. Let's break our program down into microservices.” Almost all online websites of massive scale, like Amazon.com, work with hundreds of microservices, where different servers negotiate with each other by sending messages to each other.

By programmers writing those things very carefully, they eventually get to the point where they're 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, 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 the computations they're running in parallel.

#467

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.

The idea of a transaction is a block of code that does a bunch of operations on memory. It might read, it might write, it might process an order, or it might accept or reject an order. It might transfer money between one bank account and another, and it might make conditional decisions like, “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. 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 else might have written something else. You might get inconsistent bank balances arising if you don’t have a way of ensuring that these all run in a specific order.

The idea of transactions is a way of dividing an entire program into self-contained updates that do an arbitrary amount of computation but must run in a single-threaded manner. In the case of a game engine, that’s a gameplay object update. When you’re playing Fortnite, every other player is a gameplay object. Every enemy is a gameplay object. Every rocket, projectile, car, and thing you see moving around and interacting—not just a fixed, static part of the world—is a separate game object, and each of those objects is updated at a rate of 1 update per frame, at 60 frames per second.

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. Right now, that’s done single-threadedly in each game session. This is why Fortnite is limited to 100 players. If you absolutely maxed out a server, maybe today you could get it up to 140 or something, but it’s not going to thousands or millions or billions.

What we need is a technique for magically, automatically scaling our code to that. Transactions are the idea. A transaction is a granule of code that runs in its entirety.

The idea of this transactional memory concept is that we’re going to have programmers write completely ordinary code that reads and writes variables in the completely ordinary way, and they’re not going to have to worry about concurrency at all. Today, a computer just runs your program. There’s no amount of speculation going on at the programming-language level.

The idea of transactions is that, since we have a bunch of operations, we need to apply a large set of them concurrently. Instead of each one reading and writing from global memory shared by all—in which case they might be reading and writing, contending with each other for the same data, and doing contradictory things to it—we’re going to track all of our writes locally. We’re not going to write changes out to global memory. We’re going to keep track of them in a buffer that’s just for that one transaction.

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 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 2 transactions don’t read or 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.

This is so fascinating to imagine: this kind of system, arbitrarily running millions of updates in parallel of gameplay objects. That’s the thing that enables what we’re talking about—tens of millions of people together in 1 scene.

Tim Sweeney

Exactly. The key is that you’re running these updates speculatively, and you’re not committing their changes to memory until you’re sure that they’re free of conflict. You might update 10,000 objects and find that 9,000 of them were conflict-free. So you apply those 9,000 object updates to memory, and they could have run in any order without changing the result.

Now there are 1,000 objects left over. You have to run those again, perhaps in a different way, to get them to eventually commit to memory. In the meantime, you just throw all their computations away and redo them later. By doing this, we’re moving this from being a programming problem for the programmer to deal with to being a language problem for us language designers to deal with.

We’re moving a vast amount of pain that would be imposed on a million people to a vast amount of pain imposed on a small number of people who have to actually make this work.

That’s amazing. That’s really incredible. What’s the state of things with Verse? I guess what you’re outlining is that, if it’s successful—and hopefully it is—this would be a big part of Unreal Engine 6. What’s the timeline? Where do we stand today?

Tim Sweeney

There’s a lot going on in parallel. The key thing with Verse is that we have been specifying what we think is the ultimate version of the language, with all the features we want, whereas we’ve been shipping more modest versions of the language over time. We’ve released dozens of updates to it over the past year and a half.

The idea is that the shipping version gains more and more features over time, while maintaining backward compatibility with old versions and continuing to improve and approach the ultimate version. 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 use case before we make it available to all of our partners using Unreal Engine for all of their projects.

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. We’re adding major new APIs every few months throughout the course of this year.

Unreal Engine licensees who are building standalone games already have access to the full engine through C++. They have massive expectations of an API, so we can’t release this to them until we’ve built up all the essential features they’ll need for building their gameplay in the future.

We have these 2 different tendrils of progress. There’s Unreal Engine 5 for game developers, and there’s Unreal Editor for Fortnite targeting the Fortnite community. There are different bits of development that are only in one area and aren’t applied to both. Not all of the Unreal Engine 5 features are 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 7 platforms in a platform-independent way.

The place where all these different threads of development come together is Unreal Engine 6. It’s a few years away, and we don’t have an exact time frame, but we could be seeing preview versions of it perhaps 2 to 3 years from now. We’re making continuous progress toward it.

That’s really nice. There’s this ultimate version of a language that you’re constantly working on and thinking through. Then there’s the shipped version of the language that’s used by a large number of people, but still in the constrained environment of the Unreal Editor for Fortnite—for the Fortnite game.

Then there awaits the more general Unreal Editor, Unreal Engine, for the lessons learned in the Fortnite context to be integrated into the more general context of creating simulated worlds for all kinds of games, including Fortnite. It’s a really nice setup, because you’re both using Fortnite as a testing ground for the language and keeping an eye on what the ultimate thing will look like. It’s also necessary to deliver all the features that we mentioned.

#467

Brilliant. The aim for UE6 is to bring the best of both worlds together: much easier gameplay programming for the Fortnite community and for licensees, more scalability to large-scale simulations of all sorts, and greater ease of use, meaning it will be easier to hire programmers who are familiar with and experienced with the thing.

We’ll also ensure that every game developer has the full deployment capabilities, so they can build a game once and then ship it anywhere. The ultimate version of this enables a game developer to build a game of any sort, either or simultaneously both, and ship it into Fortnite as a Fortnite island that players can go into, bring their Fortnite items and cosmetics, and interoperate properly, or ship it as a standalone game, or both.

If they ship it as a standalone game, they shouldn’t be missing out on the open economy either, because in this time frame, we’ll have opened up the Fortnite item economy to third-party developers of all sorts, hopefully through a standards body. 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, have your game items work in Fortnite, and have your item economy integrated with the overall metaverse economy.

That helps solve the really core problem of the game industry that Matthew Ball has been documenting over the past few years.

Yeah, by the way, Matthew Ball has been really helpful. He wrote a really great book that I recommend people check out. There’s an updated version. Let me just ask, because again, there are a bunch of indie developers listening to this.

I saw that a lot of solo developers out there are using Unreal Engine, and they’re basically creating video games solo. I can highly recommend one—it’s great. Choo Choo Charles is a great video game. Gavin Eisenbeisz is a great guy. He solo-created this game that’s, I think, quite popular. I believe he says he used Visual Scripting. He didn’t even use C++; he used visual scripting. He used Blueprints to create it.

So, all that to say, people should go check it out. Support indie developers. Support Gavin. Support everybody like that. I think it’s important to say because there’s so much genius and artistry out there that we want to support the crazy dreamers out there.

Anyway, all that to say, what are the ways you think Epic can support indie developers like that? People like Gavin? Give them superpowers to create games from which they can make, at the very least, enough money that they can keep doing their art.

#467

Well, that’s really about productivity. Because to be successful with a game, you have to have a great game. If you’re targeting a—if you’re building a type of game that nobody’s ever built before, you might be able to build a smaller, simpler game than if you’re competing in a massive genre that has huge expectations. But it’s all about enabling somebody to do that in a reasonable amount of time that they can spend, and to be able to finish it, ship it, and maintain it successfully.

The tools are a big part of that: having the tools be as productive as possible. But there are a lot of other facets as well, like having a content marketplace is a big thing. Just off-the-shelf piles of content, some free and 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. Somebody’s already built one, and theirs is probably perfectly suitable for your game. Over time, there’ll be more and more.

There are also a lot of indie developers living as content creators. They’ll be releasing content on Fab Marketplace or the Unity Asset Store and earning a living from 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. 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.

So we should talk about the fact that, amongst many other things, you’ve been philosophically and spiritually battling monopolies in general. One of which is the Apple marketplace that charges 30% from developers. Can you speak about this idea that you believe Apple and other companies—Valve—should not be charging that kind of revenue cut?

#467

Sure. Let’s start from a very basic principle of computing. The first computer I owned was an Apple II Plus, designed by Steve Wozniak and marketed by Apple, and then I owned an IBM PC. In those days, anybody could write code. Your computer literally turned on with a programming-language prompt in front of you. You had to actually do work not to write a program and instead run somebody else’s program.

That was incredibly empowering. Anybody could write a program. Anybody could put it on a floppy disk. Anybody could share it with their friends. Anybody could make copies of it, put it in a store, sell it, and build a business around it. They were completely able to, without seeking any big tech corporation’s permission, do whatever they wanted.

Even from IBM—remember, IBM was the dominant computer company on Earth at the time that they released the IBM PC as an open platform. 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.

Over time, the big companies have realized that they could shut down and block software makers from releasing software on their own, and block software makers from doing business with customers directly. I’ve always viewed this practice as terribly abusive.

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. There’s absolutely no reason that Apple should block you from installing apps from other developers directly if you want, by going to their web page, or writing your own apps without their permission and running them yourself without having to get a developer account or go through their bureaucracy.

There’s no reason that any consumer who gets an app shouldn’t be able to do business directly with the developer of the app. 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 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 there with mobile apps, because these stores have popped up and they don’t provide any useful value to the user.

Yes, there’s a search function to find software, but there’s no reason other companies couldn’t build a better one. I bet if you had Steam, or if you had Valve build Steam for iPhone, Steam for iPhone would be a much better app store than the iOS App Store. A lot of people would use it, and Apple would be forced to build a better app store in competition. Everybody would improve their products as a result.

Apple and Google shutting down the competitive engine that drives the software economy has massive implications for everything. 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 a sort of 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 very hard for the fun-based games to actually succeed there. The cost of operating these online games now is enormously high. You have a game that’s based on fun, and it’s not loot-box-heavy. You have to pay 30% of your revenue to Apple in order to just get access to the platform.

Thirty percent is way, way, way more than most game companies make in profits right now. If that fee is more than the profit margin of a normal company, then they can only stay in business by raising prices. These 30% fees are raising prices of all digital goods. 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 a game on Steam, and if that game’s on Steam, it’s always the first result, because Steam’s not monetized with advertising. Apple is. They do that so they can make even more than 30%.

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.

The money that’s left over is only enough to fund these games with rather abusive practices that do not look like games to normal gamers, 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.

I had a quick chat with Matthew. He asked me to ask you this question: Why don’t more companies fight Apple in the way, openly and totally, that Epic has been? What makes Epic so unique in this regard?

And I should say, I think everything you said—I agree with fully. I think what Apple is doing is just wrong. I think Apple, in many dimensions, is an incredible company. They have brought so much good to the world. In this regard, I just think it’s straight-up wrong what they’re doing.

Lex Fridman

They're not providing the value of 30%. And even if they were, the monopolization and the centralized control without competition are wrong.

Anyway, why are you fearlessly fighting Apple on this when other companies don't seem to want to step up?

#467

All companies are terrified of Apple because Apple can destroy their business. Epic was in a unique position with Fortnite. First of all, we had the biggest game in the world at the time we started the fight with Apple. Second, a majority of our users played on PC and console, which meant that if we lost access to iOS during a fight, we would still be able to survive.

That set us apart from Spotify, Facebook—you name the top 10 mobile apps. I think none of them would be able to survive without Apple. Their businesses would literally be destroyed if Apple blocked access to them. Apple was incredibly clear with developers that they're willing to deprive all users of access to any app if they get into a fight.

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.”

A very small number of vocal developers have been willing to speak up, and Apple has actually refrained from crushing their businesses when they weren't violating any Apple policies. That took a bit of discipline, which I think was also a certain amount of calculation by Apple: they couldn't survive being seen as the company killer—“If you criticize us, we'll crush your company.”

The other thing 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 from Apple—such as 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.

Apple has a very long history of playing cat-and-mouse games with developers. If a developer isn't in Apple's good graces, they'll just slow down the updates. They've been slowing down updates for several major tech companies, sometimes for weeks and sometimes for months, without it all going under the radar because everybody's afraid to challenge them publicly.

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

That thing can only exist if the Apple and Google gatekeeping monopolies are lifted. It's not just the 30% fees. The 30% fees are economically ruinous, but Apple imposes other levels of control.

Apple prevents all web browsers on iOS from implementing web standards better than Apple does. Apple has really limited data-storage capabilities and 3D-graphics capabilities on the iOS web APIs—APIs you can access from web apps running within a web browser. That's to incrementally cripple those apps and ensure they can't possibly compete with native apps. By depriving web apps of those features, they prevent web apps from competing with native apps.

If Apple treats the metaverse the way it treats the web, it will say, “You can only use Apple's metaverse engine. Unreal Engine is disallowed.” Then Apple can impose all of its 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.

They have this giant array of anticompetitive 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 Apple more effectively.

It's just a giant, to use the Soviet term, defense-in-depth strategy, where they've constructed a massive series of barriers. Each one is fatal to any attempt to compete, so even if one barrier is overcome, the others remain in place and shut down the whole scheme.

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 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.

I think it should be said once again: I think it's wrong, what they're doing there, and I hope there's public pressure and government pressure for them to open up the platform. As a person who loves Apple, I believe this is also good for Apple.

There's a natural thing in companies to want to close, control, and crush competition. But Apple is full of brilliant engineers. Open it up and win. It's going to create the right kind of competitive incentive to make the App Store better, because they're great at creating great interfaces, but competition will sharpen the sword.

It's just going to make everything much better. I do hope there's a lot of public pressure, and I deeply appreciate that you're speaking out in this way, putting that pressure on and letting people know that it's okay to say that this is wrong.

#467

Thanks.

#467

Yeah, competition makes everybody better. You have a monopoly that's forced to compete, and suddenly the monopoly's products get much better. The offerings to consumers get much better.

You see so many areas where Apple could be the best, but what they have is just really, really lousy. It's this old guard of leadership clinging to these old policies, turning themselves into the enemy of every developer and every regulator. I think it's ultimately massively to their detriment, and I can't wait for a new generation to come in and paint a bright path to the future.

Epic was an awesome partner of Apple for more than a decade, with demos, partnership, and technology usage together, and we did amazing things together. I would love nothing more than to have Apple bring back Steve Wozniak's original views. The Apple II was such an amazing thing: a completely open platform.

The manual to the Apple II included a listing for all the ROMs, the source code for the ROMs, so you could understand exactly what was happening there and learn from it. It included a hardware schematic of the entire computer, so you could learn how to make a peripheral and plug it into an open ecosystem. 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. I hope Epic and Apple find a path forward together, flourish together, and Apple embraces competition better.

One of the things I admire about this conversation is that you mentioned Steam a bunch with kind words, were supportive, and basically never mentioned the Epic Games Store. I love that. It really embodies the fact that you want variety and freedom for people to choose the best thing, and in so doing create this large network of humans interacting freely with each other.

That said, one of the competitive pressures that Epic created a few years ago was launching the Epic Games Store. Instead of Steam's 30% revenue cut, you went with a 12% revenue cut, creating competitive pressure and saying, “Listen, this shouldn't be that high of a cut.” I thought that was an amazing, brilliant idea, and I think it still is a brilliant idea. It's wonderful.

In preparing for this conversation, I looked on the internet and saw there's a lot of criticism of EGS, the Epic Games Store. First of all, 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 for one request: can we just celebrate awesome shit? Also criticize, but there's just not enough celebration.

The 2 directions of criticism are, first, that the launcher interface is clunky and lacks a lot of the features of Steam. The second set of criticism is the exclusive contracts that were made with some of the games on the Epic Games Store.

First, huge props on the 12%. Maybe you could speak to the vision of that, and second, can you comment on those 2 criticisms?

#467

Sure. One of the reasons people characterize the Epic Games Launcher as clunky is because the Epic Games Launcher is clunky. We need to improve this. There's a lot of work going on there.

I wish we'd gotten better at addressing quality-of-life features and prioritizing them above all the other features. Steam has 15 years of built-up work, with many of the best programmers in the whole industry working on it, a much larger team, and a lot more time spent on it. We've had to make a lot of prioritization decisions about what we support with the Epic Games Store and when.

#467

A lot of the time, it's been supporting commercial features like merchandising, offering multiple versions of a game for sale, offering upgrades from the regular edition to the deluxe edition, and other things that partners work on. Other priorities have been quality-of-life features, launcher load times, and other things. 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.

One thing it took us a while to realize was that it's nonuniform. Depending on your proximity to a CDN and the size of your game collection, it can be either awesome or really clunky. The users for whom it's really clunky are the people who, I think, make up a large part of the complaints. They're going to speak up. I should also say that the Steam launcher, for a long time from my memory, but also just looking online, was also very clunky in the beginning.

One of the criticisms of the Epic Games Store from the beginning was, "You don't have all of the features of Steam," but we very much don't want to have all of the features of Steam. Steam has forums dedicated to your game, and we decided we don't want to create forums. When we talked to our partners, they generally didn't want us to create Epic Games Store forums for their games because there are already channels that they prefer.

There's social media and a number of platforms, and there's Reddit, and there are lots of places for gamers to discuss their game. They prefer those discussions to be there, and so it's very much not our goal to mimic everything about Steam. But we do want to have all the convenience features that make it as easy and fun to use as Steam. There's a long journey ahead, but we continue to reinvest, and we're working to build a multibillion-dollar business there. I think we'll succeed.

Already, the Epic Games Store supports an immense amount of Epic Games commerce in Fortnite on PC, and now on Android and iOS in the European Union, too. It's a permanent facet of the industry, and we are never losing heart in it. I really feel that, at some point, the benefits of the Epic Games approach are going to outweigh the benefits of the Steam approach, especially as gaming becomes multiplatform.

One of the things that really sucks for all gamers is that you have a lot of friends in the real world, and 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. You're very much bottling up PC gaming into a hardcore group of PC-only folks and making all the other aspects of it difficult.

A lot of games have flocked toward Discord, which is a mess in itself, because now your Steam name is not your Discord name, and that's not your PlayStation name. Now you have 2 people in a game, and they have 4 different identities, and that sucks. Our aim for that, with Epic Online Services and the social systems that we built for Fortnite opened up to all developers, is to make cross-platform social features 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 multiplatform, especially multiplayer games, Metcalfe'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's the number 1 trend pervading the world of gaming today. It says that your game is quadratically more valuable the greater the percentage of a user's real-world friends it can connect to.

Your game vastly benefits by connecting all of its players together and not segregating them off into different online platform populations. 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.

That's going to be a long-running battle, because there's always a very toxic group of Steam users who even created an entire subreddit dedicated to criticizing Epic and our store. They create harassment campaigns at times against developers who use Epic Online Services. Developers do that so they can connect their players across platforms and have friends and voice across platforms, but suddenly that's trying to be turned into a negative.

It's clear that Epic wants developers to win, wants gamers to win, and wants Steam to do awesome also. In the competition between Steam and the Epic Games Store, we want to create awesome stuff together. It's obvious to me if you don't read the stuff online, but online there's this negativity that I don't think is constructive in general.

I should give a big, positive thank-you and props for the push to multiplatform that was always there with Fortnite, perhaps even before the pressure that Epic created around breaking the barriers between Xbox, PlayStation, and PC and being multiplatform. I got a chance to play Fortnite a little bit with you and all the people in the group, by the way. Awesome interface, audio chat, really fun.

You could see a couple of PC folks, a PlayStation person, and an Xbox person all together. You can't really tell what they're using except for a little icon, and it's nice. All those barriers that we've created with these platforms are gone, and you created the pressure with the Epic Games Store and with everything you're doing with the 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. Anyway, thank you for that. Thank you for creating that pressure.

#467

Thanks. Yeah, that was an interesting time. Sony had a long-standing policy preventing cross-platform play, and we had a long series of conversations that got pretty harsh toward the end. Sony ultimately came around, and they opened up PlayStation. Through a series of private conversations, they did the right thing.

Not only that, our partnership with Sony has increased since that argument back in 2018. We've gotten closer and closer and done ever more things with Sony, including brand IP like the characters from God of War and other games coming into Fortnite. There have been all kinds of crossovers, massive Unreal Engine adoption at Sony for making games and for making movies at Sony Pictures, and music partnerships with Sony Music. That's been an absolutely wonderful relationship.

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. Following a serious discussion with a close partner, they revisited it and did an awesome thing. Now Sony's much better off, Epic's better off, all game developers are better off, and the whole console industry is a lot stronger than it would have been if these silos had continued playing out.

Despite the potential concern that blocking platform play with Xbox gave Sony an advantage, Sony has actually grown in market share relative to Xbox since that time. You can't say that anything but goodness came of that time. I think a better version of Apple would have received the email I sent to senior Apple management and been like, "Huh, there's an issue here. We should have a discussion. We should reconsider this. We should listen."

They didn't, and that's why we're in the midst of a 5-year battle with Apple and, hopefully, still in the early days of a 15-plus-year partnership with Sony. Come on, Apple. We love you, Apple. Do a little bit better.

The second line of criticism that I mentioned is the exclusive contracts with some of the games. Can you just speak to that? In so much of the journey of Epic, you've been sort of against exclusivity.

Let's back up and talk about the principles at work here. Apple forcing other companies to use its payment service is a coercive decision by Apple. But if Apple convinced other developers to use its payment service by offering benefits or a better deal, or funding, or any other positive incentive, then that would be perfectly fine. One is preventing competition, and the other is actual competition.

#467

Epic has never forced any developer into any sort of exclusivity relationship. Rather, we've offered developers payment, incentives, marketing, or any number of things of value to them in exchange for coming to our store exclusively. 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 can do that as well. If we pay them money or offer other things of value in exchange for them coming exclusively to the Epic Games Store, I think that's their right.

#467

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. Some consumers who prefer Steam might prefer that the game be on Steam, but the developer in each case has decided that they would benefit more by doing this exclusive deal in exchange for benefits than by being on Steam.

One of the key exhibits in the Epic-Google trial was this opening exhibit, which was trying to point out to the jury 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 the same games as the competing store and everything is priced exactly the same.

We initially looked at 2 ways of competing strongly with Steam. 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 is going to sell for $50 and we take 12%, we could actually lower the price and potentially even lose some money to offer a better deal.

We tried to pursue this, but very quickly every developer told us that they wouldn’t agree to better pricing because, if they did, Steam would stop giving them marketing, featuring, and other benefits. The console makers would be mad, and all their relationships would be harmed. There’s an undercurrent of powerful platforms and ecosystems encouraging developers not to compete on price.

Not being able to compete on price, we decided to compete on supply by doing exclusive deals, and we signed a lot of them. We paid developers lots and lots of money. I think we distributed over $1 billion 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, and 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.

A lot of other games, especially some smaller games 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 they wouldn’t have reached organically. Some of them, in the end, we and they concluded did worse by being on the Epic Games Store exclusively, in terms of reaching fewer customers.

We had these limited-time exclusives. When they ran out, the developers put their games on Steam, and lots of data was gathered to understand what worked. This worked well for some games and didn’t work for other games, but companies seeking to compete—especially underdogs seeking to compete—have to offer some unique value. They have to offer something that isn’t available through the competitors.

I understand that Steam users who just prefer using Steam and buying games on Steam want to have their library in one place, and 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. If Valve were forced, through Epic Games Store success, to compete with the Epic Games Store, then developers would be getting a better deal and consumers would be getting a better deal.

These 30% fees would be driven down quite a lot toward the actual costs that are required to support the stores.

Yeah, I mean, there’s a lot to be said there. I’ve gotten to watch Spotify try to do this with podcasts: enter as the underdog into the space and try to attract people. They made exclusive deals, for example, with Joe Rogan, where the podcast would only be published on Spotify.

Personally, I think, long term, what I would love to see for the Epic Games Store is to not do any exclusivity, similar to what Spotify is doing now. Even with Joe Rogan, they let go. It’s open, wide open. Instead, compete on the space of the non-clunkiness of the interface, because the foundation of what the Epic Games Store represents with 12% is philosophical.

You’re also competing in the spiritual realm of what it stands for ethically. That’s also a really powerful way to win. Now that there’s a large enough number of people using the Epic Games Store, drifting away from exclusivity is understandable. It’s needed for the underdog to enter the scene, but it goes against the freedom—the free spirit of choice—that I think you represent in a lot of the decisions you’ve made: making the games cross-platform and giving freedom to the developers, giving freedom to the gamers to choose.

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

#467

Well, here’s the conundrum. The exercise of soft power by all of the competing stores has made it intractable for almost any developer to offer a better price through the Epic Games Store than through Steam.

You can imagine that, if the effect of Epic’s revenue sharing—12% to developers—was that games just cost 18% less on the Epic Games Store, that would actually start to reshape consumer behavior significantly. People would start coming here for the better deals.

But I feel like Steam gives developers nasty phone calls, and so on, when they propose to do that. What’s the mechanism that drives users away from the incumbent store to the store that offers a better deal? If 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 among multipublisher stores in line, so that a much, much smaller store can compete?

A better UI is great. Steam is super polished, and the Epic Games Store, in time, will hopefully be as polished. But 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—it’s in a developer’s interest to sell on Epic and get 18% more of the revenue—I think there’s a real power to incumbency that’s very hard to overcome through just being there and being as good.

Ultimately, where I hope it converges to is less exclusivity, and where the competition can be the kind I love the most: on the UI, on the experience, on the overall quality. Then, on the Steam side, on the 12%. It can go from 30% and start to support the developer by lowering it from 30% closer to 12%.

Anyway, I’m a big supporter, and I don’t like the criticism of the Epic Games Store. But I also have to say that I don’t love the exclusivity. 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 at least to get some of their games to try out, to experience, and to allocate some of their library to the underdog.

I totally understand and hope the UI keeps improving. Thanks.

#467

One more bit on that exclusivity point is that, when we told Google that we were going to launch Fortnite outside of Google Play and go into competition with them, they viewed exclusivity as such a powerful competitive force that they went around to the top 30 publishers and paid out hundreds of millions of dollars to them in order to agree not to do exclusive deals with competitors.

That was called Project Hug—“Hold developers close.”

That was one of the major pieces of evidence on which the jury found their practices to be illegal and anticompetitive. One more data point on that: we talk about 30%, and there are always a lot of people defending Steam. They say, “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—staffing it, maintaining it, the software, and the entire ecosystem—is around 6% of revenue. In a competitive market, what would a company whose costs are 6% be able to charge? 30%? Absolutely not.

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 points. The numbers there are strikingly supportive of outright anticompetitive market distortions.

Okay, what do you think is the future of the gaming industry? We’ve said a bunch of exciting stuff about indie developers. Do what are called AAA video game companies—these big gaming companies—have a future? What is their role? How do you see, in the next 5, 10, or 20 years, the evolution of these big companies and indie developers?

#467

There’s one constant in gaming that I think the industry manages to lose sight of from time to time, astonishingly, and that’s fun. People play games for fun. Our whole job is to deliver fun.

When you look at a lot of the games that failed recently, they just didn’t deliver fun, or they didn’t deliver fun in a manner that was nearly competitive with the other sources of fun that exist in people’s lives.

#467

And so, at a basic level, we don't need a terribly complicated theory to explain a lot of the malaise in the game industry. There's 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, 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 or are getting worse. They're making games that are less fun.

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 the core is a failure to deliver fun. 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. There are exceptions to that.

I think we're seeing much, much more playtime shifting toward games you're playing together with your friends, and not just random internet strangers who happen to play that game too, but people you actually know in the real world. 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. If you have 20 people with 20 different opinions of which game to play, in a single-player game, each one might buy a different single-player game. But in a multiplayer game, if there were 20 games out and each one had their own completely individual preference, and each one were independently choosing which game to play, each one might buy a different game.

But if they're all realizing that they want to play together, what players are doing increasingly is playing the 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. That's certainly the case in different Fortnite groups I play with from time to time. One player might have preferred to play Call of Duty, one might have preferred League of Legends, somebody else something completely random, but it's just so fun to play together. We're doing that, and that means that there's really a Metcalfe's law effect in which games that are able to attract a large percentage of your friends are more able to attract you, and not only attract but also retain you.

I think Matthew Ball's analysis of this over the years has really documented the trend toward—you can call it the metaverse, or you can call it large-scale multiplayer social gaming. He's really documented this trend. Over the past year or so, it's taken a really, really strong turn toward an increasing rate of change and increasing numbers of players coming to Fortnite. We hit an all-time high of 110 million monthly active users about a year ago. And another close to peak this time, Roblox is bigger than ever.

This trend is players consolidating into multiplayer experiences they play together. We're seeing another trend overlaid with that, which is that when an awesome single-player game or small multiplayer game comes out, people will often treat it as a vacation. They'll go off and play that game for a while, then come back. I think Black Myth: Wukong was an awesome example of that. Wonderful game from a brilliant team in China. They made a game that no Western players had really seen that type of thing done before. It was awesome and it did well, but most players played it for a while and moved back on.

That can be lucrative, but a business that's building those kinds of games is 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. 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 and increasing reinvestment.

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. So there's somewhat of an increasing winner-take-all dynamic, where the biggest games reinvest more to make their games more fun. They gain fans at a faster rate than other games, and the industry is changing around that.

I think the lesson for the game industry now is that there are really two big opportunities being pursued. There are 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.

The trend there is going to be toward 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. I think that 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 trends of restructuring the business around the technology and changes of the day.

Okay, this is going to be a ridiculous question, but aside from the games you've created, what are some of the greatest video games ever created, to you? What video games have been impactful to you in your life, or maybe you've seen created and thought, “That's a beautiful art piece”? It could be in a totally different realm. Obviously, for me, I often return to the single-player domain of role-playing games, like The Elder Scrolls series, Skyrim. That was a world that they created. A recent game, Baldur's Gate 3, was a really incredible piece of work and art, doing a lot of innovative stuff again in the single-player domain. Are there games like that outside the ones you've created?

#467

I'm most impressed with the games that have created what appears to be a full, living, breathing world. Games that give you the sense that you're just a part of it and there's a lot more happening, and there's always more. They give you the sense that you could go anywhere and do anything, even though these games really do have finite limitations and there are places you can't go. Creating that sense of wonder is just a magical thing, like The Legend of Zelda: Breath of the Wild.

Oh, yeah.

#467

Yeah. Skyrim, Red Dead Redemption.

Red Dead is great. Yeah, there's an entire ecology simulator in there. I have a high school classmate who got into studying river ecology, and he was commenting that this is one of the very few games that's hydrologically sound. They actually went to the effort of shaping the rivers to follow erosion dynamics and so on. Just the attention to detail is incredible.

#467

It's been a funny journey through the industry. I last designed a game in 1992. I'm not a game designer. I have a very open mind here: the best game genre that will ever exist has not yet been invented.

As we get more technological capabilities, and creatives use that—hopefully empowered by higher-productivity tools and so on—we'll see more and more cool things emerge that we never dreamed possible. The idea of a world simulator is actually really interesting there. It's been tried a lot. It's usually extremely slow and expensive to create, but over time maybe we'll get better at that, and that will be a thing too.

You said so many interesting things there. New city builders, Civilization—it's just mind-boggling that they built a game with that depth that can evolve so dependent on your actions. To do that at that scale of world, but to where you can step into it and be in it, you know?

I think Red Dead is a great example, but to do Red Dead Redemption in a way where you can walk around with friends at a large scale—and I guess what you have given so many years to is creating the tools that enable the artist to give that attention to detail that Red Dead does on several of those things.

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. You can feel the care that they put into it.

#467

That's right. The best games have a soul. You can really sense it. Call of Duty has a very different soul than Fortnite, and it just kind of exudes—not only in what you see in the game, but also in how players interact with it and interact with each other online. That's a really fascinating thing. I wish it would be studied more.

I think we talked about the soul on several fronts, right? I wish it would be studied more.

#467

Yeah, yeah. These little game design decisions that the designers make have a profound impact on what players think of the game and see in the game. Fortnite Battle Royale always had a sense of mystery to it. You're on this island, but you're not sure exactly what's happening here. There are all these houses. They're abandoned. Why?

I'm not the secret holder. I'm not on the design team.

#467

I experience Fortnite as a player, but it really exudes a lot of that good-spiritedness as well. Even when you're eliminated in Fortnite, there's not blood spurts and there's not gibs. You're just teleported out of the simulation. Often, you end up losing the game in a way that's hilarious enough that you're actually laughing at it, or you're like, “Respect to that player who just won because that was clever.”

It creates a very different dynamic than these other games, where players tend to be very, very positive toward each other. One of the things I like to do in Fortnite, just to gauge how the game is going, is play fill squad. I'll get matchmade with 3 other random players and play a game together. Sometimes they have voice chat, sometimes they don't.

Back when our matchmaking regions were bigger, I learned a little bit of battlefield Spanish, so I could speak with the people who were as far south as Mexico City. The positivity of the interactions there, among just 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 everybody's got to be an edgelord.

I love online gaming culture. I have to ask, because one of the legendary games is Grand Theft Auto. Speaking of the worlds that are just—I mean, that's a whole, that's its own thing, right? That world, the characters, the style, the edginess, all of that.

But the interesting thing about Grand Theft Auto 6 to me that I want to ask you about is that they took forever. It's the 6-month thing that you mentioned before. There are some games like that that just take years to bring to completion. What can you say about that process, that you eventually were able to take Fortnite to completion?

If you were to look from the outside, why does Grand Theft Auto take that long, or why do other companies take games to conclusion? Just give me some insight into what that process is like.

#467

Making games is very hard, especially when you're pushing the boundaries of something. With Grand Theft Auto, it's just the realism and feeling that you're in this huge city, that anything can happen, and it's all living and breathing, and you're just a part of it. The level with which Rockstar Games has brought quality to that genre is astonishing.

When you're building something at a level of quality and detail that's never been achieved before, you can't predict how long it will take. Whatever problems you're solving today to get to the next iteration of quality, you don't know what new problems that will unlock. 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.

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. We also won't have much success. What we've seen from Rockstar Games is that 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 is eventually released and is good.

Do you ever feel like Rockstar Games is a good example of that—the pressure of delivering quality? Epic has not missed recently, that I'm aware of, in terms of delivering quality. Do you feel the pressure of that, that you're not allowed misses?

#467

We certainly do. Everybody's often working very much to the last minute to make something excellent. It's really hard with these fast delivery time frames, because you really have to get a lot of stuff up and running before you can judge a new Fortnite season holistically.

It's not until the last month or so that you really know what you've built and you really understand it. If any late-breaking problems emerge in balance or anything else, it's usually toward the end, and that usually leads to a rapid push to fix it. Then there are other lessons you can only learn live and from experience.

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

Let me ask you a big philosophical question. You've created these gigantic worlds that bring so much fun to humanity, but you also get to learn about humanity. What gives you hope about us humans? About the future of humans, about the future of humanity?

#467

I see 2 contrasting worlds that have been brought about in the digital age. One is the world of social networks and people typing at each other, and just massive negativity and politics and hucksterism, and engagement curation by engagement, often promoting negativity and toxicity. That's a harsh world that I think is a step backward in many ways. I think the foundation of the world is actually a little bit shaky because of the social dynamic that those platforms have brought on.

But then I compare that with the good-spiritedness of what's happening online when you're connected to real people, like actually playing Fortnite, playing 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 that is that humans talking to humans and being together in a simulated world, the real world, or a virtual world is a naturally empathetic medium, which naturally leads to bonding. Though conflict sometimes occurs, it's generally so much more promoting of our social norms and good interactions between people and positivity-promoting, whereas typing angry messages at each other is a self-reinforcing negative dynamic. That's negative.

I think, though, you look at social media and you look at gaming, which is increasingly social, and I couldn't see a bigger divide between any 2 mediums as I see there in terms of the actual social dynamics: one super positive, one super toxic at times.

Yeah, that's actually really the text-based medium. Now, that could even be around gaming. You can look at Discords; they can be really toxic in text.

But you place humans together in the real world, here in the room, and I literally have never—I very rarely see humans not get along in the physical space. The degree to which you can create a digital space, like a metaverse-type space, where it's sufficiently immersive, where you feel the other person, the empathy comes out, and then the joy that's derived from the empathy comes out, it's just a reminder that humans are good, and they want to see the good in others.

They want to share the goodness. 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, it's joyful. So, yeah, that gives me hope as well.

The more worlds we can create online that make it super easy for us to connect in that empathic way, the better. 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 is amazing, and it's an honor to talk to you.

#467

Oh thank you very much it's been fun. Thanks for listening to this conversation with Tim Sweeney. To support this podcast, please check out our sponsor in the description. And now, let me leave you some words from Benjamin Franklin. We do not stop playing because we grow old. We grow old because we stop playing. Thank you for listening. I hope to see you next time.