John Carmack: Doom, Quake, VR, AGI, Programming, Video Games, and Rockets | Lex Fridman Podcast #309

0:01 I remember the reaction where he had drawn these characters and he

0:04 was slowly moving around and like people had no experience with 3D navigation,

0:08 it was all still keyboard.

0:09 We didn't even have mice set up at that time.

0:11 But slowly moving, going up, picked up a key, go to a wall,

0:16 the wall disappears in a little animation

0:17 and there's a monster like right there.

0:18 And he practically fell out of his chair.

0:21 It was just like, ah.

0:23 And games just didn't do that.

0:24 The games were the god's eye view.

0:28 You were a little invested in your little guy.

0:30 You can be like happy or sad when things happen,

0:33 but you just did not get that kind of startle reaction.

0:35 You weren't inside your game.

0:36 Something in the back of your brain,

0:38 some reptile brain thing is just going, "Oh,

0:40 shit something just happened." And that was

0:43 one of those early points where it's like,

0:45 yeah, this is gonna make a difference.

0:47 This is going to be powerful and it's gonna matter.

0:52 The following is a conversation with John Carmack,

0:55 widely considered to be one of the greatest programmers ever.

0:59 He was the co-founder of id Software and the lead

1:02 programmer on several games that revolutionized the technology,

1:06 the experience and the role of gaming in our society,

1:09 including Commander Keen, Wolfenstein 3D, Doom and Quake.

1:15 He spent many years as the CTO of Oculus VR,

1:19 helping to create portals into virtual worlds and to define

1:24 the technological path to the Metaverse at Meta.

1:28 And now he has been shifting some

1:30 of his attention to the problem of artificial general intelligence.

1:34 This was the longest conversation on this podcast at over five hours,

1:40 and still I could talk to John many,

1:42 many more times and we hope to do just that.

1:46 This is the "Lex Fridman Podcast." To support it,

1:49 please check out our sponsors in the description.

1:52 And now, dear friends, here's John Carmack.

1:57 What was the first program you've ever written?

2:00 Do you remember?

2:01 Yeah, I do.

2:02 So, I remember being in a radio shack going up to the TRS 80

2:06 computers and learning just enough to be able to do 10 print, John Carmack.

2:12 And it's kind of interesting how, of course I,

2:15 Carnegie and Richie kind of standardized hello world as the first

2:19 thing that you do in every computer programming language and every computer.

2:22 But not having any interaction with the cultures of Unix

2:26 or any other standardized things, it was just like,

2:28 "Well, what am I gonna say?" "I'm gonna say

2:30 my name and then you learn how to do,

2:32 "Go to 10 and have it scroll all off the screen." And that was

2:35 definitely the first thing that I wound up doing on a computer.

2:39 Can I ask you programming advice?

2:41 I was always told in the beginning

2:42 that you're not allowed to use Go-to statements.

2:44 That's really bad programming.

2:45 Is this correct or not?

2:46 Jumping around code?

2:48 Can we look at the philosophy and the technical

2:51 aspects of the Go-to statement that seems so convenient,

2:55 but it's supposedly bad programming?

2:56 Well, so certainly back in the day in basic programming languages,

2:58 you didn't have proper loops.

3:00 You didn't have four while and repeats, that was the land of Pascal for people

3:04 that kind of generally had access to it back then.

3:07 So, you had no choice but to use Go-tos.

3:10 And as you made, what were big programs back then,

3:13 which were a thousand line basic programs,

3:15 is a really big program, they did tend to sort of degenerate into madness.

3:20 You didn't have good editors or code exploration tools,

3:23 so you would wind up fixing things in one place, add a little patch.

3:27 And there's reasons why structured programming,

3:29 generally helps understanding, but go-tos aren't poisonous.

3:33 Sometimes they're the right thing to do.

3:35 Usually it's because there's a language feature missing,

3:38 like nested breaks or something where, it can sometimes be better to do a go-to

3:44 cleanup or go-to error rather than having multiple flags,

3:48 multiple if statements littered throughout things.

3:50 But it is rare.

3:51 I mean, if you grip through all of my code right now,

3:54 I don't think any of my current code bases, would actually have a go-to,

3:58 but deep within sort of the technical underpinnings of a major game engine,

4:03 you're gonna have some go-tos in a couple places probably.

4:07 Yeah, the infrastructure on top of, like the closer you get to the machine code,

4:11 the more go-tos you're gonna see,

4:12 the more of these like hacks you're going to see,

4:15 because the set of features available to you

4:18 in low level programming languages is not, is limited.

4:22 So, print John Carmack, when is the first time,

4:27 if we could talk about love that you fell in love with programming.

4:31 You said like this is really something special.

4:34 It really was something that was one of those love at first sight things

4:38 where just really from the time that I understood what a computer was even,

4:42 I mean, I remember looking through old encyclopedias at the black

4:46 and white photos of the IBM mainframes at the real tore tape decks.

4:50 And for people nowadays, it can be a little hard to understand

4:53 what the world was like then from information gathering

4:56 where I would go to the libraries and there

4:59 would be a couple books on the shelf,

5:01 about computers and they would be very out of date, even at that point,

5:04 just not a lot of information,

5:06 but I would grab everything that I could find and devour everything.

5:10 Whenever "Time" or "Newsweek" had some article about computers,

5:14 I would like cut it out with scissors and put it somewhere.

5:16 It felt like this magical thing to me,

5:19 this idea that the computer would just do exactly what you told it to.

5:24 I mean, and there's a little bit of the Genie

5:26 monkey's paw sort of issues there where you'd better be really,

5:29 really careful with what you're telling it to do.

5:31 But it wasn't gonna backtalk you,

5:33 it wasn't gonna have a different point of view.

5:34 It was gonna carry out what you told it to do.

5:37 And if you had the right commands you

5:39 could make it do these pretty magical things.

5:43 And so what kind of programs did you write at first?

5:45 So, beyond the print John Carmack.

5:48 So, I can remember as going through the learning process where you find

5:52 at the start you're just learning how to do the most basic possible things.

5:56 And I can remember stuff like a Superman

5:59 Comic that Radio Shack commissioned to have,

6:02 it's like Superman had lost some of his super brain and kids had to use

6:06 Radio Shack TRS 80 computers to do calculations

6:08 to help him kind of complete his heroics.

6:11 And I'd find little things like that and then get a few

6:16 basic books to be able to kind of work my way up.

6:20 And again, it was so precious back then.

6:22 I had a couple books that would teach me important things about it.

6:25 I had one book that I could start to learn a little bit of assembly language

6:30 from and I'd have a few books on basic

6:31 and some things that I could get from the libraries.

6:34 But my goals in the early days was almost always making games of various kinds.

6:40 I loved the arcade games and the early Atari 2,600 games and being able to do

6:46 some of those things myself on the computers was very much what I aspired to.

6:51 And it was a whole journey where if you learn normal,

6:54 basic, you can't do any kind of an action game.

6:56 You can write an adventure game, you can write things where you say,

6:59 "What do you do here?" "I get sort, attack, troll," that type of thing.

7:03 And that can be done in the context of basic,

7:06 but to do things that had moving graphics that were

7:09 only the most limited things you could possibly do.

7:12 You could maybe do breakout or pong

7:13 or that sort of thing in low resolution graphics.

7:16 And in fact, one of my first sort of major technical hacks

7:20 that I was kind of fond of was on the Apple II computers.

7:24 They had a mode called low resolution graphics where

7:29 of course all graphics were low resolution back then,

7:31 but regular low resolution graphics.

7:34 It was a grid of 40 by 40 pixels normally,

7:36 but they could have 16 different colors.

7:39 And I wanted to make a game,

7:41 kind of like the arcade game Vanguard, just a scrolling game.

7:44 And I wanted to just kind of have it scroll

7:46 vertically up and I could move a little ship around you.

7:49 You could manage to do that in basic,

7:50 but there's no way you could redraw the whole screen.

7:53 And I remember at the time,

7:55 just coming up with what felt like a brainstorm to me

7:58 where I knew enough about the way the hardware was controlled,

8:02 where the text screen and the low

8:04 resolution graphic screen were basically the same thing.

8:06 And all those computers, could scroll their text screen reasonably.

8:10 You could do a listing and it would scroll things

8:12 up and I figured out that I could kind of tweak,

8:15 just a couple things that I barely understood to put it

8:18 into a graphics mode and I could draw graphics and then

8:21 I could just do a line feed at the very bottom

8:23 of the screen and then the system would scroll it all up,

8:26 using an assembly language routine that I didn't know how to write back then.

8:30 So, that was like this first great hack that sort of had

8:34 analogs later on in my career for a lot of different things.

8:37 So, I found out that I could draw a screen,

8:39 I could do a line feed at the bottom, we would scroll it up once,

8:42 I could draw a couple more lines of stuff at the bottom.

8:44 And that was my first way to kind of scroll the screen,

8:47 which was interesting in that that played a big

8:51 part later on in the id Software days as well.

8:53 So, do efficient drawing where you don't have to draw the whole screen,

8:59 but you draw from the bottom using the thing

9:01 that was designed in the hardware for text output.

9:04 Yeah.

9:05 Where so much of, until recently game design was limited

9:10 by what you could actually get the computer to do,

9:13 where it's easy to say like, "Okay, I wanna scroll the screen." You just

9:16 redraw the entire screen at a slight offset.

9:19 And nowadays that works just fine.

9:21 Computers are ludicrously fast.

9:24 But up until a decade ago or so,

9:27 there were all these things everybody wanted to do,

9:30 but if they knew enough programming to be able to make it happen,

9:33 it would happen too slow to be a good experience,

9:36 either just ridiculously slow or just slow enough

9:39 that it wasn't fun to experience it like that.

9:42 So, so much of kinda the first couple

9:44 decades of the programming work that I did was

9:46 largely figuring out how to do something that everybody

9:48 knows how they want it to to happen.

9:51 It just has to happen two to 10 times faster than

9:54 sort of the straightforward way of doing things would make it happen.

9:58 And it's different now because at this point,

10:01 lots of things you can just do in the most

10:03 naive possible way and it still works out.

10:05 You don't have nearly the creative limitations

10:09 or the incentives for optimizing on that level.

10:12 And there's a lot of pros and cons to that.

10:14 But I do generally, I'm not gonna do the angry old man,

10:18 shaking my fist at the clouds bit where back

10:20 in my day programmers had to do real programming.

10:23 It's amazing that you can just kind of pick an idea and go do it right now.

10:27 And you don't have to be some assembly language wizard or deep GPU

10:31 arcane to be able to figure out how to make your wishes happen.

10:35 Well there's still, see that's true, but let me put on my old man with a fist

10:41 hat and say that probably the thing that will define the future,

10:45 still requires you to operate at the limits of the current system.

10:49 So, we'll probably talk about this, but if you talk

10:53 about building the metaverse and building a VR experience that's compelling,

10:57 it probably requires you to not to go to assembly or maybe not literally,

11:03 but sort of spiritually to go to the limits of what the system is capable of.

11:08 And that really was why virtual reality

11:10 was specifically interesting to me where it

11:14 had all the ties to, you could say that even back in the early days,

11:17 I have some old magazine articles that's

11:19 talking about doom as a virtual reality experience,

11:22 back when just seeing anything in 3D.

11:24 So, you could say that we've been trying

11:26 to build those virtual experiences from the very beginning.

11:29 And in the modern era, virtual reality, especially on the mobile side of things,

11:34 when it's standalone and you're basically using a cell phone

11:37 chip to be able to produce these very immersive experiences,

11:41 it does require work.

11:43 It's not at the level of what an old school console game programmer,

11:47 would have operated at where you're looking at hardware

11:50 registers and you're scheduling all the DMA accesses,

11:53 but it is still definitely a different level than what a web

11:56 developer or even a PC steam game developer usually has to work at.

12:01 And again, it's great.

12:02 There's opportunities for people that wanna

12:04 operate at either end of that spectrum

12:06 there and still provide a lot of value to the world.

12:09 Let me ask you sort of a big question about preference.

12:15 What would you say is the best programming language,

12:19 your favorite, but also the best, you've seen throughout your career?

12:25 You're considered by many to be the greatest programmer ever.

12:29 I mean, it's so difficult to place that label on anyone,

12:32 but if you put it on anyone, it's you.

12:33 So, let me ask you these kind of ridiculous

12:36 questions of what's the best band of all time,

12:38 but in your case, what's the best programming language?

12:41 Everything has all the caveats about it, but so what I use,

12:45 so nowadays I do program a reasonable amount of Python for AI ML sorts of work.

12:51 I'm not a native Python programmer.

12:54 It's something I came to very late in my career.

12:56 I understand what it's good for.

12:58 But you don't dream in Python.

13:00 I do not.

13:00 And it has some of those things where there's some amazing stats

13:04 when you say if you just start, if you make a loop,

13:07 a triply nested loop and start doing operations in Python,

13:10 you can be thousands to potentially a million

13:14 times slower than a proper GPU tensor operation.

13:17 And these are staggering numbers,

13:19 you can be as much slower as we've almost gotten faster

13:23 in our pace of progress and all this other miraculous stuff.

13:27 So, your intuition's about inefficiencies within the Python

13:29 sort of-- It keeps hitting me upside the face.

13:32 Where it's gotten to the point now I understand.

13:34 It's like, okay, you just can't do

13:35 a loop if you care about performance in Python.

13:38 You have to figure out how you can reformat this into some

13:42 big vector operation or something that's going to be done completely,

13:44 within a C plus plus library.

13:47 But the other hand is it's amazingly convenient and you

13:50 just see stuff that people are able to cobble

13:53 together by you just import a few different things

13:55 and you can do stuff that nobody on earth,

13:57 could do 10 years ago and you can do it in a little

13:59 cookbook thing that you copy paste it out of a website.

14:02 So, that is really great.

14:04 When I'm sitting down to do what I consider kind of serious programming.

14:08 It's still in C plus plus and it's really kind of a C flavored C plus

14:13 plus at that where I'm not big

14:15 into the modern template meta programming sorts of things.

14:18 I see a lot of train wrecks coming from, some of that over abstraction.

14:23 I spent a few years really going kind of deep into the kinda the historical

14:28 lisp work and the Haskell and some

14:31 of the functional programming sides of things.

14:33 And there is a lot of value there in the way you think about things.

14:38 And I changed a lot of the way I write my C and C plus plus code based on what I

14:43 learned about the value that comes out of not having

14:46 this random mutable state that you kind of lose track of.

14:50 Because something that many people don't really appreciate,

14:53 till they've been at it for a long time

14:55 is that it's not the writing of the program initially,

14:58 it's the whole lifespan of the program and that's when,

15:01 it's not necessarily just how fast you wrote it or how fast it operates,

15:05 but it's how can it bend and adapt as situations change.

15:09 And then the thing that I've really been learning in my time at Meta

15:12 with the Oculus and VR work is it's also how well it hands off,

15:16 between a continuous kind of revolving door of programmers

15:19 taking over maintenance and different things and how

15:22 you get people up to speed in different areas

15:24 and there's all these other different aspects of it.

15:27 Is C plus plus a good language for handover between engineers?

15:32 Probably not the best.

15:34 And there's some really interesting aspects to this where in some

15:38 cases languages that are not generally thought well of for many reasons.

15:43 Like C is derided pretty broadly that yes,

15:46 obviously all of these security flaws that happen with the memory

15:49 and unsafeness and buffer overruns and the things that you've got there.

15:53 But there is this underappreciated aspect to the language is so simple.

15:58 Anyone can go and if you know C,

16:01 you can generally jump in someplace and not have to learn

16:04 what paradigms they're using because there just aren't that many available.

16:08 I think there's, and there's some really, really well-written C code,

16:12 like I find it great that if I'm messing around with something in open BSD say,

16:16 I mean I can be walking around in the kernel and I'm like,

16:19 I understand everything that's going on here.

16:21 It's not hard for me to figure out what I need to do

16:25 to make whatever change that I need

16:29 to, while you can have more significant languages.

16:32 Like, it's a downside of lisp where I

16:35 don't regret the time that I spent with Lisp.

16:37 I think that it did help my thinking about programming in some ways.

16:42 Yes.

16:43 But the people that are the biggest defenders of Lisp are saying how

16:46 malleable of a language it is that if you write a huge Lisp program,

16:50 you've basically invented your own kind of language and structure because

16:54 it's not the primitives of the language you're using very much.

16:57 It's all of the things you've built on top of that.

16:59 And then a language like Racket, kind of one of the more modern Lisp versions,

17:03 it's essentially touted as a language for building other languages.

17:07 And I understand the value of that for a tiny little project,

17:12 but the idea of that for one of these long-term

17:15 supported by lots of people kind of horrifies me,

17:18 where all of those abstractions that you're like,

17:20 "Okay, you can't touch this code,

17:22 "till you educate yourself on all of these things "that we've built on top

17:26 of that." And it was interesting to see how when Google made Go,

17:30 a lot of the criticisms of that are,

17:32 it's like, "Wow, this is not a state-of-the-art language.

17:34 "This language is just so simple and almost

17:37 crude." And you could see the programming language people,

17:40 just looking down at it, but it does seem to be quite popular

17:44 as basically saying this is the good things about C.

17:47 Everybody can just jump right in and use it.

17:49 You don't need to restructure your brain to write good code in it.

17:53 So, I wish that I had more opportunity for doing some work in Go.

17:58 Rust is the other modern language that everybody

18:01 talks about that I'm not fit past judgment on.

18:04 I've done, a little bit beyond Hello World,

18:06 I wrote some like video decompression work in Rust, just as an exercise,

18:10 but that was a few years ago and I haven't really used it since.

