Create an Epic Multiplayer Game in Scratch 🐱 Step-by-Step Tutorial!

[Overview] Hello Fellow Scratchers! Do you want to code an online cloud game in  Scratch, perhaps even a massive multiplayer game with anything from 2 to over 100 players?  Well then you’ve come to the right place! Because I can show you how we can upgrade  almost any Scratch game to be a multiplayer

Game! Conceptually we just need each player  to share ‘their’ player’s position and costume details. Because if we know where they are,  then we can display them in ‘our game’ too. In these tutorials, we will learn step by  step how to code this fully backpackable

Cloud engine that can be easily dropped into all  your games! And yes, we’ll cover cloud variables, data encoding, buffering for smooth movement, and  of course how players Join and leave our games. So, buckle up, smash that like button  (lol), and let our crazy fun journey into multiplayer coding begin! Guys, let’s get Scratching!

[“New Scratcher’s” can’t use cloud?] But hold on… Are you a “New Scratcher”? You can check right here on your profile page.  Sadly until you are invited to full “Scratcher” status you won’t be able to play, or create  cloud games! But before you start to panic,

All you need to do is share a few projects,  love and comment on my (*cough* and other peoples) projects, and very soon, you’ll find an  invite appears, right here on your profile page. Ok, great – Let’s start a new project. In this first episode we are going to cover

The basics of Cloud Variables, how they work, and  perhaps more importantly, how they don’t work! [Cloud Variables] If we create a new variable, “CLOUD 1”, you’ll notice we have the option  to create this as a “Cloud variable (stored

On the server)”. And this is where the magic  happens. By storing a value on the cloud server, every Scratcher looking at your  project will ‘share’ the same value. When we first create one of these we get a  warning. It reads “Please note, cloud variables

Only support numbers, not letters or symbols”. And so we meet our first limitation, “Cloud Variable Rule #1, you can’t write letters  or symbols to a cloud variable”. And that is a real pain, our lives would be so much easier  if we could stuff text into these things,

But that would be open to abuse [[silly word]]  – so we are where we are. Numbers only! Ok, shall we see the cloud variables  in action? When this sprite clicked, change the cloud variable by 1. A simple enough test, just click

The cat, and we see “cloud 1” increases  as expected. But, to test this properly, we need to see the value changing on another  scratcher’s screen right? That’s the whole point! Well, you could get the help of another Scratcher  to load up your project, but for simplicity,

We can actually test this all ourselves without  even sharing the project! (which is great news, because who want’s to share an unfinished game!). [Testing with Two Web Browsers] Make sure the project is saved, then “Switch to  the Project Page”, and move the web browser to one

Side of the screen. Next, we need to duplicate  the current tab. I did that by right-clicking, but you could otherwise just create a tab and  find your project in the normal way, it doesn’t matter. And then, I pull the new tab away from  this browser window, and drop it to the right.

Okay! This is looking good. Both projects  agree that “CLOUD 1” has a value of 3. Now, when I click on the cat again the value  changes to 4, but this time, also changes to 4 in our second window too! Wonderful, this is what  Cloud variables do – They share their value with

Everyone else, almost instantly, but… not quite.  It actually takes around one tenth of a second for the value to transfer from window 1 to window 2. A  lag of around 100ms. And yes, you can click either cat, the update works in both directions. [Cloud Game Done Wrong!]

Now there’s only so much fun you can have  clicking cats, how do we go from this… to this! Well, let’s start small. Say we have the  Scratch Cat follow the mouse pointer, and try to get the second window to mirror  these movements! That would be cool.

When flag clicked, loop forever,  going to mouse-pointer. We know cloud variables can share a single number  with another Scratch project, and a sprite’s position is made up of two numbers, given by the  “x position”, and “y position” reporter blocks. So, why not create a second  cloud variable, “CLOUD 2”. Don’t

