00:00:00
I know virtually nothing about Rust. But, what I do know is that it’s one of the most hyped [music] programming languages in the world right now. Developers love it, and it keeps winning awards for being everybody’s favorite. So, I’ve decided to try to learn Rust and find out if it lives up to the hype. The problem is that Rust is also one of the hardest languages to learn. Because, unlike most languages, Rust won’t run just any sloppy code. It checks that everything is perfect, and if it doesn’t

00:00:26
like what it sees, it refuses to run at all. It’s very stubborn, just like me. So, I’ve set myself a challenge. Go from zero Rust knowledge to a fully working game in 24 hours without using AI. I’m talking pure hands-on keyboard coding here. And if I can’t pull it off in that time frame, I’m going to let the top comment on this video choose my next programming language. You guys suggested this one in the last video. Anyways, let’s get started. Start the timer. >> [music]

00:00:53
All right, there are three chapters to this story. We’re going to have to learn Rust from scratch, learn to use a game engine that runs on Rust from scratch, and then make an entire game in that engine from scratch. And we only have 24 hours. The first thing I had to do was learn [music] the basics of Rust. Since I’m trying to speedrun this, I picked out a 3-hour Rust course from YouTube University, set it to two times speed, and locked in. I’m familiar with some programming concepts. I’ve played around

00:01:18
learning bits of coding for about 6 months now, but the issue is that every programming language has its own syntax. Imagine relearning how to write sentences, but every word is spelled differently, and all the grammar rules are also completely different. That’s basically what it felt like I was doing. The course started out the same way that any programming course would, by [music] making me print “Hello, world.” In Python, my usual coding language, you write code, hit run, and it just runs.

00:01:44
But, in Rust, you need to [music] compile your code first, which means that your code gets converted into a self-contained program your computer can execute directly. So, now I have a “Hello, world” EXE on my desktop that I can run whenever I want. Nice. From there, the course walked me through the fundamentals. How to create variables and assign their data types, how to make a struct, making loops to repeat a snippet of code multiple times in succession, functions that allow me to do complex things over and over without

00:02:11
retyping a bunch of code. Basically, all the building blocks you need in any programming language. Another thing I learned, in Rust, there’s no object-oriented programming. Unlike in Python, where everything can be organized into classes and objects, Rust is a lower-level programming language, meaning that you work with simpler building blocks and structure your code differently than something like Python. The upside is that your programs run faster and with less overhead, but the downside is that a lot of things that

00:02:37
higher-level languages handle automatically, you have to build yourself. Next, the tutorial got into some concepts that I hadn’t seen before. Specifically, the heap and the stack, which are the two different sections of your computer’s memory, and they work very differently from one another. I won’t get too into it, but I spent a little too much time going down a rabbit hole trying to wrap my head around these concepts. I also had to learn a lot about ownership and borrowing, which is

00:03:00
a big part of Rust’s memory management. It’s also the thing that makes Rust different from any other coding language. Again, I don’t want to get too into it, but in Rust, every piece of data has exactly one owner. When you hand data from one variable to another, the first variable gives it up. It no longer owns that data. The way around this is called borrowing. Instead of handing your data over and reassigning its ownership, you lend it. You give another part of your code temporary

00:03:25
access to it without giving up the ownership. Ownership and borrowing basically forces your program to be memory safe, which is cool. I don’t think you can even get a memory leak in Rust if you tried. This was a brand new concept for me, and it made things really difficult [music] at first, and it honestly continued to make things really difficult all the way through, as well. And I’m not going to lie, I don’t think I came close to fully grasping these concepts, but I learned enough

00:03:48
about them to move on. 4 hours in, the syntax tutorial was done. Now, it was time to figure out how I was actually going to make the game. By the way, in Rust, every piece of data has exactly one owner, and that’s a beautiful concept. It’s a shame that the same thing doesn’t apply to your personal data online. Your real data, like your phone number, your address, your email, that’s been leaking online for years. Data brokers scrape it, package it up, and sell it to whoever’s buying. And I

00:04:14
feel this one personally. I constantly get scam calls, and that’s because my phone number’s just been sitting in some database with a price tag on it for years. And that’s exactly why this video’s been sponsored by Incogni. They hunt down hundreds of these data brokers and force them to delete your personal information. And they keep coming after them because these data brokers love to just add it right back into their databases. And if you ever spot your personal info somewhere out there in the

00:04:38
wild, you can use Incogni’s custom removal feature, send a link over to a dedicated privacy expert, and let them take care of the rest. Listen, they can’t target you if they can’t find you. So, use code Luke at incogni.com/luke to get 60% off an annual plan. Now, back to learning Rust. So, to do things like render a game window, draw sprites, detect collisions, that all requires a game engine. So, I went looking for one that works with Rust. And after some searching, I found an engine called

00:05:11
Rusty Engine, and it seemed like exactly what I needed, a 2D game engine built specifically for people who are learning Rust. One thing I wanted to try out during this challenge was getting [music] used to reading actual documentation. So, I just jumped straight into the docs without doing much research on the engine first. And it wasn’t until many, many, many hours later that I realized there is nothing else out there on this engine, no forums, no Stack Overflow threads, no YouTube videos, just some pure

