Store game state on server

Got a cool idea that should be in R'n'D? Let's hear it!

Moderators: Flumminator, Zomis

Post Reply
edud
Posts: 3
Joined: Tue Dec 07, 2021 10:28 am

Store game state on server

Post by edud »

Hello, all!
OK.
Now you can upload information about the passed levels to the server. It is interesting.
But, for example, I personally lack the ability to save the state of the game on the server. It would be possible to play from different machines with the same settings profile.
I would like to be able to run a game on a computer and then continue on a laptop. Right now I'm just copying the game profile (Rocks'n'Diamonds directory in Documents or for linux .rocksndiamonds in home directory) from one computer to another.
Hope you get the idea? The volume of files stored in the profile is small - about hundreds of kilobytes.
Ofcource, it's not easy. This raises the problems of authorization on the server (maybe UID?), the problem encryption of user data, the problem of encrypting traffic, the problem of paying for traffic on the server, the problem of versions game data and so on.

======================
Best regards,
Eugene
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Store game state on server

Post by Holger »

It's a good idea, but would indeed not be that easy to do it in a sensible way.

Users are assigned a UUID to identify them on the server, and a different R'n'D instance (on a different computer, for example) would therefore have a different UUID. So the only way to identify a "same user" would be to introduce real user accounts (with unique username, password and mail address to revocer the password). I just don't want to do this, to keep things as easy as possible (and many people probably don't like to be required to set up a user account before playing).

This could be done as an "advanced feature" though. But I'm not sure how many people would use such a feature, so it may not be worth the implementation effort... :?
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Store game state on server

Post by filbo »

It does seem like your server already has most of the state, lacking only 'what levelset was I just playing' and 'what are my settings', more or less. And, of course, a login / authentication mechanism.

Overall it looks like missing stuff is (from user's ~/.rocksndiamonds/ or equivalent):

- scores/... -- but might already be implicit in what is on the server
- levelsetup/... -- ditto
- levels/... -- user's actual levels, including WIP etc., probably don't want these uploaded except intentionally
- autosetup.conf
- editorcascade.conf
- editorsetup.conf
- levelsetup.conf
- serversetup.conf
- setup.conf
- usersetup.conf
- and I suppose the other 5 *.conf available in '-e print', for those who may have their own

Now, serversetup.conf is the 'key', i.e. it contains the player UUID. You already have the situation where players can 'pretend' to be each other by making a serversetup.conf with the other player's UUID. I think, rather than making it wildly complicated, why not just have that be the key? People copy their ~/.rocksndiamonds from system to system, which includes their serversetup.conf, therefore they're already keyed to 'login' as themselves. Yes, someone could maliciously do so, but ... would they? Why?

-- But, humans being what they are, it's probably correct to assume that it would actually happen. So maybe a simple password facility? A hash of the password would be kept locally, something like 'serveruserpass.conf'. If the user copied their entire .rocksndiamonds to a new system, they would automatically be 'logged in'. If they omitted that file, they'd have to pass a password challenge, then the file would be written and they wouldn't need to do it again. (The only reason this would be needed at all is that I assume the player UUIDs are visible in the database. If they're entirely secret, stored on the server + user's serversetup.conf but never visible in DB records, a password isn't even needed. Mind you I am not at all trying to define a 'high security' system here, just something that would keep out trivial griefers!)

Of course as soon as a 'password' is introduced, you need a 'help I lost my password' mechanism. Which probably means storing an email address, which then runs afoul of things like GDPR, huh. ughhhh.

=====

Let me suggest the following crazy password recovery mechanism:

1. None
2. If someone has lost their password, they learn [through in-software guidance etc.] how to contact Holger.
3. Holger + user figure it out in realtime

-- which is to say, I imagine -- perhaps stupidly -- that this is probably something like a twice-a-year occurrence. Someone occasionally contacts Holger with their tale of woe, and he says OK, do you have serversetup.conf? What's the UUID? Ok, let's see if you have the following level tape file stored in the right place on your system ... yeah, that seems legit. Or, no UUID? What local save files do you have? Maybe we can tie it together anyway. Or if you have nothing ... what was your player name? Did it change from a different one? ... whatever small forensic activity it would take. And always with the possible outcome of 'sorry, your data may be on the server but I can't tie you to it so you need to start over'.

It isn't really even clear to me what 'harm' someone could cause by spoofing. Play some levels before the 'real' person of that UUID, therefore stashing fake tapes? Be able to claim bragging rights for a large or high-scoring or stylish set of tapes? Given that multiple systems can 'be' the same UUID at once, none of this prevents the original person from continuing as they were; except the database may have some tapes/scores which they didn't create. That doesn't seem like an emergency; at most, sort of an annoyance. Oh, and they might change the user's settings for future logins -- that's a bigger annoyance. But seems unlikely.

=====

Some of the settings -- maybe only in setup.conf, maybe some others -- seem more system-specific than player-specific. Things like window scaling, vsync mode, engine snapshot memory, everything about input controls. I'm sure there are even some settings which some users would want to carry from system to system, and others would want to be system-specific. Slicing that mess apart seems like the hardest part...
Post Reply