168: Godot

0:00A:Programming Throwdown Episode 168: Godot. Take it away, Patrick! Welcome everyone. Starting with...

0:25B:A bit of a rant. It's that I don't know, man, it's so negative.

0:29A:It's—I have something to rant about. We have a cup, a pair of rants. Oh, okay. Is there a word for that? You know, there's like a flock of geese. Is there a word for a gaggle of rants? Okay, all right.

0:42B:Going to buy, right? So one of the things that has been like a recurring theme and it feels like it's getting worse now, I guess. Like to set the context, if this is your first episode with us—you maybe don't know—but I'm—I don't know how you would call the like role of software, do so? Maybe it's particular to the kinds of software I do, but it's been persistent. So some combination of embedded application engineering, maybe web is a bit better, I don't know. But maybe back end is pretty similar, and that is the number of things you're expected to know how to do on a computer that really don't have anything to do with programming, but you're just like you're supposed to know how to take care of it, like just random things, not just the kind of slightly strange things, like you need to know how to set up your computer, like plug in the keyboard and mouse and you know monitor. Not—not admittedly these things aren't hard, and most of us know how to do them, but like this isn't really related to programming. Like you could not know how to swap hard drives on your computer, install new RAM, but occasionally someone the other day had a hard drive, you know, crap out, and so the IT person just like sent them a new hard drive in the internal mail and like here installed a new hard drive or whatever.

1:53A:Now people know that is not.

1:56B:Common. Okay, I mean weird, right? But like you wouldn't be also surprised that a programmer was expected to know like how to install their own hard drive, like me, because it's—I guess it's part of my rant. It's just par for the course, weird for, you know, the company or whatever. But just you know not that, but like you know dealing with errors in your operating system, um, you know finagling issues about network connectivity, even if you don't develop a software that has anything to do with, you know, sockets and, you know, IP connections and just any of that stuff, you're still expected to know how to debug that at some some level and kind of figure it out. And then also things about just like setting up your development environment, right? Like having your IDE set up properly and getting all of the compilers working and all of that. There's no just like sit down and here's a text box and your sort of expectation is to just you know type in the program. And I guess that's true with a lot of jobs. There's like lots of extra stuff you need to know, um, but it gets really esoteric. So I develop in C++, which is especially bad, so just the amount of like how to get your system libraries installed correctly so they can be accessed. But the same is true Python, even when using Pip or virtual environment or whatever. Like you still have issues with like conflicting packages and package managers and Linux stuff. So it's not sufficient to just, you know, most people would know Windows or Mac OS, but probably need to know Linux, you know, and how to debug various issues when you mess something up in one of your paths and you know how to have your profile set up. And so anyways, my rant is just becoming like there's some stuff for like fixing this and virtual development environments, but they're not here yet, and I guess I would say they can't come soon enough.

3:35A:Yeah. I mean a couple of things there. One, we have this wiki page for it, it's called 'Landing Your First Pull Request,' and it's a freaking enormous. Like there's just like an insane amount of things you have to do. Um, we have a GitHub bot that actually merges all the pull requests. Like you don't actually merge them yourself. And so yeah, you have to like, you know, run all the unit tests and then run Lint, and there's a billion different kinds of lint—there's MyPy, and then there's Flake—which like both I guess check different things or there's they're not totally overlapping, you know. And then uh there's all these other things. As you said, there's like the Pip dependencies making sure that's all okay.

4:21A:And then, you know, to your point, do this wacky thing where everything runs in a Docker container. Like you actually can't run anything on your own computer because as you said you don't have any of the libraries or anything. So so everything has to run inside this Docker container, which is kind of painful if you need to use GDB, you know, or any type of debugger. You have to do this remote GDB or you TCP into like your own computer. It's just it's just weird. Um but yeah, I mean it's like a huge laundry list of stuff and like, you know, this is like none of it has anything to do with the code that you wrote. Like that entire document, you could you could just be adding a semicolon, and you have to go through that whole thing. Um The other part of it is I think in general, like just stepping back a bit, like there's just enormous cognitive overhead that there wasn't before. I was thinking about um travel agents, and now you'd have a travel agent kind of book everything for you and find the right flight and all of that. Um Now travel agents are even before our time, really. I mean, I actually never used one, but um but now, you know, you have to do all that yourself, and and you know the search and retrieval is really good so that you know normal normies, normal people like us could do it at all. But um but still it's like cognitive overhead that you didn't have before. And uh you know I think you're the same thing with the bank and you have an issue with your Amazon package or something. It's just there's an extraordinary amount of cognitive overhead, and I think as a programmer it also just seems to keep increasing the amount of things that you have to do.

6:04B:I was watching some movie the other day. I don't even remember what movie it was, and it was just one of the funny standout things was the person wanted to fly somewhere so they drove to the airport to go inside the airport to book a ticket. They weren't flying; they just like went to the airport for the purpose of like talking to a booking agent and booking a ticket. And it was like, 'Oh, I—yeah, I guess that makes sense.' Like people did that, like that, you know? Or like you said you phoned up someone or phoned up, but yeah, you know. And I think that happened to me the other day. We were trying to book something online; it was having a glitch, and we had to like talk to a person and like do it verbally, and they were reciting back to us like the various times. And it was just like, 'Oh man, this is—yeah.' In some ways it's lots better, but as you pointed out, like the number of tyranny of choice, I guess, like the number of things you can choose from and the number and it just like everything becomes an analytical decision. Yeah, it's yeah.

6:53A:I mean to riffing off your point, you—I've never had a company send me a hard drive or anything like that, but I did have a hardware failure um yesterday. It was really weird. I was on my computer and this is my personal computer, and then all of a sudden like Steam was updating some game in the background, and I was I was coding something up. I was actually working on MemeHub, which we should talk about at some point, but um I was bringing that back, and all of a sudden like I look and I see, 'Oh, Steam is updating some game,' and it's been updating for almost the entire day. Um And basically, you know, it just took a ton of triage. What I found out was my hard drive was only reading and writing at 800 kilobytes a second.

7:44A:Um, and I was immediately—yeah, I was thinking, 'Oh man, I'm gonna lose this hard drive,' you know, and I just bought it, and it has all my stuff on it, and you know it's started getting kind of nervous. Um But then I was like, you know, the I ran all the SMART tests and diagnostics—everything, everything came back fine. It's just nothing would actually finish like scanning the drive. I thought maybe I needed to free up space, but I didn't. Um And it turns out the SATA cable was bad. It went bad. Oh, and I've basically been using the same SATA cables for probably 15 years or something just because I keep, you know, when I get new ones they just go in a box, and I just already have the other one plugged in a drive, and I change the drive—I'm not changing the drive and the SATA cable at the same time really ever. Um So yeah, I just swapped out the SATA cable, but it was definitely it kind of scared me. And to your point, like like you know, I don't know like we have to fix these things ourselves. I don't really know like who I would even—I don't think Geek Squad will come and go look at this homebrew machine that's—I mean they will, but they'll also do 100 other things you didn't want. Yeah, that's right. I'll have like five copies of Norton Antivirus or something.

8:58B:Uh yeah, the other one. I'll drop just here for anyone who runs into it: HDMI cables are not all the same. So over the years if you're still using a really old HDMI cable, it may not be able to like support the proper bandwidth if you're trying to like, you know, do 4K Blu-rays or something. It's just something I was unaware of, but really I didn't know that. Yeah, wow, how?

9:18A:Do you know if it is printed on the cable or anything?

9:21B:That's a great question. To try it, you just buy the one that has the bandwidth you want and use it. That's the deal.

9:28A:You know, that's the advantage of us being our own Geek Squad. It's like if something doesn't work, we can order a cable, and it's only eight bucks. And it's like still a tiny fraction of the cost of getting someone to come to your house. So, like if you order the cable and it's wrong, it's like, 'Well, I have an upgraded cable now, and I can keep debugging.'

9:48B:And then you end up with the box of cables that every Geek has in the closet, which is just, 'I have it,' and actually.

