Login Multiple Devices

General (non-technical) Testing Forum for Moderators / Admins
#21

Hey Dingo,

I was having this same problem…

My solution was to just think of every possible case a user could mess things up and code some logic to prevent all of this. However this can get complicated very quickly, I tried it myself ;), but I must say it works now.

Another possibility might be, although I am not familiar yet with the cloud sync feature, to set a certain game sync state when on device A and to set a different state when logged in on device B. This way you can check which device has been logged in.

One thing though, I am beginning to doubt the advantage of logging a user in and out?

Because a user can still mess everything up, e.g. if a user is playing a game on device A, during the game the user can sign in on device B, this will still mess everything up right?

If this is not the case and your game can handle the above situation, I don’t really see a problem in just syncing the device first before letting the user make a new move.

Good luck!

Qwertier

#22

Dingo, to illustrate the sync feature I was thinking of:

You have three states:

NONE_LOGGED_IN, if none of the devices are logged in

LOGGED_IN_LOCKED_[random_id], no other devices are able to be played on

LOGGED_IN_AVAILABLE, other devices can now claim the logged in state

So when the state is either NONE_LOGGED_IN or LOGGED_IN_AVAILABLE the device can be logged in and the LOGGED_IN state is set to LOGGED_IN_LOCKED_[random_id] on both the cloud sync and the client itself.

All the other devices will now be unable to login until the LOGGED_IN state changes to abailable or none. The same will apply for devices already signed in but with the wrong random_id you can just sign them out the moment a user wants to make a move or get new game data.

When a user signs out of the signed in device you simply set the LOGGED_IN state to AVAILABLE again.

Hopefully you get what I mean

#23

hey qwerier, thanks a lot for your insights and ideas!

I haven’t started yet, but thanks for inputs!

#24

Hi guys,

I just want to understand a little more on what exactly is getting messed up.

Because of the stateless nature of the service, there is no contention for the same object, so things can’t really get messed up, they can be overwritten for example Scores. But this is actually the correct behavior, highest score for a user should always be recorded.

As we see it as long as the game/user/state info resides with Corona Cloud and you are not saving critical info locally (which means it can’t be sync’d), then you shouldn’t ever be in a position to mess up anything.

If you guys can share with us something specific that we can reproduce that would be really helpful.

Thanks

-Mohamed

#25

 thanks for getting back to us mohamed,

what if we have a state on the device, and do not sync that permanently? like having an offline state, and syncing only every third time? (so we dont have that many api calls)

but maybe you are right, we simply need to have all the states in the cloud. for sure this would work i guess… but at the same time, this could cause a lot of api calls?

I still need to think of a scenario that wouldn’t work :slight_smile:

#26

Hi Dingo,

We’ll keep an eye on this, and we will try and think of any scenarios that could cause things to break and address it.

In the mean time, keep us posted on use cases where this could happen and we’ll take care of it.

Thanks

-Mohamed

#27

Hi Mohamed,

Let’s give an example:

If a user logs in on the devices A and B and loads a particular game move on both of the devices, say turn C.

Now if the user processes turn C on device A and the outcome of this is turn D which is uploaded to the server again.

Because of this device B is out of sync, it still thinks we are at turn C.

If B processes turn C and turns it into a turn D and uploads it to the server, things get messed up.

Now obviously this can be prevented rather easily by checking if it’s the user’s turn, but what if another user processed turn D and uploads a turn E.

Then the original user thinks it can now upload turn D while it is the user’s turn again, however instead of D we are now at turn F.

To summarize, the letters weren’t a very good idea ;), if you don’t keep on checking for new turns every time a user makes a move, things can go out of sync rather quickly.

Unless you, of course, always check what turn the game is at; by counting turns etc. However it costs a lot of extra API calls…which we don’t like

Maybe I am missing something, please tell me

#28

Hi qwertier,

One thing to note is that the Corona Cloud server is authoritative, which means if a user makes a move regardless of the device, it will not accept another move from that users until his/her turn comes again.

So regardless of whether you check who’s turn it is or not, we would not allow more than one move per person/turn (assuming you have turn-based MP enabled).

Checking turn on your end, helps you with things like UI; to enable ‘Submit’ button for example or anything that you want to communicate to the user to indicate game progress.

Hope that makes sense.

-Mohamed

PS. Letters weren’t too bad, had to sketch down on a piece paper though! ;-) 

#29

Ok that’s nice to know :slight_smile:

The only thing that isn’t solved with this, is: what if the user submits an old turn from device B, because this device was not yet synced with device A.

So to illustrate it even better:

device A and B receive turn D -> A processes the move and submits turn E -> now device C (from another user) processes E and submits turn F

Now what if the user of the devices A and B now decides to start playing on device B, while it is still synced at turn D, what happens is that device B processes turn D and submits turn X.

This will cause no errors on CC, however it is obvious that turn X should be an answer to turn F and not to turn C.

It is plausible to code logic to prevent this problem. However for some games this might get complicated and you don’t want to check first if you are at the right turn number before submitting a move.

So there are two solutions two this problem: either log out all devices except one, or even better I think, let us send the expected turn number with the submitMove function. This way CC can check if the intended turn is the right one and otherwise throw an error.

Qwertier

PS. I understand that with the last solution you still have to make multiple API calls if the turn number is wrong, but this makes sure that you only need to resync the device when it’s needed. So when the turn numbers are not in sync anymore. If the turn numbers are in sync (most of the cases) you will save on API calls because you didn’t have to check first.

#30

Hi,

I see what you are saying.

Here what you can do is to send the game state as the submitMove which will include the new move. This way when the move is received; all devices will be in sync.

There isn’t much we can really do on the cloud side to prevent or control game logic, because we don’t actually know if this is the expected or legel move or not.

As with anything, you will have to make sure that you game has some form of sanity check, as in this case taking in the game state from the move.

So here, there isn’t any significant change or increase in API calls at all.

Does that make sense?

Thanks

-Mohamed

#31

Hi,

So what I understand from this, please tell me if I am wrong.

Everytime before I want to call submitMove I should check whether we are on the right move, either by checking a state, or just counting the number of turns gotten via the getRecentMoves function.

This is very doable of course, however you still call getRecentMoves() and then submitMove() right?

So it costs double the API calls to check. But I understand that this will always be the case and it isn’t your fault guys :slight_smile:

Qwertier