Can I Remake Super Mario World in Godot? (Part 1)

Let’s recreate Super Mario World, from  scratch, in the Godot game engine! I’m going to reverse-engineer the original  game, and go into ridiculous detail about it, and then, well, forwards-engineer it in Godot! Hi there!

I’m wye, and I want to make games! And for my first warmup project, just  to gain some experience with the engine, I’ve decided to recreate the  SNES classic Super Mario World. But why that one, of all games?

Why not  start off with a simple game like Pong, or Snake, or a Flappy Bird clone? For one thing, I’m very  familiar with Super Mario World, and I’m more invested in it than in Flappy Bird. And for another thing, I think I  can handle a more complex project, because I do have some grasp  on making playable things!

My background is in something called “ROM hacks”. Basically, there are tools  out there that let you edit games and build on top of them to make your own! You can build levels, put in new assets - and, if  you know how to program, do pretty much anything!

I’ve spent years making  Super Mario World ROM hacks, and I’ve become very familiar with  the inner workings of the game. It’ll be forever ingrained into my memory what  the tile number of these concrete blocks is, or where the game stores Mario’s powerup state. I know, it’s very impressive, please  try to contain your amazement.

But now it’s time to leave behind  my old retro game dev ways, and see if I can do the same in Godot! I won’t be getting all that far in this video,  which is just part one of however many - but I do plan to finish  this project somewhat soon, and have learned a thing or two along the way. So here we go!

After creating the project folder,  Godot greets me with an empty screen. This is the scratch from which  Super Mario World will be made! I could start by making the title screen, or the file select, but I kinda want to  build a level!

That sounds the most fun. I’m told everything in Godot is a  node, so this level is just a 2D node. And because it’s made out of tiles,  I’m attaching a TileMap node to it.

So now it’s time to make some tiles! There are Super Mario World tilesets online  - or I can just make one myself. This is where my Mario hacking  experience comes in really handy.

I’m just going to open the level editor, build a  kind of dummy level with all the objects in it, and then screenshot that to get a tileset! There’s already a lot more freedom  here compared to making SNES games. I could use any number of tiles  and as many colors as I like!

But of course I’ll be sticking  to the Mario World tileset. The tedious part is defining the collision  for each tile. I’m sure there’s a way to edit multiple tiles at once, and I’ll  be very happy when I figure it out.

But now, with all the tiles in place,  and a solid blue color for a background, let’s get to building the level! Again, it’s handy to have the actual Super  Mario World level open for reference. I’m just going to add a camera node and write a quick and dirty script so  I can have a look around.

…and also do some fun things that would be really  hard to pull off on the SNES, but easy in Godot. But this world wouldn’t be  very super without Mario in it. So let’s add a player character!

I’m going to add a CharacterBody2D node - and save it as  its own scene, because that seems useful. Mario’s collision shape is just a  16x16 box for now. It’s actually more complicated in the original  game, but I’ll come back to it.

For Mario’s graphics, I’ve prepared this sprite  sheet here that has the basic frames I need. To make these into animations, I guess  I could use an AnimationPlayer node, but for this very simple case, I think  an AnimatedSprite2D is gonna be fine. After a slightly cumbersome process (because  Godot keeps forgetting the sprite sheet layout), I ended up with these animations: idle, walk, run, jump, fall, fly, duck, look  up, slide, spin, and turn.

There are more animations in the original game, and more powerups too, and I’ll  be adding them in the future. But for now, I just want to get a basic  player character up and running - literally. Because now, it’s time for: player physics.

I’m not trying to recreate the Mario  World physics down to the pixel, but I do want it to feel like the original game. The CharacterBody comes with  a template script that gives you basic movement - walking around and jumping. But… yeah, this is not gonna cut it.

The Mario World physics are really intricate.  There are documents out there listing most of the physics values, and very patient people  have explained the finer points to me, but to really understand the logic,  a lot of times I just had to dive deep into the game’s code and take  cryptic-looking notes along the way. And the adventures from those deep dives I will  now recount to you!

First, a lesson on speed. How speed works in SNES  games like Super Mario World To make something move, you change its  position by some amount of pixels each frame. So, the basic unit of speed  is pixels per frame, right?

Well, kind of. The SNES doesn't  have any numbers with a “decimal point” - only whole numbers. And  that would be really restrictive for speeds - what if you wanted to  move Mario at 2.

25 pixels per frame? What SNES games do is imagine a unit  smaller than a pixel: a subpixel. In Super Mario World, one pixel is 16  subpixels, the SNES’s favorite number.

That way, 2. 25 pixels becomes a  whole number - 36 subpixels, or $24. This means Mario moves 2 full pixels each frame, and the remaining 4 subpixels  get added to a running total.