9:56A:Folks at home, you know, we stopped doing video because we felt like we had to get all prettied up and everything. So we stopped doing that. But folks at home can't see the giant box of cables that Patrick can see in the background. Oh, another thing that happened to me last week. So I went through a period where I was ordering a ton of stuff from AliExpress and these like straight from China things. And slowly, slowly it came to be just a terrible investment. And this is really the capstone on it. I had a Raspberry Pi 4, and I bought this thing that could control multiple servos because every year my Halloween scare bot just gets more and more extreme. So it's at the point now where I needed something to control a bunch of servos. There's this little I2C module communicates over I2C, controls a bunch of servos. And the way it works is you connect the I2C pins to the Raspberry Pi, you connect the 3.3 volts to the Raspberry Pi and that powers the board and sends all the signals. And then separately in the servo controller, you connect like a power supply right to power these servos because these servos use way more electricity than the whole Raspberry Pi. So I mean, even one of them probably does. So I set it all up. It looks all correct. One thing that was kind of a tip-off was my power supply was saying it was plugged in when it wasn't. That should have been a tip-off that something bad was gonna happen. But being an idiot, I plugged it in anyways, and smoke started coming out of the Raspberry Pi, and the Raspberry Pi got completely nuked. The SD card burnt my finger when I popped it out, and I was so mad. You know, first I thought, 'What did I do?' And I'm looking at everything, and it looks fine. And then you know, I get the multimeter, and it turns out this is shorted, and it's just a bad component that I got as cheap as possible trying to

12:10A:save. I saved two dollars off what it would cost on Amazon, and I fried like $120 worth of equipment. And I was so freaking mad, unbelievably mad. But what can you do? Man, I just had to throw the Raspberry Pi in the garbage and get another one and move on. Yeah, I

12:31B:guess there's a tip there too, just for people who want to play with that kind of stuff. Well, first of all, there's a high potential the stuff you would have bought at Amazon would have been exactly the same, just like it's possible. But the second thing is, do not plug things you get like that for the first time into your computer USB port for basically the same reason. So if you have some USB-powered device or whatever, you know, like get what do you—I don't know what you call that, like the one that plugs like a wall or something else, like a splitter. No, like don't even if it needs data, right? Like you need to like a thumb drive or whatever, right? So a thumb drive could have a short the same way. But if you at least plug it into something that isn't going to like you get an old computer or something that isn't like your nice computer because if you have a short in it, but you know, like USB drives are a little different. But I'm thinking like one of these dev boards or something you soldered up and you accidentally, right? You know, solder across it, plug it into something that will basically like you're okay losing rather than your computer—computer one because yeah, the same thing can happen, and then you'll fry your USB port or even your motherboard. It's bad days. Yep.

13:36A:Yep. And this is the second time something like this has happened to me. And the first time was my fault. First time it's totally my fault. This time is not my fault. But the one telltale sign is if things have power that shouldn't. That was sort of the common denominator. It's like, 'This thing is not yet plugged into the wall, and the light is on,' and I'm getting a voltage reading on it. That's all you're only supposed to get when it's plugged into the wall, like that right there. If you ever see something that shouldn't be on, um yeah, I told the story years ago, but in my first project, I did it on a metal bench and shorted everything. I mean, that was incredibly dumb. But you know, the sign there was, you know, that the lights were still on and I hadn't plugged it in yet. So that's the thing to look for: free power. Yeah. I mean, I thought that I had a scare bot and a perpetual energy machine. What I actually had was just accurate smoke. Yeah.

14:35B:All right. Is it time for our news of the show? Let's do it. What's your news? All right. So my first one—well, I guess these are mostly links. I don't think we have any news. I guess I have a little bit of news. So my first one is a blog: this is smartguest.is. Anyways, and it's talking about software estimates, which are notoriously very difficult. I don't even think it's a junior senior thing; I think it's just very difficult. I'm thankful that I'm not in a high-stakes software negotiating like dev estimate thing because I just can't imagine. But they were kind of making an analogy that it's like negotiating with a meteorologist. There are some caveats. I immediately sort of got the content; I like read it to make sure, you know, but just reading that it was one of those ones—like just reading the headline was enough for me to derive lots of value and smile from it. Then the person is talking about accurately, so like if you're keeping all the bounds the same, like keeping the requirements the same, and all of this, like the estimate is the estimate. To ask the estimate to be lower is just like making the—you know, just making your stuff come late or becoming a problem, and no one fusses when you come in too low. They only fuss if you come in too high. So there's always this pressure to come in faster and shorter. And you know, that's just kind of it's kind of silly. I know you can change the requirements. You can split things up. You could reassign new people or more people. I mean, those things are they're all possible, but in general, yeah, like the estimate is the estimate for the—you know, kind of statement of work, and so trying to negotiate with it just doesn't work. But you know, as I've become more and more of a person, you know, trying to work with others, I will say I do find that sometimes people give me very, very low estimates, and I try to tell them in general don't—don't. And someone was reading some commentary about this post as well. This one was pointing out correctly that programmers naively think they're going to have like their high output, like peak output for how long would it take to solve this problem at peak output when they forget is how much of the

16:34B:day are you actually at peak output? You know, are you going to meetings? You're getting interrupted. You're helping code review other people's stuff. So there's this balance between like focused time—it's this amount of hours—but you're not going to have all focused time. And additionally, you kind of often need to estimate calendar time, and your calendar time, you know, you have a lot less than you think.

16:54A:Yeah, I mean the thing where I'm really struggling here right now is this idea that folks are much more—like people really overestimate how fungible. I don't know if that's the right word, but like so for example, you talked about doing embedded and web and all of that. You know, very few people have that union of skills. And so if there's somebody who really knows embedded DSP, and you know, you're behind schedule on the website, you'll hear folks say, 'Oh, just, you know, add this person to the website to get it done faster.' And then it just never works out well because, you know, it just for so many reasons. I mean, one, the person doesn't want to build a website; they want to keep doing their DSP work too. It's like that person has to now get trained in that other skill, which takes time, and it probably might be a good thing to do, but it's definitely not going to accelerate the schedule. And so I think this is like a problem of we're in this sort of in-between phase where everyone's still called a Software Engineer at a lot of companies, but I feel like that will probably change if it hasn't already. But yeah, that's that's another problem. It's like, 'We have eight people; just put all eight people on this thing and it'll get done.' It's like well, doesn't really work that way.

18:23A:My new story is announcing Python and Excel. So you know we are predictors of the future. Patrick, basically we're amazing. So we talked about Excel months ago, two or three months ago, and talked about how it would be awesome if you could do Python or these other things in Excel. Sure enough, Microsoft—they must have been listening to Programming Throwdown—they announced Python in Excel! And actually, Guido is the first place I heard it from. He posted about it on Twitter, but it had also been on the news and everything. And it's pretty awesome. I think the way it works is it spins up and sort of like an ephemeral virtual environment to execute your functions and then spins it back down at the end, something like that. I don't know too much about the technical details, but it's definitely headed in the right direction. I think Python, you know, is shaping up to be sort of the language of the masses, and this is a great way to get Python in the hands of millions and millions of people who up until now probably never even heard about it.

19:33B:And I guess the reverse for people who know how to do Python, to not be frustrated with, 'I don't understand how to get this Excel function to do what I want.'

19:45A:Yeah, that's true. It's true. If you need to do like some real advanced stats stuff, you need SciPy, but you know you don't have any easy way to get an Excel—I wonder. You know all those companies that do kind of Excel Python? Like there's one, I think it's called XBB, but there's these Excel, you know, Python bindings that they sell commercially. Those people are probably not happy with this news, but I mean, I think for the overall community it's a huge win. If you've not watched,

20:16B:It. I just was watching it the other day because I was trying to do something with pivot tables. Don't ask anyways. There's a—there's a—I don't know what to say. Famous there's a classic. So Joel Spolsky, I think he used to be at Microsoft. Originally founded Fog Creek Software. Like I feel like a few years ago I don't hear that much about him anymore, but I feel like he was one of the sort of—he had a big blog. It was at joel-on-software, I think. Yeah, that's right, Joel. Yeah, and he would—he was like one pushing for developer productivity and like you know getting nice chairs and more monitors and like you know basically like treating your engineers, you know, kind of nice at a time when maybe that wasn't as common or wasn't—it happens more now than it used to. And I feel like he was one of the people that pushed that. Anyways, he has a YouTube video you can kind of search up: 'You Suck at Excel,' and he sort of shows that actually like you can do a lot with Excel, like pivot tables or almost there. There's some VC people who say this is like every so often, you know, I forget what the cadence is, that basically someone shows up with a startup that is basically could be solved with just a pivot table in Excel. And so you know most people underestimate just how much you can do with just pasting all your data and running the functions.

21:29A:On it? Yeah, totally. Totally. So yeah, folks definitely check that out and report back if you're using it. Let us know how you're using it. Yeah, I want

21:38B:to see. I guess that's—I need it needs to be imminently Googleable when I want to solve something. Someone to put like, 'Here's the Python,' here's the like 80 solution.' Yeah, that's.

