CoRecursive: Coding Stories - Story: Video Game Programming From Scratch

Episode Date: March 1, 2021

I'm not really a big gamer, but lately, I've fallen down this rabbit hole into the world of Casey Muratori, and this project that he started on Twitch in 2014. He is building a video game from scratch and explaining it all as he goes along. Casey is a professional video game and game engine, creator. He has been doing it for over 30 years. His approach to development feels a little bit like it's from the 1970s. Yet, it resonates with many smart people who are learning how to truly build things and understand fundamentals from Casey. Casey has a lesson about learning and teaching for us all.   Episode Page

Hello and welcome to Co-Recursive. I'm Adam Gordon-Bell. I'm trying to find and share the personal experiences of building software. I'm not really a big gamer, but lately I fell down this rabbit hole into the world of Casey Miratori and this project that he started on Twitch in 2014. The videos are me just programming. They're not even good. I mean, I'll be honest. I'd love to that that they're amazing and that i'm really great but they're not they're they're not they're just all they are is a regular programmer you know who who does actual real programming work right and so it kind of just ended up taking on a life of its own casey's game programming videos, they kind of started a movement.

It's a movement that in some ways feels like software development from the 70s, but in other ways, it's totally modern and maybe points towards the future of learning or entertainment. I'm not sure where to start with Casey's story, but the basics of his approach, they date to this job he had in the late 90s.

In 1999, I took a job at Rad Game Tools. I was still a C++ programmer at the time, meaning I was still, like, if I was going to write a matrix multiplication, it would be, like, templatized on the size of the matrix, right? So traditional C++ class hierarchy with inheritance kind of programming. Smart pointers, for example. And one of the things that was cool about Rad Game Tools is it was me and there were two other programmers there. And Rad Game Tools is kind of legendary in that the amount of money they make per programmer is kind of staggering. They were making like millions of dollars a year and they had like, you know, three programmers or something. And not on weird like web laundering of money where you basically like you're, you know, selling ads to people.

Like literally selling software. Like this is like libraries they're selling, right? Right. And so, you know, the two programmers there at the time beside me when I joined were Jeff Roberts, who has literally written the video codec for every game basically in existence, almost in history. Like every game, name a game. The videos play back through something Jeff wrote. Right. From basically the year like 94 to today. Wow. Whatever the latest game is you pick up, its videos are playing back through something Jeff wrote.

And the other programmer was John Miles, who's the guy who wrote the engine for Ultima V way back in the day. He wrote the Miles sound system, which was the sound system used in most DOS games. It was extremely popular, still exists to this day, in fact, and is used by people for sound. Oh, and he also, I think he, I want to say he also wrote the render on Wing Commander 3.

Anyway, so those are two programmers who are there, and they are old school C programmers. And so, you know, here I am looking at this and I'm like, well, these are way better programmers than me, and they don't use any of this stuff. And, you know, I wonder why, right? Like, like, why is it that, you know, you get some programmers who are like literally like some of the best programmers I've ever seen and they don't use any of this stuff. Like, why is that? Right. And not only that, but like, if you take Jeff, for example, it might be argued, he's a programmer who like, as far as the video game world is concerned, I it's it's staggering to think of how many games have

his code in it right because like they all so it's just like looking at how impactful they are and and what amazing stuff they were able to do and it's like why am i using all this stuff am i do i know something they don't? Because that seems unlikely, right? There's a little bit of programmer-y, like, I always know what I'm doing nonsense. And it's like, do you? I mean, why do these other people who are so good not need that thing, right? And so being honest with you, you have to be kind of a little bit introspective and go, like, what's going on here? Did these guys, like, talk to you and say say like, why are you using templates or no?

It was just, I mean, you know, I am always as critical of my own habits as I am of anybody else's. Right. So if I am like aggravated with some piece of software that someone else's, you know, I've had some

famous rants about Visual Studio, for example, and how bad it's gotten. That dialogue, I mean, you might be tempted to think that that is just me complaining about someone else's piece of software. No, that dialogue is happening in my head about my programs all the time. I always think they're terrible, right? And I'm always going like, what could I have done to make this less terrible? And so it only comes out of that. Like it was me just looking and going like, there's probably something to learn here. Like incontrovertible, these guys are better programmers than I am. That's true. So one reason for that could be that

