The Standup with ThePrimeagen - Legendary Game Dev Jonathan Blow

Episode Date: January 3, 2026

Jon Blow shows up to the podcast and tells us all about the journey from Braid to his newest game, Order of the Sinking Star. We talk Jai, Braid and so much more. Hope you enjoy the episode!

Thank you, everyone, for joining us to the stand of today. We have with us, legendary game programmer Jonathan Blow. If you do not know, he is upcoming releasing a game Order of the Sinking Star. Josh, play the trailer. Let us begin. Template, Four Combiner, North, a wild of heroes. Can you charm that goblin? It's too far.

I'll swap him out. East, the mirror aisles. Will the mirrors repair my soul? Will I pass the test? West, endless caverns, beams of light. Nobody else could get this old mine suit working. So all the rewards go to me. Skipping stones to lonely homes.

I'm close to the treasure. Just a few more minutes. If you don't get back before that storm hits, we're both dead. Fuse and grow. We will it so. Who are you? And what are these? Beams.

They're very useful. Watch this. Can you push a stone back across the water? That's water? When the portal appeared and I stepped into this overworked, I had never imagined such a device that could fuse realities. Not just mashing together terrains, it weaves the very laws of nature into a composite hole. The result of surprises me constantly.

But who has done with this? And what do they want with me? That was really good. You did kind of nail that. Yeah, thank you. Thank you very much. I make sure that that all happened. Okay, fantastic. Yeah, yeah, yeah, yeah, yeah, yeah. Uh, anyway, sorry.

And as always with us is Teague DV, legendary Teague, and of course, Casey, Mira, Tori, the one and the only. Thank you so much, everybody. Also legendary game developer. Also, legendary game developer. Not really. You guys always say that, but then I'm like, legendary for what? There's nothing. We have an actual legendary game developer with us. You don't need to try to hype up the showcast.

We're all good. Thank you. Thank you. But it's great to say that because you've got to remember that you're legendary in the web development space because you're that one guy that always knows what he's talking about, just absolutely ravaging people on the internet. And so you're the legendary game developer. Maybe I also heard direct from the source that Casey, you're the one who helped come up with the idea for Brade. That's not really true. That was just, it was a mailing list.

We can tell us straight. John, if you want to tell that story. It was sort of just like a mailing list argument. Yeah. That was it. No, but it is true. So back, I mean, whatever year this was, 2002 or something? It was ancient history.

You were still out of AAA gaming at that point, right? I read 2004 in my research, but yeah, something like that. Well, the actual mailing list argument might have been earlier. But like I was sort of doing a mixture of like contracting for AAA studios and then sort of working on my own. little games, which often didn't go anywhere, because like many people, I would sort of work on something for a little bit, and then my motivation for it would fizzle out or something. So I was in this mood of like, I want to do something really cool. I'm not figuring out what that is, right? So, and then, okay, so there was an argument with, it's probably okay to name

drop some of the other people in the argument. So Casey was in there. Doug Church, who was a guy whose career started at Looking Glass on like the Thief Games and stuff like that, and who still in gaming today working on some major things. I think we actually mentioned him yesterday, right? He's the one who invented church. Yes. He made church numerals, actually. His father invented church.

And church's thesis also. Yes. Yes. And then Mark LeBlanc, who's also a guy, if you look up his credits in the game industry, they're substantial. And so they were all just, trying to figure out, you know, game design of the future. And the original Prince of Persia Sands of Time had come out.

Not the original Prince of Persia, but the original Prince of Persia remake that had like rewind in it, which has also since been remade, I think, which is why I have to specify that, right? But so this came out, it did rewind for the first time that I recall seeing that in a game. Maybe somebody else. Anytime you say this thing did it first. Sweeper may have had it already. I think that was after, but I'm not sure.

I honestly don't know, but somebody will be like, actually, a PC junior game did this. Yeah, yeah. What was that time? That was PlayStation 2, the remake? It was on all platforms. It was on everything. Yeah, but it was that era, right?

It was like the PS2 era. Okay, it doesn't really matter. Whatever was 2002. Yes, you're correct. It would have been PS2. Yeah, PS3 was not out yet. Hey, is that HCTP? Get that out of here.

That's not how we order coffee. We order coffee via SSH terminal dot shop. Yeah, you want a real experience. You want real coffee. You want awesome subscription so you never have to remember again. Oh, you want exclusive blends with exclusive coffee

and exclusive content. Then check out Kron. You don't know what SSH is? Well, maybe the coffee's not for you. Okay, so it started talking about like, well, this is cool. Obviously, they could have done a technically better job. It was kind of shoehorned into the game design and stuff, right? And so, but then there was also this thing where, like, you had rewind, but you also had a traditional game where you have lives and, like,

you run out of rewind juice, and then you get killed and then your game's over, and it all seemed very cumbersome. And there was just this argument about what is the best way for games forward. And one thing that Casey said was like, look, this is a technical capability, just like you have the technical capability to like rewind a movie back in the days. So a VHS tape in a VCR was an appropriate metaphor still at this time. So he was like, you know, you should really be able to rewind any. Yes. Oh, wow. I don't even have one of those. That's actually impressive. I have props ready for this. You think I'm not prepared for this conversation? Yeah. So just like you could rewind one of those, this should be a technical feature in the

games going forward. And other people in the argument were like, no, you can't do that because it takes away the tension of maybe dying if you can undo anything. And there were points on both sides of the argument, but everybody was also just like busy and doing their own projects. And so nobody actually followed this up with action. And then I was between, I wasn't even really a participant in the argument. I might have dropped some side comments. I was not one of the main people with strong opinions because I didn't know. It wasn't something that I really thought about. And then I was on vacation. I was like, okay, it's time to start a new thing. What if I do this rewind thing and then do it? So both at a technical level that goes to the core

of the system. So it's built into the game. It's not like shoehorned on to reverse state on some other system that it's fighting with. And then also just design the game design around it. So if people are saying it removes the tension of dying, okay, so we're just not going to have that in the game. Let's see if we can replace that with something else that's a different kind of interesting than, because, you know, if you play a bunch of games and all these games are about, I'm worried that I'm going to get killed by a monster, they could have different moods and graphical styles and stuff, but at some point you're playing the same thing over and over. And the mindset, so I had been doing this thing at the game developers conference called the experiment. gameplay workshop where we just try to think every year about look at examples of things that people had done that were different and new and be like what can i do that's different and new and so i was like okay let's just do that and just see where it goes and yeah that's how it started and long answer

