So recently i had the idea to make a save system for a game. I looked into ones online and i noticed quickly a very critical flaw in the save system i am planning on to use.

So basically, the lets say the user has 50 coins in game. The user clicks the save button and then the game generates a code based on the amount of coins they have, let's say the code turns out to be “250b” this is just an example but the algrithiom for it would be the users amount of coins *5 and then the first number of the coins being a letter. (eg, 1 = a, 2 = b, 3 = c, etc).

If the user goes inside of the code and finds the algrithiom, they can reverse engineer it to give them tons of coins. For example, they could do “9999999i” and get 333333 coins.

Heres where it gets a bit complicated.

I did a little bit of research into this and the only one that i really liked was having a backend using Glitch, Replit, or even GitHub Pages. Then i would create an API Backend using Flask (pythons framework) to handle the requests, aka when the user tries to save their game, and then it would go to a Save endpoint (eg. /saveGame) that accpets user data (aka coin count).

Heres where the problem is.

Scratch doesn't directly support http requests, so the game would detect the amount of coins, and then tell the user to enter the amount of coins they have to the website, which would then perform the algrithiom there, but that still wouldn't solve the problem because the user could still enter like 999999 into the amount and still get tons of coins. In an ideal world, scratch would support http requests and when the user clicked save game, the game would submit all the game data (coins) into a http request to the website, which the website then process that and uses the algrithiom to create a save string ( eg, griffpatches paper Minecraft) , and then sends an http request back to scratch, which then displays the save string that the user can copy and paste the next time they want to load the game.

But, this is not an ideal world and heres the solution i found.

I could create a scratch extension (Using Javascript) that the user could use that is able to submit and receive http requests. However here is the problem for me. This requires knowledge of Scratch's extension API and some JavaScript coding, which i unfortunately don't have, which is why im here asking for help.

Any help would be gladly appreciated, and if you cant help please tell anyone you know that can help about this post.

Thank You!

SubForums: Help With Scripts, Collaboration, Questions About Scratch, Advanced Topics, Developing Scratch Extensions

tagging topics doesn't really do anything, and a topic can only be in one forum at once

There is a built-in API for manipulating cloud vars (clouddata.scratch.mit.edu, if I recall correctly).

Regardless of what you do, the user can still cheat by going inside and changing variables. However, if you click “see inside” and change anything it disables cloud vars for that instance of the project, so things like world records aren't affected.

Cloud vars can store up to 256 variables, and you can have 10 cloud vars per project. This allows greatly slows down the amount of information you can send in a reasonable time because that's much less than the minimum size of, say, an IP packet.

You could do some sort of encoding — make it so that the save code doesn't obviously have any numbers with a particular pattern. Maybe you could use random letters instead of numbers? Like, in the part of the save code that represents coins, use “ZADZ” to represent the number 5025. That way it's not as easy as changing a 50 to a 999999. If you make the reverse engineering require even a little bit of effort, most Scratchers probably won't attempt to do it.

I also know that there's a way you could encode the username so that the save code only works for a particular Scratcher. That way, if someone “cheats,” it will only affect one person.

Is there a reason why you want to make a foolproof anti-cheat mechanism for your game? I'm typically of the opinion that it's fine to let folks play a game however they want. After all, if someone wants 999999 coins, they can just see inside your project and give themselves 999999 coins and create a save code for that.

BigNate469 wrote:

tagging topics doesn't really do anything, and a topic can only be in one forum at once

There is a built-in API for manipulating cloud vars (clouddata.scratch.mit.edu, if I recall correctly).

Regardless of what you do, the user can still cheat by going inside and changing variables. However, if you click “see inside” and change anything it disables cloud vars for that instance of the project, so things like world records aren't affected.

Cloud vars can store up to 256 variables, and you can have 10 cloud vars per project. This allows greatly slows down the amount of information you can send in a reasonable time because that's much less than the minimum size of, say, an IP packet.

Oh cool i didnt know scratch had an anti tamper thing for that

Za-Chary wrote:

You could do some sort of encoding — make it so that the save code doesn't obviously have any numbers with a particular pattern. Maybe you could use random letters instead of numbers? Like, in the part of the save code that represents coins, use “ZADZ” to represent the number 5025. That way it's not as easy as changing a 50 to a 999999. If you make the reverse engineering require even a little bit of effort, most Scratchers probably won't attempt to do it.

I also know that there's a way you could encode the username so that the save code only works for a particular Scratcher. That way, if someone “cheats,” it will only affect one person.

Is there a reason why you want to make a foolproof anti-cheat mechanism for your game? I'm typically of the opinion that it's fine to let folks play a game however they want. After all, if someone wants 999999 coins, they can just see inside your project and give themselves 999999 coins and create a save code for that.

Yeah, the reason why is because I am going to have leaderboards and i want them to not be cheated, and as for the more complicated save code i am going to do that the theory I have was just an example.