00:05:39
documentation pages written by the guy who built it, which isn’t a problem per se. I didn’t think much of it at the time. I figured the documentation would be enough for me. However, the real problem, as I would later discover, is that if I run into problems, I’m all on my own. There’s really no answers that you can find on Google for this thing. I would come to find out that this makes things a lot harder. Anyways, I read through the documentation and finally was ready to get started on my game. I

00:06:06
decided to make a classic brick breaker clone. Smash bricks with a bouncing ball to win. This is a game that would force me to play with some mock physics, some real-time game state updating, and multiple in-game events. It was going to be a nice solid challenge. But, to really call this a game, there were four main elements that I’d have to build out from the ground up. To get started, I made some art. I opened Photoshop and designed all the sprites that the game would use. For the player, I used this

00:06:29
Rust community mascot, a little crab, and had him hold the paddle that the ball bounces off of. For the bricks, I made five different sprites, all themed after the things that the Rust crab would want to destroy. And finally, a ball. Once the images were ready, I needed to set up hit boxes. Rusty Engine has a built-in tool that lets you draw custom polygons directly over your sprite, defining exactly where the collisions should register. So, I traced the outline of each of my sprites and saved the hit box files. Sprites were

00:06:55
done. Jumping into the actual coding of the game, the first thing I set up was the player movement. Every frame, I check the keyboard state. If the right arrow is being held down by the player, I add 10 to the player’s X position. And if they’re holding down left, I subtract 10 from their X position. And then the render function uses that information to place the paddle sprite in the correct position on the screen. The ball works the exact same way. Every frame, the ball’s X and Y speed gets added to its X

00:07:21
and Y position, and this creates movement. To make it bounce off the walls, I basically check its position each frame. If the ball hits the top or the side of the screen, I multiply the ball’s speed value by -1, which essentially just reverses the ball’s direction. I also made the ball’s X speed increase or decrease based on the movement of the paddle and the ball. If the ball and the paddle are moving in the same horizontal direction, both are going right or both are going left, the

00:07:46
ball speeds up. If they’re going in opposite directions, then the ball slows down. The reason I made it this way is because without that, the ball can get stuck into a pattern where it bounces perfectly in a loop forever, and you can never beat the level. By tying the ball’s horizontal speed to the paddle direction, the player always has some control over the angle, and the game can’t really ever get stuck. Anyways, up next, I needed to make a system that would render all my bricks, and this is

00:08:08
where things start to get a little more complex. So, lock in, all you second screen viewers. To define the layout of the level, I start with a 2D array, [music] which is just a grid of numbers. Five rows, eight columns. The array can be however big I want, but each one represents a brick in the level, and every zero can mean an empty slot. And this makes it easy to design different level layouts just by changing the numbers in the 2D array. To build the grid, I loop through each [music] row and through each column, and for every

00:08:38
cell that isn’t a zero, I calculate where the brick should sit on the screen based on its row and column position. Then, I create a sprite for it and place it at that X and Y position. Each brick also gets programmatically assigned a unique ID that’s derived from its position in the grid, and a randomly selected sprite from the five designs that I came up with. The result is a grid where we get a variety of different block types. [music] All of this data gets stored in a vector full of block

00:09:02
structs, each one holding the brick’s ID, its health value, and a copy of the sprite. For collision detection, every time the ball hits a sprite, the engine passes me the ID of the block, which I then remove from the engine and from the block vector. Now, this is where the choice of game engine kind of came back to bite me. My original plan was to give each brick a health value and have them be able to tank multiple hits before breaking, but when I went to implement the texture swap, I ran into a wall.

00:09:29
Rusty Engine doesn’t support changing a sprite’s texture after it’s been created. The texture gets set when the sprite is added to the engine, and there’s no built-in way to update that. So, I searched through the documentation, found nothing. I searched online for workarounds, I found nothing. And listen, I’m sure a better programmer could have found some workaround where we swap the old sprite out entirely for a new one, but I tried doing that. I tried doing that myself for hours and I

00:09:52
just could not solve it. So, I decided to simplify. One hit, brick dead. But with that, the core game was working. I just needed to polish some things up and add in some touches. [music] A start screen that sits over the game when it first loads up. We freeze everything and have a start screen pop up until the player presses S to start the game. We add a score counter that sits in the corner and increments by [music] one every time we break a brick. And then finally, a win screen that triggers when

00:10:16
the block vector is completely empty. Oh, game over? What the hell? >> [laughter] >> I thought I won, dude. What do you mean game over? Just don’t mess anything up. Oh, I steered that. I win. I called the game finished at 15 hours and 23 minutes, which means that I didn’t need the full 24 hours. But, I’ll tell you what, I’ll still let the top comment choose a language if we hit 10,000 likes. I really, really enjoyed learning Rust, or at least the bare fundamentals that I covered in this

00:10:48
project, and I would recommend trying it out if you’re interested. By the way, just want to say, if you’ve made it this far, it would mean a lot to me if you considered subscribing. It is my dream to hit 100,000 subscribers, and almost none of my viewers are subscribed.