Chainmanner wrote:

No support. I'm pretty sure it can be done with current standards.

Not easily at all. The methods now are much too difficult for the experience level Scratch is aimed towards. Also, there is a 2 second delay in online gameplay using cloud variables, so that can really mess things up.

BTW, i updated my post. Here's what i added:

scimonster wrote:

Streaming all that data likely will use up lots of bandwidth. I have a few ideas to counter that:

1. Make sure the user explicitly allows streaming for each project – give them a dialog on projects that stream data, similar to the one for projects that can detect your username. It could say something like: “This project has X sprite(s) that share data between players. Do you want to allow it? If you are on mobile or have poor network speed, we recommend disallowing. The project may not work well without sharing.”
   
2. Have a limit on the number of sprites that can stream. Something like 50, counting clones?
   
3. Only stream diffs. When you connect, receive all the data. After that, only get/send what changes.
   

scimonster wrote:

BTW, i updated my post. Here's what i added:

scimonster wrote:

Streaming all that data likely will use up lots of bandwidth. I have a few ideas to counter that:

1. Make sure the user explicitly allows streaming for each project – give them a dialog on projects that stream data, similar to the one for projects that can detect your username. It could say something like: “This project has X sprite(s) that share data between players. Do you want to allow it? If you are on mobile or have poor network speed, we recommend disallowing. The project may not work well without sharing.”
   
2. Have a limit on the number of sprites that can stream. Something like 50, counting clones?
   
3. Only stream diffs. When you connect, receive all the data. After that, only get/send what changes.
   

Totally support all of those, especially 3. I'll add your quote to the main post.

turkey3_test wrote:

Chainmanner wrote:

No support. I'm pretty sure it can be done with current standards.

Not easily at all. The methods now are much too difficult for the experience level Scratch is aimed towards. Also, there is a 2 second delay in online gameplay using cloud variables, so that can really mess things up.

Creating a multiplayer game isn't supposed to be easy. It would actually be a good thing that it's kinda hard, since it might encourage others to learn more. The 2 second delay, yes that's an issue, but it also depends on client's connection, meaning it could be milliseconds at best.

More things to think about.

How would the ‘search for players’ block work? Meaning, who is counted as waiting? Only other people who are currently waiting with this block, or any logged in users with the project open? I'd be inclined to say the first one.

Block idea:

