How to make a mario game in turing

Let's start with that background. It's boring, right? I mean, sure, it's a pretty color but it just How about instead we add some background in the Mario style? Adding a background means treating it like a special kind of sprite, and adding this to the list of not-moving background sprites:. The important line is that addBackgroundSprite This says "Add something, which is inside the and , to the list of background sprites.

In this case we add what is known as a "Tiling Sprite" - a picture that is repeated to fill a certain area of the screen. Since we want the background to fill the entire level, we use a picture of a typical Mario sky line, and make it repeat itself starting at 0,0 , which is the upper left corner of the level, all the way down to width,height , which is the lower right corner of the level.

We could keep it at that, but since we're updating the background anyway, let's make sure that Mario can't run out of the level:. Except this time our Thingy is a Mario! And because we can, let's make one more change: a background is nice, but it would be even better if we could actually see that it repeats, by making the level wider than a single screen. Two things to note are that in our initialize method, we now make a MarioLevel that is twice as wide as the screen.

In order to make sure that game library doesn't get confused, we then also tell it that the viewbox for this game starts at 0,0 , which is the upper left of the screen, and is only screenWidth wide, and screenHeight high, so it is exactly the same size as our game "window". If we left it at this, we would see Mario run to the right and then disappear, but the viewbox is special: it can follow a player around. So we make one final change:.

We've done two things here. First, we've made the level layer always "know" what the mario word refers to. Now, if we refer to mario in any of the methods of the level layer, it will know what to use. That's important, because the viewbox needs to know who it should be following around when the level layer is being drawn.

That's the second thing we changed. Normally a level layer has a premade method called "draw" that it kind of "inherits" from the game library. But, it only draws the level layer, it doesn't do anything else. If we want to make the viewbox follow Mario around, we'll need to set up instructions that say "do what you normally do, but ALSO follow mario!

So that's what we do: super. Then the next instruction is to the viewbox: viewbox. Whenever the level layer needs to point to its owning level, we can use the word parent and the game library will know what to do. Especially now, that's pretty handy. That's enough! We added background. We added walls to the left and right. We made the level bigger than the screen.

We hopefully! Now that's what I call pretty cool! We can run around and the background will scroll along, until we reach either end of the level and we simply walk into the side walls. We've been putting it off long enough: having Mario walk on a thin little line works, but things will look a lot better if we make him walk on some actual ground. Or at least, if we make it LOOK as if he is. Let's start creating some ground, shall we?

Ground is actually quite similar to adding background. Since the only thing that determines whether Mario's "on something" or not is the normally invisible boundaries which we can see right now because we're cheating and we're drawing them, even though normally you don't , we can actually just leave the boundary where it is, and set up some more background that makes it look like there's ground underneath the boundary line.

In order to make ground, we're going to use a few images. Two, in fact. One to look like the top soil, with grass, and one that fills in the region underneath:. The trick is to lay down a row of top soil, and then fill in the rest with filler. We've actually already seen how we are supposed to do this: we use a TilingSprite. First, let's define a method for "laying" ground:.

What do those values mean? Well, x2 is the horizontal coordinate for the right-most edge of the rectangle we want to fill. So that one's pretty easy. We add 16 pixels because we know the picture for the grass is 16 pixels high. So we want to draw a row of grass that starts at 0,0 and is exactly 16 pixels high, and the normal width wide. After that, we fill the rest with filler pictures. And then it has to be wide enough to reach x2, horizontally, and high enough to reach y2, vertically.

Finally, because ground acts as something Mario can stand on, we add a boundary that runs along the top of the grass, so that Mario has something to stand on. What does that look like? Well, this:. There's another thing we can do that also makes a neat difference, and that's adding a second layer of background that looks like it's farther away, so that when we walk, it moves slower than the normal background.

We can add "parallax", or the concept of faking distance by tricking the eyes into believing there's distance by making things that should seem "close" move fast and things that should seem "far" move slolwy, by adding new layers to our level.

We're going to make it look like we have more background in the distance, so we'll add a new layer behind the main layer that has Mario on it. In fact, the code for it is not very long, can you tell what it does? The important part is that new BackgroundLayer class, which does something special. Unlike a normal layer, such as the MarioLayer , the BackgroundLayer has a more elaborate call to tell its super class what's up: it gives it seven values instead of one!

The first value is the same as for normal layers: the Level that this layer should be in. So far so good. Then, it tells it what that level's width and height are.

This is important, because those are needed to do something intelligent with the following four values: the first two are "shifting" values, which let us say by how much this layer is shifted left or right, as well as up or down.

We don't want that right now, so we keep both of those zero. Then, the two values after that tell the layer by how much it is scaled. This is very important! To make it look like this layer is farther away, we want it to move slower than the main level layer with Mario in it. Since we can't tell layers how fast they need to move, we instead tell them that they are bigger or smaller than the main level. This makes the game library squash or stretch the level, so that the start and end match up -- if we add a layer that is larger than the main layer, it will be squashed, and it'll look like it scrolls faster than the main layer.

And of course the other way around; if we add a layer that is smaller, it will be stretch, and will look like it's scrolling slower. So that's what we do, we say that this new background layer is only 0. So it should scroll slower. Let's find out: And now with a prettier background! Notice how our new background moves slower than the one we already had? Does it make it look like this new background is farther away? Cool, eh? Now we have a great start for a real game: we have a Mario, we have cool backgrounds, and we have some ground to run on.

Time to start adding finishing touches, what do you say? Usually, a "platformer" such as the game we're making is called, has "platforms" that you can jump on, and from. Of course, our game doesn't have these But we can add them pretty easily by using the same idea as before: the part of a platform that we can stand on will be represented by a boundary, and everything else will just be a backgroud image, of course placed so that it looks like there is a platform.