Forget to check that cloud variable option. And now, we can set CLOUD 1 to this sprite’s x position, AND CLOUD 2 to the y position. Nice. Running the project, clearly shows both CLOUD 1 & CLOUD 2 updating. Since these values will be shared

With window 2, we’ll just need a second script to  reposition the sprite using these shared values. When 2 key pressed – This allows us to  indicate which window is window 2. Stop other scripts in sprite. This ensures window  2 won’t be running these left hand scripts.

Instead, we Loop forever, setting the x position  to, the value shared with us in CLOUD 1. And, the same for the y  position, but with CLOUD 2. Nice! We have to test this! Once again, ensure the project is saved.

Then See Project Page and duplicate the tab. If  however you left the window open, which often I do, just make sure to reload the page, Otherwise,  the project will be out of date and may lead to confusion if things don’t work as expected! Ok, here we go. Both projects are running,

But I haven’t pressed the 2 key yet. To proceed, first, click in the right-hand window to ensure it has  the focus. Then, press the 2 key. Boom! My cat just flew over to the right. But  why did it do this? Well, it’s because the cat

On my left screen is positioned to the right,  and this window is now copying its movements! Now, let’s bring my mouse  back to the left window… And look! The x and y positions  of the first sprite are shared,

Allowing us to reposition the second sprite  to match the first one! This is basically how multiplayer games are coded in Scratch. [The Limits of Cloud Variables] But wait, do you notice something a  bit off? The right-hand window seems to be mimicking the movements of the left  window, but it’s far from smooth. Houston,

We have a problem. Upon closer inspection,  you’ll see that the movement occurs in steps, only horizontal (left and right) or vertical  (up and down). It’s quite peculiar, isn’t it? Well, I did mention that Cloud  Variables have their limitations, and we’re witnessing some of them right  before our eyes. The first limitation is this:

“Cloud Variable Rule #2 – Scratch waits 1/10th  of a second between sending cloud updates.” In other words, no matter how quickly you  update cloud variables, Scratch will only send them at a maximum rate of 10 per second.  Unfortunately, this rule also applies when we

Set two cloud variables together, in our  case the x & y positions, resulting in one change being sent before the other, and  thus the sprite moving in horizonal then vertical steps instead of a smooth diagonal line. [Encoding 2 numbers in a single Cloud Variable]

There is no way around this restriction,  So the only way to share our x & y values at once is to combine them and send  using a single cloud variable instead! Well, how about we join the two values together?  For example, an x value of “176” joined with a

Y value of “40” would come out as “17640”.  That worked, but now we face the challenge of not being able to distinguish where  one number ends and the next one starts. The problem is, we can’t insert a  separator character because of cloud

Rule #1, which states that “you can’t store  letters or symbols in a cloud variable”. So, here’s an idea. Let’s record the length of  the first number “3” before the number itself. We’ll do the same for the second number  “2”. Then, we can join all the information

Together to give our encoded string value. Has this helped us? Yes, because to extract the numbers back out, we simply look at  the first number, which is “3”. Then, we read out the next 3 digits, which gives us  “176” as our x value. The following digit is

A “2”. And reading the next two digits we  obtain “40” as our y value. Clever stuff! [Coding the basic number encoder] Let’s code this up. Create a new variable, named “encoded string”. For this sprite only. And make sure to set it to an empty value.

Now we’ll create a custom block to let us add  individual numbers to this encoded string. Name it “Write Number”. With a number input  “val” short for value, and another label of “to encoded string”. Write Number (val)  to encoded string, perfect. Make sure

To run without screen refresh so it runs fast! So after clearing the “encoded string” variable, Let’s try writing the number 1 to the  encoded string. Yes, this will want to be the x position of the sprite going  forward, but always start off simple!

Now to code up the custom block. Creating another variable, also called “val”, for this sprite only. And set val, to the input val. Clicking the script above will set val to  1 as expected. Now, the reason we’re using another variable for val is to safeguard against  fractional values like say “100.5”. This would