sorry i'm i'm known for long rambling answers so this is the stand-up okay there's anything that's canonical about all stand-ups it's that there's someone that always has a long answer and that this is a good thing yeah i will make it i will make it worse by saying the reason that I had made that comment on that mailing list in the first place was because I was playing through some old games from the Nintendo Entertainment System and I was playing them on an emulator and emulators even in that era had added the ability to like fast checkpoint so you could kind of just like you basically could rewind I don't remember if the emulator that I was playing had literal rewind but it had the ability to just like wail on a button as often as you wanted to just save your state. So every time you walked into a room of something you could just save. And I was like, you know, for playing through

these games, that's actually a lot more satisfying because it's like I can control how much replay I have to do of this game. And it just made it a more pleasant experience to like experience the game honestly. So that was why I even posted it.

That was that. That was it. Casey, you're clearly outing yourself as not a real gamer right now. Because obviously real gamers would never. Savescommer. Casey out of himself is a sagecomber. Well, not really because the most nerdy, I mean, I'm saying this is a joke, obviously, but like the most people who sink the most time into games are like the tool-assisted speed run guys.

I was, true. Which, like, that is not fun at all. But they also produce the absolute most hardcore speed run of a game that you will ever see, right? That's true. So. I was just on my way to tool-assisted. assisted speed run guys. Like, you invented the tool assistant speed road.

I was just, got hit by a build system. He wrote for C. It just never quite got the tool assistant. I don't see the problem. It's fine. So anyway. So that, yeah, well, so that's actually good because that kind of leads into one of the first questions I was hoping we could talk about.

Like, because I know, you know, you know, a decent amount about sort of how you got started thinking about braid and a little bit to the witness. I'm interested to know sort of like how did you get, into thinking of the idea of your upcoming game. And like, we'll get there, of course. But like, obviously, we want to talk about your language and, like, making an engine and a bunch of other stuff there, too. So I'm interested to hear, like, when those decision points happened, when you're like, I think it's time to just write a new language for this game. Yeah.

Other way around, I think. It's time to write a new game for this awesome language is what you're trying to say? A little bit. Well, yeah, I mean, the idea for the language came before I decided what game to use it on for sure. I don't know, which order should I answer these questions in. Let's start with what motivated you for order? Because the big thing is that we're just going to go to very technical. So it's very good so that most people that are listening can have a chance to understand more about you and your decision-making process.

So we're going to talk about the design idea and stuff to grant it, I guess. Okay, so, you know, usually every time I finish a game, it leaves me with interesting ideas do in a follow-up game, but the follow-up game usually is really different from the previous game, because that's just how, like, if you start with the actual idea that you want to do, then different forms of game mechanics or structure or whatever might do that idea better. Whereas I think a lot of the game industry likes to do sequels just because it's safe commercially and all that, but I've, like, literally never done a sequel. So in The Witness, it's this game that.

It came out in 2016, so quite a while ago. And the way the game starts is you see these puzzles. They're like little iPad screens mounted in the world really weirdly. And you can trace lines on them, and there's little symbols like in these grids and stuff. And you don't know what the symbols mean. Like, and the game doesn't tell you. And you figure out what they mean just by experimenting. And being an intelligent puzzle player, you slowly build up this idea of what these symbols mean.

And then at some point there's curveballs like, oh, wait, there's a surprise where it does kind of mean what I thought, but there's something deeper about the way this puzzle symbol works. And that's sort of one of the fun things about the game. So I really like that part of that game and that design process. And so after I was done, I was just really interested in this idea. So when I'm designing the symbols, right? At first I was just like, what are some interesting rules that I could attach to these symbols that would make interesting puzzles? But then, as I charted out the game ahead of time in my head before building it, I'm like, okay, the interesting part is going to be when we make these combinations puzzles with the symbols coming together. And so we want them to come together and generate surprise. So like one example, not to spoil too much of the witness, is like, okay, there's these little, I just thought of them as go stones initially, but they're like rounded rectangles. and you have like black and white stones in the beginning, and you're just trying to group them with the line.

And then eventually there's multi-colors, and you're like, oh, this could apply to any color. And then when there's other symbols, the color of the other symbol matters, and it's not just grouping those things. It's grouping them with anything of that color. So your idea of the rule, like, expands over the course of the game, let's say.

Okay, so I just became very interested in this, in this idea that, what game designers do in some sense for any kind of game, not even just puzzle games, is they come up with these rules. But the rules aren't just, like there are fundamental things that the rules have to do. Like if they result in a broken game that doesn't run,

that's not playable, right? If they result in a very boring game that you don't want to play, that's really bad. But then, you know, at some point, like a good game is when the rules are designed that they create emergent complex situations out of simple beginnings. And the reason that works is because the simple initial ideas is what can go in your mind and you can understand and can be communicated to you effectively. But then the surprise and the revealing of new things is what

keeps you playing because you haven't seen everything yet. There could be more that you could get out of this experience, right? And the thing that I realized about that, though, so there's other, this is not just my idea about game design. So there was a very famous, I think, think it was like Kim Swift at GDC talking about how they designed portal or something. And they do this thing where they put a spreadsheet and they say like, here's all the object types. And you could put an X in the spreadsheet cell. I'm bringing it back to stand-up style, right? So we've got spreadsheets. You put an X in the spreadsheet cell when objects interact with each other's type. And then you want that spreadsheet to be like full of X's or whatever, right?

That's an oversimplified way of talking about it. But you could imagine that, right? So the thing is game designers don't actually know why that works. Okay, so it's like we can come up with rules and design them so that they'll interact. But like why do they actually interact? Like what's the engine in the universe that makes things interact and generate complexity, right? And this is something that you see in mathematics. So, you know, if you look at like the mandelbrot set or something, any kind of fractal, you have a very simple equation that when iterated blows out into enormous complexity that you didn't expect there. Or like Stephen Wolfram's stuff.

