Hey guys! This is an introduction to the creation of Full Scale MMORPGs in Scratch, they have the potential to support hundreds of players at once, i'm dedicating this to a friend of mine who wanted to gain an insight into these concepts, however, this guide is open to everybody! Please post your opinions, feedbacks, questions, or anything else!

What is A Normal MMORPG?

In professional game development, an MMORPG would be considered a massively multiplayer game that uses a Server/Client connection in order to allow players to interact and play alongside hundreds of other players. Most of these games require an extensive team of developers, most of whom have mastered programming languages and must contribute monstrous amounts of work.

The Scratch Implementation of An MMORPG
Do not attempt to go near this tutorial if you have not mastered scratch and the concept of variables, lists, and iterations! To come as close as possible to creating an MMORPG, we must use cloud variables in the following manner (We should use lists, but cloud variables will do fine for now), the only limitation to cloud variables is interference, text and negative number storage which we will go over, here is a list of ways view cloud variables in order understand how an MMORPG will work with those peculiar bits of storage:


1. Cloud variables will not be read as a number or a value, but multiple separate values, like a list

- Here would be an example: A cloud variable that stores 3-digit X positions of sprites that has the value 123000044006999 equates to a list like this:

item 1 = 123
item 2 = 0
item 3 = 44
item 4 = 6
item 5 = 999

- **IMPORTANT** - Notice how one digit and two digit values are represented in a three digit format inside the variable, this allows a consistent retrieval, without such a procedure, it would be difficult to distinguish between separate values without some kind of unique separator, which we will talk about later (used in the username cloud variable). In order to maintain such a format, just append as many 0s as neccessary in front of the numbers that have less digits that the storage format! The value itself won't change. This is indicated in number 2.

2. Cloud variables will have consistent storage formats! This is very important, before you create a cloud variable, decide on the maximum digits or length of each player's section of the cloud variable. i.e. A variable to store x positions might use sections of 5-Digits each, this means that the maximum x position a player could store would be 99,999 and the minimum 0, you could change this range, but that's not important right now, the maximum number of values is 99,999

- If a player's current x position were 3 digits long, 256 for example, and the cloud variable had a consistent storage format of 5 digits, then you would need to append two zeros in front of the 3 digits to make it into the correct format for storage.

3. Each client (Player) will use cloud variables to retrieve, parse, and update data for the player, as well as retrieve and parse the data of all other players

- Retrieve: Each player's data will pertain to a subsection of a cloud variable, the scratch program will locate this section that pertains to them and set it into a local variable for their own sprite's use, then locate and use all other players values. The formula to retrieve the location of the data within the cloud variable:

(Player number- 1) * Storage Format Length + i = i digit of player's data

Example: A cloud variable of SFL 3 digits has this value: 111222333444

This indicates that there are 4 users, if you were user number 2 and wanted to find your value, then join together the 3 digits
with the formula to find each digit, to find them the first it would be like this: (2-1) * 3 + 1 = 4, position 4 of the variable is 2
the first digit of player two's value.

Player Number - # users when signed up, set to this value upon account creation.

SFL (Storage Format Length) - # of digits of data per player in the variable.

i - The digit you are retrieving.

- Parse: Variables will differ very much in their MMORPG function (Inventory, level, position), depending on the type of data, the value will be parse or changed into a usable format.

A variable that holds all positions must hold x & y positions right? In order to do this, you would have to create double the digits of just one position. Say that the x position's max value will be 99999, the storage format length would then be 5, therefore to store both x and y values, the length of each player's data would be 10. When retrieving this data, you would then have to parse it back into 2 separate values.

That is only one case! Some variables like an inventory, could use a special system to store values. In order to connect a player's inventory data with all the items that the inventory shall hold, there must be a way to order items and have subsections of the value correspond to each item. For example, since there are 99 different items that can be stored, each item would be a two digit value pertaining to that costume number of one sprite called object and the inventory system's max storage could be 15, thus creating a total storage format length of 15 x 2, or 30 digits per player. MMORPGs will incorporate many features, how will you parse and store data for so many different types of data! Be inventive! Among the many, there are currencies, stats, chatting, parties, etc.

The most difficult cloud variable to parse and update would be the username variable, chat variable, and other text based data? How could we store text into numbers? To do this, we need to create unique identifiers as mentioned before. All you need to do is create two lists one for all the possible values you can store and one for the numbers pertaining to each letter. The list containing the numbers need to never include two values of your choosing, say 0 and 9, these two numbers will be used as unique identifiers to tell us two two things: When we are moving from one letter to the next, and one user's data to the next. These cloud variables will not use storage length formats and will instead be separated by unique identifiers. Now let's make an example! Let's say that 0 will identify the moving on from one letter to the next, and 9 will identify the moving on from one user to the next.