I just suck and I'm never going to get any better. So it doesn't matter. So just keep using C++ and whatever, right? Another possibility is that I could learn to be as good as they are. And I'm just not taking it seriously enough. I'm not trying, right? Yes, I'm trying to program, but I'm not trying to get better, right? And so what are things I can use to get better? Well, I can look at what they are doing and go, what about what I am doing is different and can I assess if any of those are the answer?

Because they might not be, it might be that they just happen to program in C and I happen to program in C++ and they happen to be good and I happen to suck. That's a totally possible, you know, thing that could have happened there. But another thing could be that actually I could be good. I could be writing code as good as they are, but I need to learn what are the things that they know that I don't. What are the practices they have that I don't have, right? And so I

always try to do that as much as I can. If I see something that looks like it's working well or that they're getting something done well, I try to go, how can I reassess what I'm doing to see whether there's something of that that would make a difference for me? Because I want to be better. I don't want to be writing bad code,

but it's not always obvious how to improve. Did you spend time like watching them code? Like not in so many words. You know, I never walked into someone's office and was like, teach me how to program. But I tried to say, like, what are the things I could do that would assess sort of my own practices in light of the fact that I kind of have some good examples just sitting here because typically like watching a programmer program at that time would have been kind of creepy like yeah I'd be like you know like sitting it'll be like Kilroy was here like I'm peeking up over the chair like a little Casey head like pops up you know so what

I did was I was in charge of a character animation system and i wrote the first version and it sucked and i was going to write the second version as like you know let me try because i started programming c not c++ and i had become a c++ program it's like let me try just going back to c because obviously i know how to do it because i so i used to program in let me try going back to c and what i'm going to do is i'm only ever going to use one of these features in c++ if i actually can demonstrate to myself that it would create a benefit here and what i found was that literally the only two things that were at all useful were operator overloading and function overloading those are the only two things that were at all useful were operator overloading and function overloading

those are the only two everything else i was like yep the code was better without it and so unlike most programmers i actually had the experience of literally taking the time to see do these features actually improve the code or don't they and i could actually test it because i like was fortunate to have the time and control over a project to actually see what happened. And from there, I was just like, you know what? I need to do that for everything.

I need to actually start taking this seriously and stop just assuming that because someone else put something in a language, that it must be good. And when you change your thinking to, I'm going to evaluate rather than I'm going to trust, what you start finding is that most things most people say are mostly wrong. And the reason for that is they kind of have to be because a lot

of them are overlapping. So most of the time you see two different people suggesting two different ways of doing something. Obviously someone's wrong or there isn't a better way to do it. Meaning it doesn't matter which one you pick. Like either somebody was wrong and one of them was the correct way, in which case there was one that you should have rejected, or it doesn't matter which way you do this, in which case they were all wrong for suggesting that you needed to do it this way. And so I think ever since that point in my career, it's been about 20 years since then, I've just always evaluated things as carefully as I could. So I go, when I see a new thing suggested, I go, what does this actually yield? If I look at the difference between doing it this way and doing it in whatever way I would have done it before. And I go, does that result in less lines of code, less bugs, less time, blah, blah, blah. Like I go, can I make an argument along any of these lines?

And what you'll find out if you do this, honestly, is a lot of the stuff is just, it's just a waste of your time. Casey didn't just leave C++ behind. He also nurtured this sort of obscenely DIY development aesthetic that's pretty uniquely his. He doesn't use an IDE, just Emacs. He doesn't use like Make or a Build script. I mean, he doesn't use any libraries. He thinks other people should try this approach.

I think everyone should have the experience of building something from the ground up. Most programmers, no matter what they work on, would benefit greatly from having written one thing from scratch. Meaning, start in a fairly bare language such as C. Don't use the libraries. Just write everything yourself from just basic things. Even better if you want to try assembly language, but assembly language has a bunch of things that you have to do, like register allocation. I'm not sure you get much learning from the extra work that you have to do. So something like C, I find, is a really good language

for doing this kind of experiment because there's so little in it. It's a very sparse language. It just has the few basic things. It translates fairly directly into assembly language. It's easy to go on Godbolt anytime I want to and show someone how C translates to assembly language. It's trivial, right? It's really easy to see.

