Hey, you see this man right here? Okay,

do you know who it is? Well, guess what,

buddy? If you don't know who it is, you

got to you got to go back to school,

okay? You got to get a little bit of

respect in you, cuz this right here is

Chris Sawyer. Now, you may not recognize

even the name, which hey, I don't blame

you, but you should. He's the man that

can handcraft some assembly better than

pretty much anybody else. In fact, he

handcrafted one of the greatest games

ever, Roller Coaster Tycoon. Yes, we all

know Roller Coaster Tycoon. Okay, that

game has some serious aura as the as the

zoomers say. That game came out in 1999,

6 years after Doom. Doom written in C.

Chris Sawyer wrote his in assembly.

Absolutely diabolical, man. The roller

coaster tycoon optimizations are insane

and we're going to go over three of

them. And the third one, it's kind of

the craziest. It's also just a very,

very good idea. Besides for being

written in assembly, one thing about

Roller Coaster Tycoon is that it has

insane optimizations. If you've ever

played it, it was just creamy smooth on

any system. Now, remember, there's

thousands of individual NPCs, all the

little agents running through your park.

Yes, they were called agents at the

time. And look at this. The system

requirements were nothing. 16 megabytes

of RAM. To put that in perspective, look

at this. This is Node right here. A

little wild true loop. I'm going to do

this. I'm going to hit it with the old

amperand. I'm going to grab that and go

VMRSS and go 2 3 5 6 1 BAM. A while loop

in node

takes 57.3 mgabytes of RAM. Roller

coaster tycoon less than 16. Even the

fabled the bun requires 41.41

megabytes for a while loop.

>> Here at Terminal, we love Planet Scale.

We've been using Planet Scale since day

one of Terminal.shop and had an amazing

experience. So if you want a database

you don't have to worry about, choose

Planet Scale. Now back to the video.

So let's go over this gold standard of

optimization. Now I know a lot of you

have never actually had to concern

yourself with a little thing called

memory. Effectively unlimited and coding

has largely been solved. So you just

don't think about these things. But back

in the day, you had to be a lot more

careful. Now I want you to really think

about something when it comes to Roller

Coaster Tycoon. Every single one of the

park adventurers had some sort of memory

associated with them because each

individual one could become angry, they

could become nauseated, they could

become hungry, or they would just want

to leave the park. So that means every

single person had to have its own

memory. And this is our first type of

optimization. It actually involves the

size of money. Now, individual little

park adventurers, they would have a

little bit less memory associated with

their money. Okay? Hey, you don't got

the memory, you don't got the money. And

that's because the average Park

Adventure, they didn't need a ton of

money. They just needed something, say,

less than 256. So, you could just have

one bite of memory associated with how

much money that Park Adventure had. Or

in this case, it could be two bytes

associated with money. Now, remember,

there could be somewhere between 2 to

4,000 of these little guys walking

around. And so, a singular bite saved is

2 to 4K worth of memory. You can see why

that adds up a lot when you only have 16

megabytes and that is the system

requirement which means you still need

to load up the source code. You still

need to load up all the graphic tiles.

You still need to have the operating

system running somewhere. Therefore,

every single bite actually mattered. So

even the money representation, the

position representation, everything

would be squashed down such that each

character could save the maximal amount

of memory. Now, the next one's a bit

stranger, but it actually makes a ton of

sense. You'll see a bunch of these these

bit shifts of old value, say by two. All

right, so I know not all of you are

going to have some binary knowledge out

there. And let's just face it, teaching

you base 2 might take a bit of a moment,

but you can see this right here. Here is

a value 1 0 1 0 0 0. This value is

actually technically five. That's

because this value is four. This value

is one. You add those two together, bada

bing, bada boom, you got yourself five.

Now, a left shift or a shift that's

represented like this is actually pretty

easy to understand. If I were to shift

this by one, you just actually shift

over all the binary. So, that means the

original value 1 0 1 would actually

become 0 1 0 1 because it's been shifted

over by a singular bit. Now, this value

right here is actually 10. And that's

because a single left shift is the

equivalent of multiplying by two. A

single right shift is the same thing as

dividing by two. Now, you're probably