21:49A:Right. There's been a lot of Discord in our Discord. So folks have been very active in Discord, which is really cool. So you know generally we always say 'Email us,' emails, emails, but you can also go on the Discord and there's a whole community of people there, which is pretty neat. We're not just—Discord. There's Discord on Discord? Oh, you're right. Discord would be like disagreement, right? Oh no. There's Discord. There's harmony in Discord. My

22:20B:Next my next article is 'Seven Habits of Highly Effective Software Engineers.' This is at the blog making-smaller-circles.com. And this is—oh, I don't—I don't know. It's one of those kind of like classic corporate things. If you ever if you had a big company and they offer like sort of self-betterment training, you'll get 'The Seven Habits of Highly Effective People.' And it's things, you know, I don't know—whenever I take these, I feel like it's things you kind of know they're just like putting a catchy name on it. So like, you know, highly effective people always look for win-win solutions so don't compromise. You know, you look for win-win ways for, you know, what the person you're trying to reach agreement with makes them better and it makes you better. So it's just kind of like things that I feel are—I don't know—a little obvious, but you know they're helpful to have a framework. And maybe maybe they're good anyways. So this person has 'Seven Habits of Highly Effective Software Engineers,' presumably riffing on that same thing. Um I don't know if I read them or not, but go read them. You know, the first one is like actively prototype new ideas, and that one really you know sort of resonates with me is—I feel in general it is difficult, but people sort of are unwilling to just commit to trying kind of like the hard bit. Well, first identifying the hard bit is not easy, but trying to find some core hard bit and like just write a little bit of code and convince yourself that your approach works or that, and like maybe you throw it away, maybe you don't, but like tell yourself, 'You know, kind of will throw it away. You're not trying to get it right,' and then you're going to do it again. But also, you know, try to bound it, try to make it small. And so I feel like this is one of those things that people can miss out. So he has sort of documentation about code reviews just getting stuff done. Um I feel like go read that. I won't—I won't read all seven. I guess that's a spoiler, then I'll steal traffic. So I won't. Uh so so go read that post. Yeah.

24:11A:I mean the one that really resonates to me right off the bat is quick and timely code reviews. I remember when I was an engineer, I would get so unbelievably frustrated when people would sit on a code review for weeks. That would just grind my gears more than anything else. And you know, I think the reason why it happens is—at least I don't know if you're like this Patrick, you might be more methodical, but I go through bursts where there will be like two or three weeks where I will just put an unbelievable amount of energy into whatever work thing I'm doing, and then I'll have a couple of weeks where I honestly like won't work really that hard. And it averages out, you know, so it works out well. But I'm a very bursty worker, and so when I'm in that burst and someone just doesn't review a code, well that basically cuts all that energy short. Like it's kind of wasted. And then you know by the time they review it, now I'm like not that interested in it anymore. And so it's just what you end up with is not making any progress because of that, right? Um so so that's one thing to recognize is like when you're reviewing that person just wrote that they're probably like really into it, and so you might not be into it, but you have to at least pretend like you're into it for the code.

25:31B:Review. Yeah, I think the bursty thing is part of, but I think it works for the code reviewers too. Like I think—you know, try to communicate to people like schedule time, you know, at the end of the day or you know before you start your work, or just like something when you're out of focus to go do the code reviews so that you know like you said other people aren't kind of blocked. And then we also try to establish cultural things like how long is it? Like you can start requiring if no one reviews your code within, you know, two days, you know, you can start pinging people and be like, 'Hey, someone review my code.' But don't start pinging them, you know, like 30 minutes after you send it in and be like, 'Hey,' because you know people are focused, they're doing stuff or they're at lunch or whatever. Like, you know that you got to have reasonable I guess on both sides. Um but yeah, yeah, try to sort of get to them and then also, you know, make sure that the team's culture like moves towards the ability to do code reviews so not giant, you know, 10,000 line changes that weren't communicated and are like deeply impactful to infrastructure. Those discussions should be settled beforehand. It is a pet peeve of mine that people try to sort of settle team strategy decisions in code review. It's just it's not good. That's not the right place to do it.

26:41A:Yeah, I mean one thing that took me many years to learn—I think I've said on the show before but it's worth repeating—is get really good at interactive Git rebasing and resetting and all of that because you know I would, you know, and this is part of the bursty thing. You know, I would end up with like a 10,000 line code review and you know I didn't know that there was a way that I could break that apart, you know, a simple way other than like a really painful thing um where I was just—I don't know—copying and pasting from github.com or something. Like I just didn't have the technical fortitude to understand like, okay, here's some interactive way where I can break this change into like 20 different changes and test each one in isolation. So yeah, if you find yourself submitting huge peer reviews, don't do that. But like—but not just don't do that; learn the techniques and the technology where you could break that down. All right, my next one is Raspberry Pi 5 begins shipping. Um so I—uh, yeah, I have a Raspberry Pi 5 on backorder. I have always done this ever since actually. I probably learned about Raspberry Pi from you Patrick. I feel like you're the only person who would who I'd have the Raspberry Pi connection with. But um but ever since I got onto Raspberry Pi, I've been ordering them when they came out and you know it takes forever to get to you, but it's the base price, you know that Raspberry Pi offers. You're not getting upcharged by anybody. Um so mine's coming sometime in December. That's what they say. But uh—uh, yeah, I ordered it. Apparently, it's way stronger than the four in terms of compute. So that'll be kind of interesting. I don't know what I'm going to do with it yet, but uh yeah, that's TBD. We'll have to figure.

28:42B:It out. I feel like it's been a little—I was mentioning to Jason earlier when before when I saw that he you know had this up. I feel like it's been so sad to me that the Raspberry Pis went from like a really low barrier entry into, you know, some embedded stuff to scarce and hard to find. And it used to be like that when they would first come out, but then they would just be, you know, pretty ubiquitous. But the supply chain thing—they just never really sort of hit there. There's like this combination I haven't looked into. I think it's a combination of things, but um you know, it it's it's sort of unfortunate that it's a little less accessible. You can't just go on Amazon and get a reasonably priced one these days. Um this is, you know, become very difficult. There's lots of cool things people have been doing, and like you mentioned Jason, like hooking up to the I²C ports is something a lot of people if you you know go on news articles or even myself replace them with just getting older, like used enterprise mini PCs which are probably more powerful and they can run Windows and stuff, but they don't have all that library for hardware interactivity. So the whole embedded stuff is is not really workable there. If you just need something to be a NAS, well, you can probably do pretty good for yourself not using a Raspberry Pi, but for all those hardware embedded projects like it's really—it's really the best sort of easy introduction to that. And it's just yeah, I'm excited the Raspberry Pi. I hope they sort of figure out the shortage there. There's some stuff floating around too with these new RISC-V boards or RISC-V. I don't know actually how you say it, but I think it's five. Yeah, is it five? Okay, RISC-V boards and stuff too. So I'm hopeful there'll be more this like medium embedded space where it's running an OS, you know, like Linux, but still has this like really nice hardware I²C, SPI, you know, connect a little monitor to it. I think that's a—it's a.

30:29A:great space. Yeah, totally. You know one thing I'm surprised is that unlike Arduino, which is just full of aftermarket, you know, versions like you can get an Elegoo Arduino Uno or like there's a million different companies that are making just following the spec in the case of Raspberry Pi, there's—there's really nobody who—there's no company producing Raspberry Pis at least that I know of. You know.

30:57B:Much cheaper. I mean, I think it's the SoC. The Arduino uses a pretty ubiquitous chip for its processor. It was like a—I think a PIC um and it was made by Microchip or whatever. So it was like a very common piece, but I think the Raspberry Pi, the like processor which is part of why it was so cheap, whatever, is this sort of they did all the integration work, but it was a basically relatively hard to get piece, and they managed to negotiate like a good price for it or whatever, which is the actual processor that it's running. And so I don't—I haven't looked at the 5 yet, but I kind of assume it's the same thing. It's like economies of scale, and it's like not a ubiquitous piece, and so the combination makes it a little hard to duplicate. Yeah.

31:39A:That makes sense. I do also have an Intel NUC which is, you know, mini PC, and that's running my NAS and all of that, and that is amazing. I actually had some issue where it wouldn't detect my hard drive every now and then. Um I updated the BIOS just as a Hail Mary before buying another one and just saying we're done, but actually updating the BIOS fixed it. So uh it was a Hail Mary pass that actually got a touchdown, I guess. Did you try swapping?

32:08B:The SATA cables? No, no.