(# of players) //category=purple

Reports the number of people who are waiting, including yourself.

“Players” has too much of a game sound. Perhaps “connectors” would be better? Or “project players”?

What would the (player (1 v)) block report? The username? What if there is no connector with that number?
Also, i think it should not have a dropdown. Same with those (mouse x/y of [player 1 v]) blocks, which would make them (mouse x/y of player (1)).

turkey3_test wrote:

1. Non-logged in users will not be able to play unless Scratch decides to start giving them a random username with the username block, because you could not detect which offline user is who. The creator of the project could program the online capabilities to be disabled if the user is offline.

2. If the user has open multiple tabs, I'm not quite sure. Maybe your player # can be not only linked to your username but IP address, too, so you cannot play as two players from the same IP.

3. The server itself will tell who is which player. It'll take each user and give them each a number randomly.

Player ID numbers should be incremental, like the User ID block from 2.0 beta. So, the first person to connect to this session is #1, the second is #2, etc.
If someone wants to connect multiple times from the same account, let them. The first time they'll be #1 or whatever, the second #2 or something else, etc.
As for anonymous users, i don't think it's necessary to stop them. Simply set their “name” to a number sign, then their ID. So, if an anonymous user connects third, their username would be “#3”. Logged in usernames can't have the # sign, so you can simply check if they're logged in or not by checking the first character.

If Scratch gets anonymous (first-class) lists, i would also totally want a (list of players) block, that returns a list of players.

EDIT: I don't think we need a (connector ID) block, because you can just set a variable to the (# of connectors) that will be your ID.

scimonster wrote:

More things to think about.

How would the ‘search for players’ block work? Meaning, who is counted as waiting? Only other people who are currently waiting with this block, or any logged in users with the project open? I'd be inclined to say the first one.

Block idea:

(# of players) //category=purple

Reports the number of people who are waiting, including yourself.

“Players” has too much of a game sound. Perhaps “connectors” would be better? Or “project players”?

What would the (player (1 v)) block report? The username? What if there is no connector with that number?
Also, i think it should not have a dropdown. Same with those (mouse x/y of [player 1 v]) blocks, which would make them (mouse x/y of player (1)).

turkey3_test wrote:

1. Non-logged in users will not be able to play unless Scratch decides to start giving them a random username with the username block, because you could not detect which offline user is who. The creator of the project could program the online capabilities to be disabled if the user is offline.

2. If the user has open multiple tabs, I'm not quite sure. Maybe your player # can be not only linked to your username but IP address, too, so you cannot play as two players from the same IP.

3. The server itself will tell who is which player. It'll take each user and give them each a number randomly.

Player ID numbers should be incremental, like the User ID block from 2.0 beta. So, the first person to connect to this session is #1, the second is #2, etc.
If someone wants to connect multiple times from the same account, let them. The first time they'll be #1 or whatever, the second #2 or something else, etc.
As for anonymous users, i don't think it's necessary to stop them. Simply set their “name” to a number sign, then their ID. So, if an anonymous user connects third, their username would be “#3”. Logged in usernames can't have the # sign, so you can simply check if they're logged in or not by checking the first character.

If Scratch gets anonymous (first-class) lists, i would also totally want a (list of players) block, that returns a list of players.

EDIT: I don't think we need a (connector ID) block, because you can just set a variable to the (# of connectors) that will be your ID.

Good points.

This Would Be So Awesome! Im'ma Make A Topic That ADDS To This One.

I Was Inspired By Turkey3's Topic So I Thought I'd ADD To It.

Maybe There Should Be A

() Of Net User () // category=sensing

Which Would Snap ANY Reporter In.
The Most Useful:

(username)(mouse x)(mouse y)(answer)(loudness)(video [ v] on [this sprite v])

There Would Also Be Features Where You Could See Each Others' Screens.

But It Would Tell You That All This Stuff Is For Advanced Users.

But It Couldn't Just Not Let New Scratchers Use It Because What If Your Test Account Is Still A New Scratcher?

mrsrecthemes wrote:

This Would Be So Awesome! Im'ma Make A Topic That ADDS To This One.

You could just post your ideas in this topic…

ProdigyZeta7 wrote:

Definitely support. Now you need to elaborate on how it will detect all users currently using a project.

Does it exclude anonymous users? What if one user has two tabs open for the same project? How will it tell who gets to be first player, second player, and so on? How reliable will this be for fast-paced games?

It should exclude anonymous users. If the username is blank then the person is anonymous.

if <(username) = []> then
    set [players v] to [0]
end

If a user has two tabs open for the same project. It's simple to fix. You simply have to check if the username of the person opening the project from one side equals to the username of a person opening the same project from another side, then it will know that it is the same person.

if <(username) of [player 1 v] = (username) of [player 2 v]> then
    set [players v] to [1] since it's the same person
end

You can tell if a person is first or second player, if a player logs in first then they will be the first player, and if they go on the project after the first person goes on then they are the second player, and so on.

For now it won't be that reliable, since the network/cloud connection delay is 2 seconds. Until they decrease the delay to something low, then this can only be reliable to slow-paced games and not fast-paced games.

Chainmanner wrote:

mrsrecthemes wrote:

This Would Be So Awesome! Im'ma Make A Topic That ADDS To This One.

You could just post your ideas in this topic…

Paddle2See Merged Them.

Maybe make the search block a double-C like if-else where the first is if you are one of the players and the second is if you're not.

turkey3_test wrote:

Great ideas! I guess the Scratch Team would set up powerful servers so it would only take milliseconds. When you play online games, you are in constant connection with the server, but only when a cloud variable changes does the computer connect to the server, which is why, I think, it takes a couple seconds. Correct me if wrong.

Well there's no “make it faster” button, and I could imagine that the Scratch HQ doesn't have a money printer

Actually I think connecting when needed makes it faster, as you only send data when it's needed e.g. you're not saying “Nothing happened” every 0.2 seconds.

Re: block wording, how about “viewers”?

i only support the “stream sprite values” thing. the other stuff might be confusing for new scratchers.

mrsrecthemes wrote:

I Was Inspired By Turkey3's Topic So I Thought I'd ADD To It.

Maybe There Should Be A

() Of Net User () // category=sensing

Which Would Snap ANY Reporter In.
The Most Useful:

(username)(mouse x)(mouse y)(answer)(loudness)(video [ v] on [this sprite v])

There Would Also Be Features Where You Could See Each Others' Screens.

But It Would Tell You That All This Stuff Is For Advanced Users.

But It Couldn't Just Not Let New Scratchers Use It Because What If Your Test Account Is Still A New Scratcher?

Zambonifofex wrote:

i only support the “stream sprite values” thing. the other stuff might be confusing for new scratchers.

How about advanced view?

if player 1 = usernameset player to 1
when I receive playthis script is in the sprite car Aif player = 1…
when I receive playthis script is in the sprite car Bif player = 2each player ends up with his own sprite…

savaka wrote:

mrsrecthemes wrote:

I Was Inspired By Turkey3's Topic So I Thought I'd ADD To It.

Maybe There Should Be A

() Of Net User () // category=sensing

Which Would Snap ANY Reporter In.
The Most Useful:

(username)(mouse x)(mouse y)(answer)(loudness)(video [ v] on [this sprite v])

There Would Also Be Features Where You Could See Each Others' Screens.

But It Would Tell You That All This Stuff Is For Advanced Users.

But It Couldn't Just Not Let New Scratchers Use It Because What If Your Test Account Is Still A New Scratcher?

Zambonifofex wrote:

i only support the “stream sprite values” thing. the other stuff might be confusing for new scratchers.

How about advanced view?

HI LOL

turkey3_test wrote:

AmayaCreates wrote:

This would take so much effort and time to code. For nowI vote no.

When creating an online game, it's not meant to be easy to code with. Personally, I think this would be pretty easy to code with.

ProdigyZeta7 wrote:

Definitely support. Now you need to elaborate on how it will detect all users currently using a project.

Does it exclude anonymous users? What if one user has two tabs open for the same project? How will it tell who gets to be first player, second player, and so on? How reliable will this be for fast-paced games?

1. Non-logged in users will not be able to play unless Scratch decides to start giving them a random username with the username block, because you could not detect which offline user is who. The creator of the project could program the online capabilities to be disabled if the user is offline.

2. If the user has open multiple tabs, I'm not quite sure. Maybe your player # can be not only linked to your username but IP address, too, so you cannot play as two players from the same IP.

3. The server itself will tell who is which player. It'll take each user and give them each a number randomly.

4. For fast-paced games, it depends on how much data needs to be streamed. With my internet I can download files online at about 3 megabytes per seconds, so unless the project needs to stream over about 2 megabytes of data per second, speed should be fine. Sending over x, y positions, costume #s, direction, etc. should not exceed a small number of bytes. If about 100 sprites were streaming, your computer would probably be reading 1mb of data every second (remember each frame). As for sending out data, when you change the value of a streaming sprite, your computer streams out the data which the server will change and send back to each computers.

I think it would make more sense to have the player #s determined by login order.

A-no-meep wrote:

turkey3_test wrote:

AmayaCreates wrote:

This would take so much effort and time to code. For nowI vote no.

When creating an online game, it's not meant to be easy to code with. Personally, I think this would be pretty easy to code with.

ProdigyZeta7 wrote:

Definitely support. Now you need to elaborate on how it will detect all users currently using a project.

Does it exclude anonymous users? What if one user has two tabs open for the same project? How will it tell who gets to be first player, second player, and so on? How reliable will this be for fast-paced games?

1. Non-logged in users will not be able to play unless Scratch decides to start giving them a random username with the username block, because you could not detect which offline user is who. The creator of the project could program the online capabilities to be disabled if the user is offline.

2. If the user has open multiple tabs, I'm not quite sure. Maybe your player # can be not only linked to your username but IP address, too, so you cannot play as two players from the same IP.

3. The server itself will tell who is which player. It'll take each user and give them each a number randomly.

4. For fast-paced games, it depends on how much data needs to be streamed. With my internet I can download files online at about 3 megabytes per seconds, so unless the project needs to stream over about 2 megabytes of data per second, speed should be fine. Sending over x, y positions, costume #s, direction, etc. should not exceed a small number of bytes. If about 100 sprites were streaming, your computer would probably be reading 1mb of data every second (remember each frame). As for sending out data, when you change the value of a streaming sprite, your computer streams out the data which the server will change and send back to each computers.

I think it would make more sense to have the player #s determined by login order.

Agree

We should get the scratch team to see this!

Scratch On,
~Shredthe3rd
*Licks sword*