We'll be adding two types: a slanted platform, and straight platforms. A slanted platform, and horizontal platforms For the slant, we'll use a single image, and the code is pretty simple:.

By default, sprites are placed with their center point wherever you tell them to position to. If we call setPosition 0,0 and the sprite is a 16 by 16 pixel image, then 8 pixels will be on the left of 0,0 , 8 will be on the right, 8 above, and 8 below. Sometimes, that's not useful at all, and you want to change that so that if you put an image at 0,0 , the entire image is to the left, right, top or bottom of that coordinate.

In those cases, we can use align In this case, we want the image's left side, and top, to be aligned with the coordinate we give its setPosition , so we say align LEFT,TOP we have to tell it how to do horizontal align first, and then vertical align. So, not very complicated code, just "a lot of it" to make something really useful happen: After we define our function addGroundPlatform we can call it as many times as we like to add platforms to our level.

In the above code, we added six platforms, and then a little above that we added three slanted platforms, so That's more like it! Now we're starting to make a real game. Of course, there's still stuff missing. We want treasures, and enemies, and a way to win. At the least. So let's start adding those things in shall we? In the game library, treasure is a form of "pickup". Pickups are things that can be picked up by either players or NPCs non-player characters by walking into them, and when they do, "something" can happen.

Of course, we're in control, so what happens is up to us. Very handy. If you've ever played a mario game, you might known that mario likes to collect coins, of all sizes and colors. In our game, we'll give him two different kinds of coins to pick up: normal coins, and the mysterious dragon coin:. In order to make the coin pickups, we start by making a master "Mario pickup" thing, that we can use as a superclass for every pickup we're going to make in our game:.

While this code doesn't do a great deal, it'll let us group things as "Mario Pickups", and that will become handy if we ever introduce a class of pickups that aren't for Mario. I created my own coins as I could not find any flat coins.

Create 4 of them, 1 red and 3 yellow. The red one will be the starter, so once you touch it its starts a timer which counts your time taken to finish the level. Both the time taken and the amount of coins you collect are going to be recorded, so on two other scripts create, using the text tool, one says time taken while the other should say coins.

See images for advice. For all scripts, when you pull out rules you can either place them one under each other or, for certain rules, inside other rules. Unless I state so, you need to place your rules underneath one another. If you have looked at one of the example games called scrolling demo you may remember this from there. What we are going to do is allow the flooring to move by a set distance every time where press the left or right button. Under variable make a variable called scroll x.

Now go to your floor which you would like to appear first. Pull from control the 'when green flag clicked' and place it on your script. For all the other scripts you will have to do so, so unless I state otherwise start with the green flag. Next, depending on how many costumes you have on that script, pull from looks 'switch to costume drop down arrow with all of the costume numbers ' choose the one you would like to show first.

This is also something that you will be repeating for most scripts. Next, from motion, pull out 'set x to ' and 'set y to '. Set your X to 0, but your Y value must be so that you can see your whole floor above your border. Next pull out a 'forever' from control and another 'set X to '. Place the set x in the forever. Now pull out the 'scroll x' variable the one with a tick bock next to it and place it in the gap where you place the 0 last time It should look like my script in the image.

Copy your script to all your other flooring by holding the green flag part and moving it over your other sprite. You should see a grey box appear over the sprite you want to send it to. Once you have done so, your script will move back to its position, but a copy will be on the other sprite repeat this for all your other floor sprites, however you need to adjust the scroll x - X value for all the other flooring.

This tells Scratch to put the next floor on once a long floor has past, i. Add an extra for each successive sprite. See images for details. Mario is the main script, and so has many scripts that work around him. The problem is when you have too many scripts for a single sprite, or in general, then scratch tends to slow itself down or, on rare circumstance, forgets to play certain very key Mario tunes.

It can be quite annoying, but just try to relax, redo your script and try seeing where your faults were.

I first script we'll make is what I call 'the starting script' because everything basically relies on it. This is the top left hand script. In this we reset all our variables, set our starting position of Mario, set up our size and choose our costume. We reset timer, set scroll x to 0, and also set jump a new variable which you must create. You also want his sizing to be accurate, so not too big and not too small.

The next part is the movement of Mario. For left and right, refer to the middle of the top script and the script under that one. Basically what happens is every time you press the right arrow or the left arrow Mario moves in that direction. However he also changes his costumes to make it look like his is walking. You must do this at 0. You may also note that Mario himself does not walk or move left or right, but the flooring around him does. This is where the scroll x comes into play.

So whenever you press the right arrow, the scroll x changes in total by , moving the flooring by This effectively gives the impression that he is moving. Next is when he jumps. Look at the middle script on the left. So how the script works is that when the up arrow is pressed, Mario jumps up by , then his y value decreases until he is touching the flooring. This is where the colour that you put on the top of your flooring comes into play.

So set the 'touching colour' to your colour that you choose. So you're jumping around and then you fall into a gap. What do you do? You restart the level. It's obvious how it can be done with preset inputs where all the user does is push the start button.

If it is, it might require different objects like certain enemies, for example. Enemies that can activate P-Switches are a potential candidate.

I didn't construct XOR because it's naturally far more complex and is almost always defined in terms of nand or nor gates anyway. GildeDMonkey 6 years ago 3. Hail, friend. E8xE8 Topic Creator 6 years ago 4. GildeDMonkey posted I'm actually a physicist by trade, but I dabble in CS because computers and information theory are vital to work in physics and mathematics. CaioNV 6 years ago 5. Says course not found. E8xE8 posted Echixir 6 years ago 8.

E8xE8 Topic Creator 6 years ago 9. Sorry I must have copied it down wrong. Logo12 6 years ago Cool, Something I would do in every sandbox games. Now if only I got the game