He has all these very simple cellular automata, right? So there's something about the universe that does that. And game designers don't actually make that happen, right? It's like we're exploiting an underlying phenomenon about reality that we don't stop to think about anymore because we're too busy actually making games. So I wanted to make a game that was about looking at that very closely. And part of that was like, okay, instead of starting with these simple puzzle symbols, what if the ingredients in the soup that we're going to mix together are themselves games that are already fun and complete by themselves? And then we'll mix those together.

And they'll blow up into like a big like hyper reality with way more dimensions than you would usually get. So here's the other thing. If you're designing a game, you know, at first you just have some idea. And it's usually not as good as you thought. It's like not as fun as you thought or whatever. And so you implement the idea and then you start adding sophistication to it or like, oh, this thing happens that I don't like. Let's change the rules to disincentivize that or whatever.

And at some point you iterate on that enough to where it's fun or you lose out on the game of game development. But assuming you succeed, you get to the point where it's fun. And then you ship the game because it was so hard to get there that that's basically all you could do. And so what happens is games sort of have converged at a certain level of complexity of game design, right? Because the process of making them is always iterating up till you reach that and then chipping it. And so this was also a way of trying to force ourselves above that ceiling that everybody hits about how complex is the game in terms of the amount of interactivity. Because we're starting with things that were already in that zone and then mashing them together and having, you know, I don't know.

It's like if you have a vector and you do the outer product with another vector, you get a square matrix, right, for the math people. And then you could outer product another vector and you get a cube. And then you get like a four-dimensional thing. And so we have kind of this four-dimensional space of games interacting with each other. So that was the idea. And that's like the need, you don't have to give any spoilers, but that's like the four different kind of like lands that we see in the trailer and

everything and each one. So like the idea is if I'm understanding correctly, each of the like four islands, I think you called them or something like that, right, is like its own, it could be its own game effectively. It is its own game. When you start playing them, they're completely separate from each other and they have separate characters, separate stories, and separate game mechanics, right? And then later on, we show this in the trailer, so it's not that big of a spoiler, but later on, you know, some dimensional combination things happen. happen and the games then come together and you start playing with the magic mirror from this game, you know, with like the monsters from this game or whatever. And, and you see how those rules play out. And yeah, that's the fun part. Or really, the whole game is the fun part. But yeah. So I wanted to throw one thing in here just because to the extent that I have anything to contribute to this podcast, it's like digging into the back. catalog that some people might not know about.

Would you say it's worth talking a little bit about Raspberry here? Because I kind of see that as sort of like an early experiment with a different sort of, like a continuous version of this that you didn't decide to make it to a full game, but it kind of feels a little similar. Yeah. Could you give a little background on what Raspberry is? That's what I was prompting. This is something you could actually download the old version of.

There is a, I actually worked and never re-uploaded. I have a much more sophisticated version of this game, but you can download the one. I made Raspberry and a couple other prototypes while I was working on Braid. I was feeling burned out like two years into development, and I spent like two months just working on other side projects. If you search for my homepage,

I still have some like hand-coded HTML thing that I barely don't really maintain. Like every seven years I'll go and like tweak something. Put under construction on it? I never did. I never had the guy with a little, pickax or whatever. Markey tab.

But there's a game prototype on there called Raspberry. It only runs on Windows, sorry. And so the idea behind this was a little bit different, but it was about combining game mechanics. And I didn't think about it this way. But it was like, okay, what if you made a game where you tried to use game

mechanics like music, where you have one interaction that's like you're trying to click on things or something, right? And you have another interaction that's like you're trying to dodge things. And you could imagine some number of very simple things like that. And then like in a song, you might have like drums come up really loud for a little bit and do stuff. And then you'll have, you know, guitar come in or whatever.

And sometimes you have everything and sometimes you have one thing. It was about just composing these gameplay interactions in that way over time. And it was a good experiment. The conclusion that I came to was you can't exactly do that in the same way that music works. because game design is fundamentally a little bit lower frequency in the sense that the rate at which your brain can track the changes in what you need to do has some maximum rate before it just is not that fun. But it did work in the sense that like, oh, this is kind of cool and interesting. And maybe I should ship, I mean, I would have to dig it out of source control and compile it again, which, oh my God, compiling a C++ program from 15 years ago is difficult. but, you know, yeah, that was related.

So I think it goes to show that I've been thinking about this kind of thing generally for a long time. Would compiling a GI program or a J program or the language program in 15 years, will that be a challenge or will that? Well, it depends. So part of the reason we're keeping it in closed beta right now is to give ourselves the permission to change things in a somewhat incompatible way. But because there are like a thousand people in the beta now, we still try to smooth it out. So like what I'll do is I'll say, okay, this feature is going to get deprecated and replaced by this other feature.

So first we implement them both alongside each other, right? Then a month later, this one gives you a warning when you use it, right? And then a month later, it gets deleted. But if you take a year off and come back, you might have missed that. And now your program just doesn't compile, right? And there's information in the change log about why. And sometimes we can even leave error messages that say, oh, this isn't how it works anymore.

But yeah, so now there's different levels of changes that are different levels of severity and stuff, right? But what I would say is, okay, so the reason we're doing that is because of my experience with languages like C++, where they had a lot of ideas early on about like what would be really cool ideas and make programming better. And a lot of those ideas are very inaccurate.

there were other things that they really should have done early on, like, that C didn't really do, and not to blame C, but like in the days of C, it didn't make sense to think in a very clear way about integer types, let's say, because there were just all sorts of computers with all sorts of different word sizes. You didn't know what was going on and like all these things. But like now, it's like, it's pretty obvious that like if you have an unsigned eight bit number, that'll fit into a signed 16-bit number, right? If you just, and that should implicitly cast, but if you have an unsigned 16-bit number and you put it into a signed 16-bit number, you maybe should say that that's what you meant to do, right? And it, it eliminates, and like, they didn't, they weren't thinking about

that kind of, and not even saying that that's exactly the right decision that you should make, but it's like a clear, it's a clear idea that should have come up, right? And they just weren't thinking about that stuff and they had all these other things that they added to the language. And the problem with C++ now, or one of the many problems with C++, I would say there are two core ones that drove me to make a new programming language. One is the C++ is completely saddled with almost all of the baggage of almost every idea that was ever introduced, and there's no way to deprecate things, right? So that's a problem. And so that makes the new features worse. So if you actually have a better feature that actually will help people, it actually doesn't work.

