Legendary Game Dev Jonathan Blow

Thank you everyone for joining us to the stand-up 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, for combiner, north, a world of heroes.

Can you charm that goblin?

It's too far.

I'll swap him out.

East, the mirror allows.

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.

Close to the treasure, just a few more minutes.

If you don't get back before that storm hits, we're about there.

Fuse and grow, we will it so.

Who are you?

And what are these?

Beans.

They're very useful.

Watch this.

Can you push us down back across the water?

That's water.

When the portal appeared and I stepped into this overworld,

I had never imagined such device that could fuse reality.

Not just mashing together terrains, it weaves the very laws of nature into a composite home.

The result surprises me constantly.

But who has done with this?

And what do they want with me?

That was a really good introduction.

You did kind of nail that.

Yeah, I thank you.

Thank you very much.

If I'm sure that that all happened, okay, fantastic.

Anyways, I'm sorry.

And as always, with us is Teage-DV.

Legendary Teage.

And of course, Casey, Meera, Tori, the one and the only.

Thank you so much.

Also legendary game developer.

Also legendary game developer.

You guys always say that.

But then I'm like, what 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.

But it's great to say that because you got to remember that

your 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 you also.

I also heard direct from the source,

that Casey, you're the one who helped come up with the idea for great.

That's not really true.

It was just, it was a mailing list.

We could tell us right, John, if you want to tell that story.

But it was sort of just like a mailing list argument.

Yeah, that was it.

No, but it is true.

So, so back, I mean, whatever year this was,

2002 or something.

It was ancient history.

You were sort of triple A gaming at that point, right?

On the right, 2004 when 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 triple A studios and then sort of working on my own

little games, right?

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.

He made church numerals, actually.

His father invented church.

And church's thesis also, yes.

And then Mark LeBlanc, who's also a guy,

if you look up his credits in the game industry,

you know, 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.

Any time you say this thing did first.

The time 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,

there's somebody, there's somebody.

PC Junior game did this.

Yeah.

Yeah.

Was that right?

That was PlayStation 2, the remake.

It was on all platforms.

It was on everything.

Yeah, it was on Spotify for it.

It was like the PS2.

Okay, it does really matter.

Whatever with 2000s.

It would have been PS2.

Yeah, PS3 was not out yet.

Hey, is that HTTP?

Get that out of here.

That's not how we order coffee.

We order coffee by a SSH terminal dot shop.

Yeah, you want a real experience.

You want real coffee.

You want awesome subscriptions.

So you never have to remember again.

Oh, you want exclusive blends with exclusive coffee

and exclusive content.

Then check out Cron.

You don't know what SSH is.

Well, maybe the coffee is 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?

But then there was also this thing where you had rewind.

But you also had a traditional game where you have lives.

And you run out of rewind juice.

And then you get killed and then your games 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 at 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, right?

Oh, wow, I don't even have one of those.

That's actually impressive.

I have props.

I have props ready for this.

You think I'm not prepared for this conversation?

Yeah.

Come on.

So just like, just like you could rewind one of those,

this should be a technical feature in 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, OK, 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, right?

And then also just design the game design around it.

So if people are saying it removes the tension of dying,

OK, 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.

Because 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.

So I had been doing this thing at the Game Developers Conference

called the Experimental 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, OK, let's just do that

and just see where it goes.

And yeah, that's how it started.

And long answer.

Sorry, I'm known for long rambling answers.

So this is the standout.

OK, there's anything that's canonical about all stand-ups.

There's someone that always has a long answer.

And this is a good thing.

And 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 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 stuff,

you could just save.

And I was like, 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 experience the game, honestly.

So that was why I even posted it.

That was that was it.

Casey, you're clearly outing yourself

as not a real gamer right now.

Because obviously, real gamers wouldn't have ever.

SAVE SCUMMER!

Casey obviously is coming right there, so.

Well, not really, because the most nerdy,

I mean, I'm saying this is a joke, obviously,

but like the most people who sync the most time

