Tim Sweeney
speaker
640 appearances
1 recordings
1 series
first heard Apr 2025
last heard Apr 2025
Tim Sweeney’s voice in public audio — every appearance, attributed to the second.
Trend
recordings per month · last 12 monthsNo recordings in the last 12 months.Older appearances are listed below; set an alert to hear about the next one.
Appearances
What we've seen time and time again is that as... We gain more technical capabilities. Graphics gets more capable. CPUs become more performant. Web services become ever more scalable. We see new genres of games that emerge that weren't possible before. And, you know, Doom ushered in the era of Deathmatch, the first time 3D multiplayer game was even possible at all.
The early Battle Royale games, starting about 10 years or 15 years ago, only became possible back then. You couldn't have built one 20 years ago, because you just couldn't have rendered an environment that's as large as a VR game with that many players, with that level of interaction and performance. It was just not possible to run it.
So you got a certain level of technical capabilities, and a genre came out that proved to be by far the best shooter genre ever invented. But I think there are numerous, numerous more genres, some of which are better than any of the existing ones that will be invented as we get more and more capabilities.
Some of the capabilities we're lacking now are the ability to build environments and game simulations that span... more work than a single company can possibly create. And, you know, you see kind of the birth of that idea in Fortnite and Roblox, where there are tens of thousands of creators each building content, and users are playing meaningful amounts of it all.
And so there's an ecosystem that's scaled larger than company. But it's still very much, you go into one island and you play that creator's work. The other direction of scalability is putting more and more of people's work together in a seamless, continuous play space for games where that makes sense. You know, you can imagine a...
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 which are maintained by different people. So you go into different spaces, the game rules are customized according to that, and you can go from experience to experience.
And instead of having just one company's authorship ever-present wherever you are, you'd be driving a car built by one person, carrying weapons built by 20 other people, and taking place in a simulation in an environment that's built by thousands of other people, working for separate companies or their own entrepreneurs or... indies or enthusiasts all working together simultaneously.
And we totally lack the programming foundations for that. The kinds of code you would need to write now to make that happen are just not practical. And so we're investing massively in building new programming language technologies around Verse and our proposed standards for future metaverse programming that we hope will solve those kinds of problems and make that kind of world possible.
First is the programming language that we're building for large-scale simulation programming. It's designed to make it easy to write code that can scale up to not only you building a Fortnite island, but you building modules or components that can be used by millions of other programmers and coexist in a huge environment, and also can 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 the 1,000-player version of Battle Royale would be worse. But I bet there are 1,000 million and tens of million player experiences that are even better than that that will yet to be discovered. Wait a minute.
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 and see that there's that massive crowd and they could all do interesting things and interact with each other, that would be way cooler.
Sure. Well, you know, 10 million people. You have less than 10 million pixels on your screen. So as the Nyquist sampling theorem say, it says that you don't need full overhead for every player. You need to render the players here around you in some approximation of everything else.
There's a lot of work that has to happen there, but this is what we do for a living. We solve hard problems.
Because if they're easy, then other people could have solved them already.
versus a functional logic language, because we think that that's the way to make the most simple and 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 that 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.
So that you have to learn a relatively small set of things, and then the real knowledge comes as you learn ways to combine them to achieve bigger and bigger programs. And so there's a long history to the field of programming languages, but in the 1950s, the first... programming language designers got together and built the first standardized language called ALGOL.
And there was this meeting in 1956. Very few people even know about it, but it's where all the major foundations of modern programming languages were decided on, that the C family of languages inherited. And so we're very much living in a world that was defined by them. And thankfully, they got a whole lot of things right.
They defined how functions should work, how variables should work, and how recursion should work. And thank God they got those things right. But they got a few things wrong. versus 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.
Showing 401–420 of 640 · page 21 of 32
← Previous
Next →