as well as it should, and it's harder to implement and slower, because it has to interoperate with, like, all this cruff that's, like, built up over time, right? And so there's a lot of things they just can't really do. Like, I haven't tried to use the modules feature. I don't, I sort of froze my C++ usage at C++11, and even only some of C++11. Like, I do, you know, probably less severe than, like, Casey, you actually use C++. You just don't use most of the features, right? But you use the compiler. Yeah, I kind of gave up on C++ features a while back. Yeah. But like Sean Barrett didn't even use the C++ compiler forever, right? Like he was using the C compiler, which was not maintained anymore.

But he was like so much faster than the C++ compiler. Same with Jeff. Jeff Roberts still, I believe to this day, when he has his own stuff, if he doesn't have to interoperate, it's a C compiler only. And like you can't. So in that dialect of C, the last one that Microsoft made this compiler for, you can't even like declare a variable in the middle of a block. Right?

Like, what? Only at the top. It's bad. Like, original C was really different from modern C. Yeah. Modern C has, like, added a bunch of those conveniences in now, so it doesn't feel that clunky. You can, you can program in straight C. Are we talking about 89?

Are we talking 99? Well, I haven't followed anything since ANCC, right? I know there's like C-99 and stuff. I don't know what those features are. I don't care. Really, we just mean if you go download a C compiler today, whether it's Microsoft's or or Clang or, you know, Gnusi, they now all have things that you would have been very happy to have way back when,

including how like a four loop might get scoped for variable declaration. Oh, yeah, yeah. Or how you would, whether you could use Declare anywhere, those sorts of things. They didn't have any of that, right? You had to put all of your variables at the very top of the function and all that sort of thing, right? That was still the, that was still the norm in, like, you know, the year 2000. So K and RC, when I was in college, I was learning C and there was this shiny new book that said ANCC with a big stamp on the front. But in the used bookstore, they had a book that looked

almost the same. It was the same like C programming language book without the ANCC stamp. And I was like, that's pretty cheap. I'll learn from that book. And that was the K and R version of C. And so I was using compilers at school that could do the newer C stuff, but I didn't know that. And so in K&RC, for example, if you're going to call a function that's in another file because you're organizing your program, you don't declare the arguments of the function. Just whatever you pass to that function, the compiler says, sure, that seems fine, right? And so then you spend all this time debugging because like you passed a double instead of a float or you forgot an argument or whatever. And you just crashed at runtime, right? There was no static type checking on external functions.

That feels like my experience with the Lixir. I did this very regularly, tried to pass things in, getting the wrong types constantly. Yeah, it's exactly what you need when you're just trying to learn, you know? Well, I mean, we say this, but like, welcome to JavaScript, right? Like, fast forward to today and, like, a very standard programming language is still in the state where it's like, yeah, I don't know, you just pass something. Whatever you want, man. Whatever you pass is what gets passed, and good luck. Yeah.

Yeah. I mean, to be fair, most modern JavaScript they use, you know, TypeScript, which alleviates a good portion of those problems. There's still the problem of outside objects coming in. You have to literally hand-validate them with some sort of runtime checking to prove that they are what they are.

Are you sure most is true here, though? It's like 75% of new projects. It's like some decently good number these days. But nonetheless, it's nice. That's nice for the youth of today. That's nice that the web finally figured out about types. My favorite part still is that we do take we take a language that cannot be interpreted and turn it into a language that can be interpreted,

and we call it compiling. It is like we're in a very weird world in that side of the universe, but it's very fun. All right. So I want to actually steer away from the, I love the C++s and, well, actually I don't. I actually genuinely hate it. But this is great discussion all, but I actually want to focus on kind of a question with Jai. Sure. And or J.

Do you, by the way, do you call it the language, J or Jai? Yeah, I don't pronounce it. Or John's artificial intelligence. So I have an allergic reaction to one of the things. So I'm very frustrated with the quality of software, broadly speaking, right? And part of that is the culture of what are people thinking when they sit down and make software, right? And there's a pattern that I noticed that bothers me that doesn't seem to bother a lot of other people. But both in academia and industry, if you read an academic paper that's about somebody's algorithm, right, there's a very classic form, which is they put the cool name of the algorithm that they made up.

up, like the marketing name, colon, and then they tell you what it means. And hacker news posts are the same, like, Django poop, colon, a thing that converts all your comments in JavaScript to uppercase, right? And like, they come up with like the seemingly, this is my cool project name for like something totally stupid. And it's like all the effort goes into thinking about the name or like thinking that if you make a really neat name, then you've passed some hurdle of being a contributor or whatever. And, you know, meanwhile, I'm trying to implement this algorithm from a paper, for example, in a video game and, like, realizing that it doesn't actually work.

And then sometimes under very strict deadlines where I suffer greatly due to this. And just, it's really frustrated me. So this was just like a code name that I made for this language. I don't ever use it. we don't market the language. I don't have a logo for it, which is another thing that people make like first before, you know. And even when it comes to language syntax, like if you start talking about what languages should a feature have, people will talk about the syntax because it's, it is the most concrete and easy to observe thing. But it also kind of doesn't matter that

much. I mean, it does matter at some point like in the end, once you finally have a tool that you're like, this is the thing I'm going to use today for years, then small amounts of friction do add up and they really matter, right? But the problem is that if those are the main things you're concerned about when you're designing a new language, those are relatively shallow problems that you're preoccupying yourself with. And what I found, okay, so let me get back to this other thing that you sort of asked at the beginning, which was like, why did I make the language? Part of it was I was sitting there using C++ every day. So Casey visited in these days, and worked on The Witness.

And we had both an annoying, like, asset processing pipeline for the game, which I won't explain that right now, but it's like, you know, crunching the data that's going to go in the game, sometimes it would take too long. And that slows down your work process. But also just compiling the game was really annoying. It would take, like, a couple minutes, which doesn't sound that long, but it, like, really breaks your flow when you're trying to think about stuff. And it was only a couple minutes because we spent a lot of effort trying to minimize the C++ suffering