32:12A:That would be—oh my gosh, I broke two SATA cables. This one though, the hard drive just plugs right into the NUC. So I think okay. Um but uh—um yeah, actually a lot of we are really esoteric hardware issues lately that seems to be the October trend for me, but. Yeah, oh mini PCs are amazing. Highly recommend them. Really fun. They're so cheap now. Intel was selling them half off for the Amazon Prime Day. I don't know what they are now, but prices are very reasonable.

32:47B:There's also—you mentioned AliExpress before. I have seen an uptick in the number of like—I don't know—we call them—like smaller brands are usually just brands you would never recognize selling kind of like old Intel Atom chips or even Celerons or um those kinds of things in that sort of mini PC form factor, or even fanless. Um not really again competing for like the hardware embedded stuff which Raspberry Pi is. Again, if you want to do any of that, definitely go Raspberry Pi or Arduino. But yeah, for that sort of like NAS, like home networking kind of stuff—yeah, there's some pretty cool options now and like ones that are like USB-C powered. Oh wow. You know. So yeah, pretty cool. That's.

33:29A:Super neat.

33:32B:Um all right, time for book of the show. What's your book Patrick? Oh man, you did the good intro and I cut it short. Okay, all right. My book of the show is is an old one, but I've been—I've been going back through it. You know, my kids are getting old enough whatever. So so we've been going through The Which is Harry Potter and the Sorcerer's Stone, but the illustrated edition. At some point one of our family members picked this up, which is a nice big book, like not thick—like you know the Harry Potter books are thick—but this is like wide, like tall and wide, which is just a nice form factor, and it has just beautiful illustrations in it. Uh and so I feel like it's just it's just one of those things, you know, everyone begs to be able to see the page instead of instead of just uh just reading it. So I've been really enjoying that. Maybe it's a bit of a cop-out, but that's what I have. Reading time's been a little limited, so I'm going way in the way back machine to pull up this one. But but yeah, it doesn't ever recommend it if you—if you weren't aware that they have illustrated editions or if you know, I guess that that's an XKCD comic about that, like how many people are born each year. Thus if you say like, you know what, seven, eight, nine before you can kind of start getting kids into Harry Potter, there's, you know, millions of kids who sort of coming into that. So if you have one of those in your life—wow, your own kid or, you know, somebody—you know. Anyways, I'm looking for a gift idea. Shout out to this or if you've never read the series yourself. I mean, I don't think everyone on Earth has read—maybe nearly, but not everyone. So if you've not read it before, this is a great way to get.

34:57A:Into that. Very cool. Yeah, I haven't read the illustrated edition of this, but I've read the illustrated edition of Terry Pratchett by The Colour of Magic. And yeah, I'd also read the original Colour of Magic. Yeah, the illustrated edition is amazing. It's similar what you said. It's a huge—it's a very like wide tall book and has a lot of beautiful illustrations. It's a lot of fun. My Book of the Show is actually a show of the show. It's The Pete and Sebastian Show, which is another podcast. You know, there's been so much negativity, and I mean, I know this is almost becoming itself a stereotype, but there's just so much negativity on the news that I just felt like I needed something—you know, something funny. You know, some comedy, you know, something positive and funny, and where I knew that they weren't going to talk about the news. So, if you don't want to hear about the news, you should listen to Programming Throwdown. But after you've heard Programming Throwdown, if you still don't want to hear about the news, you should listen to The Pete and Sebastian Show. Those guys are hilarious. They're right around our age, so—you know, they don't really—I don't know if that matters that much, but you know some of the references are of our era, so that part of it is kind of nice too. But you know, they're really funny. They riff on each other pretty well, and it's just like some nice banter to listen to. What kind of show is it? It's basically—it's just a comedy show. So what they'll do is they'll show up with three or four topics. For example, in the last episode, I saw one of the topics was basically vermin getting into their property, so like raccoons getting you know into their backyard and things like that, and the way they deal with it, and the pest control guy—and how does someone get into that career? It's hilarious. I was just dying laughing. They also, you know, they're comedians; they have a very infectious laugh. I think that's almost par for the course to be a comedian. Yeah, it's a riot. Highly recommend it. There's a bunch of really good comedy podcasts. I'm sure I didn't stumble on the only one, but I'm really enjoying this one.

37:15A:And yeah, you can definitely follow them on Patreon, but only after you subscribe to our Patreon. So go to patreon.com/programmingthrowdown and please sponsor us. Support us. We really do appreciate it. We take that money and ultimately put it to getting more folks to learn about programming, and we're going to take some of it—whatever we have left over—and use it for gifts on the Christmas raffle, which is something we do every year, and it's coming up in a couple of months. So we try and give all of it back to the community. Or we do give all of it back to the community in some way, shape, or form, and we try and use it as best we can to get more folks into programming, and we really appreciate your support on that.

38:09B:I'm going to try to do it Jason style. It is time for Tool of the Show.

38:18A:That's amazing. What's your?

38:19B:Tool of the Show? Patrick, my Tool of the Show is Obsidian, which is—you can find out obsidian.md. This is I guess you call a note-taking app, but it's sort of there's a collection of these. I think there's one called Notion, there's Obsidian. And they have phone apps, but also desktop apps, and it's sort of your ability to sort of take notes for yourself, but not just a singular multiple notes, but also provide links between them, categorize them, and just sort of like organize your thoughts. We've talked about—I think I've talked about Google Keep before. Google Keep works pretty well too, but this one is a little bit better for sort of hierarchy and interlinking, and then there's a bunch of community-provided plugins. They do not—they do sell a way to synchronize across your devices, but you can also provide your own synchronization. And the nice thing about Obsidian is it's all just text files, so each note is a file, and each file is a Markdown text file. So that's sort of its strength and I guess maybe a little bit its weakness. So rather than a lot of companies will do a proprietary database or even like a SQLite database—a little harder here if you know the company shuts down, it's not open source at least I don't think it's open source—but if the company shuts down, you just have like a directory of text files. So it'd be very straightforward for you to recover that, to import it into something else. I know it just feels like if you're going to get invested in something that you're wanting to use, I feel like it's a really nice take on it, and I'm having something I've been trying to sort of follow. There's a lot of techniques have built up around sort of this organization, like Life Operating System, and there's like a lot of these, but I—and I've been trying to sort of get into it. People point out it becomes a trap where you like start trying to get over-organized and making notes itself.

40:19B:becomes like a hobby as opposed to just facilitating your thing. So I don't know. I find it very intriguing. I feel like I have this constant to-do list that is in my head, and getting more organized is one of those things, so I've been trying out this Obsidian on my phone and then on my desktop as well as a way to sort of take notes about what I'm doing, provide like topics, but also link to other notes. And so I've been enjoying it. Check it out: obsidian.md.

40:49A:Cool. Yeah, so I just looked it up. Obsidian is not open source, but—but you were saying you could sync it like with Google Drive or something? Yeah?

40:59B:So like I use an iPhone, so I am able to use iCloud and just like the directory. And there's some warnings to be sure; like you got to be a little careful. But I for instance wouldn't think of an example where I would be editing on my phone and my desktop at the same time. This is only for me, so the sort of synchronization should be pretty straightforward. They do offer like a—a sort of—it's not very expensive a monthly fee if you want to sort of support the developer but also enable like proper full-featured syncing, which can work. But again, the thing I like is just that you can see it. You can just open it with Notepad or whatever, VI pointed at the folder, and you can totally see all of your Markdown. Yeah.

41:41A:That is awesome. That is really cool. I was using—oh, I was using Workflowy for a while, but yeah, kind of like what you said. You know, I found myself spending more time writing things in Workflowy. I ended up switching to when I got this Remarkable. I ended up switching to just writing everything on the tablet. But yeah, I do think you having the right note-taking app is really important. It kind of reduces that cognitive load we were just talking about because once you write it down doesn't have to be in your head anymore, as long as you're willing to look at it every now and then. My Tool of the Show is Ink by Inkle. So, you know, I've talked about—actually, I think Patrick, you talked about The 80 Days or maybe I've always been the one anyways. Inkle is this company that makes a bunch of interactive fiction books. There's—I think it's called 80 Days Around the World. Oh, okay. And then there's Overboard, which is by the same company and a bunch of folks. So they released their—I don't want to say engine, but they're basically system for creating these text-based games, and it has like a nice markup and everything. They open sourced it, and it's a scripting language, is what they call it. It has a—it has like a nice template style where you can kind of Mad Lib different things into it. And the reason this came up was I guess people have been porting it to other game engines. So they recently ported it to Unreal. I think someone's working on a port to Godot or getting it to compile with Godot, but yeah, I thought that was pretty neat. It looks really fun if you want to create a know an interactive game similar to the ones that Inkle has made. Definitely check it out. I think it's a really neat tool. Oh.