When that total reaches a full pixel, Mario moves  by an extra pixel. That way, it averages to 2. 25!

It’s like how leap years work: a  year is about 365 and a quarter days, but we can’t have a quarter of a day,  so we add a full day every four years. Here’s the code from the original  game that does this calculation. So that’s how speed is measured in  Super Mario World - subpixels per frame.

You can also think of it as pixels per frame, but with an imaginary decimal  point between the digits. This is known as a fixed-point number. How speed works in modern engines like Godot In Godot, speed is measured in pixels per second.

Modern hardware and software lets you work  directly with fractional pixel values - so you can change Mario’s position by  2. 718 pixels, and Godot just handles it. But now it’s the time dimension  that’s harder to deal with.

On the SNES, one frame is  just about 1/60 of a second. But in Godot, a frame can take more or less  time, depending on how long it takes to process. You don’t know how many frames there are in a second anymore - but you still  apply the speed one time each frame!

How can you keep the speed consistent if  you don’t know how often it’s applied? That’s where delta time comes in. Godot gives you a variable, usually called delta, that tells you how long the  last frame took to process.

And every time you apply speed,  you multiply it by delta. That way, if frames take longer,  the speed gets applied less often - but it’s a higher speed, because you multiply  it by a larger number! So it evens out!

If you want to hear more of the  surprisingly intricate details, Jonas has an excellent video  on delta time and its pitfalls. But right now it’s time to climb out of that  pit, and put all this knowledge to good use! In Super Mario World, Mario’s maximum  walking speed is $14, or 20.

That’s 20 subpixels per frame, or 1. 25 pixels per  frame, or (at 60 FPS) 75 pixels per second. There we go!

…but I still have a long way to go before  this feels anything like the original game. Firstly, Mario actually has  three separate maximum speeds: one for walking, another one for  running (when you hold the run button), and a third one for running  when the P meter is full. The P meter is a kind of gauge that fills up  when Mario is running and depletes when he’s not.

When it’s full, Mario’s maximum speed is higher, and he can run even faster -  that’s also known as P speed. (The P meter was actually displayed  on screen in Super Mario Bros. 3, but here, it’s only used behind the scenes.

) And secondly, Mario doesn’t  instantly reach his maximum speed when you press a direction on the D pad - and he doesn’t instantly stop when you let go. That’s because the game has acceleration. Just like speed changes position over  time, acceleration changes speed over time - so it takes a short while to build  up speed, and to slow back down again.

And when you apply acceleration in Godot,  you have to multiply by delta again! I guess that makes sense, for calculus reasons, and also because you don’t want the  acceleration to depend on the frame rate. Delta is a pretty small number,  and factoring it in twice means the acceleration values end up being  pretty large and not easy to interpret.

But that’s no big deal - I just need to  make sure I’m doing the conversion right. So, with all the speeds  and accelerations in place, the results are finally… still not right.  It’s still a bit off from the original.

Like I said, Mario’s physics are really intricate. It took me ages to figure out the  logic of when the game does what. With a lot of help from Thomas, probably the world’s leading expert  on Super Mario World physics, I eventually landed on this code.

It doesn’t  seem like much, but I’ve agonized over this. Here are just a few fun facts about it: #1: acceleration and deceleration is  different depending on the situation. If you’re holding a direction on the D  pad, Mario slows down quicker than usual, but if Mario is ducking, he takes longer to  slow down, even if you’re holding a direction.

#2: if Mario is in the air and  you’re not holding a direction, he doesn’t speed up or slow down at all. That’s why when he shoots out from a pipe, he actually moves faster if  you don’t hold a direction! #3: the game never really caps Mario’s speed at the maximum - it just makes  him slow down if he’s too fast.

When Mario is running, his  speed is constantly fluctuating! He briefly goes above the maximum speed, so he slows down, and then he speeds  back up and goes above the maximum again. And on average, that comes out  to exactly the maximum speed.

So after implementing all of this in  Godot. . .

yeah! That feels pretty good. Mario’s position is still a few pixels  off in the long run - literally.

Either way, I’ll say this is good enough. It  definitely feels like Super Mario World now. I’ll just add some dust clouds when  Mario turns around.

That’s an easy thing for a change - I just need to make  it a scene, give it an animated sprite, and add code in the player script to spawn it. And now, we can move on to moving up. Mario’s jump is surprisingly easy to  make!

There’s not that much logic to it. When you press the jump button, Mario  moves up. And every frame there’s gravity, which changes his speed over  time, like downwards acceleration.