asking, well, why would you do this? Why

not just multiply by two? It's so much

more clear for everybody. Well, first

off, back then, people knew how to kind

of read a little bit of that binary. But

second off, the reason being is actually

quite simple. A singular multiplication

could end up taking somewhere between 3

to eight cycles is what I've read on the

internet back on those machines. And a

divided by can take tens of cycles to be

able to execute. So, if you can center

your game around these divide by twos

and multiply by twos, you can save many,

many cycles, thus making your game feel

much, much faster. So, in roller coaster

tycoon land, everything's going to be a

left shift, a left shift by two, or the

same thing as multiplying by two,

multiplying by two, or just multiplying

by four. Or you're going to see a lot of

things like right shift three or divided

by 8. I it is a very different world

because everything we kind of live with

today has just almost no bearing on

what's actually happening underneath the

hood or the CPU cycles that are being

taken by individual instructions.

Instead, you just kind of have these

really abstracted concepts and you just

go, okay, hey, I'm going to create a new

object. I'm going to throw some keys and

values in there. One of those values is

going to be a function. I'm going to

execute the function. you don't actually

think about all the individual little

cycles and instructions that are going

through your CPU at any one point, let

alone the memory that you're actually

taking up. Now, the last optimization is

actually the craziest optimization,

which is pathf finding. If you ever

watch one of these little park

adventurers kind of walk through the

park, they just wander aimlessly. They

don't actually attempt to go anywhere.

They actually choose random directions

until they find a ride that they're

interested in. or if they're hungry,

they actually continue to take random

directions until they find food. And the

reason being is that path finding is

actually really expensive. Let's pretend

we have the following graph right here.

And you are right here and you wanted to

leave this park. This is the exit right

here. How would you actually leave it?

For us, it's very easy. We just look

through and be like, "Dog, just goam

bam." Well, unfortunately, computers

can't do that. So instead, you have to

take every single one of these nodes,

node being represented by one of these

little circles, and you have to put it

into a list. And then you're going to

have to resolve slowly how to find the

exit. This is called Dystra's shortest

path. It's a decently complicated

algorithm that involves a minimum heap

and you have to store a bunch of values

and you have to look up stuff. But for

the sake of it, you can obviously see

having to do this for say 2 to 4,000

individual agents every time they want

to go somewhere is clearly going to

cause frame stuttering, especially on a

90 megahertz CPU. So to put that into

perspective, that means without any

instruction optimization. These CPUs

back then were over 30 times slower than

the CPUs you have today. Just pure raw

instruction power. Not to mention

reading from RAM, significantly slower.

So doing this kind of thing over and

over again for every single agent would

just cause massive frame freezing. But

pathf finding did actually happen in the

game. It would happen under two

conditions. One, if there was a

mechanic, the mechanic would come in and

try to find where in the park is a ride

actually broken at. And they would get

up to eight paths they could look into

to go and find. So they'd be able to go

decently far, but sometimes even the

mechanic couldn't find the ride it

needed to go fix. And two, when one of

the little park adventurers needed to

leave the park, they would get up to

five depth to be able to leave the park.

And if they couldn't find that, you

would end up seeing a picture like this.

This very familiar picture. They're

angry. They can't find the park exit.

And did you know that if you sold

individual customers maps, those that

had maps, they'd get up to a depth of

seven to be able to search for an exit.

Meaning you would have happier customers

not to find the rides. No, no, no, no,

no. Which was always a little bit That

is a very surprising fact. They bought

maps not to find rides, but to find

exits. And all of this was done just

simply to be able to make Roller Coaster

Tycoon run. The money size was to help

reduce RAM usage. The multiplication and

division being XNATE in favor of being

able to multiply or divide by two CPU

optimizations. Then Pathfinding, the

ultimate CPU uh optimization was

throughout the entire game to prevent

frame stutter. And all of this was done

not in some highlevel JavaScript

language, but just straight up in the

Lord's language, okay? Assembly. All

right? So, the next time you see this

face, put a little respect on it, okay,

buddy? Because this face right here,

this is the face of a man who made not

just one roller coaster tycoon, but two

roller coaster tycoons in assembly. The

name is the primogen.