43:40B:Very cool. All right, something else getting pushed into my queue. Okay, it goes.

43:44A:On your Obsidian. Yeah, you?

43:45B:Gotta hang on. I'm gonna write it down. I'm gonna link. All right, I think with that it is time to talk about our topic of the show, which is Godot. Yeah, Patrick, so you haven't tried Godot yet, right? No, I haven't. Written—I know, I've kind of watched the tutorials, read the stuff. I'm familiar with the system. Been tracking it for quite a while, but yeah, writing a game in Godot is like again one of those things in my queue. I've been managed to pop it out.

44:17A:Just yet. Yeah, I mean my experience with Godot was—um, you know, I had this AI hero game I talked about on an earlier episode, and originally that was written in Phaser, which was a JavaScript library. And Phaser, I guess Phaser is technically a game engine, but um the thing about Phaser is, you know, it basically gives you all the libraries like here's a graphics library, here's a physics library, but you still have to kind of code all the game up yourself. And where I got stuck was on the sort of way to be an efficient game development, you know, engineer. Like for example, imagine if you had a bug at the boss of your game and the only way you could fix the bug is by playing through the entire game getting to the boss and then trying to recreate the bug. Well, it'd be super frustrating, right? It'd take you hours and hours to encounter the bug and all of that. Um now that's a pretty, you know, extreme example, but you know if you break that down, you can kind of end up in a situation where it's really time-consuming and difficult to debug anything. Um and actually even more than debugging, you know, you really have to, you know, a friend put it really nicely, you know, find the fun right when you first make a game unless you're just re-skinning another game and keeping the mechanics identical, you know, when you create a game originally, it's—it's not very fun. At least none of the ones I made were very fun. And um for AI Hero, you know, the original concept of the game was where you would sort of bring your own shapes, so it's like, oh, I need a circle here. Oh, I need a line here. I need a curve here. And and you'd sort of draw from this toolbox of shapes. And um that ended up not being very fun because, you know, if you got it wrong, it was really frustrating. Or like often the more complex shape

46:16A:like a curve could do anything a line could do, right? So you just always pick the curve. And it got to this point where it—yeah, it wasn't very fun. And um I couldn't really iterate quicker, quickly because of what we just talked about. And so I got stuck and so I put it down. Um when I ported it to Godot, you know, obviously it still wasn't fun because I just straight ported it to Godot exactly as it was. But I could—um, you know, and we'll talk about this when we talk about Godot, but I could go into specific parts of the puzzle and just play that part in isolation or just look at a certain curve in isolation and play around with it. And eventually that was what allowed me to find the fun in that game. Um so so that was my experience with Godot, and overall I'm a—I'm a big fan.

47:07B:I think game engines, and maybe it sort of changed today, but I think like this example like you're saying, Jason, there's nothing that could have like you're a capable programmer. You could have coded all of this yourself, right? So the things we're going to talk about that are like the components of a game engine, it's—it's really like an almost like a menu, and many game engines are pretty flexible and that they like let you order stuff off the menu, but you can also kind of like sub in your own thing. And I think some people get into any, you kind of see post-mortems or whatever, get into their own like, 'I'm just going to build my own game engine,' or 'I'm building something so different or so off nominally like the expected path that I'm going to start by building my game engine.' And they just never finish building the game engine. Um and you just sort of get into this, you know, sort of thing. And I think like, you know, it is—it's like programming language choice in a way, which is that, you know, probably there are many ways to solve it, and for every person in every situation, it's just going to be, you know, going to pick one and hope for the best. But I think like starting with that basic game loop, right? Where—unlike most applications or at least that I write, you know, they sort of start, they do some processing and then they end. That's not how a game works. A game doesn't—I mean, I guess at some high level you exit the game, but you get into this loop, right? And so just setting up the loop and forcing like you were saying to get into the process of rapidly testing and getting to the part where you have a sort of working prototype somewhat as quickly as possible also helps with the motivation. And I think that gets underestimated—that like having something that's demoable and, you know, playable and sort of excites you helps you stick.

48:49A:With it. Yeah, you're totally right. Um I mean, think about like some of the really iconic games. Um and—I'm going to sort of date myself here, but like Super Mario 3 for example on Nintendo, there was one level where you got this boot, and the boot would let you walk over spikes. You could jump really high. You could like step on things and and kill them that you know you couldn't without the boot. It just radically changed the game. And there was only one level where you had the boot, and that level was kind of designed around the boot. Um, you know, there's just a lot of spikes that you wouldn't be able to survive otherwise and stuff like that. Um and so yeah, I mean, you know, the game developers and designers, you know, they had an idea, and they tested that idea, and they built a whole level around that idea. And then when you fast forward to modern Mario games—yeah, I play what is it called? The one on the Switch where four people could play and only one person needs to win. Is oh yeah, that's right, Super Mario 3D. Um what I find when I play these games is basically almost every level kind of has some kind of trick to it or something kind of unique. Like one level will have, you know, platforms that flip over when you jump on them. Another level will have, you know, something else. And so and so you have to be able to test all these concepts independently and very quickly, and game engines are really, really good at doing that.

50:24B:I don't—I think we talked about Unity briefly before, but since then I've read The Masters of Doom, which I think we had a book, a show before, which is basically how John Romero and John Carmack kind of started their game studio and how they sort of evolved it. And you know, I think one of the things through—through that that sort of impacted me is the sort of separation of concerns, I guess you'll call it, which is John Romero just had this ability to create levels and and interesting mechanics like you were saying, and John Carmack would focus—I hope I'm getting this right. I think I'm getting it right. John Carmack is like very specifically on like at the time, the limited hardware, right? And and sort of saying, 'How do I optimize rendering a 3D scene?' So think about like Wolfenstein 3D or eventually Doom. Like how do I get the levels encoded textured blitted onto the screen so that you know John Carmack can kind of push the engine and and sort of work the fun? And I think, you know, talking about—you know, we're talking about Godot here, and it tries to give you that same separation of concern, let you focus on the half of creating with the tools like Jason's saying, the mechanics and the interesting bits is the part that they're—they're not really going to be able to provide. You got to bring that yourself. Yeah.

51:36A:And you're getting to what you were saying earlier, just circling back to that. You know, I go to a lot of video game development meetups. Like if you're in Austin and you're at one of these, you'll probably run into me at some point. And um a lot of the time I see people who have a really interesting game engine, but then there's—there's no fun. It's not there's no fun there. So for example, I saw one recently where it was like Minecraft, you know, the engine was like Minecraft where it's all voxels, but you had a grappling hook kind of like Spider-Man's web web fingers, right? So you could swing around the level and then you also had these rockets that could just blow big craters in the level. And with the two of them, you could actually, you know, dig tunnels or dig up from the ground. And it—it was like a joy to swing around the levels and and put holes in the ground, but it was—it was just an engine, right? Like there was there was no fun there. And um I think that, you know, it might be better to have let's say built that in Godot even if you're getting, you know, five frames per second or something, but like you could figure out what the fun is, you know, like what's—what can I add to this game to make it really fun? And then, you know, if you have to rewrite it, it's fine because at that point you've done the rapid prototyping and you've sort of found the fun, and now you just have to recode it. It's probably better to do that and end up with two copies of your game than to start building your

53:11B:own engine. So maybe—maybe that's a good segue where at least I'll force it is—like what what game engine is and then specifically Godot's kind of version. I think talking generically, we already mentioned—I already mentioned the sort of loop, the sort of execution loop. And in that you're going to have stages, and one of those stages is going to be input handling, which yes everyone could write themselves, but you really don't want to, which is how do you handle keyboard input? Multiple keys pressed down at the same time? Mouse input clicks and, you know, all of that kind of like input handling. As well as like just some of the stuff that, you know, hey, you want to make a menu on the screen. We talked about—I think it was last time, right?—about desktop UIs, and we were—we were alluding to game UIs, but you really don't want to write a windowing system or a menu system, you know, from from scratch. And so they're going to bring that kind of stuff as