18:14 The best programming language is the one that works,

18:17 generally that you're currently using,

18:19 because that's another trap is in almost every case I've

18:22 seen when people mixed languages on a project, that's a mistake.

18:26 I would rather stay just in one language,

18:29 so that everybody can work across the entire thing.

18:31 And we have, like at Meta,

18:33 we have a lot of projects that use kind of React framework.

18:36 So, you've got JavaScript here and then you have C plus plus for real work,

18:40 and then you may have Java interfacing with some other part

18:43 of the Android system and those are all kind of horrible things.

18:46 And that was one thing that, I remember talking

18:51 with with Boz at Facebook about it where like,

18:54 man, I wish we could have just said we're only hiring C plus plus programmers.

18:58 And he just thought from the Facebook Meta perspective,

19:02 well we just wouldn't be able to find enough,

19:04 with the thousands of programmers they've got there.

19:08 It is not necessarily a dying breed,

19:10 but you can sure find a lot more JavaScript programmers and I kind

19:15 of mentioned that to Elon one time and he was kind of flabbergasted about that.

19:21 It's like, well you just,

19:22 you go out and you find those programmers and you don't hire

19:24 the other programmers that don't do the languages that you want to use.

19:28 But right now, I guess, yeah,

19:29 they're using JavaScript on a bunch of the, the SpaceX

19:31 work for the UI side of things.

19:33 When you go find UI programmers, they're JavaScript programmers.

19:37 I wonder if that's because there's a lot of JavaScript

19:39 programmers because I do think that great programmers are rare,

19:44 that if you just look at statistics

19:47 of how many people are using different programming languages,

19:51 that doesn't tell you the story of what the great programmers are using.

19:55 And so you have to really look at what you

19:58 were speaking to, which is the fundamentals of a language.

20:00 What does it encourage you?

20:01 How does it encourage you to think,

20:03 what kind of systems does it encourage you to build?

20:05 There is something about C plus plus that has elements

20:10 of creativity but forces you to be an adult about your programming.

20:15 [John] Is that it expects you to be an adult.

20:16 It does not forced you to.

20:19 And so it brings out people that are willing to be creative

20:25 in terms of building large systems and coming up with interesting solutions,

20:29 but at the same time, have the sort of the good software engineering

20:35 practices that amend themselves to real world systems.

20:38 Let me ask you about this other language, JavaScript.

20:43 So, if aliens visit in thousands of years and humans are long gone,

20:50 something tells me that most of the systems

20:52 they find will be running JavaScript.

20:55 I kind of think that if we're living this simulation,

20:58 it's written in JavaScript.

21:01 For the longest time,

21:03 even still JavaScript didn't get any respect and yet it runs

21:08 so much of the world and an increasing number of the world.

21:11 Is it possible that all everything will be written in JavaScript one day?

21:17 So, the engineering under JavaScript is really pretty phenomenal.

21:20 The systems that make JavaScript run as fast as it does

21:25 right now are kind of miracles of modern engineering in many ways.

21:29 It does feel like it is not an optimal

21:34 language for all the things that it's being used

21:36 for or an optimal distribution system to build huge apps

21:40 in something like this without type systems and so on.

21:44 But I think for a lot of people it does reasonably the necessary things.

21:50 It's still a C flavored language, it's still a braces and semicolon language.

21:55 It's not hard for people to be trained in JavaScript

21:59 and then understand the roots of where it came from.

22:02 I think garbage collection is unequivocally a good

22:06 thing for most programs to be written in.

22:08 It's funny that I still just this morning

22:11 I was on, I was seeing a Twitter thread

22:13 of a bunch of really senior game dev people

22:15 arguing about the virtues and costs of garbage collection.

22:18 And you will run into some people that are top-notch programmers that just say,

22:22 "No, this is literally not a good thing."- Oh, because it makes you lazy?

22:26 Yes, that it makes you not think about things.

22:28 And I do disagree.

22:29 I think that there is so much objective data on the vulnerabilities

22:34 that have happened in C and C plus plus programs,

22:37 sometimes written by the best programmers in the world.

22:40 It's like nobody is good enough to avoid

22:42 ever shooting themselves in the foot with that.

22:44 You write enough C code,

22:45 you're going to shoot yourself in the foot and garbage collection

22:48 is a very great thing for the vast majority of programs.

22:51 It's only when you get into the tightest of real

22:54 time things that you start saying, it's like, "No,

22:56 the garbage collection has more costs "than it has benefits for me there."

22:59 But that's not 99 plus percent of all the software in the world.

23:04 So, JavaScript is not terrible in those ways

23:09 and so much of programming is not the language itself,

23:14 it's the infrastructure around, that surrounds it.

23:17 All the libraries that you can get and the different stuff that you can,

23:20 ways you can deploy it, the portability that it gives you.

23:24 And JavaScript is really strong on a lot of those things where

23:27 for a long time and it still does if I look at it,

23:30 but the web stack about everything that has to go when you do

23:34 something really trivial in JavaScript and it shows up on a web browser

23:38 to kind of X-ray through that and see everything that has to happen

23:42 for your one little JavaScript statement to turn

23:45 into something visible in your web browser.

23:47 It's very, very disquieting, just the depth of that stack and the fact

23:54 that so few people can even comprehend,

23:56 all of the levels that are going on there.

23:59 But it's, again, I have to caution myself to not

24:02 be the, in the good old days old man about it,

24:05 because clearly there's enormous value here.

24:08 The world does run on JavaScript to a pretty

24:12 good approximation there and it's not falling apart.

24:14 There's a bunch of scary stuff where you look at console logs

24:18 and you just see all of these bad things that are happening,

24:20 but it's still kind of limping along and nobody really notices.

24:24 But so much of my systems design and systems analysis goes around,

24:30 you should understand what the speed of light is,

24:32 like what would be the best you could possibly do here?

24:36 And it sounds horrible, but in a lot of cases you can be a thousand times

24:40 off your speed of light velocity for something and it still be okay.

24:45 And in fact it can even sometimes still be

24:48 the optimal thing in a larger system standpoint where there's

24:51 a lot of things that you don't wanna have

24:54 to parachute in someone like me to go in and say,

24:56 make this webpage run a thousand times faster.

25:01 Make this web app into a hardcore native application that starts up

25:06 in 37 milliseconds and everything responds in less than one frame latency.

25:11 That's just not necessary.

25:12 And if somebody wants to go pay me millions of dollars to do software

25:16 like that, when they can take somebody right out of a bootcamp and say,

25:19 "Spin up an application for this," often

25:21 being efficient is not really the best metric.

25:26 And that applies in a lot of areas where it's kind of interesting

25:30 how a lot of our appliances

25:32 and everything are all built around energy efficiency,

25:36 sometimes at the expense of robustness in some

25:39 other ways or higher costs in other

25:40 ways where there's interesting things where energy

25:43 or electricity could become much cheaper in a future

25:46 world and that could change our engineering

25:48 trade-offs for the way we build certain

25:50 things where you could throw away efficiency

25:53 and actually get more benefits that actually matter.

25:56 I mean that's one of the directions I was considering

26:00 swerving into was nuclear energy when I was kind of like,

26:03 what do I want to do next?

26:04 It was either gonna be cost

26:06 effective nuclear fission or artificial general intelligence.

26:10 And one of my pet ideas there is like,

26:14 people don't understand how cheap nuclear fuel is and there would

26:19 be ways that you could be a quarter the efficiency or less,

26:24 but if it wound up making your plant 10 times cheaper,

26:27 that could be a radical innovation in something like that.

26:31 So, there's like some of these thoughts around,

26:32 like direct fission energy conversion,

26:35 fission fragment conversion that maybe you build something

26:38 that doesn't require all the steam turbines and everything,

26:40 even if it winds up being less efficient.

26:42 So, that applies a lot in programming where there's always,

26:46 it's always good to know what you could do

26:48 if you really sat down and took it far,

26:51 because sometimes there's discontinuities, like around user reaction times,

26:56 there are some points where the difference between operating

26:59 in one second and 750 milliseconds, not that huge.

27:03 You'll see it in webpage statistics,

27:05 but most of the usability stuff not that great.

27:08 But if you get down to 50 milliseconds,

27:10 then all of a sudden this just feels amazing.

27:13 It's just like doing your bidding instantly,

27:15 rather than you're giving it a command,

27:17 twiddling your thumbs, waiting for it to respond.

27:19 So, sometimes it's important to really crunch hard to get over some threshold,

27:25 but there are broad basins in the value metric for lots

27:29 of work where it just doesn't pay to even go that extra mile.

27:32 And there are craftsmen that, they just don't

27:35 wanna buy that and more power to them, if somebody just wants to say, no,

27:39 I'm going to be, my pride is in my work,

27:42 I'm never going to do something that's not as good as I could possibly make it.

27:46 I respect that and sometimes I am that person,

27:50 but I try to focus more on the larger

27:53 value picture and you do pick your battles and you

27:55 deploy your resources in the play that's going to give

27:58 you sort of the best user value in the end.

28:01 Well if you look at the evolution of life

28:03 on earth as a kind of programming effort,

28:09 it seems like efficiency isn't the thing that's

28:14 being optimized for, like natural selection is very inefficient,

28:17 but it kind of adapts and through the process of adaptations,

28:22 building more and more complex systems that are more and more intelligent,

28:25 the final result is kind of pretty interesting.

28:28 And so I think of JavaScript the same way.

28:30 It's like this giant mess that, things naturally die off

28:35 if they don't work and if they're become useful to people,

28:39 they kind of naturally live.

28:40 And then you build this community,

28:42 large community of people that are jittering code and some code is sticky,

28:47 some is not, and nobody knows the inefficiencies

28:51 or the efficiencies or the breaking points,

28:53 like how reliable this code is and you kind of just run it, assume it works,

28:57 and then get unpleasantly surprised and then

29:01 that's very kind of the evolutionary process.

29:03 So, that's a really good analogy and we can go a lot

29:06 of places with that where in the earliest days of programming,

29:09 when you had finite, you could count the bites that you had to work on this.

29:13 You had all the kind of hackers playing code golf to be one

29:16 less instruction than the other person's

29:18 multiply routine to kind of get through.

29:20 And it was so perfectly crafted,

29:22 it was a crystal piece of artwork when you had a program,

29:26 because there just were not that many.

29:28 You couldn't afford to be lazy in different ways.

29:31 And in many ways I see that as akin to the symbolic AI work where again,

29:35 if you did not have the resources to just say,

29:38 "Well we're gonna do billions and billions

29:40 "of programmable weights here," you have

29:43 to turn it down into something that is symbolic and crafted like that.

29:47 But that's definitely not the way DNA

29:50 and life and biological evolution and things work.

29:54 On the one hand it's almost humbling

29:58 how little programming code is in our bodies.

30:00 We've got a couple billion base pairs and it's like

30:03 this all fits on a thumb drive for years now.

30:05 And then our brains are even a smaller section of that.

30:08 You've got maybe 50 megabytes and this is not like Shannon limit,

30:12 perfectly information dense conveyances here.

30:17 It's like these are messy codes, they're broken up into amino acids.

30:21 A lot of them don't do important things or they do things in very awkward ways.

30:26 But it is this process of just accumulation on top of things.

30:30 And you need scale, both you need scale

30:34 for sort of the population for that to work out.

30:37 And in the early days in the 50s and 60s,

30:39 the kind of ancient era of computers where you could count when they say like,

30:44 when the internet started,

30:45 even in the seventies there were like 18 hosts or something on it.

30:48 It was this small finite number and you were still

30:51 optimizing everything to be as good as you possibly could be.

30:54 But now it's billions and billions of devices and everything going on and you

31:00 can have this very much natural evolution

31:02 going on where lots of things are tried, lots of things are blowing up.

31:07 Venture capitalists lose their money when a startup invested in the wrong

31:11 tech stack and things completely failed or failed to scale.

31:14 But good things do come out of it.

31:17 And it's interesting to see the mimetic

31:20 evolution of the way different things happen.

31:22 Like mentioning Hello World at the beginning,

31:24 it's funny how some little thing like that where everybody,

31:27 every programmer knows Hello World now.

31:29 And that was a completely arbitrary sort of decision that just came out

31:33 of the dominance of Unix and C and early examples of things like that.

31:38 So, millions of experiments are going on all the time,

31:42 but some things do kind of rise to the top and win

31:45 the fitness war for whether it's

31:47 mind space or programming techniques or anything.

31:50 Like, there's a site on stack exchange

31:53 called Code Golf where people compete to write

31:56 the shortest possible program for a particular

31:58 task in all the different kinds of languages.

32:01 And it's really interesting to see folks kind of, that are

32:08 masters of their craft really play with the limits of programming languages.

32:13 It's really beautiful to see and across all the different programming languages,

32:17 you get to see some of these weird programming languages and mainstream ones,

32:22 difference between Python two and three.

32:25 You get to see the difference between C and C plus

32:27 plus and Java and you get to see JavaScript, all of that.

32:30 And it's kind of inspiring to see how much depth of possibility

32:38 there is within programming languages that code golfed kind of tasks reveal.

32:44 Most of us, if you do any kind of programming,

32:46 you kind of do boring kind of very vanilla type of code.

32:50 That's the way to build large systems.

32:52 But it's nice to see that the possibility

32:54 of creative genius is still within those languages,

32:57 it's laden with in those languages.

33:00 So, given that you are once again one of the greatest programmers ever,

33:05 what do you think makes a good programmer, maybe a good modern programmer?

33:11 So, I just gave a long rant/lecture at Meta

33:15 to the TPM organization and my biggest point was,

33:20 everything that we're doing really should flow from user value.

33:24 You know, all the good things that we're doing.

33:26 It's like we're not technical people.

33:28 It's like you shouldn't be taking pride, just in the specific thing.

33:32 Like code golf is the sort of thing, it's a fun puzzle game,

33:34 but that really should not be a major motivator for you.

33:38 It's like we're solving problems for people

33:40 or we're providing entertainment to people.

33:41 We're doing something of value to people

33:44 that's displacing something else in their life.

33:46 So, we want to be providing a net value over what they could be doing,

33:50 but instead they're choosing to use our products.

33:53 And that's where, I mean, it sounds trite or corny,

33:56 but I fundamentally do think that's how you make the world a better place.

34:00 If you have given more value to people than it took you and your team to create,

34:05 then the world's a better place.

34:07 People have, they've gone from something of lesser value,

34:10 chosen to use your product and their life feels better for that.

34:13 And if you've produced that economically, that's a really good thing.

34:18 On the other hand, if you spent ridiculous amounts of money,

34:22 you've just kind of shoveled a lot of cash into a wood

34:25 chipper there and you should maybe not feel so good, about what you're doing.

34:29 So, being proud about like a specific architecture or a specific

34:34 technology or a specific code sequence that you've done,

34:37 it's great to get a little smile, like a tiny little dopamine hit for that.

34:41 But the top level metrics should be that you're building things of value.

34:45 Now you can get into the argument about what is user value,

34:49 how do you actually quantify that?

34:51 And there can be big arguments about that, but it's easy to be able to say,

34:55 "Okay, this off user there is not getting value "from what you're doing.

34:59 "This user over there with a big smile on their face.

35:01 "I am the moment of delight when something happened.

35:04 "There's a value that's happened there." I mean if you have

35:06 to at least accept that there is a concept of user value.

35:09 Even if you have trouble exactly quantifying it,

35:12 you can usually make relative arguments about it,

35:15 well this was better than this, we've improved things.

35:18 So, being a servant to the user is your job when you're a developer.

35:25 You want to be producing something that you

35:27 know other people are gonna find valuable.

35:30 And if you are technically inclined,

35:32 then finding the right levers to be able to pull to be able to make

35:37 a design that's going to produce the most value for the least amount of effort.

35:41 And it always has to be kind of divide.

35:44 There's a ratio there where you, it's a problem at the big tech companies,

35:48 whether it's Meta, Google, Apple, Microsoft,

35:51 Amazon, companies that have almost infinite money.

35:54 I mean, I know their CFO will complain that it's not infinite money,

35:58 but from most developer standpoints it really does feel like it.

36:02 And it's almost counterintuitive that if you're

36:05 working hard as a developer on something, there's always this thought,

36:08 if only I had more resources, more people,

36:11 more RAM, more megahertz, then my product will be better.

36:16 And that sense that at certain points,

36:18 it's certainly true that if you are really hamstrung by this, removing

36:22 an obstacle will make a better product, make more value.

36:27 But if you're not making your core design decisions in this fiercely

36:31 competitive way where you're saying feature A or feature B,

36:35 you can't just say let's do both.

36:38 Because then you're not making a value judgment about them.

36:41 You're just saying, "Well they both seem good.

36:42 "I don't wanna necessarily have "to pick out which one is

36:45 better or how much better "and tell team B that, sorry,

36:49 we're not gonna do this, "because A is more important."

36:52 But that notion of always having to really critically value what you're doing,

36:58 the resources you expend,

36:59 even the opportunity cost of doing something else, that's super important.

37:05 Well let me ask you about this, the debates

37:06 that you're mentioning of how to measure value.

37:12 Is it possible to measure it kind of numerically

37:19 or can you do the sort of Johnny,

37:21 the design route of imagining sort of somebody using

37:25 a thing and imagining a smile on their face,

37:30 imagining the experience of love and joy that you have when you use the thing,

37:35 that's from a design perspective or if you're building

37:38 more like a lower level thing for like Linux,

37:41 you imagine a developer that might come across this and use

37:45 it and become happy and better off because of it.

37:50 So, where do you land on those things?

37:52 Is it measurable?

37:53 So, I imagine like Meta and Google, will probably try to measure the thing,