into games are like the tool-assisted speedrun guy.

I was just like, that is not fun at all.

But they also produce the absolute most hardcore speedrun

of a game that you will ever see, right?

That's true.

So I was just on my way to tool-assisted speedrun, guys.

Like, you know, I wasn't saying the tool-assisted speedrun.

I was just like, got hit by a build system,

he wrote for C, it just never quite got the tool-assisted.

I don't see the problem.

It's fine.

So.

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, 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 it 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 fair to say that most people that are listening

can have a chance to understand more about you

and your decision-making process.

Right, so we're going to talk about the design idea and stuff

to grab it, I guess.

So usually, every time I finish a game,

it leaves me with interesting ideas to do in a follow-up game.

But the follow-up game, usually,

is really different from the previous game.

Because that's just how it, 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 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, in 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, OK,

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, OK, there's these little,

I just thought of them as ghost stones initially,

but they're like rounded rectangles.

And you have 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 expands over the course of the game,

let's say.

OK, so I just became very interested 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, there are fundamental things

that the rules have to do.

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 at some point, 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.

And the thing that I realized about that, though,

this is not just my idea about game design.

So there was a very famous, I think it

was like Kim Swift at GDC talking

about how they design portal or something.

And they do this thing where they put a spreadsheet,

and they say, 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 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 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.

So it's like, we can come up with rules

and design them so that they'll interact.

But why do they actually interact?

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 if you look at 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 Steven Wolfram 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, OK,

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 hyper reality

with way more dimensions than you would usually get.

So here's the other thing.

If you're designing a game, at first,

you just have some idea.

And it's usually not as good as you thought.

It's 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 of 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, right?

And so what happens is games 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 we're already in that zone and then matching them together

and having, you know, I don't know,

but 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 match 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, 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 ideas,

if I'm understanding correctly,

each of the like four islands,

I think you called them or something like that, right,

is like it's own, it could be its own game effectively.

It is its own game, in fact.

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

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 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.

Okay.

Can you give a little background on what Raspberry is?

Okay, this is what I was prompting, sorry.

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 had the guy with the little

yeah, pickaxe or whatever.

Marquis tab.

But there's a game prototype

when they're 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, you'll 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 what 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.

What the conclusion that I came to was,

you can't exactly do that in the same way that music works

because game design is like 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.

Yeah.

Would compiling a GI program or a J program

or the language program in 15 years?

Will that be a challenge or will that be a challenge?

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 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 that C didn't really do,

and not to blame C, but 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 in all these things.

But now it's pretty obvious that if you have

an unsigned 8-bit number, that'll fit into a signed 16-bit number,

right, 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 eliminates, and they weren't thinking about that kind of,

I'm not even saying that that's exactly the right decision

that you should make, but it's like 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 craft

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 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 kind of game up on C++ features as well.

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 Roberts still, I believe to this day,

when he has his own stuff,

if he doesn't have to interoperate,

it's the 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, 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 street C.

Where are we talking about 89?

Are we talking 99?

Well, I haven't followed anything since NCC, right?

I know there's like C99 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 Clang or, you know,

GNUC, they now all have things

that you would have been very happy to have way back when.

Like including like how like a for loop might get scoped

for variable declaration 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 norm in like, you know, the 2000.

So K and RC, when I was in college, I was learning C

and there was this shiny new book that said,

NCC 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 NCC 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 and RC, for example,

if you're gonna 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.

So that feels like my experience with the Lixer.

I did this very regularly, tried to pass things

and getting the wrong types constantly.

Yeah, it's exactly what you need when you're just trying

to learn, you know?

It's, 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 passed something

and whatever you want, man.

Whatever you pass is what gets passed and good luck.

Yeah, I mean, to be fair, most modern JavaScript

they use, you know, TypeScript,

which alleviates a good portion of those problems.

They're still the problem of outside objects coming in.

You have to literally hand validate them

with some sort of runtime checking.

You say most.

Or what they are.

Are you sure most is true here?

It's like, it's like all like 75% of new possessors.