about how long things take. And so I was like, I have all these problems. Like, I was kind of sad and depressed working on this game, even though it was the best thing I had ever made, and it was clear that it was going to succeed at some level. I mean, who knows about commercially, but like, artistically, we had at that point succeeded in making a good game.

We just had to finish it, right? And I was still bummed out going into the office every day, just working on this thing. And I was like, okay, part of this is the programming language, and part of it is the asset stuff. And the asset stuff we can look at next time. we make an engine. The processing, the programming language, though, I would go online and look at what are the

conversations people are having because, like, there's a C++ committee, right? And then there's other people making other languages and like, why? What are they saying is their motivation? And I would look at the problems that they say that they are solving. And they had very little to do with the problems that I had from day to day that was making it hard, right? And the thing is, like, when you're working on a smaller program or you're working on, or you're a new programmer, right? You feel like there's certain things that are serious problems,

but actually when you get more experience, you're like, yeah, yeah. Like, you don't really make that many syntax errors when you type later. But if you're a new programmer, you're like, syntax errors are really, I'm drowning in syntax errors. This is obviously a big problem. You're like, why, what? Yeah. Yeah. Now it is true that better syntax error messages can help people learn really fast, but that's not like a deep. So, so what I found was that once, and I think this is obvious once you say it, but like once programs get past a certain size of code and or, because it's like some kind of product function, and or a certain complexity of like the internal data and how it has to be arranged and like, you know, what the structures look like and what the constraints are.

Once it gets past a certain point in complexity, it's just hard to work on the code because it's hard to understand everything and see everything and just know what's going on. And that's kind of the bottleneck is that it just gets complicated. And so that's what I wanted help with was like code that just gets really complicated. And I was looking at what people were talking about. And they just didn't have any of that as a concern. And then the other thing, it was compile times. Can I inject one thing that too?

Like when you look at like the biggest thing that frustrates me when I've looked at things like C++ committee discussions or how they go about like deciding. what and how to put in the language is the mindset, in my opinion, when you're designing a language, has to be that we are trying to make the best possible system for the working programmer. Like, the person who's going to sit down and is trying to get their job done that day,

that is what you need to, unless you are making, like, if you're making some abstract, like, you know, like ML or something like this, or LISP and you're making, you're intentionally going down that road to make a theoretical language, then that you do whatever you're trying to explore. That's your thing and that's fine. But if you're like the C++ committee, your job should be to focus on what is going to allow the working programmer to have the tools they need to succeed every day, right?

But if you actually look at the way that they make decisions, it's almost all about weird, esoteric, theoretical things. Like they are never, they will never go like, okay, well, we have to make this thing work because this is what would actually be effective in day-to-day work. So we'll go and we'll deal with ugliness in the theoretical realm or something as a result. They will never make those decisions. And it always ends up feeling a lot like, you know, you're in some like rundown, like dilapidated shack. And someone is like, okay, we've got this beautiful mansion that we're going to move to. and they're like, whoa, whoa, whoa, whoa, whoa, whoa, we can't move to that mansion.

I planted this tulip bulb back at the shack, and I don't know how we're going to move that, right? And, like, literally, like, you're really like, I'm like, what? Like, you guys, like, you guys decided you can't do any of these things in the good way that you would have done them because of this one little thing. And, like, no, like, this is why the language keeps getting worse. And so I do think, like, there's this, there's, in some languages, they've, they've calcified. this very academic process for like moving the language forward and it always results in substandard features

over and over and over again and so anyway and can I also say it does feel a little bit different too if it felt like I mean we already made the joke about it being impossible to build an old C++ plus project it'd be one thing if I could pull any C++ plus project out from any time and they're like

you have a random one from 1997 you can compile but I feel like I never so it's not even like you're getting this feeling of like, oh, I have this rock solid thing I can always build. It's like, we're going to keep all the features around, but you still can't build it. You get nothing from it, yeah. That's like the history of all of computers, really, is like there's these stated reasons why

things are the way they are. We need to do it this way to get this benefit. And then you actually ask if you get the benefit. And it's like, well, we get 5% of the benefit. Yeah, yeah. They're like, no, not really. So a question would be, is that a design by committee problem? Because, John, you're like, you're effectively the decider of the language.

You're the benevolent dictator of it. Yeah. So do you avoid a lot of those problems? Because you look at the tulip and go, I'll just play with the new one. Like, you can just make that decision. You don't have five people of the 10 being like, that tulip is life. I cannot let go of the tulip. Like, you don't have to make those fights.

You can just say, no, this is the way. It's the best way. Yeah. I would say that the problem still occurs, even if you have a benevolent dictator, because you do want to listen to your audience a little bit. at least as part of a grounding like so even if you think you have the best ideas and nobody else can have better ideas which is not usually exactly true you still need to listen to people to know like okay i have an idea that doing this feature this way will help a certain class of program

there's people out there writing that class of program they can tell you if that feature actually did what you meant it to do or not um you can't quite do all of those yourself because you're like i said the real problems happen when you're you're you're the real problems happen when you you're deep in a very complex program. And you can write like little demo programs to test your features out and stuff, but you just don't have enough human life years to like write all these super deep programs. So you need to talk to the people who are using your thing. And they're going to have all different opinions about what you should do.

And you need to just like not listen to some of them. Like that's simply how it is. Because if you listen to everybody with an equal weighting, it is equivalent to design by committee. And so you just have to say, I'm sorry. it's, you know, for some people, it's not that you necessarily have a worse idea or anything like that, but this language has to pick a direction to go. And it's just not that direction. And maybe a different language could go that direction, right? And maybe that's better.

Like we're just, you know, you're doing some hill climbing process, right? Where hill climbing is this thing in computer science where you start out on some landscape and you just, you only can look nearby, probably. And you just go the way that seems the best, but you don't exactly know. And this is an entire class of algorithm in computers, right? And so you're kind of doing that. But you have to, if you listen to everybody, you'll add up all these vectors that point in all these different directions, and they will sum to zero, and you will not go anywhere, right? And so that's a – so you just need to be willing to be a little bit, like, not even exactly disagreeable,

because you don't have to argue with people or anything, but it's just like, look, that's just – I appreciate that you want this thing. It's just not what we're doing here. You have to have conviction. Yeah, something like that. have to, yeah, yeah, yeah, you have to not be a super people, right? Like, here is what we're trying to accomplish that, that includes some things that you will take seriously, and some things that you will just decide we're not going to do, like, right? If you tried to do, I mean, C++S also has a little bit of that problem where they don't have a strong idea of exactly