Mess up our encoding, so we’ll pop in a rounding  operator to remove the issue before it occurs. Great, so then we simply set “encoded string”  to the JOIN of, itself, encoded string, and… ok, two more things, so another JOIN. The length of  the variable “val” (not the pink, but the orange

One we rounded). And the value itself. A length of 1, and the number 1 should come out as “11”. Pop that on the end of the encoded string, and this custom block is done. We can test it by clicking the above script again,

And encoded string is indeed “11”. How about if we write a second number “2”. Click – Not a problem. 1 digit, the number 2. And a longer number, “345”? Click – We see “3” digits, followed  correctly by “345”. Great! [Coding the basic number decoded] Now, the next step is to retrieve

These numbers from the encoded string, which is  known as decoding. The key is to keep track of our current position in the encoded string as  we start from the left and progress across. To accomplish this, we’ll introduce a new variable  named “encoded idx” specific to this sprite.

This variable will serve as our tracker. We’ll initialize the “encoded idx” variable to 1, indicating the starting position at  the first digit of the encoded string. Next, let’s create a custom block responsible for  decoding each number. We’ll name it “val = READ

NUMBER from encoded string”. Apologies for the  lengthy name, but it accurately describes the block’s purpose. Remember to set the block to run  without screen refresh for optimal performance. To facilitate testing, let’s  plug in the code right away. Assuming the “encoded string” variable  begins “1112…”, for the initial read,

We aim to retrieve the number 1 for the  length and another 1 as the value itself. First, let’s ensure that the “val”  variable is empty at the start. Next, we’ll retrieve the value of the  current letter in the “encoded string”, which will be “1” as expected. Just remember the current position

Is given by the “encoded idx” variable. Right, so we can agree that this returns the number of digits that we need to read in to  get the next full value. So, how about we use a “repeat” block for that exact number? Currently, it will repeat only once,

But for longer numbers, it will repeat  as many times as there are digits. We need the next digit, so let’s  immediately change “encoded idx” by 1. And now letter “encoded idx” of “encoded  string” will give us the next digit in the

Encoded string. We’ll want to append this  digit to the “val” variable by setting “val” to the JOIN of “val” and this next digit. This “repeat” loop will then do it’s job looping around adding digits to val. The only thing left  to do is to ensure that we increment “encoded idx”

By 1 more at the end, so we are positioned to  read the next number from the encoded string! Well, this is exciting! We can now test  if we can correctly decode these numbers. Click the script and confirm that we  obtain the first value, which is “1”.

Nice! There it is in the “val” variable! To get the next one, we simply need to run a “READ NUMBER” block on its own. Click. Splendid, there’s our number “2”. And with one more click, we get “345”. It  perfectly matches the order and value of our encoded numbers. [Negative Numbers]

“Great! With this, we can encode and retrieve  our numbers. However, we mustn’t forget that the screen positions of sprites can often go negative.  If we try to encode a negative number like “-10,” then, oh dear, “3-10”. That will definitely  fail cloud rule #1 as it’s not a valid number.

Somehow we need to encode negative numbers  without using the negative symbol. Hmm… Well, since no numbers will begin with 0’s and  the “-“ always appears at the start of a number, how about we simply replace the “-” with a 0  instead. So, “-10” becomes “010,” and we can

Identify it as negative because it starts with 0. Let’s code that up in our Write Number script. We first check for negative numbers.  If the value (val) is less than 0, we’ll use a “set val” block, joining a 0  digit on the left, with. And we need to be

Careful to remove the negative sign from val,  so we’ll use the absolute value (abs) of val. Simple enough! Click the test script and see how  “-10” now becomes “010” preceded by a 3 as it is 3

Digits long including the that 0. And that’s cool  because it passes the cloud rule test. The same goes for -20. No negatives in sight. [Decoding Negative Numbers] Next up, we need to decode these values.  Currently, if we read out the first encoded