37:58 they'll try to, it's like you try to optimize engagement or something,

38:01 let's measure engagement.

38:03 And then I think there is a kind of, I mean,

38:06 I admire the designer ethic of like,

38:09 think of a future that's immeasurable and you try

38:13 to make somebody in that future that's different from today happy.

38:17 So, I do usually favor if you can get any kind of a metric that's good,

38:23 by all means listen to the data.

38:25 But you can go too far there where we've had problems where it's like,

38:29 "Hey, we had a performance regression,

38:30 "because our fancy new telemetry system "is doing

38:34 a bazillion file rights "to kind of archive this stuff,

38:37 "because we needed to collect information

38:38 "to determine if our plans were good." So,

38:43 when information is available, you should never ignore it.

38:47 From actual users using the thing, human beings using the thing,

38:51 large number of human beings and you get to see sort of at all large.

38:55 So, there's zero to one problem of when you're doing something really new,

38:57 you do kind of have to make a guess.

38:59 But one of the points that I've been making at Meta is we

39:03 have more than enough users now that anything somebody wants to try in VR,

39:08 we have users that will be interested in that.

39:10 You do not get to make a completely greenfield blue sky pitch and say,

39:15 I'm going to do this, because I think it might be interesting.

39:18 I challenge everyone.

39:20 There are going to be people,

39:21 whether it's working in VR on your, like on your desktop

39:26 replacement or communicating with people in different ways or playing the games.

39:31 There are going to be probably millions of people or at least

39:35 if you pick some tiny niche that we're not in right now,

39:38 there's still gonna be thousands of people out there

39:40 that have the headsets that would be your target market.

39:43 And I tell people, pay attention to them.

39:46 Don't invent fictional users, don't make an Alice, Bob,

39:49 Charlie that fits whatever matrix of tendencies that you

39:54 want to break the market down to, because it's

39:56 a mistake to think about imaginary users when you've

39:58 got real users that you could be working with.

40:01 But on the other hand there is,

40:03 there is value to having a kind of wholeness of vision for a product.

40:09 And companies like Meta have,

40:13 they understand the trade-offs where you can have a company

40:17 like SpaceX or Apple in the Steve Jobs era where

40:20 you have a very powerful leading personality that can micromanage

40:24 at a very low level and can say it's like, no, that handle needs to be different

40:29 or that icon needs to change the tint there.

40:32 And they clearly get a lot of value out of it.

40:34 They also burn through a lot of employees

40:37 that have horror stories to tell about working there afterwards.

40:41 My position is that you are at your best

40:45 when you've got a leader that is at their limit

40:48 of what they can kind of comprehend of everything

40:50 below them and they can have an informed opinion,

40:53 about everything that's going on.

40:55 And you take somebody,

40:56 you've gotta believe that somebody that has 30, 40 years of experience,

41:01 you would hope that they've got wisdom that the the just out of bootcamp person,

41:05 contributing doesn't have.

41:07 And that if they're like, well that's wrong there,

41:09 you probably shouldn't do it that way or even

41:11 just don't do it that way, do it another way.

41:14 So, there's value there, but it can't go beyond a certain level.

41:17 I mean I have Steve Jobs stories of him saying,

41:21 things that are just wrong right in front of me,

41:23 about technical things, because he was not operating at that level.

41:27 But when it does work and you do get that kind of passionate

41:31 leader that's thinking about the entire product and just really deeply cares,

41:35 about not letting anything slip through the cracks,

41:38 I think that's got a lot of value.

41:40 But the other side of that is the people saying that, "Well,

41:42 we wanna have these independent teams "that are

41:45 bubbling up the ideas because" and like it's almost,

41:48 it's anti-capitalist or anti-free market to say it's like I want my grand,

41:52 my great leader to go ahead and dictate all these points

41:54 there where clearly free markets bring up things that, you don't expect.

41:59 Like in VR we saw a bunch of things,

42:01 like it didn't turn out at all the way the early people

42:04 thought were gonna be the key applications and things that would not

42:07 have been approved by the dark cabal making the decisions about what

42:12 gets into the store turn out to, in some cases be extremely successful.

42:17 So yeah, I definitely kind of wanted to be

42:20 there as a point where I did make a pitch.

42:22 It's like, "Hey, make me VR dictator "and I'll go

42:24 and get shit done." And it's not in the culture at Meta,

42:28 they understand the trade offs.

42:30 And that's just not the way, that's not the company that they want,

42:34 the team that they want to do.

42:37 Yeah, it's fascinating 'cause VR and we'll talk about it more.

42:39 It's still unclear to me in what way VR will change the world,

42:46 because it does seem clear that VR

42:48 will somehow fundamentally transform this world.

42:51 And it's unclear to me how.

42:54 [John] Yeah, let me know when you wanna get into that.

42:56 We will, well hold on a second.

42:58 So, stick to the, you being the best programmer ever, okay,

43:03 in the early days when you didn't have adult responsibilities of leading teams

43:08 and all that kind of stuff and you can focus on just being a programmer,

43:13 what did the productive day in the life of John Carmack look like?

43:17 How many hours of the keyboard, how much sleep?

43:20 What was the source of calories that fueled the brain?

43:24 What was it like, what time did you wake up?

43:26 So, I was able to be remarkably consistent about what

43:30 was good working conditions for me for a very long time.

43:33 I was never one of the programmers that I,

43:37 that would do all-nighters, going through work for 20 hours straight.

43:41 It's like my brain generally starts turning to mush after 12 hours or so,

43:45 but the hard work is really important and I would work for decades.

43:52 I would work 60 hours a week.

43:53 I would work a 10 hour day, six days a week and try to be productive at that.

43:59 Now, my schedule shifted around a fair amount when I was young without any kids,

44:02 I am any other responsibilities,

44:05 I was on one of those cycling schedules where I'd kind of get

44:08 in an hour later each day and roll around through the entire time

44:12 and I'd wind up kind of pulling in at two or three

44:14 in the afternoon sometimes and then working

44:17 again past midnight or two in the morning.

44:20 And that was when it was just me trying to make

44:24 things happen and I was usually isolated off in my office.

44:28 People generally didn't bother me much at it and I

44:31 could get a lot of programming work done that way.

44:35 I did settle into a more normal schedule when

44:37 I was taking kids to school and things like that.

44:40 So, kids were the forcing function that got you to wake up

44:42 and at the same time these-- And it's not clear to me that there

44:45 was a much of a difference in the productivity with that where I

44:49 kind of feel if I just get up when I feel like it,

44:53 it's usually a little later each day.

44:55 But I just recently made the focusing decision

44:58 to try to push my schedule back a little bit earlier to getting up at eight

45:01 in the morning and trying to shift things around.

45:04 Like I'm often doing experiments with myself about

45:08 what should I be doing to be more productive.

45:10 And one of the things that I did realize was happening

45:14 in recent months where I would go for a walk or a run.

45:19 I cover like four miles a day and I would usually do that, just

45:23 as the sun's going down at here in Texas now and it's still really damn hot.

45:27 But I'd go out at 8:30 or something and cover the time

45:31 there and then the showering and it was putting a hole

45:34 in my day where I would have still a couple hours after

45:37 that and sometimes my best hours were at night when nobody else is around,

45:41 nobody's bothering me.

45:42 But that hole in the day was a problem.

45:44 So, just a couple weeks ago I made the change to go ahead and say,

45:48 "All right, I'm gonna get up a little earlier,

45:49 "I'm gonna do a walk or get out there

45:51 first "so I can have more uninterrupted time." So,

45:54 I'm still playing with factors like this as I kind of optimize my work efforts.

45:59 But it's always been, it was 60 hours a week for a very long time.

46:05 To some degree I had a little thing in the back of my head where I was almost

46:08 jealous of some of the programmers that would do

46:10 these marathon sessions and I had like Dave Taylor, one of the guys that he had,

46:14 he would be one of those people that would fall asleep under

46:16 his desk sometimes and all the kind of classic hacker tropes about things.

46:20 And a part of me was like always a little bothered that that wasn't me.

46:23 That I wouldn't go program 20 hours straight,

46:27 because I'm falling apart and not being very effective after 12 hours.

46:31 I mean, yeah, a 12 hour programming,

46:33 that's fine when you're doing that, but you're not doing smart work much after,

46:38 at least I'm not, but there's a range of people.

46:41 I mean that's something that a lot of people,

46:42 don't really get in their gut where there are people that work on four

46:46 hours of sleep and are smart and can continue to do good work,

46:49 but then there's a lot of people that just fall apart.

46:52 So, I do tell people that I always try to get eight hours of sleep.

46:56 It's not this, push yourself harder, get up earlier.

46:59 I just do worse work, you can work a hundred hours a week and still get

47:05 eight hours of sleep if you just kind of prioritize things correctly.

47:08 But I do believe in working hard, working a lot.

47:11 There was a comment that a game dev made that, that I

47:16 know there's a backlash against really hard work in a lot of cases,

47:20 and I get into online arguments about this all the time.

47:23 But it was basically saying, yeah, 40 hours a week,

47:26 that's kind of a part-time job and if are really in it,

47:29 you're doing what you think is important,

47:31 what you're passionate about, working more gets more done.

47:35 And it's just really not possible to argue with that if you've been around

47:40 the people that work with that level of intensity and just say it's like,

47:44 no, they should just stop.

47:46 And we had, I kind of came back around to that a couple

47:50 years ago where I was using the fictional example of, alright,

47:54 some people say, they'll say with a straight face, they think no,

47:57 you are less productive if you work more than 40 hours a week.

48:01 And they're generally misinterpreting things where

48:03 you're marginal productivity for an hour,

48:06 after eight hours is less than in one of your peak hours,

48:09 but you're not literally getting less done.

48:10 There is a point where you start breaking things and getting

48:14 worse behavior and everything out of it where you're literally going backwards,

48:18 but it's not at eight or 10 or 12 hours.

48:21 And the fictional example I would use was,

48:23 imagine there's an asteroid coming to impact,

48:26 to crash into earth destroy all of human life.

48:29 Do you want Elon Musk or the people working at SpaceX

48:34 that are building the interceptor that's going to deflect the asteroid?

48:38 Do you want them to clock out at five, because damn it they're just gonna go do

48:42 worse work if they work another couple hours.

48:44 And it seems absurd and that's

48:47 a hypothetical though and everyone can dismiss that.

48:50 But then when Coronavirus was hitting and you have all

48:53 of these medical personnel that are

48:55 clearly pushing themselves really, really hard.

48:58 And I'd say it's like, okay, do you want all of these scientists,

49:02 working on treatments and vaccines and caring for all of these people?

49:05 Are they really screwing everything up by working more than eight hours a day?

49:09 And of course people say,

49:10 "I'm just an to say something like that," but it's the truth.

49:15 Working longer gets more done.

49:18 So, that's kind of the layer one.

49:20 But I'd like to also say that at least I believe depending on the person,

49:25 depending on the task, working more and harder will make you better

49:34 for the next week in those peak hours.

49:37 So, there's something about a deep dedication

49:40 to a thing that kind of gets deep in you.

49:44 So, it's the hard work isn't just about the raw hours of productivity.

49:49 It's the thing it does to you in the weeks and months after too.

49:56 You're tempering yourself in some ways.

49:59 And I think, it's like the "Jiro Dreams

50:01 of Sushi." If you really dedicate yourself completely

50:03 to making the sushi like to really putting

50:06 in the long hours day after day after day,

50:10 you become a true craftsman of the thing you're doing.

50:14 Now there's of course discussions about are

50:16 you sacrificing a lot of personal relationships?

50:18 Are you sacrificing a lot of other possible things you could do with that time?

50:22 But if you're talking about purely being a master or a craftsman of your art,

50:30 that more hours isn't just about doing more,

50:34 it's about becoming better at the thing you're doing.

50:36 Yeah and I don't gain say anybody that wants to work the minimum amount,

50:41 they've got other priorities in their life.

50:42 My only argument that I'm making, it's not that everybody should work hard,

50:46 it's that if you want to accomplish something,

50:49 working longer and harder is the path to getting it accomplished.

50:53 Well, let me ask you about this then.

50:55 The mythical work-life balance, for an engineer,

51:02 it seems like that's one of the professions

51:06 for programmer where working hard does lead to greater productivity

51:12 and but it also raises the question of, sort

51:17 of personal relationships and all that kind of stuff,

51:19 family and how are you able to find work-life balance?

51:24 Is there advice you can give, maybe even outside yourself?

51:27 Have you been able to arrive at any wisdom

51:29 on this part in your years of life now?

51:32 So, I do think that there's a wide

51:33 range of people where different people have different needs.

51:36 It's not a one size fits all.

51:38 I am certainly what works for me.

51:40 I can tell enough that I'm different than

51:44 a typical average person in the way things impact me.

51:48 The things that I want to do,

51:50 my goals are different and sort of the levers to impact

51:54 things are different where I have literally never felt burnout.

51:59 And I know there's lots of brilliant, smart people that do world leading work

52:03 that get burned out and it's never hit me.

52:07 I've never been at a point where I'm like, I just don't care about this.

52:13 I don't wanna do this anymore.

52:14 But I've always had the flexibility to work on lots of interesting things.

52:18 I can always just turn my gaze to something

52:21 else and have a great time working on that.

52:23 And so much of that, so much of the ability to actually work hard is the ability

52:27 to have multiple things to choose from and to use

52:30 your time on the most appropriate thing.

52:32 Like there are time periods where I am,

52:36 it's the best time for me to read a new research

52:38 paper that I need to really be thinking hard about it.

52:41 Then there's a time that maybe I should just scan and organize

52:43 my old notes because I'm just not on top of things.

52:47 Then there's the time that, alright, let's go,

52:49 bang out a few hundred lines of code for something.

52:52 So, switching between them has been, real valuable.

52:57 So, you always have kind of joy in your heart for all the things you're

53:00 doing and that is a kind of work life balance as a first sort of step.

53:04 So you're always happy?

53:06 I do.

53:07 I mean it's like I, a lot of people would say

53:10 that, often I look like kind of a grim person with just

53:13 sitting there with a neutral expression or even like knitted brows

53:16 and a frown on my face as I'm staring at something.

53:19 That's what happiness looks like for you.

53:20 Yeah, it's kind of true where that it's like,

53:24 okay, I'm pushing this, I'm making progress here.

53:27 I know that doesn't work for everyone.

53:30 I know it doesn't work for most people.

53:32 But what I am always trying to do in those cases is,

53:35 I don't wanna let somebody that might be a person

53:38 like that, be told by someone else that, "No,

53:41 don't even try that out as an option," where work life-balance

53:45 versus kind of your life's work where there's a small subset

53:50 of the people that can be very happy being obsessive about

53:55 things and obsession can often get things done that just practical,

54:00 prudent pedestrian work won't or at least won't for a very long time.

54:06 There's legends of your nutritional intake in the early days.

54:11 What can you say about sort of as a being a programmer, as a kind of athlete?

54:17 So, what was the nutrition that fueled?

54:21 So, I have never been that great on really paying attention

54:25 to it where I'm good enough that I don't eat a lot,

54:29 I've never been like a big heavy guy.

54:31 But it was interesting where one of the things

54:34 that I can remember being an unhappy teenager, not having enough money and like,

54:38 one of the things that bothered me about not having

54:40 enough money is I couldn't buy pizza whenever I wanted to.

54:43 So I got rich and then I bought a whole lot of pizza.

54:46 So, that was defining, like that's what being rich felt like.

54:49 You could buy Pizza.

54:51 There was a lot pizza of the little things.

54:51 Like I could buy all the pizza and comic books and video

54:53 games that I wanted to, and it really didn't take that much.

54:58 But the pizza was one of those things and it's

55:01 absolutely true that for a long time it did software.

55:04 I had a pizza delivered every single day.

55:06 The delivery guy knew my name,

55:09 and I didn't find out until years later that apparently I was

55:12 such a good customer that they just never raised the price on me.

55:15 And I was using this 6-year-old price for the pizzas

55:18 that they were still kind of sending my way every day.

55:21 So, you were doing eating once a day or were you-- It would be spread out.

55:26 You have a few pieces of pizza,

55:27 you have some more later on, and I'd maybe have something at home.

55:31 It was one of the nice things that Facebook Meta is they do,

55:35 they feed you quite well.

55:36 You get a different, I guess now it's DoorDash sorts of things delivered,

55:40 but they take care of making sure that everybody does get well fed.

55:44 And I probably had better food those six years that I

55:47 was working in the Meta office there than I used to before.

55:51 But it's worked out okay for me.

55:53 My health has always been good.

55:55 I get a pretty good amount of exercise and I

55:58 don't eat to excess and I avoid a lot of other,

56:01 kind of not so good for you things.

56:03 So, I'm still doing quite well at my age.

56:05 Did you have a kind of, I don't know,

56:09 spiritual experience with food or coffee or any of that kind of stuff?

56:15 I mean, the programming experience with music,

56:18 or like I listen to brown noise in a program or like

56:23 creating an environment and the things you take into your body.

56:26 Just everything you construct can become a kind

56:28 of ritual that empowers the whole process of the program.

56:32 Did you have that relationship with pizza?

56:34 It would really be with Diet Coke.

56:36 I mean, there still is that sense of drop the can down,

56:39 crack open the can of Diet Coke.

56:40 All right now, I mean business, we're getting to work here.

56:43 But still to this day, diet Coke is still part.

56:47 Yeah, probably eight, eight or nine a day.

56:49 Nice, okay.

56:50 What about your setup?

56:52 How many screens, what kind of keyboard is there something interesting,

56:56 what kind of IDE, Emacs, Vim or something modern.