I think most programmers would benefit greatly from going through that exercise. Pick something simple, a simple web server, like a thing that just like answers non-HTTPS, just HTTP. You can write a simple web server and see in not very many lines of code. If you're a web developer, doing that one time and seeing how it actually works, I think would be greatly educational for a lot of people. Not because I think you should go rewrite your web server and see yourself, because that may be a very bad idea for you.

It's for your understanding. I think it's invaluable to have done at least one project from scratch. Something that's very different from the current aesthetic in the cloud development world that you learn working on a game development tool is that developer ergonomics should take a backseat to performance concerns. Yeah, I think there's a failure to recognize that it's not sufficient to simply serve ourselves is the broadest way to put it.

When you sit down at a computer, your first thought should not be, how do I make my job easier so I can go home earlier today? Right. The thought should be, how do I make the best program for my user? Right. And when we fundamentally start thinking about how do we make it easy, how do we make the easiest possible thing for the programmer to program? And we don't care that the thing that we ship the user is like a hundred times slower than it should be. To me, that's like, in a way, it's almost dishonorable.

It's like, I feel like I'm being dishonorable by thinking primarily about my experience and not about theirs. So eventually, Casey leaves Rad Game Tools. He starts his own thing called Molly Rocket, and he works on some indie games. And then in 2014, something happens. So I'm friends with Jonathan Blow, who is a very famous game designer. He made Braid and The Witness. He's also famously working on a new language right now

called JAI. But he was doing streams on Twitch, the gaming live stream platform, to talk about his ideas for making a programming language way back then. He was like, we need to make a new programming language and I want to talk about some ideas that I have. I'm pretty sure that was the first thing that I saw on Twitch of anyone doing like a programming thing on Twitch. Right. And I liked it and there were other people there who knew who I was the reason for that was because I had worked on the witness with John and I had written some articles like I wrote these things called witness Wednesdays where I talked about some of the code in the Witness and how it worked. I did a bunch of work with collision detection systems

because we were doing some novel stuff there to make it so that you couldn't ever do stuff like fall through the world. I don't know if you've ever seen bugs in video games where people are trying to walk. So we did some pretty novel stuff in that game to make it so that that couldn't happen, so that we had provably secure algorithms

where you couldn't actually have these kind of bugs happen and so i'd written some of that up and i wrote up some other things and blah blah blah so people kind of knew who i was who would have tuned into john's broadcast right it's like we we were sort of linked in that way so when i was on the twitch chat some of the people were asking me like when are you going to do a programming stream? And I was like, I don't know what I would do with a programming stream. Like, I don't know. And so then in my head, I started thinking, I was like, you know, I've always wanted to have a complete recording of making an entire game engine.

Just to watch what happens because when you think back about what happened when you're programming your memory is far from perfect like you compress down things that actually maybe took you quite a bit of time you overemphasize things that maybe didn't take you very much time and so i was just kind of curious to see like what if we just recorded this like would it give us any insight and so i was like oh okay so yeah maybe i'll do this thing where i'll stream just making a game right i'll just make a game and i was thinking like a little tiny game that was just like some sprites on a backdrop or something right like pretty basic and i mean on twitch at that time for a programming stream i mean the viewer count, if you looked in the equivalent of the like programming category, you know, the numbers were like 10 people.

Right. And for whatever reason, and I have no idea what the reason is, the first episode of this thing got like a thousand viewers or something. Oh, wow. So it was like a massive turnout for this thing. That first lesson started with creating a text file called handmade.cpp, opening it in Emacs and compiling it. From there, you know, writing stuff into a buffer and displaying that buffer on a screen.

Casey would live stream building a professional, commercial quality video game from scratch every weeknight for as long as it took until it was done and so it kind of just ended up taking on a life of its own whereas like oh i guess i should start trying to teach like real stuff here to a certain degree and take this more seriously because it's like it seems like this is something that people actually really wanted and i'm surprised even to this day originally i had my email on the handmade hero homepage i received so much email i had to take it down people were just like thank you so much for putting this up like this is so helpful i didn't understand how to do any of this programming

until i watched this this videos like i went through four years at university and I don't feel like I learned anything. I watched these videos and it all clicked for me. And mind you, this is just me. The videos are me just programming. They're not even good. I mean, I'll be honest. I'd love to say that they're amazing and that I'm really great. But they're not. They're not.