what we are trying to accomplish at the end of the day. So, right? Everything and nothing, sort, right? Like, they, they all, it's everything and nothing somehow, right? And, and so, you know, it also pays to have, separate from design by committee or not, if you're going to have a committee design things, it helps to have an overriding idea of like, we are trying to get the language to this place and accomplish this thing so that we have like a guiding principle.

Like I said, like, make the working programmer's life easier every day or something. Like, there's something like that you could point to so that somebody on the committee can argue, look, we're just going to have to trash the tulip because we really need,

like, this mansion is going to be so much more helpful for everybody. And we need it to be good or whatever. Anyway, I interrupted John when he was about to talk about compile time. So maybe we can jump out. Oh, yeah. Well, that, so there are friction things. And so when people talk about like, oh, the syntax needs to be good or whatever, they're talking about the minute-to-minute pleasure of using a language.

And for some reason, people focus on that. And then, you know, it takes two minutes to compile Hello World now. And it's like, what happened? How am I supposed to have a thought process? How am I supposed to develop when it's like so painful that I just sit there and wait to see what happens. And so that was an emphasis from the beginning. Also, because I come from the world of video games, like even a video game 10 years ago did an insane amount of computation in one frame, especially on the GPU, which is a highly specialized very parallel thing. But even if you factor

that out, the amount of stuff that a video game does just to figure out what to put on a screen is very high at a very high rate. And it's because that was just like the fitness function under which the industry evolved. People wanted games that rendered smoothly and looked good, right? And, like, for some reason, no such fiction fitness function exists in programming languages. There is one, but it's like, it's something about how cool of an anecdote can you post on hack or doze or something, right? It's like not, it's not really to do with usability. I mean, at some level there is, I don't know, it's complicated.

But, you know, so looking at these compilers, I was just like, look, I've written compilers. before, never as serious as this one, but like in college, I wrote like 12. Instead of doing my homework and doing class work, I wrote like 12 compilers for different languages. And so I knew how it worked and I knew what they were doing under the hood. And I was like, it's way less computation than a game does actually. And so it should be really fast. And so, you know, part of the goal was to just try and fix that. And because, you know, we're decently, we've done a pretty good job at that. So our 300,000 line game does a full build. We don't have incremental builds because that's, in my experience,

another source of bugs in confusion. Like, even the more you have to think from minute to minute about what are all the different ways that a thing might be building and which one is selected, right? It's just another roadblock. And so it's just like, look, it's a full build all the time. Right now, that takes about two seconds for a debug build, which is longer than I wish it was. I feel like it should be like a quarter of a second. but you know we've reached the point where with the team size that we have it's it's hard to push that number down without concerted effort and we're still trying to ship the game and all that right but that's still you know a lot of these other languages that have been made in the past 10 years how long does it take them to compile a 300,000 online program like way way way longer and it's just like decisions that are made about how the language works yeah two seconds is a lot less of the temptation to pull out my phone and forget everything

everything that I was doing than two minutes or 20 minutes. Yeah, it's like just short enough because if you turn around to do anything, the prompt will come back up, right? Yep. It's actually like 1.7. Personally, I think it's really impressive. 300,000 lines for two seconds in modern development that is genuinely unheard of. Because, you know, even in my personal, what's it called, interpreted languages, as of recent,

it often takes more than two seconds for significantly less lines. So this, you know, it's a, that is actually, in modern sense, a very, impressive feat. Yeah, so that's something that our beta users enjoy, you know, significantly. Is that bad up iteration? I know we've got a hard stop. I got a few last quick questions for you, if that's all right. So they might not be quick, so then you don't have to answer them too.

I could one word answers. All right, okay. Good, because I got some too. All right, here you go. Do you think that AI is going to save the game industry by forcing RAM and GPU prices up so high that people actually have to care about performance? Interesting take to you. I'm not sure. Okay, we'll not try to one more to answer that.

Here's the thing. You can also include web development as well. Yeah. Well, yeah, I don't do web development much ever. Yeah. But like, so this is a problem like games for a while was known as, the place where there were still a lot of really good programmers because we were like forged in this fire of really difficult stuff and that's become increasingly untrue. I think game

programmers are like reverting to the mean and so it wouldn't be too bad. I don't think that like I think things are going to adjust and ramp prices are going to come back down pretty soon. This is just a short frequency trend like like all of these. Yeah yeah. But yeah. Prime you want to ask one? We can alternate. Yeah. Common wisdom says or at least common wisdom on Twitter, so it may not be actually wisdom or common. It suggests that you should be making a game and getting it out fairly fast and and making sure your concepts are good and getting it in front of people and all this kind of stuff. You shouldn't go and hide yourself away for many years to build one game.

You obviously having the time to build a language, build an engine, then build a game 10 years total. When do you make that decision to say, no, actually taking your time, taking the 10 years, taking the five years, this is actually the more superior choice. Like, when do you know to make that decision? For me, it usually happens gradually. So all of these projects I would have envisioned being shorter. Like, this game was supposed to be the proof of concept game with like a simple engine just to prove out the programming language.

And it turned it. I just always want to do a good version of everything. And then, I don't know, there was like a lot of weird stuff that happened over development that I won't go into about like what different people on the team want and things. And so we ended up making. an engine that's actually more sophisticated than the one for the last game when I was hoping for simple

but it means the game looks really beautiful and yeah but here's the thing so I think that that advice that you said is the right advice for someone new to games or just projects generally like if you have never shipped anything before you should not spend five years

in a back room doing something because you're just you're going to be miscalibrated you're going to be slow at what you're doing, you're not going to have the right amount of experience. And so being quick early is a good way to just iterate and learn, right? However, somebody's got to be working on really whatever you want to call, like moving things forward and not just trying to release something and make some money. Like there have to be adults in the room somewhere who are worried about actually improving life in some way. And sometimes that's just really hard.