57:02 Linux, what operating system laptop or any

57:04 interesting thing that brings you joy?

57:07 So, I kind of migrated cultures where early on through

57:10 all of game dev there was sort of one culture there,

57:13 which was really quite distinct

57:14 from the Silicon Valley venture culture for things.

57:19 They're different groups and they have pretty different

57:21 mos in the way they think about things where,

57:23 and I still do think a lot of the big

57:26 companies can learn things from the hardcore game development

57:30 side of things where it still boggles my mind how

57:33 hostile to debuggers and IDEs that so much of them,

57:38 the kind of big money get billions

57:40 of dollars Silicon Valley venture backed funds are.

57:44 Oh, that's interesting.

57:45 Sorry, so you're saying like big companies at Google and Meta

57:49 are hostile to-- They are not big on debuggers and IDEs.

57:52 Like so much of it is like Emacs,

57:54 Vim for things and we just assume that debuggers,

57:57 don't work most of the time for the systems.

58:00 And a lot of this comes from a sort of Linux

58:03 bias on a lot of things where I did come up,

58:06 through the personal computers and then the DOS,

58:09 and then Windows and it was Borland tools and then Visual Studio.

58:17 [Lex] Do you appreciate debuggers?

58:18 Very much so.

58:19 I mean, a debugger is how you get

58:21 a view into a system that's too complicated to understand.

58:23 I mean, anybody that thinks just read the code and think about it,

58:27 that's an insane statement, you can't even read all the code on a big system.

58:31 You have to do experiments on the system.

58:33 And doing that by adding log statements, recompiling and rerunning it,

58:39 is an incredibly inefficient way of doing it.

58:41 I mean, yes, you can always get things done,

58:43 even if you're working with stone knives and bare skins.

58:46 That is the mark of a good programmer is that, given any tools,

58:50 you will figure out a way to get it done.

58:52 But it's amazing what you can do with sometimes much,

58:56 much better tools where instead of just going through this iterative, compile,

59:00 run debug cycle, you have the old Lips direction of like you've

59:04 got a riple and you're working interactively and doing amazing things there,

59:08 but in many cases a debugger as a very powerful user interface that can stop,

59:13 examine all the different things in your program,

59:15 set all of these different break points.

59:16 And of course you can do that with GDB or whatever there,

59:20 but this is one of the user interface

59:23 fundamental principles where when something is complicated to do,

59:26 you won't use it very often.

59:28 There's people that will break out GDB when they're at their wits end

59:31 and they just have beat their head against a problem for so long.

59:35 But for somebody that kind of grew up in game dev,

59:37 it's like they were running into the debugger anyways,

59:40 before they even knew there was a problem.

59:42 And you would just stop and see what was happening.

59:44 And sometimes you could fix things, even before you know,

59:47 even before you did one compile cycle,

59:50 you could be in the debugger and you could say,

59:52 well, I'm just going to change this right here and yep,

59:54 that did the job and fix it and go on.

59:57 And for people don't know, GDB is a sort of popular,

1:00:00 I guess Linux debugger primarily for C plus plus.

1:00:05 They handle most of the languages.

1:00:06 Okay, but it's based on C as the original kind of Unix heritage.

1:00:10 And it's kind of like command line, it's not user friendly.

1:00:12 It doesn't allow for clean visualizations and you're exactly right.

1:00:17 So, you're using this kind of debugger,

1:00:18 usually when you're at what's end and there's a problem that you can't

1:00:22 figure out why by just looking at the codes they have to find it.

1:00:26 That's how, I guess normal programmers use it.

1:00:28 But you're saying there should be tools that kind

1:00:31 of visualize and help you as part of the programming process,

1:00:35 just a normal programming process to understand the code deeper?

1:00:40 Yeah, when I'm working on like my C, C plus plus code,

1:00:42 I'm always running it from the debugger,

1:00:45 just I type in the code, I run it many times.

1:00:48 The first thing I do after writing code is

1:00:50 set a break point and step through the function.

1:00:53 Now other people will say, it's like, "Oh, I do that in my head." Well,

1:00:55 your head is a faulty interpreter of all

1:00:58 those things there and I've written brand new code,

1:01:01 I wanna step in there and I'm gonna single step through that, examine

1:01:03 lots of things and see if it's actually doing what I expected it to.

1:01:08 It it is a kind of companion, the debugger,

1:01:12 like you're now coding in an interactive way with another being,

1:01:16 the debugger is a kind of dumb being, but it's a reliable being.

1:01:21 That is an interesting question of what role does AI play in that kind

1:01:25 of with Codex and these kind of ability to generate code might be,

1:01:30 you might start having tools that understand the code

1:01:34 in interesting deep ways that can work with you.

1:01:37 Because there's a whole spectrum there from static

1:01:40 code analyzers and various kind of dynamic tools

1:01:43 there up to AI that can conceivably grok

1:01:45 these programs that literally no human can understand.

1:01:49 There are two big too intertwined and too interconnected,

1:01:51 but it's not beyond the possibility of understanding.

1:01:54 It's just beyond what we can hold in our heads

1:01:57 as kind of mutable state while we're working on things.

1:02:00 And I'm a big proponent again of things like

1:02:04 static analyzers and some of that stuff where you'll

1:02:07 find some people that don't like being scolded

1:02:10 by a program for how they've written something where it's like,

1:02:13 "Oh, I know better." And sometimes you do.

1:02:15 But that was something that I was, it was very,

1:02:19 very valuable for me when and not too

1:02:22 many people get an opportunity like this to have,

1:02:24 this is almost one of those spiritual experiences as a programmer and awakening

1:02:28 to, be it in software code bases were a couple million lines of code.

1:02:32 And at one point I had used a few of the different analysis tools,

1:02:36 but I made a point to really go through and scrub

1:02:40 the code base using every tool that I could find.

1:02:42 And it was eye-opening where we had a reputation

1:02:45 for having some of the, the most robust, strongest code,

1:02:48 where there were some great things that I

1:02:51 remember hearing from like Microsoft telling us about

1:02:53 crashes on Xbox and we had this tiny

1:02:56 number that they said were probably literally hardware errors.

1:02:59 And then you have other significant titles that just have

1:03:02 millions of faults that are getting recorded all the time.

1:03:04 So, I was proud of our code on a lot of levels,

1:03:07 but when I took this code analysis squeegee, through everything,

1:03:11 it was shocking how many errors there were in there.

1:03:16 Things that you can say, "Okay, this was a copy paste,

1:03:19 "not changing something right here." Lots of things that were,

1:03:23 the most common problem was something in a print

1:03:26 F format string that was the wrong

1:03:28 data type that could cause crashes there and you

1:03:31 really want the warnings for things like that.

1:03:33 Then the next most common was missing a check

1:03:35 for null that could actually happen that could blow things up.

1:03:38 And those are obviously like top C, C plus plus things.

1:03:41 Everybody has those problems, but the long tail of all of the different

1:03:45 little things that could go wrong there.

1:03:47 And we had good programmers and my own code,

1:03:49 it's not that I'd be looking at, it's like, "Oh, I wrote that code,

1:03:52 that's definitely wrong." We've been using

1:03:54 this for a year and it's this submarine,

1:03:58 this mind sitting there waiting for us to step on.

1:04:01 And it was humbling.

1:04:03 And I reached the conclusion that anything

1:04:07 that can be syntactically allowed in your language,

1:04:10 if it's gonna show up eventually in a large enough code base,

1:04:14 you're not gonna, good intentions aren't going to keep it from happening.

1:04:18 You need automated tools and guardrails for things.

1:04:21 And those start with things like static types

1:04:24 and or even type hints in the more dynamic languages.

1:04:27 But the people that rebel against that basically say,

1:04:31 that slows me down doing that.

1:04:33 There's something to that I get that I've written,

1:04:36 I've cobbled things together in a notebook.

1:04:38 I'm like, "Wow, this is great that it just happened," but yeah,

1:04:41 that's kind of sketchy, but it's working fine.

1:04:43 I don't care.

1:04:44 It does come back to that value analysis where sometimes it's right to not care,

1:04:49 but when you do care,

1:04:51 if it's going to be something that's going to live for years and it's gonna

1:04:54 have other people working on it and it's

1:04:56 gonna be deployed to millions of people,

1:04:59 then you want to use all of these tools you want to be told.

1:05:02 It's like, no, you've screwed up here, here and here.

1:05:04 And that does require kind of an ego check about things where you have

1:05:09 to be open to the fact that everything

1:05:11 that you're doing is just littered with flaws.

1:05:14 It's not that, "Oh, you occasionally have a bad

1:05:16 day," it's just whatever stream of code you

1:05:18 output there is going to be a statistical

1:05:21 regularity of things that you just make mistakes on.

1:05:24 And I do think there's the whole argument about,

1:05:27 test driven design and unit testing versus,

1:05:30 kind of analysis and different things.

1:05:33 I am more in favor of the analysis and the stuff that just like,

1:05:36 you can't run your program until you fix this, rather than you can

1:05:39 run it and hopefully a unit test will catch it in some way.

1:05:42 Yeah, in my private code I have asserts everywhere.

1:05:47 [John] Yeah.

1:05:48 It just, there's something pleasant to me, pleasurable to me,

1:05:52 about sort of the dictatorial rule of like, this should be true at this point.

1:05:58 And too many times, I've made mistakes that shouldn't have been made and I

1:06:05 would assume I wouldn't be the kind of person that would make that mistake,

1:06:09 but I keep making that mistake.

1:06:10 Therefore, an assert really catches me, really helps all the time.

1:06:15 So, I would say like 10 to 20% of my private code,

1:06:19 just for personal use is probably a service.

1:06:21 And they're active comments.

1:06:22 It's one of those things that in theory

1:06:24 they don't make any difference to the program.

1:06:27 And if it was all operating the way you expected it would be,

1:06:30 then they will never fire.

1:06:32 But even if you have it right and you wrote the code right initially,

1:06:36 then circumstances change.

1:06:38 The world outside your program changes.

1:06:40 And in fact that's one of the things where I'm kind of fond in a lot

1:06:44 of cases of static erase size declarations where

1:06:47 I went through this period where it's like,

1:06:49 okay, now we have general collection classes,

1:06:51 we should just make everything variable,

1:06:54 because I had this history of, in the early days you get Doom,

1:06:58 which had some fixed limits on it,

1:06:59 then everybody started making crazier and crazier things

1:07:02 and they kept bumping up the different limits,

1:07:04 this many lines, this many sectors.

1:07:06 And it seemed like a good idea.

1:07:09 Well, we should just make this completely generic.

1:07:10 It can go kind of go up to whatever

1:07:13 and there's cases where that's the right thing to do.

1:07:17 But it also, the other aspect of the world changing around you is it's

1:07:21 good to be informed when the world has changed more than you thought it would.

1:07:25 And if you've got a continuously growing collection,

1:07:28 you're never gonna find out.

1:07:29 You might have this quadratic slowdown on something where you thought, "Oh,

1:07:33 I'm only ever gonna have a handful of these, "but something changes and there's

1:07:37 a new design style "and all of a sudden you've got 10,000 of them." So,

1:07:41 I kind like in many cases picking a number,

1:07:44 some nice round power of two number and sending it

1:07:48 up in there and having an assert saying it's like, "Hey,

1:07:50 you hit this limit." You should probably

1:07:53 think about the choices that you've made around

1:07:55 all of this still relevant if somebody's using

1:07:58 10 times more than you thought they would?

1:08:00 Yeah, this code was originally written with this kind of worldview,

1:08:04 with this kind of set of constraints.

1:08:06 You were thinking of the world in this way.

1:08:09 If something breaks, that means you gotta rethink the initial stuff.

1:08:12 And it's nice for it to for it to do that.

1:08:16 Is there any stuff like keyboard or monitors?

1:08:21 I'm fairly pedestrian on a lot of that where I did move to triple monitors,

1:08:26 like in the last several years ago.

1:08:27 I had been dual monitor for a very long time and it

1:08:30 was one of those things where probably years later than I should have,

1:08:35 I'm just like, well the video cards now generally have three output ports.

1:08:38 I should just put the third monitor up there.

1:08:40 That's been a pure win.

1:08:41 I've been very happy with that.

1:08:43 But no, I don't have fancy keyboard or mouse or anything really going on.

1:08:49 The key things is an ID that has helpful debuggers has helpful tools,

1:08:54 so it's not the Emacs, Vim route and then Diet Coke.

1:08:57 Yeah, so I did spend, I spent one of my week-long retreats where I'm like,

1:09:01 okay, I'm gonna make myself use, it was actually classic VI,

1:09:05 which I know people will say you should never have done that.

1:09:07 You should have just used Vim directly.

1:09:09 But I gave it the good try.

1:09:11 It's like, okay, I'm being in kind of, classic Unix

1:09:14 developer mode here and I worked for a week on it.

1:09:18 I used end key to like teach myself

1:09:20 the different little key combinations for things like that.

1:09:24 And in the end it was just like, alright,

1:09:26 this was kind of like my civil war reenactment phase,

1:09:29 it's like I'm going out there, doing it like they used to in the old days.

1:09:32 And it was kind of fun in that regard.

1:09:33 You're offending so many people right now,

1:09:36 they're screaming as they're listening to this.

1:09:38 So again, the out is that this was not modern Vim, but still yes,

1:09:42 I was very happy to get back to my visual studio at the end.

1:09:47 Yeah, I'm actually, I struggle with this a lot, because,

1:09:49 so I use a Kinesis keyboard and I use Emacs primarily,

1:09:56 and I feel like I can exactly as you said,

1:09:59 I can understand the code, I can navigate the code.

1:10:00 There's a lot of stuff you could build within Emacs with using Lisp.

1:10:04 You can customize a lot of things for yourself to help you introspect the code,

1:10:09 like to help you understand the code

1:10:11 and visualize different aspects of the code.

1:10:13 You can even run debuggers, but it's work and the world moves past you

1:10:18 and the better and better ideas are constantly being built.

1:10:21 And that puts a kind of, I need to take

1:10:26 the same kind of retreat as you're talking about,

1:10:28 but now I'm still fighting the Civil War.

1:10:30 I need to kind of move into the 21st century.

1:10:33 And it does seem like the world is or a large

1:10:35 chunk of the world is moving towards Visual Studio Code,

1:10:38 which is kind of interesting to me,

1:10:40 against the JavaScript ecosystem on the one hand and IDEs are

1:10:44 one of those things that you want to be infinitely fast.

1:10:47 You want them to just kind of immediately respond.

1:10:51 And like, I mean, heck, I've got, there's someone I know,

1:10:53 I am an old school game dev guy that still

1:10:55 uses Visual Studio Six and on a modern computer,

1:10:59 everything is just absolutely instant on something like that because it was made

1:11:03 to work on a computer that's 10,000 or a hundred thousand times slower.

1:11:07 So, just everything happens immediately and all the modern systems just feel,

1:11:13 they feel so crufty when it's like, "Oh,

1:11:15 why is this refreshing the screen and moving

1:11:17 around "and updating over here and something blinks down

1:11:20 there "and you should update this." And there

1:11:22 are things that we've lost with that incredible flexibility,

1:11:27 but lots of people get tons of value from it.

1:11:31 And I am super happy that that seems to be winning over even

1:11:34 a lot of the old Vim and Emacs people that they're kind of like,

1:11:37 "Hey, Visual Studio code is may be not so bad." I am that may

1:11:41 be the final peacekeeping solution where everybody

1:11:44 is reasonably happy with something like that.

1:11:47 So, can you explain what a dot plan file

1:11:50 is and what role that played in your life?

1:11:53 Does it still continue to play a role?

1:11:55 Back in the early, early days of id Software,

1:11:57 one of our big things that was unique with what we did is I had adopted next

1:12:03 stations or kind of next steps systems from Steve

1:12:06 Jobs's out in the woods way from Apple Company.

1:12:11 And they were basically, it was kind of interesting,

1:12:15 because I did not really have a background with the Unix system.

1:12:18 So, many of the people, they get immersed in that in college

1:12:21 and that sets a lot of cultural expectations for them.

1:12:27 And I didn't have any of that, but I knew that my background was,

1:12:31 I was a huge Apple II fan, boy, I was always a little suspicious of the Mac.

1:12:36 I was not really what kind of I wanted to to go with.

1:12:41 But when Steve Jobs left Apple and started NeXT,

1:12:44 this computer did just seem like one of those amazing things

1:12:47 from the future where it had all of this cool stuff in it.

1:12:50 And we were still back in those days, working on DOS, everything blew up.

1:12:54 You had reset buttons,

1:12:55 because your computer would just freeze if you're doing development work,

1:12:58 literally dozens of times a day.

1:12:59 Your computer was just rebooting constantly.

1:13:02 And so this idea of, yes, any of the Unix workstations,

1:13:06 would've given a stable development platform where

1:13:08 you don't crash and reboot all the time.

1:13:11 But NeXT also had this really amazing graphical interface and it was great

1:13:16 for building tools and it used objective C as the kind of an interesting.

1:13:21 [Lex] Oh wow.

1:13:22 So, NeXT was Unix based, instead objective C.

1:13:26 So, it has a lot of the elements.

1:13:28 That became Mac, I mean the kind of reverse acquisition of Apple by NeXT,

1:13:31 where that took over and became what the modern Mac system is.

1:13:35 And defined some of the developer like the tools and the whole community.

1:13:41 Yeah, you've still got, if you're programming on Apple stuff now,

1:13:43 there's still all these Ns somethings which was

1:13:46 originally next step objects of different kinds of things.

1:13:49 But one of the aspects of those Unix systems was

1:13:53 they had this notion of a dot plan file where,

