how did griffpatch make an MMO with 9 cloud variables?? been messing for hours trying to guess how he encoded 200 players at a time in only 9 cloud variables and cant find a solution less than 256 chars, how did griffpatch do it?

He's magic -_- DUHHH

LittleAuthor wrote:

He's magic -_- DUHHH

please dont be a little kid adoring griffpatch just because everyone else does

Okay, I don't know how “MMO” on Scratch works exactly, but I have a rough idea from observations. The trick behind “MMO” on Scratch is not assigning players to slots, but having many different clients sending data to random Cloud variables hoping that the other clients catch the data. Although there is a 0.1-second cooldown for sending data, you can receive it instantly with a reliable connection.

Although it gets a little funky without optimizations and with more players, player slots are not used to create what we call the “MMO” experiences, so technically, you can have as many players as you want on them (even if it does mean weird behavior with lots of active players), and that's what makes them “massively multiplayer”.

D-ScratchNinja wrote:

Okay, I don't know how “MMO” on Scratch works exactly, but I have a rough idea from observations. The trick behind “MMO” on Scratch is not assigning players to slots, but having many different clients sending data to random Cloud variables hoping that the other clients catch the data. Although there is a 0.1-second cooldown for sending data, you can receive it instantly with a reliable connection.

Although it gets a little funky without optimizations and with more players, player slots are not used to create what we call the “MMO” experiences, so technically, you can have as many players as you want on them, and that's what makes them “massively multiplayer”.

thats really a good idea! that must mean technically you need only 1 cloud variable then? funky… thats so unreliable though, if different clients send to the same variable at the same time or something like that.

i thinnk using that method somewhat makes sense.

you can send the player number, x and y through each tick to whatever cloud variable.
somebody else catches that and places that player number to that x, y.

this makes sense! thanks so much, cleared so much confusion thinking it was assigning players to slots.

ElectricEe1 wrote:

D-ScratchNinja wrote:

Okay, I don't know how “MMO” on Scratch works exactly, but I have a rough idea from observations. The trick behind “MMO” on Scratch is not assigning players to slots, but having many different clients sending data to random Cloud variables hoping that the other clients catch the data. Although there is a 0.1-second cooldown for sending data, you can receive it instantly with a reliable connection.

Although it gets a little funky without optimizations and with more players, player slots are not used to create what we call the “MMO” experiences, so technically, you can have as many players as you want on them, and that's what makes them “massively multiplayer”.

thats really a good idea! that must mean technically you need only 1 cloud variable then? funky… thats so unreliable though, if different clients send to the same variable at the same time or something like that.

i thinnk using that method somewhat makes sense.

you can send the player number, x and y through each tick to whatever cloud variable.
somebody else catches that and places that player number to that x, y.

this makes sense! thanks so much, cleared so much confusion thinking it was assigning players to slots.

how did player movement get ignored by turbo mode is confusing and how hackers hack is confusing, but thats a different question.

D-ScratchNinja wrote:

Okay, I don't know how “MMO” on Scratch works exactly, but I have a rough idea from observations. The trick behind “MMO” on Scratch is not assigning players to slots, but having many different clients sending data to random Cloud variables hoping that the other clients catch the data. Although there is a 0.1-second cooldown for sending data, you can receive it instantly with a reliable connection.

Although it gets a little funky without optimizations and with more players, player slots are not used to create what we call the “MMO” experiences, so technically, you can have as many players as you want on them (even if it does mean weird behavior with lots of active players), and that's what makes them “massively multiplayer”.

also what variable they sent it to is it actually pick random?

ElectricEe1 wrote:

D-ScratchNinja wrote:

Okay, I don't know how “MMO” on Scratch works exactly, but I have a rough idea from observations. The trick behind “MMO” on Scratch is not assigning players to slots, but having many different clients sending data to random Cloud variables hoping that the other clients catch the data. Although there is a 0.1-second cooldown for sending data, you can receive it instantly with a reliable connection.

Although it gets a little funky without optimizations and with more players, player slots are not used to create what we call the “MMO” experiences, so technically, you can have as many players as you want on them (even if it does mean weird behavior with lots of active players), and that's what makes them “massively multiplayer”.

also what variable they sent it to is it actually pick random?

I believe it's entirely random.

ElectricEe1 wrote:

D-ScratchNinja wrote:

Okay, I don't know how “MMO” on Scratch works exactly, but I have a rough idea from observations. The trick behind “MMO” on Scratch is not assigning players to slots, but having many different clients sending data to random Cloud variables hoping that the other clients catch the data. Although there is a 0.1-second cooldown for sending data, you can receive it instantly with a reliable connection.

Although it gets a little funky without optimizations and with more players, player slots are not used to create what we call the “MMO” experiences, so technically, you can have as many players as you want on them, and that's what makes them “massively multiplayer”.

thats really a good idea! that must mean technically you need only 1 cloud variable then? funky… thats so unreliable though, if different clients send to the same variable at the same time or something like that.

you can use one variable, but more is wayyyyy faster
the way griffpatch does the 0.1 second wait and transmit motions smootlhy is to have a buffer
so here is how it does that.
say my charector follows my mouse. we'll say gobo for reference. @ElectricEe1 is right,
but it does not just send the current x and y positions. instead what happens is it records 4 frames and then sends it to the other clients.
the way it does this is to take the length of the first value you will pass in, and make that the first charector in the message,
so that after that length, it can expect a charector to be in there that is just the length, not the actual value.
playes are given a UID at the start, and players are clones of the cloud player sprite.
minuses (-) are converted to zeros becouase of lcoud variable limitations.
it would be very hard for 2 clients so send to variable at the same time,
as their computers would have to be started at the EXACT same time, and start the project at th EXACT same time,
and have the EXACT same clock speed for the entire time the computer is running until the game is stopped, AND have the EXACT same specs.therefore very unlikely. so here is the actual example. say my mouse was at the top of the screen (y 180). so i move it down 80 pixels and that
position gets recorded into a list. then, next frame, my y is at 100. that is recorded as well. 0. -100. now it has four values of y to send. i will not incude x in this so it is eaiiser to understand. it sends that data to the other clients like this, assuming the UID is 50 : 25028031001040100.
then the gobo clone takes that information, and converts it to a set of positions. then, frame by frame, it assumes these positions.
by the time it is done, another set is ready to be used. of course with this you will experieance a wait in between movements like usual.
if that was not enough information, i can provide more at your disposal.

D-ScratchNinja wrote:

I believe it's entirely random.

Entirely random is the best way to do it.
a) Assign one cloud variable per player at the start of the project –> too much risk of one variable being overloaded with players compared to others
b) Try to find the best available variable –> theoretically great, but almost impossible to get working (every player will try to use the same cloud variable at once!)
c) Random –> risk of players trying to use the same cloud variable at the same time, but the risk is evenly distributed among everybody so it works out

Topic closed to prevent future necroposts.