54:04A:well yeah, totally, totally. And they're going to do it in a way that is cross-platform. So you know, in my case um when I use the JavaScript game engine, they had a way of running it on the phone. And this is—this is a little bit beyond me, so I'm not going to try and explain how that works, but but um, you know, then when I switched to Godot, that was one of the things that I really wanted to make sure because although I was play testing and developing on my computer, my intent was for almost everybody to play this on their phone. And so, you know, similar to if you're doing Raspberry Pi or Arduino stuff, you have to kind of cross-compile, right? And you have to—to make whatever you're doing work in that other architecture. And there could be all sorts of little nits there. And so um and so with, you know, Godot has this nice way of saying, 'Okay, you can use your mouse on your computer or you can use the touch screen on your phone,' and they sort of like have one API that can kind of handle all of that. I didn't even

55:10B:think about that. So yeah, I guess we've been dodging the big one though, which is also just the actual kind of rendering engine, which I think is what all probably most people think about first as the thing they don't want to go solve themselves, right? No one wants to write directly in OpenGL, although you can. Um and now I guess that story again to your cross-platform importability is is probably a bit of a different story with DirectX and OpenGL and shaders, and, you know, so they're going to provide that ability to push 3D or 2D assets, um which would be like sprites, particle effects, models that you load, uh or sprite sheets if you're—if you're doing sort of sprites, and push those through and then handling things like rigging and animation. And they're going to have sort of file formats worked out and even in the case of Godot-like editors for that stuff as well. So so not just oh I'm in a script file like, you know, writing all this stuff by hand, which may work, but how would you join with someone else who wants to contribute to your game and say, 'Hey, listen, like why don't you handle tweaking the run animation?' Um and, you know, here's the editor and here's the keyframes,' and, you know, allow you to figure out that

56:20A:kind of stuff. Yeah, totally. I mean, I honestly to this day I have no idea how how the hardware, you know, graphics acceleration stuff works on Android or iOS. I don't know if they both use the same thing or if there's two different ones, and Godot had to write everything twice. Um I mean, the Godot system or Unity or any of these is handling all of that for you. So you run it on your computer, which—it could even be OpenGL or DirectX. I don't know that either because Godot is handling all of that. Um And then when you run it on the phone, it just works. And they've—they've done their best to make sure you get exactly the same experience on all these different devices, which is actually really remarkable if you think about it. Another piece of this is the editor. The editor is extremely important. Um, you know, Phaser and these other game engines, they don't—they don't have a development environment. They're a set of libraries, and you're meant to write your game in them. But but, you know, Godot comes with an editor. The editor is also written in Godot, which is kind of interesting. It shows that it actually works for something. But they—um the editor is beautiful, and um, you know, you drag and drop different sprites or sounds, you know, and it'll do positional audio and all of that. Um And then you can also do so, so the editor gives you scenes. So for example, you know, one of my scenes in my game is the main menu, and there's a bunch of little boxes like hitboxes that you could click on for the different options of the menu, and all of that. Um But then they have a recursive—the scenes are recursive, so you can actually, for example, um, you know, each level of my game had a

58:13A:scene for each line. So your point of the game is you're drawing these lines to kind of separate different groups of dots, and each line is a sub-scene. And so you can actually drill into the line scene and you can manipulate a single line, and when you click the button it should grow a little bit to like acknowledge that you've tapped the button and everything, and you can test all of that in isolation very, very quickly. Um and then uh and then when you're—when you are comfortable, then you can spiral back out and test the larger scene. Um There's some things you'll have to contend with. So for example, you know, if you're testing the line scene by itself, then you've never loaded a level. And so if you, you know, like one of the issues I ran into was when I'm testing the line scene, I would drag the line and then it would crash because it would see, 'Oh, did the player solve the level with the where the line is now?' And there is no level. So you have to deal with that. Um But what you get in exchange is the ability to test each of these different components, and I found that to be really the thing that got the game across the finish line.

59:26B:So other things that I think, time editor are, you know, as Jason's already mentioning with the scenes, but often many games have levels, and for levels you need some sort of map or, you know, your environment. And so having the ability to do that is something I remember—I guess that was like Unreal Tournament or something way back in the day came with, or no, it was Half-Life. I remember had an editor, and you could download the editor and you could like make your own Half-Life levels. It's

59:59A:called like Hammer or something. I don't remember.

1:00:01B:I'll have to look it up now. But you know, people started shipping that, hey listen, like anyone can kind of create their own level here. And you know, it's just a way of defining it. But again, this is something that sort of—I guess I overused the Python thing 'batteries included' that when you want to go build a level, here's a way to allow others to build levels for your game. So if you're, you know, building a logic puzzler or Jason was just mentioning the Inkle stuff and sort of like, hey, they built a robust way for even others to reuse their approach. And so being able to kind of have the level editing and sort of either 2D or 3D sort of be included is another good separation of concerns to allow other people to build out those pieces while you're focusing on maybe some of the mechanics.

1:00:49A:Yeah, totally. I was Valve's Hammer Editor, and I remember playing with that too. That was a blast. Another one I played a lot with was the Starcraft editor. Starcraft one had this amazing editor, and you could actually take the maps you made and play them with your friends on Battle.net, and they would download the map from you, and they joined the game and everything. But yeah, there is nothing more demotivating than like, you know, you edit a JSON file, and then it takes like three minutes to compile, and then you join, you start the game, you have to click 'New Game,' you have to choose your character, you do all that, you have to like skip to the right level, and then oh, the JSON file was wrong. The level is unplayable, and you have to do the whole thing over again, right? And so yeah, when people say they're going to build their own game engine, I think a lot of them think about, 'You know what? What do I want the engine to do?' You know, to like render or to play. Like, what does what do I want the engine to do for the player? That's usually what people think about, but what you really need to think about is what can the engine do for me to make me as a developer 100x more productive, especially if you're a solo or a small group, or you're doing one of these game jams, or you only have three days. You really need the editor to do so much for you.

1:02:19B:I think I just like put two and two together. Maybe I'm wrong; I'll have to look. I think there's been like an uprising, resurgence, increase in people doing procedural games. In part—well, we should talk about that. We have that perpetually on our list—but something like wave function collapse and other Perlin noise and these kinds of things for doing procedural generation. You mentioned Minecraft, right? Kind of famously does this, but other even more elaborate games as well trying to sort of do every game is unique, you know, are a little different, but there's rules that are obeyed to make sure it's sort of still playable. And I think some of that—not all of it, of course—very fun game mechanic, right? And sort of almost adds that infinite replayability if you can make it fun, but also gets you out of having to build levels, right? So I think there's this temptation too for some of those games to say, 'Well, look, I don't have to sit down and design a fun level. Like, I'm just going to work on an algorithm,' and if it's not fun, the person will just regenerate, you know, the world or will just do something again. And it's—you know, I think can be not always, but I think it can start to be a little bit of a crutch because someone just saying like, 'Hey, it's kind of more fun to work on an algorithm to make levels than to actually sit down and make levels,' if you're sort of a programmer by trade or by inclination. Some of that sort of artistic crafting and designing the sort of perfect one. And I think that's interesting. We were talking about—I think I mentioned last episode, or two episodes ago, about Factorio, but interesting, I was thinking about this: there's another game, Satisfactory, which is sort of similar to Factorio. And interestingly in Satisfactory, the map is actually static. So they have one map, and over time they want to add new features, and so they have to like tell you, 'Hey, when we do this upgrade, this portion of the map—warning, like if you're building something elaborate here, you won't really be able to upgrade because this portion is going to change. Like, we want to change this portion of the'

1:04:16B:map versus something like Factorio, whatever, like you're playing on your—you know, seed, you're playing on your specific incarnation. So stuff can be added, but you wouldn't really see it unless you regenerated. So same like Minecraft, and Minecraft added a new biome, right? Like you wouldn't see that new biome unless you sort of regenerated. And so there's this interesting dichotomy between like a static map and a procedurally generated one.

1:04:43A:Yeah, totally. I think that there's this—it's another one of these traps kind of like building your own engine. But there's this trap where you think that, 'Oh, I'm gonna make a sandbox.' I think is what they're called. 'I'm gonna make a sandbox game where I'm just gonna throw a bunch of mechanics together,' and that way I get to do all the fun stuff without having to do things that I think is not very fun, like designing levels or having very scripted situations, right? And actually it's really, really, really hard to make a sandbox game. There's a few of them.

1:05:21A:They've gotten kind of a cult following. You know, I mean other than Minecraft—I mean Minecraft is kind of like the Michael Jordan or the Beatles or whatever; it's kind of like its own entity, right? But if you take away Minecraft, you know, the sandbox games like X4, for example, or Gary's—um, Gary's Mods are a good one. You know, a lot of them, they're just very hard to pull off. And so I would suggest to folks who are making their first game, you know, make something that has like pretty well-defined levels where you can just reduce the scope, but it turns out making things more complex is very easy.