They're just, all they are is a regular programmer who does actual real programming work, not a theoretician or somebody who's pie in the sky and talking about, you know, solid principles or whatever people like to theorize about, right? Yeah. All it was was just a regular programmer programming and people being able to see that made all the difference for them Because they're like, oh, I can do that, right? Like, I was having trouble understanding how the Liskov substitution principle comes into play when I need to, like, print out the number five. Hint, it doesn't. Forget about it.

It's irrelevant but um if you just focus on what programming actually is and not all of the crap that people have piled on top of it a lot of people can do it in other words people wanted to know where to start a lot of people love video games and want to build one for themselves so they would tune in on Twitch, there's a chat and people would ask questions. And in true Casey style, he would answer these questions from scratch. So one of the things that people often mention about when they ask a question on one of my programming streams, I think the joke is I always start with the universe cooling down. First, the Big Bang happened. And then I explain from there to the question.

It usually takes like 40 minutes. Someone asks about some CPU thing on a modern x64, and I'm like, well, when you started with an 8-bit CPU, it did this, that, and you could see this here. Let's pull up a diary, right? And so for some reason, I just, by habit, always seem to go back and sweep all the way through the history. I think it might just be how my brain stores things, and it's probably just wasting their time at some level.

But it also helps for doing things like instructional courses, because there you're dealing with beginners, they need the whole thing. So working with a novice, I can be more effective, I think, usually. He also tried to explain the background on whatever was being done that day. If the game requires sound, we need to learn about how waves work. If we need to do rotations, then we better learn some linear algebra. Did I mention he started in 2014? It's

now early 2021, and he's still going. People are following along, and they're building up their own things. They're using him as inspiration for their own games, for their own programming languages, for their own debuggers. If you pre-order the game, you can get access to GitHub, where there's an annotated version of the source code linking to all the videos. I'm not entirely sure how many hours of content he's produced building this game, but he has about 700 episodes so far, and they range from one to three hours.

So conservatively, there's at least 1500 hours of programming content, which is kind of astounding, right? I do not have 1500 hours of content I can put out that I could teach people. It kind of makes me wonder how Casey learned all this. How did he get started? My dad taught me how to program when I was seven. The way that home computing used to work in those days was that anything that was even remotely considered a home computer had BASIC on it. A lot of times it was built in. So if you think about very popular names of computers from the day, so Commodore 64, Apple II, these computers all had BASIC in the ROM. So meaning when you turn the computer on, you don't have to connect any storage of any kind to it.

The literal ROM chip soldered into this computer has a BASIC interpreter in it. And BASIC, for people who don't know, is the language that looks like, you know, 10 space print quote, hello world, right? That's basic. And so it's definitely, it's a language that's really designed for, you know, people like a seven-year-old like me. It doesn't have hardly any syntax. It looks more like a command prompt than anything else. So, you know, you're, you know, like you can do CD and dir, you can probably put in a crappy little basic program. And so when I was seven, my dad taught me how to do some basic programming. And that's just like, yeah, I mean, you know, you can imagine a seven year old, you can learn to type, you know, print and put in some words and then you, you know, go out and you just type run to run the program or

whatever and it would run and it would type the thing out right and it was a super crappy program it was basically probably just said like print and it printed out like a thing for my mom it said like you know pick one of the following options and you know it had like one two or three and then if you type like one it would print something if you type two it would print something three like that was it but it was you know it has all the things you need to start understanding programming, the ability to like print something out so you know what happened,

the flow control of, you know, going to something based on what the input was, right? And the ability to run the program afterwards and see it happen, that gets you started, right? And I've been programming ever since. Basic was definitely a simpler language and the ability to run the program afterwards and see it happen, that gets you started, right? And I've been programming ever since. Basic was definitely a simpler language than the languages we have today. And Casey thinks this simplicity of this earlier environment,

it just made things easier to learn in a way that people today refuse to acknowledge. If you've grown up your whole life and you learn to program in a simple way at a simple time, I think it can be very hard for people like me, for example, to appreciate just how much garbage today's beginner without a guide would think they had to wade through. Because where do you start? You don't know. If you come at programming today, you don't have a basic interpreter on a commodore 64 or the deck rainbow you don't get introduced to programming's fundamentals let's take a simple example you'd never even hear about go to okay go to considered harmful is just a phrase that we say, right? Yeah. And I'll be completely honest.