So after jumping, Mario slows down  and then starts falling down again. I remember reading somewhere that  Super Mario World doesn’t actually apply gravity while Mario is jumping up, so  his upwards speed would actually be constant. But as far as I can tell, that’s just not the  case.

Maybe I’m misremembering the rumors. But Mario’s gravity can change! While you hold  the jump button, it’s only half as strong.

So when you hold the button the whole time, Mario jumps higher and doesn’t  speed up as much when falling. That’s also what lets you run  across these one-tile gaps. And of course, Super Mario World also  has the spin jump, which has pretty much the same logic as the normal one,  except Mario jumps a little less high.

When I coded the jump, I noticed  Mario was jumping a little higher in my Godot version than he does in  Super Mario World for some reason. That “some reason” turned out to be: I forgot to  apply gravity to Mario when he’s on the ground. That extra frame of not having gravity  pull on him can make a difference.

Mario’s upward speed, and thus his jump height,  actually depends on how fast he’s running. So the faster he runs, the higher he jumps. And technically, there’s not even  a limit to this jump height!

It’s only limited by how fast he can  run, and that does have a limit. But if I were to remove that, just  for the heck of it, then… yahoo! Now that we have walking physics and jumping  physics, let’s get to… walking physics.

Because you know what I forgot? Slopes. Slopes might be the most annoying  part of platformer physics.

They’re not that much of a pain in Godot, because the physics engine  handles collisions well enough - but recreating the exact slope physics of  Super Mario World is a different story. There are four types of slope in the original  game: gradual, normal, steep, and very steep. First of all, how do I even detect when Mario  is on a slope, and what kind of slope it is?

After some trial and error I found  the get_floor_normal function, which gives you a vector  pointing away from the surface. If it points straight up, then Mario is  on flat ground - and if it’s at an angle, I can find out what type of slope he’s  on by how much it’s leaning to the side. Trigonometry!

Godot actually makes things slow  down when they move uphill - a nice gesture, but I want to have finer control  over the physics here, so I’ll disable that. I’ll also need to set the floor_snap_length, so Mario sticks to the ground a little and  doesn’t overshoot when he walks uphill. Now Mario is walking across the whole terrain at  the same speed, which is a good starting point.

Now, what do slopes do to  that speed? A bunch of things: #1: they change Mario’s maximum speed, so  he’s slower uphill and faster downhill. #2: they change Mario’s  acceleration and deceleration, so he speeds up quicker  downhill and slower uphill.

#3: Mario can slide on slopes when you press DOWN,  and there’s a separate speed just for sliding. #4: on steep and very steep slopes,  when you let go of the D pad, Mario starts walking down the slope on his own. That auto-walk has its own,  separate, acceleration values.

And of course, all these things are  different depending on the type of slope, and also on whether Mario is  walking uphill or downhill, and also whether you’re  holding the run button or not - so I need to check for all those cases. Eventually I gave up giving these numbers  meaningful names, and just hardcoded them all in. I was really struggling with  these very steep slopes, because they’re a special case in many ways.

They’re so steep that Mario can’t walk  uphill even if you hold the run button, and they make Mario slide automatically, without you pressing DOWN, and  without showing the sliding animation! That was pretty fun to find out. I’ve had my fair share of  slip-ups - but eventually, I got slopes under more or less control.

This is all still far from perfect,  but perfect isn’t my goal here! I want to learn how to use Godot,  and I’ve already learned plenty. And the movement really feels like Super Mario  World now!

This seems good enough to move on with. There are so many details I  couldn’t cover in this video. And there’s still so much left to do  here even just for player movement: water physics, climbing, flying, springboards, conveyor belts, more springboards,  Yoshi - not to mention powerups.

But I’ll leave that for another time. For now, I’m gonna add some polish to  the level and give it a background. I’ll make a “Background” scene, add a colored  rectangle node for the backdrop color, and also a parallax layer node, because that seems like the easiest way to  make it scroll slower than the foreground.

In modern games you would probably  just use an image for the background, but in Super Mario World, the  backgrounds are also made of tiles, so I’m adding a TileMap node and putting  the background together from a tileset. And to round off the jump mechanic, I’ll give Mario an “audio stream player”  node and make it play a jump sound. At this point, I think I’d be  remiss not to mess around a bit.

Here’s where engines like Godot really shine: once you have something coded up, you  can just copy it, and now you have two! …or three, or four, or five! But yeah, there we have it!

An okay Mario in an okay level - the start of my adventures in recreating  Super Mario World in Godot. In the next video, I’m probably gonna  take a break from Mario physics, and flesh out the world a bit by making  coins, powerups, blocks, and enemies. …or maybe I’ll just add some more Marios.

Either way, thank you so much for watching! If you enjoyed this video… you’re a frickin’ nerd.