Negative number, we get back “010” in the variable  ‘val’. It should have been “-10”. So, all we need to do is watch for that leading 0 and then convert  the number to a negative, resulting in -10. We’ll add this script at the bottom  of the “define READ NUMBER” script.

If the first letter (letter  1) of ‘val’ is equal to 0, then we set ‘val’ to be negative ‘val’ or,  in other words, subtract ‘val’ from zero. Let’s quickly test it, and yes, now we are getting  back -10 just as we hoped. Click on the next READ

NUMBER block, and out pops -20. This is great  news! It means we now have fully functioning encoding and decoding scripts! [Updating our Game to use a single cloud variable] Wow, finally, we can put these to good use. Remember why we were doing this?  Oh yes, our cloud player was moving in steps

Because “Cloud Rule #2” says we shouldn’t update  more than one cloud variables at a time. Well, no problem – Now we can encode both the x & y  positions into a single value. So, back to our original game loop. We begin by setting the  “encoded string” variable to empty, and then

Using our WRITE custom block to encode first the x  position, and then the y position of the sprite. After that, all we need to do is set CLOUD 1 to  the “encoded string”. Super! That sorts player 1,

And the cloud variable will make it’s way over to  player 2’s computer which is running this script. All we need to do is decode it! Begin by setting “encoded string” to the new value from “CLOUD 1”. Then set “encoded idx” to 1 (to start

Decoding from the first letter). Now we use our  READ custom block to get the first value out of the encoded string. This is an “x position”,  so immediately set the “x position” to ‘val’. Then we can do the same again, “read a value”  and this time set y position to val. Excellent!

[Testing] Because THAT my friends is all there is to it! To test this out, make sure the project is  saved, and then get those two browser tabs side by side. Remembering to reload the right  hand page if you kept it open all this time.

Now with both projects running, I’ll click  into the right window, and press the 2 key. When my mouse is over the left hand window,  the cat in the right window follows my motions, but HOW MUCH BETTER IS THIS? We can move the player diagonally

And the cloud player doesn’t glitch sideways  at all, nope – no stepping to be seen. Also, the lag between the left movement and the  right movement is surprisingly small. If you got this far then you can be pretty  chuff with yourself, it’s super cool.

But we are far from perfect yet. You’ll notice the  movement on player 2’s screen is more choppy than on the 1st screen. That’s because cloud rule #2  also states that we can’t update a cloud variable faster than every 1/10th of a second. So even  though we are only updating one cloud variable

Now, we are still updating it at a rate of 30  times a second. The rule is that Scratch will only send 10 changes per second max, so 2 of every  3 animation frames are skipped ☹. This is far from

Ideal, and is not the smooth gameplay action we  might expect from a top class network game. So how do we fix this? [Next Episode] In the next episode of this exciting series,  we will learn how movement buffers and data

Streams can smooth out player motion making  our games look top notch. But in the process we’ll also begin to expand our cloud engine to  take advantage of my latest Massive Multiplayer Online Techniques as seen in MMO Minecraft & my  MMO platformer projects – These can easily handle

Vast number of players and are seriously  a lot of fun. The great thing about these is that they also make joining and leaving a  game way more robust than my previous cloud engines and support testing on a single unshared  project, a huge bonus for us Scratch developers!

[Outro] Well I hope you enjoyed this video, if you did then please, please smash that like  button under the video. Did you click it? And if you don’t want to miss the next exciting  episode, and guys it’s going to be so cool – Then

Make sure you are subscribed to the channel, and  that you’ve clicked the bell icon to be notified. Lastly, if you are interested in supporting this  channel further, then you can join my channel membership, there are some cool perks, and even  the option to get access to the scratch projects

That go along with each episode! So cool. That just leaves me to say thank you for watching, I hope you have a great  week ahead, and… Scratch on guys!