I don't use gotos in my codes, and I generally don't think you typically need to use gotos in my code. So I certainly wouldn't sit around going like, oh, woe is me, where hath my goto gone? But a beginner programmer should absolutely start with goto because that's what the cpu is doing if a person fundamentally thinks that programming's actual that what is actually going on in programming is that you can map something over an iterator which is nonsense it does it doesn't exist in

a computer it's a it's a fictional construct we created because we found it convenient, right? It maps to goto. When you look at the assembly language code, there is no map over iterator, right? The assembly language has a jump statement. And so one of the things that I think people don't understand, especially people who didn't have this experience, is that if you never teach someone what a go-to is, they'll go their whole life not understanding how a computer works. It sounds like a joke. But you, I mean, when I see the emails people write me,

it absolutely breaks my heart to think about how far they've gone through life and the things they tell me that they were told or that they didn't understand, that all they need is just someone going, look, let's just take basic how a computer works and build programs out of it. Because then there's nothing wrong with mapping something over an iterator, right? But you need to know what that turns into.

And giving someone the fundamentals of what actually goes on in a program for real makes it so much easier to understand all of these other things and not only that but they can see the equivalences between them they can they can understand the difference between a for loop right and mapping something over an iterator versus a lambda versus a blah blah like there's all kinds of related programming things that are going on they all turn into a very simple set of things right test jump basic register operations if you start understanding all of those underpinnings, suddenly all of this other stuff just gets immediately demystified

because you're just like, oh, it's just another way of producing this set of assembly code. And now I can just, in my head, trivially decide which one of these things was better rather than going to stack overflow and asking a question of the form, should I be using

this ruby construct or that ruby construct to do blah and it's like you don't need to ever ask those questions right you can have you can learn to have the fundamental understanding to just evaluate these things yourself and know how you would investigate them yourself in a very little amount of time. But like, I mean, I like the sentiment a lot, but like, I feel like I disagree with parts of it. Like, I think that Python is easier to learn than C. Like, I mean, it just is, right? And I think that like, like I used gotos in basic, but like I didn't understand that they, you know, were the same. I didn't understand that they became a jump instruction, right? Like, I mean, that wasn't important to my understanding of a basic program, I guess.

Well, two things I would say about that. It's not understanding that they turn into a jump instruction. It's understanding jumps. So if you learned a program in BASIC, you intuitively understand that the computer is a thing that has an instruction pointer in it, and it moves from one to the next to the next, and then jumps move you from wherever you are to wherever you're going.

You don't have to know that assembly language even exists. BASIC, by its very nature, line number, that's instruction address, right? Go to, that's jump. The line number you're going to, that's the parameter of the jump instruction. Your brain was taught without you ever knowing how a computer really works. And now when someone shows you a loop loop your brain automatically maps it onto that thing right yeah and so when you come at something having had a a more reasonable introduction to how a computer actually works and you build on it that's so much easier for you to handle

than starting with something incredibly complicated where it's very difficult to parse out all of the rules and what people are telling you and trying to get back down to that layer without a guide, right? And so in some sense, I guess I'm saying I had an advantage when I learned to program computing. I got to start when it was simple. So I didn't have to journey down. I didn't have to journey down. I didn't have to start at Python and eventually work my way back down to figure out what the heck was going on and why Python programs are so slow. Right? I knew that combing into it because I'd started from the easier place.

And it's just like it may also not be for everybody. So different people may learn in different ways. But the problem is no one was teaching it this other way. So all of the people who couldn't make sense of it, all of a sudden they can. Does that make sense? Yeah, no, it does make sense. It's like, I mean, I guess you're saying I like to teach things bottom up. Let's start with base principles and let's accumulate our knowledge on top, like step by step. Is that?

Yes. And another way to think of it is, let's suppose that you were going to sit down. Do you play any video games? I'm not a big gamer. It's kind of funny for me to interview you, I think, in a way. Okay. So this analogy might not land, but for any of your listeners out there who play video games, they probably intuitively know the difference between the type of game where you are handed a controller and every button on the controller is mapped to some crazy thing and you go through an hour-long series of tutorial levels where they're like in order to