1:13:56 a dot file is an invisible file, usually in your home directory or something.

1:14:02 And there was a trivial server, running on most Unix systems at the time

1:14:05 that, that when somebody ran a trivial little command,

1:14:09 called finger, you could a finger and then somebody's address,

1:14:13 it could be anywhere on the internet if you were connected correctly,

1:14:16 then all that server would do was read the dot plan file

1:14:20 in that user's home directory and then just spit it out to you.

1:14:24 And originally the idea was that could be,

1:14:26 whether you're on vacation, what your current project was,

1:14:30 it's supposed to be like the plan of what

1:14:31 you're doing and people would use it for, various purposes.

1:14:35 But all it did was dump that file,

1:14:38 over to the terminal of whoever issued the finger command.

1:14:42 And at one point I started just keeping a list of what I was doing in there,

1:14:48 which would be what I was working on in the day.

1:14:51 And I would have this little syntax, I kind of got to myself about,

1:14:55 here's something that I'm working on, I put a star when I finish it,

1:14:58 I could have a few other little bits of punctuation.

1:15:01 And at the time it was, it started off as being just like my to-do

1:15:05 list and it would be these trivial obscure little things,

1:15:10 like I fixed something with collision detection code,

1:15:12 made Fireball do something different and just little one-liners

1:15:16 that people that were following the games could kind of decipher.

1:15:20 But I did wind up starting to write much more in depth things.

1:15:24 I would have little notes of thoughts and insights

1:15:28 and then I would eventually start having little essays.

1:15:30 I would sometimes dump into the dot plan files,

1:15:33 interspersed with the work logs of things that I was doing.

1:15:36 So, in some ways it was like a super early proto blog

1:15:39 where I was just kind of dumping out what I was working on.

1:15:42 But it was interesting enough that there were

1:15:44 a lot of people that were interested in this.

1:15:48 So, most of the people didn't have Unix workstations.

1:15:51 So, there were the websites back in the day that would

1:15:53 follow the Doom and Quake development that would basically make

1:15:57 a little service that would go grab all the changes

1:15:59 and then people could just get it with a web browser.

1:16:02 And there was a period where like all of the little kind

1:16:05 of Dallas gaming diaspora of people that were at all in that orbit,

1:16:09 there were a couple dozen plan files going on, which was,

1:16:12 and this was some years, before blogging really became kind of a thing.

1:16:17 And it was kind of a premonition of sort of the way things would go.

1:16:22 And there was, it's all been collected,

1:16:25 it's available online in different places and it's kind of fun

1:16:27 to go back and look through what I was thinking,

1:16:30 what I was doing in the different areas.

1:16:32 Have you had a chance to look back?

1:16:33 Is there some interesting, very low level specific to-do items,

1:16:38 maybe things you've never completed, all that kind of stuff and high level

1:16:42 philosophical essay type of stuff that stands out.

1:16:46 Yeah, there's some good stuff on both,

1:16:48 where a lot of it was low level nitpicky details,

1:16:52 about game dev and I've learned enough things where there's no project that I

1:16:57 worked on that I couldn't go back and do a better job on now.

1:17:00 I mean you learn things hopefully if you're doing it right,

1:17:03 you learn things as you get older and you should be

1:17:06 able to do a better job at all of the early things.

1:17:08 And there's stuff in Wolfenstein, Doom, Quake that like, "Oh,

1:17:12 clearly I could go back and do a better job at this." Whether it's something

1:17:16 in the rendering engine side or how

1:17:18 I implemented the monster behaviors or managed resources.

1:17:22 Do you see flaws in your thinking now looking back?

1:17:25 Yeah, I do.

1:17:27 I mean sometimes I'll get the, I'll look at it and say, "Yeah,

1:17:30 I had a pretty clear view of, "I was doing good work

1:17:33 there" and I haven't really hit the point where there was another programmer,

1:17:38 Graham Devine, he had worked at id and 7th Guest

1:17:41 and he made some comment one time where he said,

1:17:44 he looked back at some of his old notes and he was like, "Wow,

1:17:47 I was really smart back then." And I don't hit that so much where,

1:17:51 I mean, I look at it and I always know that, yeah,

1:17:54 there's all the, with aging you get certain

1:17:57 changes in how you're able to work problems.

1:18:00 But all of the problems that I've worked,

1:18:02 I'm sure that I could do a better job on all of them.

1:18:06 Oh wow.

1:18:07 So, you can still step right in.

1:18:08 If you could travel back in time and talk to that guy,

1:18:10 you would teach him a few things.

1:18:12 [John] Yeah, absolutely.

1:18:14 That's awesome.

1:18:15 What about the high level philosophical stuff?

1:18:18 Is there some insights that stand out that you remember?

1:18:21 There's things that I was understanding about development and the industry

1:18:27 and so on that we're in a more primitive stage,

1:18:31 where I definitely learned a lot more in the later

1:18:36 years about business and organization and team structure.

1:18:41 There were, I mean, there were definitely things that I was

1:18:45 not the best person or even a very good person about managing,

1:18:48 like how a a team should operate internally, how people should work together.

1:18:53 I was just, the just get outta my way and let me work on the code and do this.

1:18:59 And more and more I've learned how in the larger scheme of things,

1:19:05 how sometimes relatively unimportant,

1:19:07 some of those things are where it is this user value generation.

1:19:11 That's the overarching importance for all of that.

1:19:14 And I didn't necessarily have my eye on that ball

1:19:17 correctly through a lot of my earlier years.

1:19:20 And there's things that, I could have gotten

1:19:24 more out of people handling things in different ways.

1:19:27 I could have made in some ways more

1:19:31 successful products by following things in different ways.

1:19:33 There's mistakes that we made that we couldn't

1:19:36 really have known how things would've worked out.

1:19:38 But it was interesting to see in later years,

1:19:40 companies like Activision showing that, hey,

1:19:42 you really can just do the same game, make it better every year.

1:19:46 And you can look at that from a negative standpoint and say it's like, "Oh,

1:19:49 that's just being derivative and all that." But if

1:19:51 you step back again and say it's like,

1:19:53 no, are the people buying it still enjoying it?

1:19:55 Are they enjoying it more than what they might have bought otherwise?

1:19:59 And you can say, "No,

1:20:00 that's actually a great value creation engine "to do that if you're

1:20:04 in a position where you can." Don't be forced into reinventing everything,

1:20:09 just because you think that you need to, lots of things

1:20:14 about business and team stuff that could be done better.

1:20:17 But the technical work that the kind

1:20:19 of technical visionary type stuff that I laid out,

1:20:22 I still feel pretty good about.

1:20:23 There are some classical ones about my defending of OpenGL,

1:20:27 versus D3D, which turned out to be one of the more,

1:20:32 probably important momentous things there where it never,

1:20:36 it was always a rear guard action on Windows

1:20:38 where Microsoft was just not gonna let that win.

1:20:42 But when I look back on it now,

1:20:44 that fight to keep OpenGL relevant for a number of years

1:20:48 there meant that OpenGL was there when mobile started happening.

1:20:52 And OpenGL ES was the thing that drove,

1:20:55 all of the acceleration of the mobile industry.

1:20:58 And it's really only in the last few years as Apple has

1:21:01 moved to Metal and some of the other companies have moved to Vulcan,

1:21:05 that that's moved away.

1:21:06 But really stepping back and looking at it, it's like,

1:21:09 yeah, I sold tens of millions of games for different things,

1:21:13 but billions and billions of devices wound up with an appropriate

1:21:19 capable graphics API in no small part to me,

1:21:23 thinking that that was really important that we

1:21:26 not just give up and use Microsoft's, at that time really terrible, API.

1:21:32 The thing about Microsoft is the APIs don't stay terrible.

1:21:35 They were terrible at the start,

1:21:37 but a few versions on they were actually quite good.

1:21:40 And there was a completely fair argument to be

1:21:42 made that by the time DX9 was out,

1:21:45 it was probably a better programming environment than OpenGL.

1:21:48 But it was still a wonderful good thing that we had an open standard that could

1:21:53 show up on Linux and Android and iOS and eventually WebGL still to this day.

1:21:58 So, that was one that would be on my greatest hits list of things

1:22:03 that I kind of pushed-- Impact it had on billions of devices, yes.

1:22:07 So, let's talk about it.

1:22:08 Can you tell the origin story of id Software,

1:22:12 again, one of the greatest game developer companies ever.

1:22:16 It created Wolfenstein 3D,

1:22:18 games that define my life also in many ways as a thing

1:22:23 that made me realize what computers are capable of in terms of graphics,

1:22:26 in terms of performance.

1:22:28 It just unlocks something deep in me

1:22:32 and understanding what these machines are all about, as games can do that.

1:22:35 So, Wolfenstein 3D, Doom,

1:22:36 Quake and just all the incredible engineering innovation that went into that.

1:22:41 So, how did it all start?

1:22:44 So, I'll caveat upfront that I usually don't consider

1:22:48 myself the historian of the software side of things.

1:22:51 I usually do.

1:22:52 I kind of point people at John Romero

1:22:55 for stories about the early days where I've never been,

1:23:00 like I've commented that I'm a remarkably unsentimental

1:23:02 person in some ways where I don't really spend

1:23:04 a lot of time unless I'm explicitly prodded to go

1:23:07 back and think about the early days of things.

1:23:10 And I didn't necessarily make the effort

1:23:14 to archive everything exactly in my brain.

1:23:17 And the more that I work on machine learning and AI and the aspects

1:23:20 of memory and how when you go back and polish certain things,

1:23:23 it's not necessarily exactly the way it happened.

1:23:25 But having said all of that from my view,

1:23:29 the way everything happened that led up to that was after

1:23:34 I was an adult and kind of taking a few college classes,

1:23:38 deciding to drop out, I was doing,

1:23:40 I was hard scrabble contract programming work,

1:23:43 really struggling to kind of keep groceries and pay my rent and things.

1:23:48 And the company that I was doing the most

1:23:50 work for was a company called Soft Disc Publishing,

1:23:53 which had the sounds bizarre now

1:23:56 business model of monthly subscription software.

1:23:59 Before there was an internet that people could connect

1:24:02 to and get software you would pay a certain

1:24:05 amount and every month they would send you

1:24:07 a disc that had some random software on it.

1:24:09 And people that were into computers thought this was kind of cool.

1:24:12 And they had different ones for the Apple II, the 2GS,

1:24:16 the PC, the Mac, the Omega, lots of different things here.

1:24:20 So, quirky little business.

1:24:21 But I was doing a lot of contract programming for them

1:24:24 where I'd write tiny little games and sell them for 300, $500.

1:24:29 And one of the things that I was doing, again,

1:24:32 to keep my head above water here was I decided that I

1:24:36 could make one program and I could port it to multiple systems.

1:24:41 So, I would write a game like Dark Designs

1:24:44 or Catacombs and I would develop it on the Apple II, the 2GS and the IBM PC,

1:24:49 which apparently was the thing that really kind

1:24:52 of peaked the attention of the people working down there.

1:24:56 Like Jay Wilber was my primary editor and Tom Hall was

1:24:59 a secondary editor and they kept asking me, it's like, "Hey,

1:25:03 you should come down and work for us here." And I pushed it off a couple times,

1:25:08 because I was really enjoying my freedom of kind of being off on my own,

1:25:11 even if I was barely getting by.

1:25:14 I loved it.

1:25:14 I was doing nothing but programming all day.

1:25:17 But I did have enough close scrapes with like,

1:25:20 I'm just really outta money that maybe I should get an actual job,

1:25:24 rather than contracting these kind of one at a time things.

1:25:27 And Jay Wilbur was great.

1:25:29 He was like FedExing me the checks when I would need

1:25:31 them to kind of get over whatever hump I was at.

1:25:35 So, I took the, I finally took 'em up

1:25:38 on their offer to come down to Shreveport, Louisiana.

1:25:41 I was in Kansas City at the time,

1:25:43 drove down to through the Ozarks and everything

1:25:47 down to Louisiana and saw the Soft Disc Offices.

1:25:51 Went through, talked to a bunch of people,

1:25:53 met the people I had been working with remotely at that time.

1:25:57 But the most important thing for me was,

1:25:59 I met two programmers there, John Romero and Lane Roth,

1:26:03 that for the first time ever I had met

1:26:05 programmers that knew more cool stuff than I did,

1:26:08 where the world was just different back then.

1:26:11 I was in Kansas City, it was one of those smartest kid in the school,

1:26:14 does all the computer stuff, the teachers don't have anything to teach him.

1:26:18 But all I had to learn from was these few books at the library.

1:26:21 It was not much at all.

1:26:23 And there were some aspects of programming that were kind of black magic to me.

1:26:27 Like it's like, "Oh, he knows how to format a track

1:26:29 "on a low level drive programming interface." And this was,

1:26:35 I was still not at all sure I was gonna take the job,

1:26:38 but I met these awesome programmers that were doing cool stuff.

1:26:41 And like Romero had worked at Origin Systems and he had done like

1:26:46 so many different games ahead of time that I did kind of quickly decide.

1:26:50 It's like, yeah, I'll go take the job down there.

1:26:53 And I settled down there, moved in and started working on more little projects.

1:26:59 And the first kind of big change that happened down there

1:27:03 was the company wanted to make a PC gaming focused subscription,

1:27:08 just like all their others.

1:27:09 The same formula that they used for everything,

1:27:11 pay a monthly fee and you'll get a disc with one

1:27:15 or two games just every month and no choice in what you get,

1:27:18 but we think it'll be fun.

1:27:19 And that was the model they were comfortable with and said, "All right,

1:27:22 we're gonna start this Gamers' Edge Department." And all

1:27:25 of us that were interested in that, like me and Romero,

1:27:29 Tom Hall was kind of helping us from his side of things.

1:27:33 Jay would peek in and we had a few other programmers working

1:27:36 with us at the time and we were going to just start making games.

1:27:41 Just the same model.

1:27:42 And we dived in and it was fantastic.

1:27:46 So, you have to make new games.

1:27:47 [John] Every month.

1:27:48 Every month.

1:27:49 Yeah.

1:27:50 And this, in retrospect, looking back at it,

1:27:52 that sense that I had done all this contract programming

1:27:55 and John Romero had done like far more of this where

1:27:58 he had done one of his teaching himself efforts was

1:28:01 he made a game for every letter of the alphabet.

1:28:03 It's that sense of like,

1:28:04 I'm just gonna go make 26 different games, give him a different theme.

1:28:07 And you learn so much when you go through

1:28:10 and you crank these things out like on a biweekly,

1:28:13 monthly basis, something like that.

1:28:15 From start to finish.

1:28:16 So, it's not like an I just an idea.

1:28:17 It's not just, from the very beginning to the very end.

1:28:21 It's done, it has to be done, there's no delaying, it's done.

1:28:25 Yep and you've got deadlines.

1:28:27 And that kind of rapid iteration pressure cooker environment

1:28:32 was super important for all of us developing the skills

1:28:35 that brought us to where we eventually went to, I

1:28:38 mean people would say like in the history of the Beatles,

1:28:41 like it wasn't them being the Beatles,

1:28:43 it was them playing all of these other early

1:28:45 works that that opportunity to craft all of their skills,

1:28:48 before they were famous that was very critical to their later successes.

1:28:53 And I think there's a lot of that here

1:28:54 where we did these games that nobody remembers.

1:28:58 Lots of little things that contributed to building up

1:29:01 the skillset for the things that eventually did make us famous.

1:29:05 Fyodor Dostoevsky wrote "The Gambler," he had

1:29:09 to write it in a month, just make money.

1:29:12 And nobody remembers that probably, 'cause he had to figure out,

1:29:15 'cause it's literally he didn't have enough time to write it fast enough.

1:29:21 So, to come up with hacks, to actually literally write it faster.

1:29:24 It gain comes down that point where

1:29:26 pressure and limitation of resources is surprisingly important.

1:29:30 [Lex] Yeah.

1:29:31 And it's counterintuitive in a lot of ways where you just think that if you've

1:29:33 got all the time in the world and you've got all the resources in the world,

1:29:36 of course you're gonna get something better.

1:29:38 But sometimes it really does work out

1:29:40 that the innovations mother necessity and you know where

1:29:45 you can or resource constraints and you have

1:29:47 to do things when you don't have a choice.

1:29:49 It's surprising what you can do.

1:29:50 Is there any good games written in that time, would you say?

1:29:53 Some of them are still fun to go back and play where you get the, they were all

1:29:58 about kind of the more modern term is game

1:30:01 feel about how just the exact feel that things,

1:30:04 it's not the grand strategy of the design,

1:30:06 but how running and jumping and shooting and those things feel in the moment.

1:30:12 And some of those are still you sat down at 'em,

1:30:14 you kind of go, it's a little bit different.

1:30:16 It doesn't have the same movement feel,

1:30:17 but you move over and you're like bang, jump bang.

1:30:20 It's like, "Hey, that's kind of cool still."- So,

1:30:23 you can get lost in the rhythm of the game.

1:30:25 Like is that what you mean by feel?

1:30:27 Just like there's something about it that pulls you in.

1:30:31 Nowadays, again, people talk about compulsion loops and things

1:30:34 where it's that that sense of exactly what you're doing,

1:30:38 what your fingers are doing on the keyboard, what your eyes are seeing.

1:30:41 And there are gonna be these sequences of things.

1:30:43 Grab the loot, shoot the monster, jump over the obstacle,

1:30:45 get to the end of the level.

1:30:47 These are eternal aspects of game design in a lot of ways.

1:30:50 But there are better and worse ways to do all of them.

1:30:53 And we did so many of these games that it was, we got a lot of practice with it.