Possible Values List Possible Values List
item 1 = a item 1 = 1
item 2 = b item 2 = 2
item 3 = c item 3 = 3
item 4 = d item 4 = 4
item 5 = e item 5 = 5
item 6 = f item 6 = 6
item 7 = g item 7 = 7
item 8 = h item 8 = 8
item 9 = i item 9 = 11
item 10 = j item 10 = 12
item 11 = k item 11 = 13
item 12 = l item 12 = 14
item 13 = m item 13 = 15
item 14 = 1 item 14 = 16
item 15 = 2 item 15 = 17
item 16 = 3 item 16 = 18
item 17 = 4 item 17 = 21
item 18 = 5 item 18 = 22
item 19 = 6 item 19 = 23
item 20 = 7 item 20 = 24

Username has the value 12010301309201101401409

The value when parsed would be jack and bill, see that? the 9 tells you it's the next user, the 0 tells you each character, and the numbers are translated using these lists. In order to parse it, you must loop through username and keep adding the parsed usernames into a local list.


- Update: The reverse to retrieving player data, the player will constantly take the newly changed local data and update it back into the cloud variable at intervals depending on when it's neccessary (i.e. a player who just gained exp, would update that back into the cloud variable and not at other times because it would affect performance and be unnecessary)

Cloud variables require updating the entire variable in order to update a single player's subsection, as a result there may be massive interference, and many possible issues. There are solutions to this, but they are very complicated and will not be included in this basic tutorial! Brainstorm your own To update the value back into the cloud, you must take the subsection of all the players before your player number, then take your player number's subsection and append the two, finally you must take the subsection of all the players after your player number and join all three together, then set it back to the cloud variable.


Thank you very much for reading my tutorial! Feel free to post any feedback you may have! Hope that this may have helped you, i will be adding on how to clone sprites according to the x and y position cloud variables and finishing the rest of it as time permits! Good luck to all! If anybody would like to join an awesome MMORPG project, consider OTIMUS COLLAB!

A great resource of blocks for the functions neccessary for mmorpgs! Check this out, the substring block is perfect for retrieval of subsections! bobbybee's Block Collection

itsmomito wrote:

A great resource of blocks for the functions neccessary for mmorpgs! Check this out, the substring block is perfect for retrieval of subsections! bobbyBee's Block Collection

It's bobbybee.. but..

hey, cool, I'm mentioned! :p

Also, there are some serious security concerns with this method. I can explain them in depth, if someone cares, but let's just say anyone with a little technical knowhow can do some real stuff…

bobbybee wrote:

itsmomito wrote:

A great resource of blocks for the functions neccessary for mmorpgs! Check this out, the substring block is perfect for retrieval of subsections! bobbyBee's Block Collection

It's bobbybee.. but..

hey, cool, I'm mentioned! :p

Also, there are some serious security concerns with this method. I can explain them in depth, if someone cares, but let's just say anyone with a little technical knowhow can do some real stuff…

Lol! Sorry about that, i'll change it! Ahh very interesting, I'd love to hear about this “technical knowhow” and the security concerns!

This tutorial is amazing! I have about everything down in this section. Thanks for taking the time to write such a well thought-out tutorial!!!

And security concerns? o.o

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

bobbybee wrote:

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

Thank you very much for writing that up! Wow, that's amazing! I never thought of the security concerns. I won't ever stop caring though So, I'll be looking for ways to increase security and test the things you were talking about. ScratchJIT sounds amazing! What's the progress on that so far?

bobbybee wrote:

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

Could you maybe try implementing Diffie-Hellman's key exchange for security? Or would no encryptions be of any use?

NNNEEEOOO11 wrote:

This tutorial is amazing! I have about everything down in this section. Thanks for taking the time to write such a well thought-out tutorial!!!

And security concerns? o.o

No problem! Glad it could help you

itsmomito wrote:

bobbybee wrote:

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

Thank you very much for writing that up! Wow, that's amazing! I never thought of the security concerns. I won't ever stop caring though So, I'll be looking for ways to increase security and test the things you were talking about. ScratchJIT sounds amazing! What's the progress on that so far?

I haven't worked on JITScratch since Scratch Day 2013 when I presented it (along with my cloud data hack :3), however it is in a working state (it currently implements all essential blocks. I don't have a list but I believe it was everything except for motion, sound, costumes, and some sensing)

itsmomito wrote:

bobbybee wrote:

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

Could you maybe try implementing Diffie-Hellman's key exchange for security? Or would no encryptions be of any use?

You could, indeed, implement an encryption algorithm into cloud data, which, albeit being slow, would solve issues of unauthorized modification. However, you are still left with the issue of controlling function-based rather than data-based objects. (read: NPCs, AI of all kinds, including doors opening and whatnot, and PvP battle).

bobbybee wrote:

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

Wow, you're amazing

I never knew any of this. I didn't even think a hacker would hack a Scratch project (though I imagine it wouldn't be too hard). Maybe I could ask one of my hacker friends what he thinks of it.