1:06:06A:But making things fun—is, for example, in Mario. You know what I at least what I think we're getting into sort of like really subjective territory here, but I think what's fun about Mario is that you have all these very simple systems. Like the Goomba is very simple, the little like fireball that spins, you know, the what do you call that thing? You know, I'm talking about the wall of fire—that no, it's not a ball.

1:06:31B:Oh, the rotating arm of fireballs.

1:06:33A:Yeah, yeah, the rotating arm of fireballs. So all of these things, all the speedrunners are

1:06:37B:really mad at us right now.

1:06:39A:Yeah, I know we're gonna get email for there's gonna be Discord and Discord over this. Um, is you know that in isolation they're trivial, right? In isolation, they're trivial to overcome, but it's when you compose them in different ways that it becomes really interesting. And um, so you know start with something really simple. Everyone says this—I'm not inventing something new here—but start with something simple that's very scripted and then work your way up by adding more and more complex systems. And again, like a library, I mean a toolchain like Godot is really important for that. I don't

1:07:19B:Know while we're on subjective game dev advice, having never built a game, I would say I think one of the things too—but but I guess cross-pollinating from other stuff is don't set out to build your dream game first. I mean that does work. There are stories you can Google them about people who like their very first game was successful and amazing or whatever, but I think much more common is like set your sights on something like attainable. You can—you can kind of iterate on the dream game, the fantasy game, the one day I'm going to build this, but for now, you know, sort of just execute on what's in your scope to finish and get sort of the reps in of, you know, start to end and actually sort of doesn't have to be amazing or you don't have to—you don't have to send it to anyone, but just like complete and playable. And you know, have a beginning and a middle and an end. And Jason mentioned game jams, but this is my like secret thing is like one day I'm gonna sign up for a game jam. It's gonna force me to do this like it's time.

1:08:11A:Bound! You need to do it, Patrick. Oh no, we need to do it. We got to take like three days off work when there's a game jam and make a game. All right, I gotta do.

1:08:19B:Practice before that. But all right, the line is drawn trying to get back onto Godot physics. We didn't talk about as well. This is another one where maybe people either think it's too easy or too hard, but having a physics engine and not worrying about all the things that come with it—collision detection, you know, right? Gravity adding, you know, parameters that you can script to other functions or actions or superpowers like Jason mentioned, you know, having a boot that turns off the spikes, right? Like you want to code all that logic with a, you know, spaghetti function. Good luck. Like yeah, you could do that. You know, or you could let a system that sort of has all those things, you know, handle.

1:08:58A:It for you. Yeah, I mean another thing that's really complicated is, you know, look at Mario for example. You know certain things are affected by physics, like the mushroom falling off the edge of a ledge or something, right? Um but then you know there's certain things where you just need a lot more control. Like if Mario is controlled by a physics engine, it would be just too unreliable. And you know obviously speedrunners would be really upset. It's like, oh, you know my computer, you know skipped a frame and Mario couldn't make that jump or something. But but then also like, you know, it would just be too complicated for beginner players to really understand. You know, so—so—you need Mario where when you jump he has an extremely fixed trajectory. He could even change trajectory in midair and things that are like physically implausible. Um but then you need, you know, mushrooms and barrels and stuff that are just normal physics things. And so, you know, Godot has—I'm not going to get the terminology right, but it basically is a concept for I think they call it a static dynamic body or something. I don't remember anyways, but there's a concept for like here's a thing that I want to exist in my physics universe, but I'm going to be controlling it directly, and you'd use that for something like a player. I think it's called a KinematicBody. Um and then they have dynamic bodies so you could just use little circles, you know, to represent the mushrooms and the barrels and everything. Um and they—they handle like what happens when one type of body bounces off another one because that's another issue is like, you know, what if you who have like total control over Mario? Let's say there's something like a barrel and Mario pushes the barrel against the wall. You know what happens is that barrel gets squeezed and then explodes. You know, like you see in physics engines I go flying or does Mario stop moving? Like there's all this complexity, and—

1:10:58A:the game engine, you know, will really help you navigate all of that.

1:11:04B:Talking about barrels and pushing in this, I think um also—and you can correct me if I'm wrong—but I was telling Jesus is one of those things that pops up with Discord, not in our Discord, just in general, which is Entity Component Systems. Like one of those game development philosophies. So I think good Joe Jason mentioned scenes and the sort of hierarchy, but I think Godot famously does not sort of natively push the Entity Component System, which is one way of handling what we're talking about, which is hey, you have all these things moving around—you have enemies and you have, you know, rotating fire flamethrowers and swords and pickups and all of these things need to be sort of tracked, inventories and what's in your backpack, and you know all of these things, you know, need to be handled, rendered, updated every frame. And so it becomes a place to sort of, you know, be rigorous in how you're going to not handle each specific object uniquely but handle sort of all objects collectively in a common way and have a common thing. And so the Entity Component System approach—oh, I'm going to see if I can get this right. So entities are roughly sort of IDs into the world. Um so rather than everything being a pointer, you give everything a unique ID so that the system can refer to other IDs and do things like, you know, garbage collection off, you know, off frame or phasing them out or changing them between levels. And so entities are—and then the component is sort of like the thing in the sort of inheritance hierarchy. It's like it is an object it has properties and attributes that you can add, and they can be common across like this is a this is a, you know, barrel. Do you want barrels to be destroyable or not? So it does have a destroyable attribute or it's not. Is it squishy or non? Is it rigid or not rigid? I guess it's there we go. Um and then the system is the yeah, the thing that runs it, right? It hooks up all of the calls that need to be routed between each other and does the updates and sort of flows everything through. Um and it's a way of modeling.

1:13:02B:Um this—that the other places take, I think there's some sort of extensions to Godot that will allow you to implement this. It's not a game engine unique thing. You could develop other code that uses the same kind of logic. Um but this is just one of the things some game engines use. And then Godot uses a sort of a hierarchy instead through sort of inheritances to show some of this and sort of a more—I I think am I am I sort of on the right track? Yeah, no, you're nailing it. Yeah, yeah. Okay, good. But this is one of those trade-offs that your game engine, I think it's a little bit, you know, I described like a menu, but it's sort of like it may bring its own approach. It doesn't prevent you from using something different and really going in—in sort of the ECS, the Entity Component System, but it's sort of out of the box. It's not gonna kind of do all that piping for you. And this is one of those people will go opine for long blog posts about the pros or cons of such an approach.

1:13:56A:Yeah, I mean one thing where I tried to make a game a long time ago, um just in C++ from scratch. I tried to write my own game engine who's not smart, but to be fair, it was a text-based is like one of these rogue type games where I didn't need a lot of graphics. But um one of the things that really tripped me up back then was circular references. You know, like if I if I have a sword, then like the person has the sword, the sword's attached to the person. Um and just like what how do you break that reference elegantly? Like for example, um what if you have a sword that is like a, you know, a like a magical sword that disappears after 10 seconds? Like it's part of a spell, right? And like as you're swinging the sword, the 10 seconds are up. You know, like there's weird things like that where like oh, you know the sword disappeared, but now like you know you had already committed to swinging the sword, so you just get these weird effects, right? Um and you know one thing Godot does is it has this like a type of queuing system where you queue an object to be freed, but it kind of keeps it around for a little bit longer just to make sure that you don't have this—this uh sort of—so it's a form of deadlock in a way, sort of deadlock issue. Um and that fixed a variety of issues I had especially when I was changing levels in AI Hero and I was trying to like tear everything down. Um You know, with Godot, it just kind of like took care of all of that for me. But I know in past projects, you know, I've had a bunch of issues where even Maim Hub Maim Hub crashes on exit, and I still don't know how to fix it. So so um you know, it kind of alleviates all of those those issues for you of dealing with, you know, C++ pointer nastiness.

1:15:52B:Um speaking of C++, because we haven't said so, Godot programming languages do. You want to take it out?

1:15:59A:Oh yeah. Um good call, man. Um so yeah, so Godot uses something called GDScript. Have you seen this, Patrick? Yes, yeah. It's—it's very similar to Python. There's just a few tiny differences, but um but yeah, I found it very approachable in the beginning. Um I didn't want to have to learn another language, to be honest. So I thought let me try Godot with C#. There is a they call it Godot Mono, but that was just plagued with issues. I mean, it was brand new when I was trying it out. This was Godot 3, and um it's just—I just had so many technical issues. I was like, let me, you know, there's not that much code in AI Hero. Let me just learn try out this Godot Script, and I'm so glad I did. I mean, it took almost no time to learn. Um You know, there's just a few like really subtle differences. Like I think, you know, in Python you use enumerate when you want to get a—um so if you want to get like if you want to do a for loop over a list of objects but you also need the index, so you need the object and its index at the same time. In Python you do like `for x in enumerate(my_list)`, right? I think Godot it's something different, but it's like these kind of really minor things. Um And in exchange, like, you know, it was such a better developer experience. Um Now I think the C# is getting much more mature.