1:30:58 So, one of the kind of weird things that was happening

1:31:01 at this time is John Romero was getting some strange fan mail.

1:31:06 And back in the days, this is before email,

1:31:09 so we literally got letters sometimes and telling him,

1:31:12 it's like, "Oh, I wanna talk to you about your games.

1:31:14 "I wanna reach out different things."

1:31:16 And eventually it turned out that these were

1:31:20 all coming from Scott Miller at Apogee Software and he was reaching out through,

1:31:26 he didn't think he could contact John directly that he would get intercepted.

1:31:29 So, he was trying to get him to contact him through,

1:31:32 like back channel fan mail because he basically was saying,

1:31:35 "Hey, I'm making all this money on shareware games.

1:31:38 "I want you to make Shareware games." Because

1:31:41 he had seen some of the games that Romero

1:31:43 had done and we looked at Scott Miller's

1:31:47 games and we didn't think they were very good.

1:31:49 We're like, that can't be making the kind of money

1:31:53 that he's saying he's making 10 grand or something.

1:31:55 I am off of this game.

1:31:57 We really thought that he was full of shit.

1:31:59 That it was a lie trying to get to get him into this.

1:32:03 So that was kind of going on at one level,

1:32:07 and it was funny the moment when Romero realized that he had some

1:32:10 of these letters pinned up on his wall of like all of his fans.

1:32:13 And then we noticed that they all had

1:32:15 the same return address with different names on them,

1:32:17 which was a little bit of a two-edged sword there.

1:32:20 But trying to figure out the puzzle laid out before him.

1:32:23 Yeah, what happened after I kind of coincident with that was

1:32:27 I was working on a lot of the new technologies where I

1:32:30 was now full on the IBM PC for the first time

1:32:33 where I was really a long hold out on Apple II forever.

1:32:37 And I loved my Apple II,

1:32:38 it was the computer I always wished I had when I was growing up.

1:32:41 And when I finally did have one,

1:32:43 I was kind of clinging onto that well past it, sort of good use by day.

1:32:47 Was it the best computer I ever made you, would you say?

1:32:50 I wouldn't make judgments like that about it.

1:32:53 But it was positioned in such a way, especially in the school systems,

1:32:56 that it impacted a whole lot of American programmers

1:32:59 at least where there was programs that the Apple

1:33:02 IIs got into the schools and they had enough

1:33:05 capability that lots of interesting things happened with them.

1:33:08 In Europe it was different.

1:33:09 You had your Omegas and Ataris and Acorns

1:33:12 in the UK and things that that had different things.

1:33:16 But in the United States it was probably the Apple II,

1:33:18 made the most impact for a lot of programmers of my generation.

1:33:23 But, so I was really digging into the IBM

1:33:26 and this was even more so with the total focus,

1:33:29 because I had moved to another city where

1:33:31 I didn't know anybody that I wasn't working with.

1:33:33 I had a little apartment and then at Soft Disk,

1:33:36 again, the things that that drew me to it,

1:33:38 I had a couple programmers that knew more than I did and they had a library,

1:33:43 they had a set of books and a set of magazines.

1:33:46 They had a couple years of magazines, the old "Dr.

1:33:48 Dobbs Journal" and all of these magazines that had information about things.

1:33:53 And so I was just in total immersion mode.

1:33:56 It was eat, breathe, sleep, computer programming,

1:33:59 particularly the IBM for everything that I was doing.

1:34:03 And I was digging into a lot of these low

1:34:05 level hardware details that people weren't usually paying attention to.

1:34:08 The way the IBM EGA cards worked, which was fun for me.

1:34:14 I hadn't had experience with things at that level.

1:34:16 And back then you could get hardware documentation,

1:34:20 just down at the register levels.

1:34:21 This is where the CRTC register is,

1:34:23 this is how the color registers work and how the different things are applied.

1:34:27 And they were designed for a certain reason.

1:34:30 They were designed for an application.

1:34:31 They had an intended use in mind,

1:34:33 but I was starting to look at other ways that they

1:34:37 could perhaps be exploited that they weren't initially intended for.

1:34:40 Could you comment on like, first of all, what operating system was there?

1:34:44 What instruction set was it?

1:34:45 Like what are we talking about?

1:34:48 So, this was Dawson X86.

1:34:50 So 16 bit 8086, the 286s were there and 386s existed.

1:34:55 They were rare.

1:34:56 We a couple for our development systems,

1:34:59 but we were still targeting the more broad, it was all DOS 16 bit.

1:35:04 None of this was kind of DOS extenders and things.

1:35:07 How different is it from the systems of today,

1:35:09 is it kind of the a precursor that's similar?

1:35:12 Very little if you open up command.com on Windows,

1:35:17 you see some of the remnants of all of that.

1:35:19 But it was a different world.

1:35:20 It was the 640K is enough world and nothing was protected.

1:35:25 It crashed all the time.

1:35:26 You had TSRs or terminate and stay resident hacks

1:35:29 on top of things that would cause configuration problems.

1:35:33 All the hardware was manually configured in your auto exec.

1:35:37 So, it was a very different world.

1:35:39 The code is still the same.

1:35:41 You could still write it.

1:35:42 My earliest code there was written in Pascal.

1:35:44 That was what I had learned kind of at an earlier point.

1:35:48 So, between Basic and C plus plus there was Pascal.

1:35:51 So, when basic assembly language and some of my-- [Lex] Take a step back.

1:35:55 Yeah, my intermediate stuff was,

1:35:55 well you had to for performance, basic was just too slow.

1:35:58 So, most of the work that I was doing

1:36:00 as a contract programmer in my teenage years was assembly language.

1:36:05 You wrote games in assembly?

1:36:07 Yeah, complete games in assembly language.

1:36:10 And it's thousands and thousands of lines

1:36:12 of three letter acronyms for the instructions.

1:36:17 You don't earn the once again greatest programmer ever label

1:36:21 without being able to write a game in assembly, okay.

1:36:23 But that's again, everybody wrote their, everybody

1:36:25 serious wrote their games in assembly language.

1:36:27 Pretty serious, you see what he said?

1:36:29 Everybody's serious.

1:36:30 It was an outlier to use Pascal a little

1:36:33 bit where there was one famous program called Wizardry.

1:36:36 It was one, like one of the great early role playing games.

1:36:39 That was written in Pascal, but it was almost nothing used Pascal there.

1:36:43 But I did learn Pascal and I remember doing all of my, like to this day,

1:36:47 I sketch in data structures when I'm thinking about something,

1:36:50 I'll open up a file and I'll start writing

1:36:54 struct definitions for how data is gonna be laid out.

1:36:56 And Pascal was kind of formative to that, because I remember

1:37:00 designing my RPGs in Pascal records structures and things like that.

1:37:04 And so I had gotten a Pascal compiler for the Apple IIGS that I could work on.

1:37:08 And the first IBM game that I developed, I did in Pascal.

1:37:12 And, and that's actually kind of an interesting story, again,

1:37:15 talking about the constraints and resources where I had an Apple IIGS,

1:37:20 I didn't have an IBM PC.

1:37:21 I wanted to port my applications to IBM,

1:37:24 because I thought I could make more money on it.

1:37:27 So, what I wound up doing is I rented a PC

1:37:30 for a week and bought a copy of Turbo Pascal.

1:37:33 And so I had a hard one week and this was

1:37:36 cutting into what minimal profit margin I had there.

1:37:38 But I had this computer for a week.

1:37:40 I had to get my program ported, before I had to return the PC.

1:37:44 Yeah.

1:37:45 And that was kind of what the first thing that I had done

1:37:47 on the IBM PC and what led me to the taking the job at Soft Disk.

1:37:52 And Turbo Pascal.

1:37:53 How's that different from regular Pascal?

1:37:55 Is it different compiler or something like that?

1:37:57 So, it was a product of Borland, which before Microsoft kind of killed them,

1:38:00 they were the hot stuff developer tools company.

1:38:04 You had Borland Turbo Pascal and Turbo C and Turbo Prologue,

1:38:08 I mean all the different things.

1:38:09 But what they did was they took

1:38:11 a supremely pragmatic approach of making something useful.

1:38:14 It was one of these great examples where Pascal

1:38:17 was an academic language and you had things like

1:38:20 the UCSDP system that Wizardry was actually written

1:38:23 in that they did manage to make a game with that.

1:38:27 But it was not a super practical system.

1:38:30 While Turbo Pascal was,

1:38:32 it was called Turbo because it was blazingly fast to compile,

1:38:35 I mean really ridiculously 10 to 20 times

1:38:39 faster than most other compilers at the time.

1:38:41 But it also had very pragmatic access to look,

1:38:44 you can just poke at the hardware in these different ways.

1:38:46 And we have libraries that let you do things.

1:38:49 And it was a perfectly good way to write games.

1:38:52 And this is one of those things where people

1:38:54 have talked about different paths that computer development could

1:38:57 have taken where C took over the world

1:39:01 for reasons that came out of Unix and eventually Linux.

1:39:04 And that was not a foregone conclusion at all.

1:39:07 And people can make real reasoned,

1:39:09 rational arguments that the world might've been

1:39:12 better if it had gone a Pascal route.

1:39:14 I'm somewhat agnostic on that, where I do know

1:39:17 from experience it was perfectly good enough to do that.

1:39:21 And it had some fundamental improvements.

1:39:23 Like it had range checked arrays as an option there,

1:39:26 which could avoid many of C's real hazards that happened in a security space.

1:39:31 But C one, they were basically operating at about the same level of abstraction.

1:39:35 It was a systems programming language.

1:39:38 But you said Pascal had a more emphasis on data structures.

1:39:41 I actually, in the tree of languages the Pascal come before C,

1:39:47 did it inspire a lot-- They were pretty contemporaneous.

1:39:49 So, Pascal's Lineage went to modular two and eventually

1:39:52 Oberon which was another Niklaus Wirth kind of experimental language.

1:39:58 But they were all good enough at that level.

1:40:01 Now some of the classic academic

1:40:03 oriented Pascals were just missing fundamental things.

1:40:05 Like, oh, you can't access this core system thing,

1:40:08 because we're just using it to teach students.

1:40:10 But Turbo Pascal showed that only modest changes

1:40:13 to it really did make it a completely

1:40:16 capable language and it had some reasons why

1:40:18 you could implement it as a single pass compiler.

1:40:20 So, it could be way, way faster,

1:40:22 although less scope for optimizations if you do it that way.

1:40:25 And it did have some range checking options.

1:40:28 It had a little bit better typing capability.

1:40:30 You'd have properly typed enums sorts of things and other stuff that C lacked.

1:40:35 But C was also clearly good enough and it wound up

1:40:38 with a huge inertia from the Unix ecosystem and everything that came with that.

1:40:43 Garbage collection.

1:40:44 [John] No, it was not garbage collected.

1:40:45 It's the same kind of thing as C.

1:40:46 Same manual.

1:40:47 So, you could still have your use after freeze and all those other problems,

1:40:50 but just getting rid of array overruns,

1:40:53 at least if you were compiled with that debugging option,

1:40:56 certainly would've avoided a lot of problems and could have a lot of benefits.

1:40:59 But, so anyways, that was the next thing, I had to learn C,

1:41:02 because C was where it seemed like, most of the things were going.

1:41:07 So, I abandoned Pascal and I started working in C.

1:41:09 I started hacking on these hardware things,

1:41:11 dealing with the graphics controllers and the EGA

1:41:15 systems and what we most wanted to do.

1:41:18 So, at that time we had, we were sitting in our darkened office playing,

1:41:22 all the different console video games and we're figuring out what do we want

1:41:26 to kind of, what games do we want to make for our Gamers Edge product there?

1:41:30 And so we had one of the first super Nintendos sitting there

1:41:34 and we had an older Nintendo and we were looking at all those games.

1:41:37 And the core thing that those consoles did that you just didn't

1:41:40 get on the PC games was this ability to have a massive

1:41:44 scrolling world where most of the games that you would make

1:41:46 on the PC and earlier personal computers would be a static screen.

1:41:51 You move little things around on it and you interact

1:41:54 like that, maybe you go to additional screens as you move.

1:41:58 But arcade games and consoles had this wonderful ability to just

1:42:02 have a big world that you're slowly moving your window through.

1:42:06 And that was for those types of games, the kind of action exploration,

1:42:10 adventure games, that was a super, super important thing.

1:42:13 And PC games just didn't do that.

1:42:15 And what I had had come across was

1:42:18 a couple different techniques for implementing that on the PC.

1:42:22 And they're not hard complicated things.

1:42:24 When I explained 'em now, they're pretty straightforward,

1:42:28 but just nobody was doing it.

1:42:29 You sound like Einstein describing his five papers as pretty straightforward.

1:42:33 I understand.

1:42:34 But they're nevertheless revolutionary.

1:42:36 So, side scrolling is a game changer.

1:42:38 [John] Yeah, it's scrolling-- It's a genius invention.

1:42:40 There's tighter vertical.

1:42:41 And some of the consoles had different limitations,

1:42:43 about you could do one but not the other.

1:42:45 And there were similar things going on as advancements,

1:42:48 even in the console space where you'd have like

1:42:50 the original Mario game was like just horizontal scrolling.

1:42:54 And then later Mario Games added vertical aspects to it

1:42:57 and different things that you were doing to explore,

1:43:01 kind of expand the capabilities there.

1:43:02 And so much of the early game design for decades was removing limitations,

1:43:07 letting you do things that you envisioned as a designer,

1:43:10 you wanted the player to experience,

1:43:11 but the hardware just couldn't really or you didn't know how to make it happen.

1:43:16 It felt impossible.

1:43:18 You can imagine that you want to create,

1:43:20 like this big world through which you can side scroll,

1:43:23 like through which you can walk and then you ask yourself a question,

1:43:28 how do I actually build that in a way that's, like the latency is low enough,

1:43:33 the hard work can actually deliver

1:43:36 that in such a way that's a compelling experience.

1:43:39 Yeah and we knew what we wanted to do,

1:43:40 because we were playing all of these console games,

1:43:42 playing all these Nintendo games and arcade games.

1:43:45 Clearly there was a whole world of awesome things

1:43:47 there that we just couldn't do on the PC,

1:43:49 at least initially because every programmer can tell,

1:43:52 it's like if you wanna scroll, you can just redraw the whole screen.

1:43:55 But then it turns out, well, you're going five frames per second.

1:43:58 That's not an interactive fun experience.

1:44:01 You wanna be going 30 or 60 frames per second or something.

1:44:04 And it just didn't feel like that was possible.

1:44:06 It felt like the PCs had to get five

1:44:09 times faster for you to make a playable game there.

1:44:12 And interestingly, I wound up with two

1:44:15 completely different solutions for the scrolling problem.

1:44:18 And this is a theme that runs through

1:44:22 everything where all of these big technical advancements,

1:44:25 it turns out there's always a couple different ways of doing them.

1:44:28 And it's not like you found the one true way of doing it.

1:44:31 And we'll see this as we go into 3D games and things later.

1:44:35 But, so the scrolling,

1:44:36 the first set of scrolling tricks that I got was the hardware

1:44:41 had this ability to, you could shift like inside the window of memory.

1:44:46 So, the EGA cards at the time had 256 kilobytes of memory.

1:44:51 And it was awkwardly set up in this planer

1:44:55 format where instead of having 256 or 24 million colors,

1:45:00 you had 16 colors, which is four bits.

1:45:03 So you had four bit planes, 64K a piece.

1:45:06 Of course 60 4K is a nice round number for 16 bit of dressing.

1:45:10 So, your graphics card had a 16 bit window that you could look

1:45:15 at and you could tell it to start the video scan out anywhere inside there.

1:45:18 So, there were a couple games that had taken this approach.

1:45:22 If you could make a two by two screen or a one by four screen and you could

1:45:26 do scrolling really easily like that, you could just

1:45:28 lay it all out and just pan around there,

1:45:31 but you just couldn't make it any bigger,

1:45:32 because that's all the memory that was there.

1:45:34 The first insight to the scrolling that I had was,

1:45:38 well, if we make a screen that's just one tile larger,

1:45:42 and we usually had tiles that were 16 pixels by 16 pixels,

1:45:45 the little classic Mario block that you run into, lots of art

1:45:49 gets drawn that way and your screen is a certain number of tiles.

1:45:52 But if you had one little buffer region outside of that, you could

1:45:57 easily pan around inside that 16 pixel region that could be perfectly smooth.

1:46:01 But then what happens if you get to the edge and you want to keep going?

1:46:06 The first way we did scrolling was what I call the adaptive tile refresh,

1:46:10 which was really just a matter of you get to the edge and then you

1:46:14 go back to the original point and then only change the tiles that have actually,

1:46:19 that are different between where it was.

1:46:21 In most of the games at the time if you think about sort of your classic,

1:46:25 Super Mario Brothers game, you've got big fields of blue sky,

1:46:29 long rows of the same brick texture and there's a lot of commonality.

1:46:34 It's kind of like a data compression thing.

1:46:36 If you take the screen and you set it down on top of each other,

1:46:40 in general, only about 10% of the tiles were actually different there.

1:46:45 So, this was a way to go ahead and say, well,

1:46:48 I'm gonna move it back and then I'm only going to change those 10,

1:46:51 20, whatever percent tiles there.

1:46:54 And that meant that it was essentially five times

1:46:57 faster than if you were redrawing all of the tiles.

1:46:59 And that worked well enough for us to do a bunch of these games for Gamers Edge,

1:47:04 we had a lot of these scrolling games,

1:47:06 like slurred acts and shadow nights and things like that, that we were

1:47:09 cranking out at this high rate that had this scrolling effect on it.

