Suggestion: Persistent save data (with persistent game links)

Arcade Help
1

With the introduction of persistent links (quite a while back, actually) I’ve wondered if saving a setting in one game version, then updating it and republishing it with the Update existing share link for this project option checked would make the setting’s value remain.

Unfortuantely, this is not the case. It works in the editor, but trying it in the actual game by accessing the link doesn’t. The reason this feature would be VERY useful, would be gaining the ability to update the game (whether it’s adding new features or just bug fixes) while letting the player keep their progress between versions. If you want to erase the data, you can just simply tick the update to disable it and drop a new link for the new version. Would it be possible to implement this @richard?

5 Likes
2

Hmmm… That’s an interesting idea, but it worries me a bit. For example, what if someone makes a game that stores a value and then releases a new version that makes that previous value invalid and crashes the game; the person playing the game could accidentally be locked out of that game permanently.

Of course, it’s definitely possible to cause a similar bug with the current implementation… I just think that people would have a harder time anticipating such bugs if we changed the behavior. I agree though that it’s nice for the experienced dev.

3 Likes
3

Perhaps an option to enable it for advanced devs? And of course a killswitch for the user that allows them to clear all saved settings for a specific game in the sim (since this is easy to do on real hardware already)
Just a suggestion on how to approach it, idrk how you’d specifically go about it in the best way.

Just wanted to bring attention to it, so think about it since it’s a cool feature I think many people would really appreciate

2 Likes
4

@richard any updates on this? It’s a feature I think a lot of people would really appreciate; it’s no use making any sort of progression/level system right now because as soon as there’s an update it’s all gone.

I can’t pull off a lot of game ideas because of the lack of this feature :slightly_frowning_face:

1 Like
5

Does it work for GitHub pages? (I don’t remember if it does)

6

hmm @UnsignedArduino that might be a nice compromise…

3 Likes
7

So, are we getting it or what :smirk:

1 Like
8

i would say this is a low priority feature right now, not because it’s a bad idea but because we have a big backlog of issues to work on.

that being said, getting it to work on the github pages embed shouldn’t be too much trouble. i’ll take a look at it when i have a sec.

5 Likes
9

Thanks, 'preciate it

1 Like
10

I believe there is also a need for something like this for educational use. My experience with using MakeCode in a classroom setting, is the unfortunate, but expected and indeed creative, occurrence of 2 particular forms of “cheating”, either:

  1. To go into JavaScript in the teacher’s solution file and just copy the text code and then paste the text code into your own assignment and share and hand in, or
  2. To get a copy the solution from one of the classes’ brightest or most industrious students and just share this with your own new share link and hand in as-is.

The first one is pretty easy to control by either postponing the publishing of the teacher’s solution, or bake into the students’ hand-outs subtle differences in the code, so that copying and pasting text code from the teacher’s solution either does not run correctly and/or has watermarked differences that are easily noticeable.

The second “cheat”, however, I have so far found to be more difficult to both discover and hinder.

With settings persistent across shares, like @Sarge here suggests, wouldn’t it then be possible to run a unique hash routine only once on opening the program, which would then be carried on with the new share which is handed in to the teacher, watermarking it as unique for the first student who handed it in, regardless of the various share link URLs?

Maybe one could also use an ask-for-name-routine on only the first run/open of the assignment, like this one from @AlexK, where the name is carried on as setting in the new share link that is handed in?

Lastly, perhaps there already exists a technique to guard against “cheat” no. 2, using GitHub, file save, or some other mechanisms, that @KIKIvsIT and others in the @MakeCode team who are focused on the educational side of MakeCode already know about and could please share?

1 Like
11

Speaking of which, any updates on this issue?

2 Likes
12

Yeah, any updates on this issue?

I am mostly interested in any measure in @KIKIvsIT bag of educational anti-cheating tricks, but believe that persistent save data could be used with great success also for such purposes. :wink:

2 Likes
13

To be honest I just want it since it would greatly improve game experience, but I can see it being used for educational purposes as well!

3 Likes
14

we talked about this on monday’s stream. Go check it out!
(spoiler: it will probably not happen)

2 Likes
15

Of course, @Sarge! Both use cases would benefit greatly from this! Maybe other use cases as well. I am just trying to keep your thread hot and unforgotten, so that we might get some responses eventually.

«Bump» is just so boring and unoriginal… :wink:

2 Likes
16

Did you file this as a pxt-arcade issues feature request, @Sarge?

17

Didn’t do it yet. Feel free to if you want to

2 Likes
18

Thanks! But there’s been an inflation of issues and feature requests in my name lately, so it might here be more effective coming from someone else… :wink:

And after all, this is your baby and brainchild!

1 Like
19

Okay, so I went and checked out the stream and richard stated (@ 32:00) that the feature should be functional when deploying your projects on github pages (data is not wiped on update) and that we should just tell him if it does not so he can fix it. I’ll be sure to test this out and post the results!

2 Likes