If you could find a way to do that, in fact, there almost always is a way to do that that's actually small and incremental. It's just, that's not the way that I think, apparently. But for me, it's a lot more about motivation. Like, if you can, yeah, however long it takes to do something that's genuinely meaningful is how long you should take, if that's your lot in life. And that's different from the guy who's like, I just, I'm supporting my family by having a job. That's cool too. That's totally fine. But we need some percentage of people who actually are trying to like lift up the quality of things. Otherwise, it'll just be an eternal slide into a pit that we never get out of.

Recently also, oddly enough, there's been some examples of these kind of long gestating games that I think might have also been first times. Like I want to say both blueprints was like seven years ago. I don't know if Animal Well was his first though. We're both very long gestating single person or close to it games. Yeah. And so if you think you can hit the target. And they sold fantastic. They were very, very popular, right?

So it's kind of hard to guess what's going to happen. I think you just, it's nasty. I mean, the thing that we don't see is how many of those did the same strategy. And they just weren't, they just didn't have the best idea or whatever. I don't know. Yeah. Any advice for people balancing CEO of Game Studio? and someone who wants to be programmer slash designer.

So the way that I do that is by not CEOing very much. Because as you know, programming takes a lot of time and game design also takes a lot of time. So one thing that I'm doing this time that helps somewhat is I did sign this game with a publisher. This is the first time that we ever did that. Part of that was to get additional funding to help finish the game,

but part of it was just like they have a whole information infrastructure for like doing stuff that left to my own devices I would do but not as well. So like marketing the game like they're running ads for the game right now. I wouldn't be running ads for the game right now. And like all these things just like so we're kind of delegating some of that to this other company who now also has a financial interest in the game succeeding and all that. And so I think that's good. I never I don't like want to run a business. That's never been my motivation, but I have to in order to be able to do what I want to do, because nobody's going to pay you to do some weird thing that they don't understand. Now, in the earlier days,

the game business was easier, and so I could kind of be a little bit more, just lackadaisical, especially, like, when there was no teams, it's just me working on braid and, like, with occasional contractors. It's a lot cheaper, and it's like, you can just make whatever decision you want, it doesn't matter that much. Now there's like a pretty serious burn rate and there's people and like, so I have to balance this. Like we have to stay in business and not be like constantly losing money year after year. But at the same time,

if you turn into generic business making generic product, that's also bad because it's not what I signed up to do. And people are not motivated by that because there's just a bunch of the same slop out there. And so it's actually kind of hard. And the past couple of years, we have survived the massive slaughter of 2023 to 2024 that afflicted a great amount of game industry. Yeah.

So we'll see. Cool. All right. So I don't know if you've answered this one anywhere. I could not find it. You don't have to give it an answer if it's still kind of, if it's a secret. But why did you call it Brade? Some of these things are just creative decisions that happen at a relatively deep level.

I don't like to explain them. That's fine. sometimes the magic is in the non-explained things. And so I'll just say it's part, there's some kind of, the idea for the game involves like a mood and a feeling and like a texture. And that was just part of it. And that's all.

Cool. I got one that I feel like is really good for Twitter. Okay. If you could give a two minute, one minute piece of advice to all people coming into modern web dev, I don't know anything about modern web debt. Don't do it. What do you mean?

Well, because that's where a lot of people enter into, right? Sure. That will always be the entrance. And because it's just the easiest to get something on the screen and theoretically make one million dollars by making another chat wrapper. So if you were to give somebody an advice other than don't do it, what would you say to them that could potentially put them on the right track? So in 10 years, they look back and say that guy was right. I'm going to say what I think the right answer is. And this may not do it.

You can say whatever you'd like. Yeah, still don't do it. But here's the thing. Okay, the web started. I saw the very, very beginnings of the web and chose not to participate. So just to spend like 30 seconds giving a little background. I was at UC Berkeley. I was in this place called the Experimental Computing Facility,

which is just like students enthusiastic about programming. The Gimp guys were there a couple years after me. That's why the file extension for GIMP is .XCF, because they came out of like the same computing lab. A little bit of trivia for you. I did not know that. I've always wondered about that. So the X and XDS stands for experimental.

Yes. So this was like when if you had a computer at home, it was like a Commodore 64 or like a not that good of a PC. You didn't have an equivalent of a Unix operating system at home. That was not a thing. And so if you wanted to program real programs on real computers, there were these workstation class computers that were in relatively short supply. There was a whole controversy that the XEF snagged allocations from the university that were meant for another group called the Open Computing Facility.

And there was like a war between the students about this. All that happened a little bit before I showed up. Okay. So there was a guy next to me named Payway who wrote one of the first web browsers before I even knew what that was. It was called the Viola browser. It doesn't exist anymore, but you could look it up. And I was at an early conference and Mark Andreessen was there. and everybody was angry at Mark Andreessen.

Something's never changed. Yes. He was making the mosaic browser at University of Illinois Urbana-Champaign, and web browsers didn't have images at that time. They just couldn't display bitmaps on the screen. And there was a discussion underway that was one of these laborious committee discussions that Casey's talking about because it was like, the web community, we want to make sure we think about these and do everything. And he was like,

you know, angle bracket, I.M.G. Angle bracket file name or whatever, you know, URL. Boom, it puts it on the screen. And they were all mad at him for implementing that and having images in his browser before everybody else. So that's, that was my experience of the web. And like, I didn't, I didn't really love it. I didn't, I didn't stay in web from that time. But it was very, so even Viola, right, was very visionary in the following way. It was not just a web browser that put the text on the screen, but it had an embedded programming language

that was interpreted. It was a lot like JavaScript, but it was a different language. So it was not really semantically equivalent. And then JavaScript came, again, you know, a couple years later or whatever, you know, 96 or whatever year it was, 95. When Brendan Ike

famously did it in 10 days, right? The reason it made sense to do something like this in 10 days was that like, look, it's just to change a couple state variables in the browser about whether they push the button. It's not for real programs. So it doesn't need to be very serious. And so we don't need to use all this.

And we want it to be cross-platform. So it's just going to be a very lightweight language, right? Okay. Fast forward. And now it's like the language that most software is written in, right? Yes. Nobody thought that that was... What can be written in JavaScript will be written in JavaScript is the considered truth