distract the guard hold down the right trigger and then press a and b at the same time and then move the left stick to choose the location and then let go but if you hold it for more than a second it will you know everyone knows the difference between that and the game that just starts you playing and introduces those concepts slowly so you start off and you don't have to distract the guards. You just learn how to move by like moving through the space. And then they're like, there's a guard up ahead. And they're like, a little thing maybe says, hold A to throw something in the environment. And then you do, oh, I see, right?

It would be very strange if that same thing that so obviously happens when learning a simple system somehow wasn't equally effective when learning a simple system somehow wasn't equally effective when learning a much more complicated system. In other words, it's not harder to build something from scratch. It's easier. You learn C and a bit how computers execute code, and you just start going. And Casey's there to guide you. Casey's trying to build the guidance system he wished he had. When he was young, he wanted to build a text adventure game, but he never figured out how. The reason that I didn't know how to build a text adventure was sort of, was I always imagine that in order to solve a problem,

it has to be solved well. I know it's a strange thing to say, but I always imagine that other people are solving a problem well. So when I play a text adventure, I imagine them having something when they built that text adventure, like their structure for the program and how they built it. If you were to compare in the abstract as a child, when I was looking at those text adventures, what I imagined them to be doing under the hood, even though I couldn't conceptualize it because I didn't know. First of all, Infocom, which is the main text adventure company at that time,

under the hood, the most advanced text adventures of the time from Infocom were actually running sort of like a Lisp variant, right? And I don't even know. It was their own Lisp, basically. They came from the AI department of MIT, if I remember correctly. So, you know, I mean, they love their scheme over there. And so Lisp-like languages are big. I mean, I didn't know what Lisp was. I knew what BASIC was. So I

wouldn't have even had a way of conceptualizing even the language that they were using to develop these text adventure games. But one of the things that would happen in my brain is i would just imagine that whatever their solutions must have been they were like very advanced right yeah but in actuality if you go look at the code it's terrible and very primitive right and so even just knowing what I did, if I just said, no, like make it work with what you have now, your stupid seven year old brain that only knows basic.

I could have made a little text adventure if I just really pushed myself to just no matter how ugly and not really solving the problem, this is just paper over it as best you can and that would have made a text adventure and and i wish i had learned that lesson earlier because assuming that that the thing that you're actually building has to be better than it really does is very limiting i think a lot of programmers who are writing me these letters they're not saying thank you so much for teaching me how to program i program just like you. And I watch all your streams and oh my God, you're amazing. No, I don't think that's what they're saying at all. I think they're saying, thank you for showing me how to start doing this thing.

And then I think they go their own way. I think they're learning to program the way they want to program. I don't think I'm really the, I don't think I'm providing the, the, uh, programming education that way. I think I'm giving them the opportunity to have their start at this sort of more fundamental type of programming. And I'm super proud of that. And I'm super happy about it. I don't want to minimize it.

But I don't think I'm providing any kind of like Swami programming wisdom. Like I don't think that's what's actually happening. I think I'm providing just the place for them to start. And the reason that I say that is because if I go back in my own history, the reason I never really wrote much assembly language as a child was because I didn't know how. I never had someone show me,

oh, here's an assembler, A. Here's how you start writing the code that you need to just get a simple thing running. I would have loved to have done that, right? But I just didn't know how. And so to me, I think that's more of what's happening. I'm just showing them, here's how to get started. And then I think they, I think it's in them.

It's not in me. It's not coming from me into them. It's in them and they just couldn't access it. And I'm just showing them, oh, here's the door. Let me open the door for you. And then they're off. Right. And they don't need me anymore.

Yeah. Yeah. It makes a lot of sense. It's like you're an existence proof that this is possible. That's all it is. And that little bit of startup. Yeah. Because then they, because they're very smart.

You can tell, you know, these people are good. They, they only needed me to show them that there was a direction to go in and then they're going, they're the ones who are going. Yeah. It's not magical. There's not like wrong ways. You just like go at it. Yeah. And they're going to end up programming much different from me. And you know what? I love that. And so I do think it literally just boils down to that sometimes. It's just that mental permission that someone tells you like, no, of course you can do this. Here's how you get started. And then for people who have that sort of natural drive going through it, it just feels like growing up.