It's like some decently good numbered these days,

but that's nice.

That's nice.

That's nice for the youth today.

That's nice that the web finally figured out about TypeScript.

My favorite part is that we do 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 actually genuinely hate it,

but this is a great discussion all,

but I actually want to focus on kind of a question with Jai.

Sure.

Or J, do you, by the way, do you call it the language J or Jai?

Yeah, I don't pronounce it.

Or it's one'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 notice 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, like the marketing name, colon,

and then they tell you what it means.

And hacker news posts are the same, like,

Django poop, colon,

I think that converts all your comments

in JavaScript to uppercase, right?

And like they come up with 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 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.

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 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,

and once you finally have a tool that you're like,

this is the thing I'm gonna 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

and that's gonna go in the game

sometimes we'd 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 of 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 of 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 gonna 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 a card, 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.

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 problem.

Who are you calling it?

You're like, what are you saying?

Why? What?

Yeah.

Now it is true that better syntax error messages

can help people learn really fast.

But that's not like a deep.

So what I found was that once,

and I think this is obvious once you say it,

but once the 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 the internal data

and how it has to be arranged and 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

it 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 because like.

Can I inject one thing to 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 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 run down like dilapidated shack

and someone is like, okay, we've got this beautiful mansion

that we're gonna move to and they're like, 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 gonna move that, right?

And like literally like, you're really like,

well 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 calcified this very academic process

for like moving the language forward

and it always results in substandard features

over and over and over again.

Yeah, so anyway.

And can I also say it does feel a little bit different

to if it felt like, I mean, we already made the joke

about it being impossible to build

an old C++ project.

It'd be one thing if I could pull any C++ project out

from any time and they're like, you have a random one

from 1997, you can compile.

But I feel like I know, 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 gonna keep all the features around

but you still can't build it.

Like what is that?

You get nothing from it.

Yeah.

So anyway, it'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, this like, no, not really.

Yeah, yeah.

So 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 two look and go,

ah, it was probably a new one.

Like you can just make that decision.

You don't have five people of the 10 being like,

that tool is life.

I cannot let go of the two look.

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.

You can't quite do all of those yourself

because like I said, the real problems

happen when you're like 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 gonna 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.

Yeah, to have conviction.

Yeah, something like that.

Yeah, yeah, yeah.

You have to nod and ideology, right?

Like here is what we're trying to accomplish

that includes some things that you will take seriously

and some things that you will just decide

we're not going to do, right?

You, if you tried to do, I mean,

C++ 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 everything and nothing, sort, right?

Like they, they all, it's everything

and nothing somehow, right?

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 overwriting 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 programmers life easier every day

or something, like there's something like that

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 interrupt a job when he's about

to talk about compile time.

So maybe we can try that.

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 do's

or something, right?

It's like 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 classwork,

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 part of the goal was to just try and fix that.

And because 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 and 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 wish I feel like it should be like a quarter of a second.

But we've reached the point where, with the team size

that we have, 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 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 line

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 a temptation

to pull out my phone and forget 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 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 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 sped 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.

So we'll just one word answers.

All right, OK, good, because I got some, too.

All right, here you go.

Do you think that AI is going to save the game

as an industry by forcing RAM and GPU prices up so high

that people actually have to care about performance?

Interesting take.

I'm not sure.

OK, we'll not try to one word 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.

But 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 forged in this fire of really difficult stuff.

And that's become increasingly untrue.

I think game programmers are reverting to the mean.

And so it wouldn't be too bad.

I don't think that I think things are going to adjust

and RAM prices are going to come down pretty soon.

This is just a short frequency trend like all of these.

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 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.

Why did it like, when do you make that decision to say,

you know, 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 plot, 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 backroom doing something

because you're just, you're gonna be miscalibrated.

You're gonna be slow at what you're doing.

You're not gonna have the right amount of experience.

And so being quick early is a good way

to just iterate and learn, right?

However, somebody's gotta be working on really,

whatever you wanna call it, 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 they're 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'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 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.

