[Intro] Hello Fellow Scratchers!
If you didn’t know - I’ve been working hard on a new “Minecraft MMO” Scratch
game – Something I’ve been wanting to try to code for a really long time, but technically,
it’s quite a challenge!
In this video I’m going to take you on a deep dive into the tricks I’ve discovered
that helped me make this multiplayer masterpiece possible in Scratch!!
MMO stands for Massive Multiplayer Online, and as such you may see as many as 60 Scratcher’s
in game simultaneous, yes you heard me right, 60 players, all mining, crafting, chatting
and swapping items in the same world!
I love simply walking around and seeing what my fellow Scratchers have been building!
From deep mines, to pumpkin houses!
Nice one BELEGAL102 😊. [Cloud Game Basics]
So as with all online Scratch games, this project is built using the humble “cloud
variable”! They work like normal variables, except their values are shared across the
internet to all other players of your Scratch project.
Very cool, but with serious limitations.
You can only have 10 of them per project, they can only store numbers, not text, and
after setting a cloud variable, you must wait a tenth of a second before setting another
one to avoid facing stability issues.
[Tiled Platformer Engine] But before we talk anymore about the cloud,
what about the scrolling platformer engine?
Does this look familiar to you?
It’s actually adapted directly from episode 4 or 5 of my tiled RPG tutorial!
Yes, so this is a 500 x 100 tiled grid list where the tileset costumes were sourced directly
from the Minecraft sample resources on GitHub, and it works just great.
The tiles are stamped, so it used minimal clones, and I’ve used very basic platformer
scripts like those in my early tiled Mario tutorials.
And really, enough said about that.
I was just pleased I could adapt the code so quickly and save all that re-thinking!
[MMO Cloud Engine] Next up I needed the multiplayer code.
Again, I was able to re-use some of my existing scripts to get a head start, specifically
from my MMO platformer game.
But, we should take a step back, and let’s first take a look at the precursor to this
, my first successful cloud game, Cloud Platformer Multilayer Fun.
All my cloud games up until very recently worked like this.
We have 8 cloud variables for the players, and we allocate them out, 1 for each player.
Then each player’s scratch project is responsible for taking the player’s username, their
position on the screen, and the costume number, and encoding all of that into a single, ‘cloud
variable friendly’ value, or data packet if you will.
They then set their allotted cloud variable to this value (as do all the other players),
and in this way, all the connected scratch projects know who is playing, and where they
should be on the screen.
It works really well, but it does have an obvious limitation…
We can’t support more than 8 to 10 players at a time!
Then along comes my new experimental “MMO platformer” project.
And this one blows the 10 player limit right out of the water and far up the beach.
See for yourself as I’m joined by over 130 of my Fellow Scratchers, all in game at the
same time!
What magic is this?
Well – it’s actually pretty straight forward.
Let me explain; As before, each player’s scratch project
constructs a data value from their username, and sprite position, etc.
But this time, just pick any of the cloud variables at random, and set it to their data
value.
Now all 140 players of the game will see that cloud variable change value, and this is where
it gets funky!
Each project maintains two lists.
The first contains the names of players who’ve joined the game.
By decoding the start of an incoming cloud variable, we can identify who sent it (This
one’s username was “guy”).
If they’ve already joined, then we find them in the “name” list, and use the second
list to store the actual cloud value alongside their name, both at the same item number.
This is called a key-value pair.
The other case is that the cloud variable is for a player we have yet to see before.
A new player.
In this case we simply add then to the player names list, and insert the cloud value too.
And that’s it – Awesome – By using lists to store the cloud data, we are no longer
restricted to a maximum of 10 players, and players sharing the same cloud variable do
not have to worry about overwriting each other as the list keeps each players codes safely
stored away.
So cool!
It’s then just a matter of cloning a sprite for each new player, and decoding their position
for display.
[Synchronizing a 50,000 tile game world] So, since this cloud engine worked so well,
I dropped it in to my modified RPG engine, and yay!
It’s perfect for running and jumping around with all my friends.
But, that’s really only half the story.
Not only do we need to synchronise our players movements via the cloud, but also, the state
of the entire game world too!!!
And this is a huge problem.
A HUGE problem indeed!
Because a level consists of 50,000 tiles.
Back when cloud variables didn’t have a limit on their size, we could in fact squeeze
an entire level into one variable, think Scratcharia!
But sadly, as of 2023, we can only squeeze in 256 digits at a time…
Scratcharia R.I.P.
The next idea would be to split the level code up into chunks and send them one at a
time across the cloud…
Well with the limits on cloud updates, that would take a full 2 minutes.
That’s a long time to wait for a game to load, and who is going to be sending this
anyway?
We need this to be somehow self coordinated between all the players of the game.
[A predefined level with incremental updates] So, to cut down on the amount of data that
needs to be sent, I decided to begin the game with a predefined world, akin to the demo
world in Minecraft.
That would allow all projects to load up instantly in a common land.
Good.
Then, as a player mines and places blocks, all we need to worry about is keeping a list
of these changes, and sending those details to everyone else.
Obviously the list of changes will gradually grow quite large, and so we can’t send them
all at once.
So we keep a record of the last sent block, and cycle around the list sending just 4 or
5 updates, along with our normal username, and position data.
In this way, every player will eventually see every block that we’ve modified.
[Multiplayer Building Conflicts] Splendid!
– We have a workable solution.
But as with all good ideas, there’s always issues to be teased out.
For example, when another player changes a block that we previously changed, we have
to be careful we don’t accidentally overwrite it again with our recorded change.
So, remove the record of our change as soon as another user overwrites it.
It’s useful to keep a record of who changed each tile, and when to best resolve these
little conflicts.
We can see this working in game by holding space – So, that’s who stole my precious
cake!
[Player leaving the game] Another issue that causes a LOT of trouble,
is when a player leaves the game.
All existing players will continue seeing bob’s glorious house exactly as bob left
it.
But, a new player joining the game will not see bob’s house!
Why?
Because bob is no longer around to send his tile edits to new players!
They are seeing the level as if bob never existed.
And this is a serious problem, because the levels are out of sync between players, and
it’s never going to sort itself.
We must have consistency between our players or this game will fall apart!
[Natural Level Regeneration - Combatting Entropy] The easiest solution is, after bob leaves,
is to reset all has changes he made for everyone.
(And since I’m already keeping a record of who modified which game tiles this shouldn’t
be hard).
Goodbye Bob Vill…
And sorry to that poor Scratcher exploring bob’s mine!
Sad.
But… the plus side to this strategy is that our level, which would slowly descend into
chaos (that’s entropy in action my friends), now continually self repairs as players leave.
If all is well, we strike a nice balance, and everyone can have a lot of fun!
[The Future] So, obviously there’s tons more I could
talk about, the inventory hot bar, crafting, smelting, player costumes, armour.
But what’s interesting is where this project is heading!
I began it as an experiment to see whether it was even possible to make an online Minecraft
style game, and the answer is a very positive yes!
But, there are things I have not yet added, and with good reason.
Falling Sand & Gravel Blocks – These are particularly tricky since once a block moves,
I have to decide where it ends up, and who is the owner for consistency across computers.
Far harder than it sounds!
Water & Lava – For the same reason as sand and gravel, any tile with movement brings
me lots of pain!
Maybe one day I’ll look into it and figure something out.
Day, Night & illumination in general – Calculating this is quite expensive even in a single player
game.
If I extend this out for 60 players it’s going to be too slow – trust me!
Perhaps there’s some trick I can use, but I haven’t thought of it yet.
Chests – Now then, these would be cool – but it’s another layer of complexity, for where
do we store the chest data, and how to we make sure it’s synchronised over the cloud?
PvP – Seriously?
This is a peaceful game!
The biggest problem is that game lag means that everyone is a half second behind each
other movement wise, and when you think you hit someone…
you didn’t… and vice-versa.
Nobody wins, and no one is happy ☹ Mobs – Oh man!
Usually for these I end up having one player’s computer take control of the mobs nearest
to them.
But sending enough data to make that work will be super hard given the current cloud
restrictions.
I would really love to add some pigs & chickens!
I have pondered on providing masks that let you take on the role of different mobs – So
players can play as people or other mobs 😊 – I dunno, what do you think!
Could be very entertaining.
If you think it is then drop me a comment…
Lastly, Safe Zones / Teaming – It’s obvious that there are a number of people who find
it more fun to destroy peoples hard work than build themselves, and I really don’t approve.
So I wonder if there’s something clever I could do to help prevent it and still support
collaborative building – tricky!
So let the discussion begin!
I value your ideas & thoughts.
[Outro] Well, I hope you enjoyed that little technical
overview, and update, if you did then please say thanks by smashing the like button under
this video!
I’m having a lot of fun coding this game and I’d love your feedback so do drop me
a comment or two!
If you haven’t yet subscribed to my channel then you can do that now, and don’t forget
to toggle that bell icon on to not miss being notified that my next video has dropped!
So I’ll see you again soon, but until then, take care, have a great week ahead, and Scratch
on Guys!