of JavaScript. And so the problem with all that is that somehow we forgot all this thing that we knew about programming. Like it doesn't matter what programming language you use because the computer knows how to run some backend representation, which in the old days was machine language, right? So then you move to the browser. You're like, we want it to be portable. So it can't be machine language, right? But like, it wouldn't have even taken that long. If I had a time machine, it's like, do you try to find baby Hitler and re-educate him?

him to be a kind and loving young boy? Or do you try to find Brendan Ike and say, look, spend two more days to make a little bite code engine so that your language agnostic on the front end, right? Really? Big decisions there at the time. One of software's biggest questions. Yeah. So, I don't know.

I'm not serious. Obviously, the answer is baby Hitler. I'm not, that's not really a joke. But so because baby Hitler was so much earlier in time that maybe everything would have gone better after that. And you don't, you know, yeah. So, but the point being, like, it used to be before the web that, like, if you wanted a language with strong type checking, you had your pick of a whole bunch. And they all worked the same. And they all targeted the same back end at the same level of quality.

So it's not like you were using some janky transpiler to, like, build. some massive 10x too large amount of bloat code that you can't debug or anything. It's just like they would target. I mean, those things did exist too, but you didn't have to use them because you had choices, right? And like we threw all that away and we made this thing where like, now there's an interpreter engine and it just runs this one thing and then you can have wrappers around that one thing, right? Okay. So now we also ostensibly have WebAssembly, but it just because it came in later and people are

not, like all these companies also benefit from the fact that they're the only few people who can make browsers, right, as well, that there's no competition there. And so, like, Google loves that, dude. That's why they put so many resources into the browser. And so they're disincentivized from making it easy to retarget, like, to control your own computing environment, let's say, right? Because if there's a very simple substrate and you don't need Google's permission to have new features or whatever, they can't, they can't leverage that against you in the future as part of their more, like, it would enable incumbent browsers to come in and displace their market share and all that, right?

It's actually worse than that because also you have companies like Apple who are actively invested in not having the web be very good, because if it was, then you don't have to use the app store. Yes. There's like every, and that's not hypothetical. They literally, like you can literally go watch them do that in the minutes of W3C meetings, which I have done. and it's frankly pretty disgusting.

Yeah, so every big company has a different angle on this, but they're all kind of in common. Every angle is about kind of capturing more market share and preventing their current market share from being eroded in the future by competition, right? So that's... This is all a long-winded way of saying, okay, there's good things about a browser.

You can just open a web page. and just there's a program running. And that's something that we didn't use to have. It didn't used to be that easy. But like, we didn't have to throw away all the good things about system software to get that. And there's this fundamental confusion about this. Like, if you just targeted an equivalent to a machine language, but that's cross-platform, well-defined, it has some instruction set.

And then the browser was interpreting that, which is, again, ostensibly what WebAssembly is, but it doesn't quite get there for, I don't know, various reasons. And it's certainly not the default, right? But if we had that, you could run real debuggers on your web program, right? You could do all these things. And so getting that back, like, those tools are actually incredibly valuable if you want your software to be high quality, because they bring in a level of analyzability and and understandability that we just didn't have

once we made the jump to interpreted languages by default. So getting back there would be great. And so this has been a 28 minute long answer by which I'm saying you could like work on getting back some of the things that we lost and getting them back into web infrastructure so that we could have the best of both world. You could have the convenience, right?

but also the quality and robustness of older systems. And that would be great. All right. I think you're probably out of time. I don't want to keep. I definitely don't want Wuchash to get pushed back. Yeah, sorry. Long answer.

It was not a one word answer. That's great answer. That's okay. Great answer, though. We like it. Yeah. That's part of the standup. You're supposed to schedule the standup for a certain amount of time, and it's supposed to go long.

That's true. We did perfectly do what a stand-up is supposed to do. We got to get the people what they want. We're not standing up, though. You can't stand up during standup. It's too long. Okay. Yeah, it would be painful.

It would be bad for your knees. Technically, aren't you supposed to end by asking John what he's going to get done tomorrow? Yeah. So what are you blocked? Any blockers right now, John? Any blockers? Yeah. There's some stuff about the end game.

So we have playtesters, and they got to the end game of the final end game, because there are multiple end games. And one of them got there a couple of them. couple days ago, and it was totally broken because, like, we'd change some stuff in the code, and it didn't work. And we have automated tests, and the automated test claimed they worked, but, like, the objects were invisible. And then also some other things that are not covered by the tests didn't. So I've been fixing that. And in the process of fixing that, it's like, oh, there's some feature that I won't spoil. But a good end game is, like, it follows on

naturally from the game that came before, but also brings in some new stuff, some surprises and stuff, right? It feels like the culmination of the game. And some of that stuff, you know, there's a programming part that you've got to do, and then there's the user level part of like,

let me mark up the level to have the right script triggers and like whatever. And like a few of those levels that I had designed were not marked up. And so people went to play them and they're like, I don't know what's going on in this level. So last night, I feverishly fixed a bunch of these things and shipped a new build, because with Steam, you just push a button and deploy it really fast. And then an email from one of the people who's helping out with design, he was like, oh, but you know, the geometry of this level has this bug exploit that I emailed you about months ago that we never got around you.

So I'm like, oh, I thought I was done with it. So I've got to go and like redesign the geometry of the level a little bit. bit to like dodge this exploit and this levels in two places in the game so there's that like the copies have to match up and all so that's what I'm doing and then after that so I'm trying to make time during Christmas break when I'm relaxed and can work on story stuff is the other thing so that's that's my roadmap but awesome the most immediate thing that I'm doing right after this is I'm going on the Wuchash podcast go check them out you can like and subscribe I've started the raid so that way you can

to get going, okay? It is now a requirement that you go. Okay, see any blockers for you? Nope, no blockers for me. I'm just, I'm, I'm, uh, I'm, uh, going to go listen to this Wuchash podcast. Nice. There we go. Yeah, nice.

We're all going to get distracted for the rest of the day. Awesome. Well, thank you very much for joining the startup. If you want to listen, or the stand up, not the startup. If you want to listen to the full podcast, check us out on Spotify. Thank you again, Jonathan for joining us. Please check out and wish list. Order of the Sinking Star.

And as always Casey, thank you for joining us. TJ, thank you for joining us. Of course. Thanks, John. See, John. All right. Booth up the day. Fypeco.

Errors on my screen. Terminal coffee and hair. And hair.