Blue prints was like seven.

Blue prints and animal well.

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

it's a long target, you know,

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 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 wanna run a business.

That's never been my motivation.

But I have to in order to be able to do what I wanna do.

Cause like nobody's gonna 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 lack of daisicle.

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

and 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 it all, people are not motivated by that

because there's just a bunch of the same slop out there, right?

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.

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 in as an answer

if it's still kind of, if it's a secret.

But why did you call it braid?

Some of these things are just creative decisions

that happen at a relatively deep level.

I don't like to explain them because 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.

All right, 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 dev.

What, don't do it.

What do you mean?

Well, because that's where a lot of people enter into, right?

Like that's where that will always be the entrance.

And because it's just easiest to get something on the screen

and theoretically make $1 million

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, don't 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 of years after me.

That's why the file extension for GIMP is .xcf

because they came out of the same computing lab.

A little bit of trivia for you.

I don't know that.

Yeah, I was wondering about that.

So the X and Xcf stands for experimental.

Yes, so this was like when if you had a computer at home,

it was like a Commodore 64 or 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 like the X and Xf

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 because-

Something's never changed.

Yes.

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,

we're the web community.

We want to make sure we think about these and do everything.

And he was like, you know, angle bracket, IMG,

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 was my experience of the web.

And like, I didn't really love it.

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

in 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 of 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?

OK, fast forward.

And now it's like the language that most software

is written in, right?

Nobody thought that that was...

And that written in JavaScript will be written in JavaScript

is the considered track 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 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 reeducate him

to be a kind and loving young boy?

Or do you try to find Brendan Eich

and say, look, spend two more days

to make a little bytecode engine so that your language

agnostic on the front end, right?

Really big cousins there at the time.

One at software's biggest question.

Yeah.

So I don't know that.

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 know, yeah.

So but the point being, 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 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 is an interpreter engine.

And it just runs this one thing.

And then you can have wrappers around that one thing, right?

OK.

So now we also ostensibly have web assembly,

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 re-target, 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 leverage that

against you in the future as part of their work,

like it would enable incumbent browsers

to come in and displace their market share and all that, right?

OK.

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.

No, 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 that 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 this is all a long-winded way of saying, OK,

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 use to be that easy.

But 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.

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, those tools

are actually incredibly valuable if you want your software

to be high quality, because they bring in

a level of analyze ability 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 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 it.

I definitely don't want Wukash to get pushed back.

So.

Yeah, sorry, long answer.

There was not a one-row answer.

That's OK, great answer, though.

We like it.

Yeah.

That's part of the stand-up.

You're supposed to schedule the stand-up for a certain amount

of time, and then it's supposed to go long.

That's true.

That's what we did perfectly do what a stand-up is

supposed to do.

We've got to get some people what they want.

We're not standing up, though.

I'm just standing up.

You can't stand up for a stand-up.

It's too long.

OK.

Yeah, I would be painful.

Be bad for your knees.

Technically, aren't you supposed to end by asking John what

he's going to get done tomorrow?

Yeah, what are you talking about?

I've got any blockers right now.

John, any blockers?

Yeah.

There's some stuff about the end game.

So we have play testers, 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 days ago.

And it was totally broken, because we'd

chain some stuff in the code, and it didn't work.

And we have automated tests, and the automated tests

claim they worked, but the objects were invisible,

and then also some other things that

were not covered by the tests didn't work.

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 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 to.

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 to like dodge this exploit,

and this level's 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 the road map.

But awesome, the most immediate thing

that I'm doing right after this is I am going

on the Wukash podcast, which go check them out.

You can live and subscribe.

I've started the reign, so that way you can have to get going.

Okay.

There's no requirement that you know.

All right. Thanks guys for you.

Nope. No blockers for me.

I'm just I'm I'm going to go listen to this Wukash podcast.

Nice. Here 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 list 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, everyone.

See you, John. Yes.

All right.

Boot up the day.

Five.

Errors on my screen.

Turn me in a car.

And live in the dream.