I was going to post this in help with scripts, but then I thought, it might be too complicated.
Anyways, I'm making an RPG and I wanted a multiplayer option, with a lobby (where people can chat about the games they have played, progress in single-player etc.) and 3 game rooms, where people fight it out. 2 players in each game rooms.
Does anyone know how to do that?
(P.S: In the lobby, people will have to chat using chat options already given. Like Ultimate safe chat in club penguin.)

bump.

Theoretically you could emulate a list be delimiting your entries and then serializing them into number format, but that would be really slow, so I'd recommend waiting for lists.

GeonoTRON2000 wrote:

Theoretically you could emulate a list be delimiting your entries and then serializing them into number format, but that would be really slow, so I'd recommend waiting for lists.

You can use custom blocks with “run without screen refresh” enabled. Most computers should be able to handle that.

The current problem with cloud variables for multiplayer games isn't to do with scripting (although having to create all the encoding/decoding for your list of info is obviously a pain), nor is it speed (assuming you don't have seriously tons of info per user )- Scratch can get through quite a lot in a fraction of second.

I think the current problems are:
1) The periodic polling of the cloud server is about once a second - that means approximately 2 seconds between you setting a variable and someone else seeing it. This gives a total round-trip time of about four seconds (between setting one, and seeing a response from another user).
2) The delay in seeing others update after you've updated your own - once you set a cloud variable you don't see any others update for at least a second. This means if you update more than once a second or so, then you may *never* see any updates of other cloud variables. So you have to leave a significant gap between cloud variable updates.
3) No foolproof way to prevent the problem of two users updating the same cloud variable within the delay time (i.e. a couple of seconds). This means you can't guarantee that the change you've just made to a cloud variable didn't just in some way ‘miss’ or ‘ruin’ a change made by someone else just a second before.

As an example, something I've seen happen fairly often with cloud variables is that you can set it to some value, and then about a second later it gets set back to the previous value. If you then set it again, it most likely will be fine - though not always.
I think what might be happening (and this is a guess - maybe someone can suggest an alternative theory) is that the server sends off its periodic latest info about variables just before you update one. But network delay means you receive that info just after you've sent the update. But your client then dutifully sets your copy of the cloud variable to the ‘new’ value that the server just sent you…

I've had a go at making cloudvars more robust, but it's still obviously pretty slow. Would be interested if anyone has any better ideas…?

DadOfMrLog wrote:

The current problem with cloud variables for multiplayer games isn't to do with scripting (although having to create all the encoding/decoding for your list of info is obviously a pain), nor is it speed (assuming you don't have seriously tons of info per user )- Scratch can get through quite a lot in a fraction of second.

I think the current problems are:
1) The periodic polling of the cloud server is about once a second - that means approximately 2 seconds between you setting a variable and someone else seeing it. This gives a total round-trip time of about four seconds (between setting one, and seeing a response from another user).
2) The delay in seeing others update after you've updated your own - once you set a cloud variable you don't see any others update for at least a second. This means if you update more than once a second or so, then you may *never* see any updates of other cloud variables. So you have to leave a significant gap between cloud variable updates.
3) No foolproof way to prevent the problem of two users updating the same cloud variable within the delay time (i.e. a couple of seconds). This means you can't guarantee that the change you've just made to a cloud variable didn't just in some way ‘miss’ or ‘ruin’ a change made by someone else just a second before.

As an example, something I've seen happen fairly often with cloud variables is that you can set it to some value, and then about a second later it gets set back to the previous value. If you then set it again, it most likely will be fine - though not always.
I think what might be happening (and this is a guess - maybe someone can suggest an alternative theory) is that the server sends off its periodic latest info about variables just before you update one. But network delay means you receive that info just after you've sent the update. But your client then dutifully sets your copy of the cloud variable to the ‘new’ value that the server just sent you…

I've had a go at making cloudvars more robust, but it's still obviously pretty slow. Would be interested if anyone has any better ideas…?

You could write a Scratch extension using nXIII's node.js framework and Socket.IO, but then people could change the variables easily.

Proboly only LSTC would be the only way or as above writing a extention and linking that to a server but if you are thinking cloud vars no nearly inpossoble its hard enoth making cloud lists and stuff like that

I have a moving system here, but like DadOfMrLog said, it's slow.

how do i make a moltie player game? I am trying to make moltie player games.

showed i just look it up?

AJanik wrote:

showed i just look it up?

Yes, you could also try flogging dead horses too. If you look at the date of the original post and read the content then compare with this more recent post https://scratch.mit.edu/discuss/topic/231940/?page=1#post-2357177 then you'll notice that multiplayer is a pipe dream!

(Edit: For “real-time” multiplayer which is what most people seem to want to do)