And you might feel stupid right now because you're not getting like a programming theory. So it's like, no, that's just your programming brain is growing up and it takes time. Right. It just takes time for your brain to like structure itself in a way that these things will work. And so persistence and curiosity, if you can just keep them alive long enough, you will gain that ability.

If everybody watched your first 30 videos, everybody who was like, wanted to develop software, what would that change about them or the world? So the first thing I'll say is, I don't even know if that's something I would recommend. Because you have to understand that Handmade Hero was something started on a whim. It wasn't designed for any particular purpose. It was just designed to be a record of a complete recording of how you program a game engine, right? And so it's not designed for anyone to watch the first 30 videos and get anything out of it. It was never designed for that.

So my new project, which is Starcode Galaxy, is designed for that. The answer I have for you there is I'm trying very hard to produce my attempt at the first universal programming course, a course that basically like everyone can go into this and learn something about programming if they're not already like an expert. And what I think it does is refocus on those fundamentals, right? It's an attempt to say, what are the crucial things that you need to know about programming that are always true? Because what I see in a lot of course materials and educational materials, both for novices and intermediates, is they focus on learning something specific. And the problem with learning something specific is it's here and then it's gone. If I teach you how to use Angular, you know how to use Angular, and that's it. To answer your

question directly, if they were to go watch 30 or 40 hours of Handmade Hero, what would that change? Really all I think that it offers is, here is how a person who programs from first principles without libraries, without, you know, using a whole set of frameworks or that stuff, here's how they step-by by step bootstrap themselves up into a fully functioning system.

Because within the first 30 episodes of Handmade Hero, we've got graphics on the screen and sound and controller input. And we've got dynamic code reloading. We have looped live code editing. You can like hit the record button, move the character around

and then hit the stop button it'll play that back you can go into the c code change the c code and it will change on the fly as it's playing back the recording that's all in the first 30 or 40 episodes actually so what i think you could get out of it is wow this stuff is a lot more accessible maybe than I thought. Because you can watch me do it in 30 or 40 hours, get straight to that point. No SDL, no libraries, no boost, no Python, no interpreter, no JavaScript, no nothing, just C code. That's what Casey brings to the table. It's directness. Casey does hate modern C++ and Python and Visual Studio and, well, maybe everything.

But his teaching approach works because he doesn't have to teach all that. He just started building a game and started answering questions along the way. Learning modern software development, it could take a lifetime. There's just too much to learn. And if you got into software wanting to build a game, then at some point you just might wonder like, hey, when do I get to build my game? And that's when you find Casey. And he says, step one, create a text file and put a main method and let's make a buffer. And we're going to start

writing things to the screen. So that's what I've learned from Casey. I'm probably not going to go build a video game, but if I want to build a video game or if I want to make a programming language or a database or whatever, the thing I'll remember from Casey is start with what you know, and you'll be surprised how far you get, even if it's kind of ugly. So that was the show. I hope you liked it. If you did, please tell somebody about it or give me a review in whatever your podcast app is. I'm on Android and I use Podcast Addict and you can leave reviews right in there. If you're on the iPhone, you can leave reviews in the podcast app or if you use Overcast,

I think you give a star and the stars increase the ranking of the podcast, I think, so that's super helpful. But my absolute favorite thing is when people just tell other people about the podcast. I see people recommending it on Twitter or LinkedIn and somebody wrote a blog post mentioning it and that's just my favorite thing. other people about the podcast. I see people recommending it on Twitter or LinkedIn, and somebody wrote a blog post mentioning it. And that's just my favorite thing. That brings me a

lot of joy, makes me feel good about the effort that I put into this. So thank you very much for anyone who does that. Oh, and I'm also working on the website, trying to add some professional transcripts, trying to put together a newsletter, and just improving how things look a bit. So there's lots happening. This is Adam Gordon-Bell. Until next time, thank you so much for listening. I'm going to place you on the C++ language committee. First meeting's tomorrow, you get to decide the agenda. Okay. So I'm in charge of the C++ standards committee? Yeah. I mean, C++, the first item on the agenda would be to start a, like, whatever they have, a working group, a committee, a subcommittee. I would start a subcommittee on carbon neutral ways to, you know, incinerate the C++ 1700 page specification in a way that produces energy

but doesn't harm the atmosphere, right? When that committee reported back, we would burn all the copies of the C++ spec and start over.