1:47:13 And it worked well enough.

1:47:14 There were design challenges there where if you made the worst case,

1:47:18 if you made a checkerboard over the entire screen,

1:47:20 you scroll over one and every single tile changes

1:47:23 and your frame rates now five frames per second,

1:47:25 because it had to redraw everything.

1:47:27 So, the designers had a little bit that they had to worry about,

1:47:29 they had to make these relatively plain looking levels,

1:47:32 but it was still pretty magical.

1:47:34 It was something that we hadn't seen before.

1:47:36 And the first thing that we wound up doing with that was,

1:47:41 I had just gotten this working and Tom Hall was sitting there with me and we

1:47:46 were looking over at our Super Nintendo

1:47:49 on the side there with Super Mario three running, and we had the technology,

1:47:54 we had the tools set up there and we stayed up all

1:47:57 night and we basically cloned the first level of Super Mario Brothers.

1:48:01 Performance wise as well?

1:48:02 Yeah and so and we had our little character running and jumping in there.

1:48:06 It was close to pixel accurate as far as all of the backgrounds and everything,

1:48:11 but the gaming was just stuff that we

1:48:13 cobbled together from previous games that I had written.

1:48:15 I just kind of like really kitbashed the whole thing together to make this demo.

1:48:19 And that was one of the rare cases when I said I,

1:48:21 I don't usually do these all night programming things.

1:48:24 There's probably only two memorable ones that I can think about.

1:48:28 One was the all-nighter to go ahead and to get

1:48:31 our Dangerous Dave in copyright infringement is how we titled it,

1:48:35 because we had a game called Dangerous Dave,

1:48:37 which was running around with the shotgun shooting things.

1:48:39 And we were just taking our most beloved game at the time there,

1:48:43 the Super Mario Three,

1:48:44 and sort of sticking Dave inside that with this new scrolling

1:48:48 technology that was going perfectly smooth for him as it ran.

1:48:54 And Tom and I just kind of literally the next morning,

1:48:57 kind of left and we left a disc on the desk

1:49:01 for John Romero and Jay Wilbur to see and just said, run this.

1:49:05 And we eventually made it back in later in the day.

1:49:08 And it was, like they grabbed us and pulled us in pulled us into the room.

1:49:13 And that was the point where they were like, we gotta do something with this.

1:49:17 We're gonna make a company, we're gonna go make our own games.

1:49:21 Where this was something that we were able to just kind

1:49:24 of hit them with a hammer of an experience like, "Wow,

1:49:26 this is just like so much cooler than

1:49:29 "what we thought was possible there." And initially

1:49:32 we tried to get Nintendo to let us make Super Mario three on the PC.

1:49:36 That's really what we wanted to do.

1:49:37 We were like, "Hey, we can finish this.

1:49:40 "It's line of sight for this'll be great."

1:49:42 And we sent something to Nintendo and we

1:49:45 heard that it did get looked at in Japan

1:49:48 and they just weren't interested in that.

1:49:50 But that's another one of those life could have gone a very different

1:49:53 way where we could have been like Nintendo's House PC team at that point.

1:49:59 And to find the direction of Wolfenstein and Doom

1:50:04 and Quake could have been a Nintendo creation.

1:50:09 Yeah, so at the same time that we were just doing our first scrolling demos,

1:50:13 we reached out to Scott Miller at Apogee and said, it's like,

1:50:18 "Hey, we do wanna make some games." These things that you think you want,

1:50:21 those are nothing, what do you see what we can actually do now?

1:50:24 This is gonna be amazing.

1:50:26 And he just like popped right up and sent a check to us

1:50:29 where we at that point we still thought he might be a fraud,

1:50:32 that he was just lying about all of this.

1:50:34 But he was totally correct on how much

1:50:36 money he was making with his shareware titles.

1:50:39 And this was his kind of real brainstorm about this, where

1:50:43 Shareware was this idea that software doesn't have a fixed price.

1:50:47 If you use it, you send outta the goodness

1:50:49 of your heart some money to the creator.

1:50:51 And there were a couple utilities that did make some significant

1:50:54 success like that, but for the most part it didn't really work.

1:50:58 Now, there wasn't much software in a pure shareware model that was successful.

1:51:03 The Apogee innovation was to take something,

1:51:07 call it shareware, split it into three pieces.

1:51:10 You always made a trilogy and you would put the first piece out,

1:51:14 but then you buy the whole trilogy for some shareware amount, which in reality,

1:51:19 it meant that the first part was a demo where you kind of like

1:51:22 the demo went everywhere for free and you paid money to get the whole set,

1:51:26 but it was still played as shareware.

1:51:28 And we were happy to have the first one go everywhere.

1:51:31 And it wasn't a crippled demo where the first episode of all of these trilogies,

1:51:35 it was a real complete game and probably 20 times as many

1:51:38 people played that part of it thought they had a great game,

1:51:41 had found fond memories of it but never paid us a dime.

1:51:45 But enough people were happy with that, where it was really quite successful.

1:51:50 And these early games that we didn't think

1:51:52 very much of, compared to commercial quality games,

1:51:55 but they were doing really good business,

1:51:57 some fairly crude things and people, it was good business people enjoyed it.

1:52:02 And it wasn't like you were taking a crapshoot on what you were getting.

1:52:05 You just played a third of the experience and you

1:52:08 loved it enough to hand write out a check

1:52:10 and put it in an envelope and address it and send

1:52:13 it out to Apogee to get the rest of them.

1:52:16 So, it was a really pretty feel

1:52:19 good business prospect there because everybody was happy,

1:52:22 they knew what they were getting when they send it in.

1:52:26 And they would send in fan mail if you're going

1:52:27 into the trouble of addressing a letter and filling out an envelope,

1:52:31 you write something in it.

1:52:32 And there were just the literal bags of fan mail for the shareware games.

1:52:37 So, people loved them.

1:52:39 I should mention that for you,

1:52:41 the definition of wealth is being able to have pizza whenever you want.

1:52:46 For me, there was a dream, because I would play shareware games over and over,

1:52:51 the part that's free over and over.

1:52:53 And it was very deeply fulfilling experience.

1:52:56 But, I dreamed of a time when I could actually afford the full experience.

1:53:02 And this is kind of this dream land beyond

1:53:05 the horizon where you could find out what else is there.

1:53:09 In some sense, even just playing the shareware was,

1:53:15 it's the limitation of that, life is limited, eventually all die.

1:53:21 In that way, shareware was like somehow really fulfilling to have

1:53:27 this kind of mysterious thing beyond what's free always there.

1:53:32 It's kind of, I don't know,

1:53:33 maybe it's because a part of my childhood is playing shareware games.

1:53:37 That was a really fulfilling experience.

1:53:39 It's so interesting how that model still brought joy to so many people.

1:53:44 20x people that played it.

1:53:45 Yeah, I felt very good about that.

1:53:46 And I would run into people, it's like that would say, oh,

1:53:49 I loved that game, that you had early on Commander Keen whatever.

1:53:53 And they meant just the first episode that they got to see everywhere.

1:53:58 That's me, I played the crap outta Commander Keen.

1:54:01 And that was all good.

1:54:03 Yeah, yeah.

1:54:04 But so we were in this position where Scott Miller

1:54:06 was just fronting us cash saying, yeah, make a game.

1:54:10 But we did not properly pull the trigger and say, "All right,

1:54:14 we're quitting our jobs." We were like, we're gonna do both.

1:54:17 We're gonna keep working at Soft Disc working on this and then we're going

1:54:22 to go ahead and make a new game for Apogee at the same time.

1:54:26 And this eventually did lead to some legal problems and we had trouble.

1:54:31 It all got worked out in the end, but it was not a good call at the time there.

1:54:36 And your legal mind at the time was not stellar.

1:54:39 You were not thinking in terms in legal terms.

1:54:42 No, I definitely wasn't.

1:54:44 None of us were.

1:54:45 And in hindsight, yeah,

1:54:47 it's like how did we think we were gonna get away with like

1:54:49 even using our work computers to write software for our breakaway new company.

1:54:56 It was not a good plan.

1:54:58 How did Commander Keen come to be?

1:55:01 So, the design process,

1:55:02 we would start from, we had some idea of what we wanted to do.

1:55:05 We wanted to do a Mario-like game.

1:55:08 It was gonna be a side scroller, it was gonna use the technology.

1:55:11 We had some sense of what it would have to look like,

1:55:14 because of the limitations of this adaptive tile refresh technology.

1:55:17 It had to have fields of relatively constant tiles.

1:55:21 You couldn't just paint up a background and then move that around.

1:55:25 The early design or all the design for Commander Keen really

1:55:28 came from Tom Hall where he was kind of the main

1:55:33 creative mind for the early id Software stuff where we had

1:55:37 an interesting division of things where Tom was all creative in design.

1:55:42 I was all programming,

1:55:43 John Romero was an interesting bridge where he was both a very good programmer

1:55:47 and also a very good designer and artist

1:55:50 and kind of straddled between the areas.

1:55:52 But Commander Keen was very much Tom Hall's

1:55:55 baby and he came up with all the design

1:55:57 and backstory for the different things of kind

1:56:00 of, a mad scientist little kid with I am,

1:56:04 building a rocket ship and a zap gun and visiting alien worlds and doing

1:56:09 all of this that the background that we lay the game inside of.

1:56:13 And there's not a whole lot to any of these things.

1:56:16 Design for us was always just what we needed to do

1:56:19 to make the game that was gonna be so much fun to play.

1:56:23 And we made our, we laid out our first trilogy of games, the shareware formula.

1:56:27 It was gonna be three pieces.

1:56:29 We would make Commander Keen one, two, and three.

1:56:31 And we just really started busting on all that work.

1:56:35 And it went together really quickly.

1:56:37 It was like three months or something that while

1:56:40 we were still making games every month for Gamers' Edge,

1:56:43 we were sharing technology between that.

1:56:45 I'd write a bunch of code for this and we'd just kind of use it for both.

1:56:48 Again, not a particularly good idea there that had consequences for us.

1:56:53 But in three months we got our first game out and all of a sudden

1:56:58 it was three times as successful

1:57:00 as the most successful thing Apogee had had before.

1:57:03 And we were making like $30,000 a month,

1:57:05 immediately from the Commander Keen stuff.

1:57:09 And that was again, a surprise to us.

1:57:11 It was more than we thought that was gonna make.

1:57:15 And we said, well, we're gonna certainly

1:57:17 roll into another set of titles from this.

1:57:19 And in that three months, I had come up with a much better way of doing

1:57:23 the scrolling technology that was not the adaptive tile refresh,

1:57:27 which in some ways was even simpler.

1:57:29 And these things, so many of the great ideas

1:57:32 of technology are things that are back of the envelope designs.

1:57:36 I make this comment about modern machine learning where all

1:57:39 the things that are really important practically in the last decade are,

1:57:42 each of them fits on the back of an envelope.

1:57:44 There are these simple little things,

1:57:46 they're not super dense, hard to understand technologies.

1:57:51 And so the second scrolling trick was just a matter of like, okay,

1:57:55 we know we've got this 64K window and the question was always like,

1:58:00 well you could make a two by two but you can't go off the edge.

1:58:04 But I finally asked, well what actually happens if you just go off the edge?

1:58:09 If you take your start and you say it's like, okay, I can move over.

1:58:13 I'm scrolling, I can move over, I can move down.

1:58:15 I'm scrolling.

1:58:16 I get to what should be the bottom of the memory window?

1:58:19 It's like, well what if I just keep going and I

1:58:22 say I'm gonna start at, what happens if I start at FFFE

1:58:26 at the very end of the 64K block and it turns

1:58:29 out it just wraps back around to the top of the block.

1:58:33 And I'm like, "Oh well this makes

1:58:35 everything easy." You can just scroll the screen

1:58:37 everywhere and all you have to draw is just one new line of tiles,

1:58:40 which everything you expose,

1:58:42 it might be unaligned off various parts of the screen memory, but it just works.

1:58:48 That no longer had the problem of, you had to have fields of the similar colors,

1:58:52 because it doesn't matter what you're doing,

1:58:54 you could be having a completely unique world and you're

1:58:57 just drawing the new strip as it comes on.

1:58:59 But it might be like you said unaligned, so it can be all over the place.

1:59:03 Yeah and it turns out it doesn't matter.

1:59:04 I would have two page flipped screens.

1:59:06 As long as they didn't overlap,

1:59:07 they moved in series through this two dimensional window of graphics.

1:59:12 And that was one of those like, well this is so simple, this just works.

1:59:17 It's faster there.

1:59:19 It seemed like there was no downside.

1:59:21 Funny thing was, it turned out after we shipped titles

1:59:25 with this, there were what they called super VGA cards,

1:59:29 the cards that would allow higher resolutions

1:59:31 and different features that the standard ones didn't.

1:59:35 And on some of those cards, this was a weird compatibility quirk again,

1:59:40 because nobody thought this was not what it was designed to do.

1:59:43 And some of those cards had more memory,

1:59:45 they had more than just 256K in four planes.

1:59:48 They had five 12K or a megabyte.

1:59:51 And on some of those cards, I scroll my window down and then it

1:59:56 goes into initialized memory that actually exists there,

1:59:59 rather than wrapping back around to the top.

2:00:01 And then I was in the tough position of, do

2:00:04 I have to track every single one of these?

2:00:06 And it was a madhouse back then with, there were 20 different

2:00:09 video card vendors with all slightly

2:00:11 different implementations of their non-standard functionality.

2:00:14 So, either I needed to natively program all of the VGA cards there

2:00:20 to map in that memory and keep scrolling down through all of that.

2:00:24 Or I kind of punted and took the easy solution

2:00:27 of when you finally did run to the edge of the screen,

2:00:30 I accepted a hitch and just copied the whole screen up there.

2:00:33 So, on some of those cards, it was a compatibility mode.

2:00:38 In the normal ones, when it all worked fine,

2:00:40 everything was just beautifully smooth.

2:00:42 But if you had one of those cards where it did

2:00:44 not wrap the way I wanted it to, you'd be scrolling around,

2:00:48 scrolling around and then eventually you'd have a little hitch

2:00:50 where 200 milliseconds or something that was not super smooth.

2:00:54 Yeah, it froze a little bit.

2:00:55 And it's a binary thing.

2:00:57 Is it one of the standard screens or is it one of the weird ones?

2:01:00 The super VGA ones.

2:01:02 Yeah.

2:01:02 Okay.

2:01:03 And so we would default to, and I think that was one of those that changed,

2:01:06 over the kind of course of deployment where early on we

2:01:09 would have a normal mode and then you would enable

2:01:12 the compatibility flag if your screen did this crazy flickery

2:01:15 thing when you got to a certain point in the game.

2:01:18 And then later I think it probably got enabled

2:01:20 by default as just more and more of the cards.

2:01:23 It kind of did not do exactly the right thing.

2:01:26 And that's the two-edged sword of doing unconventional

2:01:28 things with technology where you can find something

2:01:31 that nobody thought about doing that kind

2:01:33 of scrolling trick when they set up those cards.

2:01:36 But the fact that nobody thought that was the primary reason when I was

2:01:39 relying on that, then I wound up being broken on some of the later cards.

2:01:44 Let me take a bit of a tangent,

2:01:45 but ask you about the hacker ethic, 'cause you mentioned shareware,

2:01:51 it's an interesting world, the world of people that make money,

2:01:56 the business and the people that build systems, the engineers.

2:02:02 And what is the hacker ethic?

2:02:05 You've been a man of the people and you've

2:02:08 embodied at least the part of that ethic.

2:02:12 What does it mean?

2:02:13 What did it mean to you at the time?

2:02:14 What does it mean to you today?

2:02:16 So, Stephen Levy's book "Hackers" was a really

2:02:18 formative book for me as a teenager.

2:02:21 I mean I read it several times and there was all

2:02:24 of the great lore of the early MIT era of hackers and ending up

2:02:29 at the end with, it kind of went through the early MIT hackers

2:02:34 and then the Silicon Valley hardware hackers

2:02:36 and then the game hackers in part three.

2:02:39 And at that time as a teenager, I really was kind of bitter in some ways.

2:02:44 Like I thought I was born too late,

2:02:46 I thought I missed the window there and I really thought I

2:02:50 belonged in that third section of that book with the game hackers.

2:02:53 And they were talking about the Williams

2:02:56 at Sierra and Origin Systems with Richard Garriott,

2:02:58 and it's like, I really wanted to be there.

2:03:02 And I knew that was now a few years in the past it, it was not to be,

2:03:08 but the early days, especially the early MIT hacker days,

2:03:12 talking a lot about this sense of the hacker ethic,

2:03:16 that there was this sense that it was about sharing information, being good,

2:03:20 not keeping it to yourself and that it's not a zero sum game that you

2:03:25 can share something with another programmer

2:03:28 and it doesn't take it away from you.

2:03:30 You then have somebody else doing something.

2:03:33 And I also think that there's an aspect

2:03:35 of it where it's this ability to take joy

2:03:39 in other people's accomplishments where it's not the cutthroat

2:03:42 bit of like I have to be first,

2:03:44 I have to be recognized as the one that did this in some way.

2:03:48 But being able to see somebody do something and say, "Holy shit,

2:03:52 that's amazing." And just taking joy in the ability

2:03:55 of something amazing that somebody else does.

2:03:58 And the big thing that I was able to do through id Software was this ability

2:04:05 to eventually release the source code for most

2:04:07 of our, like all of our really seminal game titles.

2:04:10 And that was a, it was a stepping stone process where we were

2:04:14 kind of surprised early on where people were able to hack the existing games.

2:04:19 And of course I had experience with that.