I get most of what you're saying. That group computing sounds like a game of chess, where players shout out A2 to A4 or something. And does JITScratch convert Scratch to JS or are the custom blocks in a different language? Also, would you be able to manually access or view the JS code code? Sorry - so many questions. I'm not as code-savy as you or itsmomito. I'm still learning JS and HTML/CSS

NNNEEEOOO11 wrote:

bobbybee wrote:

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

Wow, you're amazing

I never knew any of this. I didn't even think a hacker would hack a Scratch project (though I imagine it wouldn't be too hard). Maybe I could ask one of my hacker friends what he thinks of it.

I get most of what you're saying. That group computing sounds like a game of chess, where players shout out A2 to A4 or something. And does JITScratch convert Scratch to JS or are the custom blocks in a different language? Also, would you be able to manually access or view the JS code code? Sorry - so many questions. I'm not as code-savy as you or itsmomito. I'm still learning JS and HTML/CSS

Thanks

Not exactly. Really, it's like a game of chess, where you have the 2 players and a referree, and if anyone breaks the rules (moves the opponent's pieces when they're not looking, etc.), one of the 3 people will say something and it's crosschecked against the third person. Problem here is that if the third person as well is compromised, you can effectively frame people.

As for, JITScratch, it simply iterates through the blocks and converts it 1-1 to JavaScript. (a Scratch compiler, if you will). JITScratch's main engine by itself does not run anything and is highly customizable: out of the box, it will simply output the JavaScript representation, and with a little bit of tweaking, it will run it as a server (I had a demo up and running where it would serve to a Flash project, never bothered to finish integrating it with Scratch).

No problem I think the more people like you today, the more smart people we'll have in a few years from now. I was once as clueless as you, too.

bobbybee wrote:

NNNEEEOOO11 wrote:

bobbybee wrote:

Well, cloud data, in its peer-to-peer distributed nature, are very prone to both natural distortion due to instability, and more so, it is trivial to modify their contents by manipulating the packet stream (I can explain how this works, but I'm not sure the Scratch Team wants these details public. If you're interested, run a packet sniffer, I prefer Wireshark, and it's on cloud.scratch.mit.edu). At this point, you now have access to the low-level protocol: my old implementation of this was sufficient for hacking simple polls and high scores, where there is a simple number and no encoding.

Therefore, once the entire client side and/or the distributed cloud data network is compromised, a hacker (or, at this point more likely a script kiddie) may run the algorithms packaged in the MMO (Scratch makes this very easy, especially this implementation: simply run the custom blocks to en/decode the desired data). At this point, you now have access to the project-specific encoding: this cannot be automated by a library, but it *can* be reverse engineered on a project-by-project basis to avoid restriction to Scratch and have seamless integration with a foreign language library.

Now, you can control any synchronized between the users through cloud data. This ranges everything from simple scores, to lists encoding player positions, to rather disturbing game control (one odd one I think of at the moment is changing other peoples chat history and usernames..) All your base are belong to me.

Anything that happens on the client (read: anything you code in your Scratch project rather than on the Scratch servers) can and will be hacked.

The only way to circumvent this is group computing, which I may write an article on sometime later. This is where you use cloud data as a private message system and have multiple users messages each other in a web-like fashion to collaboratively control NPCs.

I personally am still hoping that JITScratch will become a Scratch reality, where users can write custom blocks for game logic, and run it on the server at lightning speeds by converting it into JavaScript (which is JIT compiled into native code under node.js)

tl;dr
Scratch is slow and cloud data insecure. Either move to another language, or stop caring :p

Wow, you're amazing

I never knew any of this. I didn't even think a hacker would hack a Scratch project (though I imagine it wouldn't be too hard). Maybe I could ask one of my hacker friends what he thinks of it.

I get most of what you're saying. That group computing sounds like a game of chess, where players shout out A2 to A4 or something. And does JITScratch convert Scratch to JS or are the custom blocks in a different language? Also, would you be able to manually access or view the JS code code? Sorry - so many questions. I'm not as code-savy as you or itsmomito. I'm still learning JS and HTML/CSS

Thanks

Not exactly. Really, it's like a game of chess, where you have the 2 players and a referree, and if anyone breaks the rules (moves the opponent's pieces when they're not looking, etc.), one of the 3 people will say something and it's crosschecked against the third person. Problem here is that if the third person as well is compromised, you can effectively frame people.

As for, JITScratch, it simply iterates through the blocks and converts it 1-1 to JavaScript. (a Scratch compiler, if you will). JITScratch's main engine by itself does not run anything and is highly customizable: out of the box, it will simply output the JavaScript representation, and with a little bit of tweaking, it will run it as a server (I had a demo up and running where it would serve to a Flash project, never bothered to finish integrating it with Scratch).

No problem I think the more people like you today, the more smart people we'll have in a few years from now. I was once as clueless as you, too.

Thanks for explaining that! Would you be able to view the JS code and edit it? It would be amazing to be able to convert a Scratch project to JS and code it from there. Though a big problem would be cloud variables, I imagine.