1:17:36B:I think you can also do stuff in C++ as well. So I think C++, C#, GDScript—those are kind of the core ones, and then I think they're, you know, like in general bindings for other stuff if you if you kind of want to, but you sort of start to leave the—I know there's like some core functionality you want to kind of stay in. If you if you don't know that you need to specifically do something or you're on a, you know, quest, you want to say stay in kind of one of those. So the other thing that we alluded to, like I mentioned when we were talking about Entity Component Systems or the sort of plugins, but I think another thing a game engine gets you is again this like core functionality being there and offering stuff. You can go get other libraries to do things for you. So we've talked about that when we talked about Unity, and they have sort of the Marketplace as always, like, you know, paid and free sort of extensions. And Godot has something similar. So there's things that you can go grab and just add in that you really wouldn't want to do from scratch. So you want to show ads? What kind of ads you want to show? You know, like little banner ads or, right? Like you're going to get all of that for you. Or, you know, please I don't even want to go down—never had to do it myself—but like you want to offer unlocks or, you know, in-app purchases or do a please don't freemium game that has microtransactions? Like you really want to code up all that stuff by yourself? Like

1:18:52A:No, so yeah, I mean talking to all these different services because you have to talk to the Google service for Android and the iOS service for Apple, so you're not—you will have to at least code it twice, and it's probably going to be very painful. God, oh just.

1:19:07B:Handles it? What is the in-app equivalent for PC? Is there one? I don't actually know. Like is there a DLC? Right? This is okay. So like you would just like Steam App or through like—I don't know. Like how would? Okay, yeah, it's

1:19:20A:A good. So you know, I yeah, okay, there's two types of microtransactions, right? There's—there's DLC and then there's kind of like buying, you know, I guess like cosmetic stuff or or buying like advancement in the game, right? Um that second one, yeah, I really don't know what your options are for PC, but the first one would definitely be DLC. Like you could say, you know, like Polytopia is a good example where you have to buy the different races, you know, to play them, and it kind of like unlocks a bit more of the game. Um and in Steam, you just make each race a DLC and buy it through there.

1:20:01B:Godot when it was early was a lot of tutorials and stuff for platformers and sort of like, you know, I guess basic phone games, you know, the sort of casual, casual games, I guess, like 2D stuff. But I think—and I think that was what you were describing—sort of your game to be to AI here is it's sort of like, but yeah, but recently they've added—they've been working pretty hard to become more fully featured as like a 3D game engine as well.

1:20:25A:Yeah, I mean, I don't have any experience with it. But or Unity that matter for? I haven't done a lot of 3D stuff in a long time, but um but yeah, I think you know Godot is trying to be really, you know, feature complete with Unity and Unreal and those alternatives, which is great. My personal advice: I wouldn't start with a 3D game. Um there, you know, people will say there's advantages like if you have a 3D mesh it doesn't have to look as detailed as a 2D sprite. Like you could basically get away with a lot more on the art side. I don't know. I'm a little skeptical of that, to be honest. I feel like you could have pretty low quality art even in 2D if you have a solid game hook. Um so yeah, I would definitely start with 2D. But Godot, you know, think about Godot is, you know, if you do eventually want to get a career in gaming or you do, you know, you have a vision for a 3D game you want to build yourself up to it, you know, you could do the whole thing. You could build yourself up in Godot and know that it'll—it'll support your 3D game that you want to build. Um getting back to your component system, something that really struck me, that took a while for me to get used to, is there's no like main function, you know? Like there's no entry point. So the way it works is you attach functions to individual entities. So like I attach this function to like—let's just use Mario as an example. So you'd actually attach code to a Goomba and that code would say like every tick, you know, move left until I hit a wall, then move right. And you would like actually just attach that code to the Goomba, and it just floats in isolation. Um and you could attach that same code to the Turtle. You could even say in that code like 90% of it's the same, but you could

1:22:21A:even have a clause saying like if Turtle then like—let Mario turn me into like from a living turtle to a shell or whatever. Um but so so you could do some curing and stuff, but it's not like a traditional program where you start with main and then you set up some things and then you have a for loop that loops through all your characters. Like there's none of that. Like you're writing little tiny snippets of code and you're relying on the engine to systematize all of that. Um that was something it took a ton of getting used to, and writing code that was not garbage in that way was actually took a lot of practice. Um but but I also once I got used to it, I really enjoyed it. I like the fact that you know I could just like create a new thing, give it some code, and it could just live in the existing universe. Um that part of it was really exciting.

1:23:22B:Well, being the one of the two of us that have actually written a game in Godot, all right, you got to give it

1:23:30A:A rating. Yeah. So you know, I've tried Unity. You know, I've tried Phaser and a bunch of these. I definitely give Godot an A+. I really loved it. Um I didn't make any money off my game. My game's totally free. There's no in-app purchase or anything, but if I did, I would give all that money to Godot. They deserve it. Um So the Godot gets a hundred percent of the proceeds from a hundred percent zero. Um I was really, really impressed, honestly. I think if you're getting started, this is unquestionably the way to go. Um You know, you know, I think that you know Godot is open source, totally open source. You can fork it. You can make changes to it. I mean, all of that we didn't talk about that. Um That's not the reason I would use it. Um I actually think it is much simpler. Unity is very, very complicated, and you know there's definitely advantages to that. Um But I think if you're starting out Godot is just such a beautiful, very simple experience in the same way as Next.js. It is very opinionated. As I said, you know there's no main function, you know for your global data. Um You know you have to do it using this like special global object, and in the beginning I was a little frustrated with all of the sort of the opinionated nature of it. Um but once you know at the end of it when I launched my game at that point, I totally came to understand why they had made those design decisions. So um you know I definitely think Godot is a great place to get started. There's a really solid community.

1:25:16A:Um and and you never have to worry about licensing issues or any of that. Um You know even if your game isn't a huge hit, you know that's still a lot of red tape to have to jump through getting the professional Unity account or I don't even know what it is. Oh, you know with Godot it's like when my game was ready, you know I just shipped it. So so yeah, I'd highly recommend it. Um There's one thing. Oh, there's Godot 3 and Godot 4. I jumped on the Godot 4 bandwagon a little bit too early, and it was in rough shape. Um You actually can't go back. If you go to four, you can't go back to three unless you know you can with source control obviously, but you lose whatever progress you've made in four. Um But at this point I think four is mature enough that folks can go straight to Godot 4, and it's been a lot of fun.

1:26:13B:Awesome. Well, you know, you mentioned earlier but you know shout out to the shout out to the Patreon sticking with us and all our supporters and people listening to us. I this is a great episode on game development. We always talk about that. It's like one of those first things that everyone always attempts to get in, and so it's a great gateway. I was gonna say drug. That sounds bad. Just just gateway. The great great way to programming. Great gateway. That's

1:26:40A:A hard thing to say. Great Gateway, Gateway, Gateway. Yeah, The Great Gatsby. Um, so yeah, it's awesome. Thanks. Yeah, as Patrick said, thanks so much for our patrons. Uh, we're gonna do the giveaway, so if you've ever wanted to be a Programming Throwdown patron, now is a great time. You could theoretically make money where you could be a patron for a dollar, get a prize, and then punch out. You know, we won't hold it against you. I will say, actually, I feel a little bit bad. Except this is private, so it's not actually incriminating anyone. Someone did do something interesting: elect to become a patron, send me a message saying they should be on our show, and then cancel their patronage before we even got one dollar. I thought that was clever. Um, but I didn't respond. I felt like that was maybe beyond the pale. But being a patron, you know, giving us one buck and then winning a T-shirt, I think is totally above water. I'm totally.

1:27:41B:An ethical life pro tips right here.

1:27:43A:Patrick is shaking his hand. All right. Well, hey, it's a pleasure to come record the show with Patrick for you all. We have a great time and we will catch you all on the next one.

1:28:09B:Music by Eric Barndoller.

1:28:12A:Programming Throwdown is distributed under a Creative Commons Attribution-ShareAlike 2.0 license. You're free to share, copy, distribute, transmit the work, to remix, adapt the work, but you must provide attribution to Patrick and I, and ShareAlike in kind.