2:04:21 I remember hacking my copies of Ultima, so I'd give myself,

2:04:24 9999 gold and raise my levels and break out the sector editor.

2:04:29 And so I was familiar with all of that.

2:04:31 So, it was just, it was with a smile when

2:04:33 I started to see people doing that to our games.

2:04:35 Making level editors for Commander Keen or hacking up Wolfenstein 3D but I made

2:04:43 the pitch internally that we should actually release

2:04:46 our own tools for like what we did, what we used to create the games.

2:04:51 And that was a little bit debatable about well, we'll give people a leg up.

2:04:57 It's always like, what's that gonna mean for the competition?

2:05:00 [Lex] Yeah.

2:05:01 But the really hard pitch was to actually

2:05:04 release the full source code for the games

2:05:06 and it was a balancing act with the other people inside the company where,

2:05:11 it's interesting how the programmers, generally did get,

2:05:17 certainly the people that I worked closely with, they did kind

2:05:21 of get that hacker ethic bit where you wanted to share your code,

2:05:24 you were proud of it,

2:05:25 you wanted other people to take it and do cool things with it.

2:05:28 But interestingly, the broader game industry

2:05:33 is a little more hesitant to embrace

2:05:36 that than like the group of people that we happen to have at id Software.

2:05:40 Where it was always a little interesting to me,

2:05:42 seeing how a lot of people in the game

2:05:45 modding community were very possessive of their code.

2:05:47 They did not want to share their code,

2:05:49 they wanted it to be theirs, it was their claim to fame.

2:05:52 And that was much more like what we tended to see with artists where

2:05:56 the artists understand something about credit and wanting

2:05:59 it to be known as their work.

2:06:02 And a lot of the game programmers, felt a little bit more like artists than

2:06:07 like hacker programmers in that it was about

2:06:10 building something that maybe felt more like art

2:06:12 to them than the more tool-based and exploration-based,

2:06:16 kind of hacking culture side of things.

2:06:19 Yeah.

2:06:19 So, it's so interesting that this kind of fear

2:06:23 that credit will not be sufficiently attributed to you.

2:06:28 And that's one of the things that I do bump into a lot,

2:06:30 because I try not to go clean.

2:06:34 I mean, it's easy for me to say,

2:06:35 because so much credit is heaped on me for the the id Software side of things.

2:06:39 But when people come up and they want to pick a fight and say no,

2:06:42 it's like that wasn't where first person gaming came from.

2:06:45 And you can point to some of like things on obscure

2:06:49 titles that I was never aware of or like the old

2:06:52 Plato systems or each personal computer had something that was 3D-ish

2:06:57 and moving around and I'm happy to say it's like no,

2:07:00 I mean I saw Battle Zone and Star Wars in the arcades.

2:07:03 I had seen 3D graphics, I had seen all these things that I'm

2:07:06 standing on the shoulders of lots of other people,

2:07:09 but sometimes these examples they pull out,

2:07:10 it's like, "Nah, I didn't know that existed." I mean there,

2:07:13 I had never heard of that before then that didn't contribute to what I made.

2:07:17 But there's plenty of stuff that did.

2:07:19 And I think there's good cases to be made that obviously Doom and Quake

2:07:25 and Wolfenstein were were formative examples

2:07:27 for what everything that came after that.

2:07:31 But I don't feel the need to go fight

2:07:34 and say claim primacy or initial invention of anything like that.

2:07:38 But a lot of people do want to.

2:07:40 I think when you fight for the credit

2:07:42 in that way and it does go against the hacker ethic,

2:07:45 you destroy something fundamental about the culture,

2:07:48 about the community that builds cool stuff.

2:07:51 I think credit ultimately,

2:07:55 I had this sort of, there's a famous wrestler and freestyle wrestling,

2:08:00 called Tatsuhiro Saito,

2:08:03 and he always preached that you should just focus on the art

2:08:08 of the wrestling and let people write your story however they want.

2:08:16 Te highest form of the art is just focusing on the art.

2:08:20 And that's something that is something,

2:08:22 about the hacker ethic is just focused on building cool stuff,

2:08:26 sharing it with other cool people and credit will

2:08:30 get assigned correctly in the long arc of history.

2:08:37 Yeah.

2:08:38 And I generally think that's true and you've got,

2:08:40 like there's some things there's,

2:08:43 there's the graphics technique that got labeled CarMax Reverse,

2:08:46 literally named and it turned out that I

2:08:49 wasn't the first person to figure that out.

2:08:51 Like most scientific things or mathematical things, you wind up, it's like,

2:08:55 "Oh this other person had actually done that, "somewhat

2:08:57 before." And then there's things that get attributed to me,

2:09:00 like the inverse square root hack that I actually didn't do.

2:09:03 I flat out that wasn't me.

2:09:04 And it's like, it's weird how the mimetic power of the internet.

2:09:07 I cannot convince people of that, yes.

2:09:12 It's just everything just gets attributed to you now,

2:09:14 even though you've never sought the credit of things.

2:09:17 I mean, but part of the fact

2:09:19 that humility behind that is what attracts the attributions.

2:09:25 Let's talk about a game, to me one of the greatest games ever made.

2:09:29 I know you could talk about Doom and Quake

2:09:30 and so on, but to me Wolfenstein 3D was like,

2:09:33 whoa, it blew my mind that that world like this could exist.

2:09:38 So, how did Wolfenstein 3D come to be in terms of the programming,

2:09:43 in terms of the design, in terms of some of the memorable

2:09:46 technical challenges And also actually just something

2:09:49 you haven't mentioned is how do these ideas come to be inside your mind,

2:09:58 the adaptive side scrolling.

2:10:00 So, the solutions to these technical challenges.

2:10:03 So, I usually can introspectively pull back,

2:10:06 pretty detailed accounts of how technology solutions

2:10:11 and design choices on my part came to be.

2:10:14 Where technically we had done two games,

2:10:17 3D games like that before where Hover Tank was the first one

2:10:21 which had flat shaded walls but did have the scaled enemies inside it.

2:10:25 And then Catacombs 3D which had textured walls,

2:10:28 scaled enemies and some more functionality,

2:10:34 like the disappearing walls and some other stuff.

2:10:37 But what's really interesting from a game

2:10:39 development standpoint is those games Catacombs 3D, Hover Tank and Wolfenstein,

2:10:45 they literally used the same code for a lot of the character

2:10:50 behavior that a 2D game that I had made earlier called Catacombs did,

2:10:54 where it was an overhead view game, kind of like gauntlet,

2:10:56 you're running around and you can open up doors,

2:10:58 pick up items, basic game stuff.

2:11:01 And the thought was that this exact same

2:11:05 game experience just presented in a different perspective.

2:11:09 It could be literally the same game, just with a different view into it,

2:11:13 would have a dramatically different impact on the players.

2:11:17 So, it wasn't a true 3D, you're saying that you could kind of fake it.

2:11:22 You can like scale enemies,

2:11:24 meaning things that are farther away, you can make 'em smaller.

2:11:27 So, from the game was a 2D map,

2:11:29 like all of our games used the same tool for creation.

2:11:33 We used the same map editor for creating Keen,

2:11:35 as Wolfenstein and Hover Tank and Catacombs and all this stuff.

2:11:39 So the game was a 2D grid made outta blocks and you could say,

2:11:43 well these are walls, these are where the enemies start.

2:11:45 Then they start moving around.

2:11:47 And these early games like Catacombs, you played it strictly in a 2D view.

2:11:51 It was a scrolling 2D view and that was kind of using an adaptive

2:11:54 tile refresh at the time to be able to do something like that.

2:11:57 And then the thought that these early games,

2:12:01 all it did was take the same basic enemy logic,

2:12:04 but instead of seeing it from the god's eye view on top,

2:12:07 you are inside it and turning from side to side yawing

2:12:10 your view and moving forwards and backwards and side to side.

2:12:13 And it's a striking thing where you always talk

2:12:17 about wanting to isolate and factor changes in values.

2:12:20 And this was one of those most pure cases

2:12:22 there where the rest of the game changed very little.

2:12:25 It was our normal kind of change the colors

2:12:27 on something and draw a different picture for it,

2:12:29 but it's kind of the same thing.

2:12:30 But the perspective changed in a really

2:12:33 fundamental way and it was dramatically different.

2:12:36 I can remember the reactions where the artist

2:12:40 Adrian that had been drawing the pictures for it,

2:12:42 we had a cool big troll thing in Catacombs 3D and we had these walls

2:12:46 that you could get a key and you

2:12:48 could make the blocks disappear and really simple stuff,

2:12:51 blocks could either be there or not there.

2:12:52 So, our idea of a door was being able to make a set of blocks just disappear.

2:12:57 And I remember the reaction where he had drawn these characters and he

2:13:00 was slowly moving around and like people had no experience with 3D navigation,

2:13:04 it was all still keyboard.

2:13:05 We didn't even have mice set up at that time.

2:13:08 But slowly moving, going up, picked up a key, go to a wall,

2:13:12 the wall disappears in a little animation

2:13:14 and there's a monster like right there.

2:13:16 And he practically fell out of his chair.

2:13:18 It was just like, ah.

2:13:19 And games just didn't do that.

2:13:22 The games were the god's eye view.

2:13:24 You were a little invested in your little guy,

2:13:26 you can be like happy or sad when things happen,

2:13:29 but you just did not get that of startle reaction.

2:13:32 You weren't inside your game.

2:13:34 Something in the back of your brain.

2:13:35 Some reptile brain thing is just going, "Oh,

2:13:38 shit something just happened." And that was

2:13:40 one of those early points where it's like,

2:13:42 yeah, this is gonna make a difference.

2:13:44 This is going to be powerful and it's gonna matter.

2:13:47 Were you able to imagine that in the idea stage or no?

2:13:51 So not that exact thing.

2:13:53 So again, we had cases like the arcade games,

2:13:56 Battle Zone and Star Wars that you could kind of see a 3D

2:13:59 world and things coming at you and you get some sense of it.

2:14:03 But nothing had done the kind of worlds that we

2:14:06 were doing and the sort of action based things.

2:14:08 3D at the time was really largely about the simulation thoughts.

2:14:13 And this is something that, really might have trended differently if not

2:14:18 for the id Software approach in the games where there were flight simulators,

2:14:23 there were driving simulators, you had like hard drive in and Microsoft

2:14:27 Flight Simulator and these were doing 3D and general

2:14:30 purpose 3D and ways that were more flexible

2:14:33 than what we were doing with our games.

2:14:35 But they were looked at as simulations.

2:14:38 They weren't trying to necessarily be fast or responsive

2:14:42 or letting you do kind of exciting maneuvers,

2:14:44 because they were trying to simulate reality and they

2:14:47 were taking their cues from the big systems,

2:14:49 the Evans and Sutherlands and the Silicon Graphics that were doing things.

2:14:52 But we were taking our cues from the console and arcade games,

2:14:56 we wanted things that were sort of quarter eaters that were

2:15:00 doing fast paced things that you could smack you around,

2:15:02 rather than just smoothly gliding you from place to place.

2:15:06 So, quarter years.

2:15:08 And a funny thing is, so much that that built into us that Wolfenstein,

2:15:13 still had lives and you had like one

2:15:15 of the biggest power ups in all these games, like was an extra life,

2:15:18 because you started off with three lives and you lose your lives and then

2:15:22 it's game over and there weren't save games in most of this stuff.

2:15:26 It sounds almost crazy to say this, but it

2:15:29 was an innovation in Doom to not have lives.

2:15:32 You could just play doom as long as you wanted.

2:15:33 You just restart at the the start of the level and why not?

2:15:36 This is like we aren't trying to take people's quarters,

2:15:39 they've already paid for the entire game.

2:15:41 We want them to have a good time and you would have some,

2:15:45 some old timer purists that might think that there's something

2:15:47 to the epic journey of making it to the end, having to restart all the way

2:15:51 from the beginning after a certain number of tries.

2:15:53 But now more fun is had when you just let people kind of keep trying

2:15:57 when they're stuck rather than having to go

2:15:58 all the way back and learn different things.

2:16:02 So, you've recommended the book,

2:16:03 "Game Engine Black Book Wolfenstein 3D" for technical exploration of the game.

2:16:07 So looking back 30 years,

2:16:10 what are some memorable technical innovations that made this perspective shift

2:16:15 into this world that's so immersive that scares you when a monster appears?

2:16:20 What were some things you had to solve?

2:16:22 So, one of the interesting things that come

2:16:24 back to the theme of deadlines and resource constraints,

2:16:27 the game Catacombs 3D we shipped,

2:16:32 we were supposed to be shipping this for Gamers'

2:16:33 Edge on a monthly cadence and I had slipped,

2:16:36 I was actually late, it slipped like six weeks,

2:16:39 because this was texture mapped walls doing stuff that I hadn't done before.

2:16:44 And at the six week point, it was still kind of glitchy and buggy.

2:16:48 There were things that I knew that if you

2:16:51 had a wall that was like almost edge on, you

2:16:53 could slide over to it and you could see

2:16:55 some things freak out or vanish or not work.

2:16:57 And I hated that, but I was up against the wall.

2:17:01 We had to ship the game.

2:17:03 It was still a lot of fun to play.

2:17:04 It was novel, nobody had seen it.

2:17:05 It gave you that startle reflex reaction.

2:17:09 So, it was worth shipping, but it had these things that I knew were kind

2:17:13 of flaky and janky and not what I was really proud of.

2:17:17 So, one of the things that I did very differently in Wolfenstein, I was went,

2:17:24 Catacombs used almost a conventional thing where you

2:17:27 had segments that were one dimensional polygons basically,

2:17:30 that were clipped and back faced and done kind

2:17:34 of like a very crude 3D engine from the professionals.

2:17:37 But I wasn't getting it done right.

2:17:39 I was not doing a good enough job.

2:17:41 I didn't really have line of sight to fix it, right?

2:17:45 There's stuff that of course I look back, it's like,

2:17:47 oh it's obvious how to do this and do the math right?

2:17:49 Do your clipping right, check all of this, how you handle the precision.

2:17:53 But I did not know how to do that at that time.

2:17:56 Was that the first 3D engine you wrote Catacombs 3D?

2:17:59 And Hover Tank had been a little bit

2:18:00 before that, but that had the flat shaded walls.

2:18:02 So the texture mapping on the walls was

2:18:04 what was bringing in some of these challenges.

2:18:06 That was hard for me and I couldn't solve it right at the time.

2:18:11 Can you describe what flat shading is and texture mapping?

2:18:13 So, the walls were solid color, one of 16 colors in Hover Tank.

2:18:19 So, that's easy, it's fast.

2:18:20 You just draw the solid color for everything.

2:18:23 Texture mapping is what we all see today where you have an image

2:18:26 that is stretched and distorted onto the walls

2:18:29 or the surfaces that you're working with.

2:18:31 And it was a long time for me to just

2:18:34 figure out how to do that without it distorting

2:18:37 in the wrong ways and I did not get it

2:18:40 all exactly right in Catacombs and I had these flaws.

2:18:44 So, that was important enough to me that rather than continuing to bang

2:18:48 my head on that when I wasn't positive I was gonna get it,

2:18:51 I went with a completely different approach for drawing,

2:18:54 for figuring out where the walls were,

2:18:56 which was a ray casting approach, which I had done in Catacombs 3D,

2:19:00 I had a bunch of C code trying

2:19:02 to make this work right and it wasn't working right.

2:19:05 In Wolfenstein, I wound up going to a very small amount of assembly code.

2:19:11 So, in some ways this should be a slower way of doing it,

2:19:14 but by making it a smaller amount of work

2:19:16 that I could more tightly optimize, it worked out.

2:19:19 And Wolfenstein 3D was just absolutely rock solid.

2:19:22 It was nothing glitched in there.

2:19:25 The game just was pretty much through all of that and I was super proud of that.

2:19:29 But eventually, like in the later games, I went back to the more span based

2:19:35 things where I could get more total efficiency,

2:19:37 once I really did figure out how to do it.

2:19:40 So, there were two sort of key technical things to Wolfenstein.

2:19:43 One will this ray casting approach, which you still to this day,

2:19:47 you see people go and say let's write a ray casting engine because it's

2:19:51 an understandable way of doing things that lets

2:19:53 you make games very much like that.

2:19:55 So, you see ray casters in JavaScript, ray casters in Python,

2:19:58 people that are basically going and reimplementing that approach

2:20:03 to taking a tiled world and casting out into it.

2:20:06 It works pretty well, but it's not the fastest way of doing it.

2:20:09 Can you describe what ray casting is?

2:20:11 So you start off and you've got your screen,

2:20:13 which is 320 pixels across at the time if

2:20:16 you haven't sized down in the window for greater speed.

2:20:19 And at every pixel there's gonna be an angle

2:20:22 from, you've got your position in the world

2:20:24 and you're gonna just run along that angle and keep going until you hit a block.

2:20:28 So, up to 320 times across there, it's gonna throw a cast array out

2:20:34 into the world from wherever your origin is until it

2:20:37 runs into a wall and then it can figure out exactly where on the wall it hits.

2:20:42 The performance challenge of that is as it's

2:20:44 going out every block it's crossing it checks, is this a solid wall?

2:20:49 So, that means that in like the early Wolfenstein levels,

2:20:52 you're in a small jail cell going out into a small hallway,

2:20:55 it's super efficient for that, because you're

2:20:57 only stepping across three or four blocks.

2:21:00 But then if somebody makes a room that covers,

2:21:02 our maps we're limited to 64 by 64 blocks.

2:21:05 If you made one room that was nothing but walls at the far space,

2:21:09 it would go pretty slow,