What's the worst that could happen? (Farm copying)

[worfc]

Because of the way farm-recovery is being implemented in v1.4 ("Soon!"), it will be possible for multiple copies of your farm to exist.

Because of the the way auto-save works, it will be possible to run 2 copies of your farm, make changes in both, and have one of the copies "stomp"-save over the other, costing loss of progress.

Because "safeguard" and "recover" farm is being implemented via Facebook login (soon: Google, others), anybody who can login as you on Facebook can get a copy of your farm.

My question to you is:

What's the worst that could happen?

I mean this from all angles. Obvious ones include:

* What's the worst possible cheat someone could effect using multiple copies of their farm?
Item duplication? Coin duplication? I don't think so, but maybe I'm missing something.

* What's the worst possible user experience related to multiple copies of their farm.
What comes to mind is: (a) user could purchase IAP on farm #1, then farm #2 auto-saves without IAP-information and they lose real-world cash.[1] (b) You could sign-in to Facebook on someone else's iPad, forget to sign out, they use the "already logged in" feature to "recover" your farm (putting a copy on their device), then forget about it. You spend the next month working really hard and advancing your farm, then the other person launches your month-old farm and saves it. The next time you launch, you're back to that old farm.

What else might go wrong?

What are some possible fixes?

Thanks!


---
[1] There are big, giant warnings about how you shouldn't do this, baked into the system. I can't help people who willfully damage themselves.

[noivad]

I don’t have either FB nor Google for several reasons.

Also, can’t you timestamp saves so only the latest save loads instead making “copies.” IF you want to actually make a clone of the farm, can’t you fork the farms by adding a new farm ID concatenated with the User ID (or however you uniquely label farms/users)?

The reason I mention this is because, I designed a shared document DB where I had to allow forks and then allow merges (much like say github does it now) for the primary content last millennium for a company. Of course there were a ton of metadata columns I could pull from to make sure I could combine UserID+ContentID+Timestamp to prevent overwrites—That’s assuming you have a relational structure—no idea since I dunno anything about your DB’s structure.

The scripting language I had to use was no where near as full featured as Obj-C nor even php, but it was more advanced than mySQL’s stored procedures (or at least a lot easier to write), but I was able to hack it together without much slowdown (probably due to the DB’s script cache architecture—like memcache, and various other caching of script output, etc.) and it was solid. Then again, the scripting language didn’t allow you to make mistake (more safety nets in a scripting language after all). So, adapt that idea if you think it’s useful.

[worfc]

No FB or Google: These aren't required (and other OpenID solutions are "on the list"), it's just a mechanism to offer people a way to safeguard their farm.

You may have noticed that WoRFC is currently "login-less login" -- you never see your UserID or password. However, if you delete & reinstall your app, the new copy of your app never sees your UserID or password, either, and tries to create you a new farm.

"Safeguard your farm" is intended to allow you a way to recover a thus-lost farm. However, as a side effect, it means I can hand you my iPad, you can log-in, and "recover" your farm to my iPad. Now we both have your farm.

While there might be complicated schemes to prevent this sort of thing, my #1 goal is to give people a way to not lose their progress. #2 is to make the experience not-horrible. "Protect users that are actively hostile to themselves after they've been multiply warned" is way-way down on "The List"

Merging forked farms: This sounds like the perfect way to create item/money duplication problems. Again, I'm ok with slogging through the issues and dealing with them all... "later." For now, I'm just trying to give users a way to not experience "I lost all my hard work." Again, it's not required; it's just an available option.

Preventing overwrites: Well, I guess that's one of the questions -- is this important? The "normal" use case is to recover an otherwise-lost farm and get back The One True Copy. The only way to get multiple copies is if you're "messing around with it", and this is strictly warned against (just not prohibited). Are you suggesting that putting effort into prohibiting this is important?

If I do a thing where I give the recovered farm a new ID, I guess I'd have to invalidate the old farm so it could never be saved again. Else you'd have the cheat where one guy just runs off duplicate copies of his far-advanced farm and gives them to people.

But, again: that's extra effort that takes away from other more-fun features so, again, we're back to "is that important?"

I'm not arguing for or against; I'm honestly asking for your (collective) thoughts.

Thanks!

[noivad]

No FB or Google: These aren't required (and other OpenID solutions are "on the list"), it's just a mechanism to offer people a way to safeguard their farm.

You may have noticed that WoRFC is currently "login-less login" -- you never see your UserID or password. However, if you delete & reinstall your app, the new copy of your app never sees your UserID or password, either, and tries to create you a new farm.

"Safeguard your farm" is intended to allow you a way to recover a thus-lost farm. However, as a side effect, it means I can hand you my iPad, you can log-in, and "recover" your farm to my iPad. Now we both have your farm.

While there might be complicated schemes to prevent this sort of thing, my #1 goal is to give people a way to not lose their progress. #2 is to make the experience not-horrible. "Protect users that are actively hostile to themselves after they've been multiply warned" is way-way down on "The List"

Merging forked farms: This sounds like the perfect way to create item/money duplication problems. Again, I'm ok with slogging through the issues and dealing with them all... "later." For now, I'm just trying to give users a way to not experience "I lost all my hard work." Again, it's not required; it's just an available option.

Preventing overwrites: Well, I guess that's one of the questions -- is this important? The "normal" use case is to recover an otherwise-lost farm and get back The One True Copy. The only way to get multiple copies is if you're "messing around with it", and this is strictly warned against (just not prohibited). Are you suggesting that putting effort into prohibiting this is important?

If I do a thing where I give the recovered farm a new ID, I guess I'd have to invalidate the old farm so it could never be saved again. Else you'd have the cheat where one guy just runs off duplicate copies of his far-advanced farm and gives them to people.

But, again: that's extra effort that takes away from other more-fun features so, again, we're back to "is that important?"

I'm not arguing for or against; I'm honestly asking for your (collective) thoughts.

Thanks!

The diff/merge (compare) was to see which copy & use the latest or one before things went wrong. Sorry I meant compare.

I am suggesting the the biggest guidelines in GUI is easily allowing a person to recover from mistake. It’s called forgiveness. Apps that are not forgiving tend to make it easy to hit the wrong button. So, make it forgiving if not impossible. Some sort of sync or timestamp could allow multiple changes with only the latest ever loading. If you ever had co-op in the game (I visit your farm with goods to trade), or to help plant/harvest with a secondary bot. Could even make group farms too, etc. Anyway, having a sync system that applied changes with a built in queue system could make advances in playing with others, or competing, etc. But that future expansion advantage is beside the point. By being forgiving, you also increase the appeal of your game. No matter how much you try to warn people, some will STILL screw it up. And they also are pretty loud and don’t take: “I warned you of this” as a good defense. The result is them trashing your game, undeservedly.

[worfc]

No matter how much you try to warn people, some will STILL screw it up. And they also are pretty loud and don’t take: “I warned you of this” as a good defense. The result is them trashing your game, undeservedly.

Yeah, this is the key point that finally sunk in. I must be getting tired or something, because I know this, I was just blind to it when I first started implementing the feature.

D'oh!

(That's why I put these things out here. Something wasn't feeling right, but I was too caught up in implementation details to see the obvious. Thanks for the "smack up-side the head".)

So my new thinking is: don't put up blaring warnings, just make sure the thing I'm warning people about doesn't happen.

In detail, I'm planning to make it so that "farm recovery" is just that -- recover lost farmID information to a device. As you suggested, this will entail disabling* the "old" farm in order to give the user access to the new "branch" of it.

-----
* I suppose, if the person has an off-line copy running on another device, they could continue to play, but I would disable SAVING that "old" farm, so it would always open up to the same spot, similar to a DEMO farm.

I can also do this in a non-destructive way**, to facilitate manual-recovery, should anything go wrong. (I mean a bug, not user error. "Manual fixing" of user error doesn't scale )

** Ex: just tack "--farm-disabled" onto the end of the password-hash in the database, such that it never matches any hash sent by the app.

[noivad]

No matter how much you try to warn people, some will STILL screw it up. And they also are pretty loud and don’t take: “I warned you of this” as a good defense. The result is them trashing your game, undeservedly.

Yeah, this is the key point that finally sunk in. I must be getting tired or something, because I know this, I was just blind to it when I first started implementing the feature.

D'oh!

(That's why I put these things out here. Something wasn't feeling right, but I was too caught up in implementation details to see the obvious. Thanks for the "smack up-side the head".)

So my new thinking is: don't put up blaring warnings, just make sure the thing I'm warning people about doesn't happen.

In detail, I'm planning to make it so that "farm recovery" is just that -- recover lost farmID information to a device. As you suggested, this will entail disabling* the "old" farm in order to give the user access to the new "branch" of it.

-----
* I suppose, if the person has an off-line copy running on another device, they could continue to play, but I would disable SAVING that "old" farm, so it would always open up to the same spot, similar to a DEMO farm.

I can also do this in a non-destructive way**, to facilitate manual-recovery, should anything go wrong. (I mean a bug, not user error. "Manual fixing" of user error doesn't scale )

** Ex: just tack "--farm-disabled" onto the end of the password-hash in the database, such that it never matches any hash sent by the app.

One of the big things software makers have to contend with is thinking (all) users can handle the responsibility of managing syncing. And one of the big reasons “It should be difficult to do destructive things” (thus “are you sure?” dialogs) and “user input is sacred” (meaning the effort spent either making a document or advancing in a game should be treated as valuable, and the more time required to accomplish something, means the more value) are talked about in even the oldest UI/UX books. Both are guidelines in MHIG, and should be considered. In fact, reading the MHIG and applying it is the best guide for learning what to consider when designing an app’s UI, and feature set, since it explores what things have to be considered and why something is important.

The concept of forgiveness, and appropriate control/permissions comes into play. This means don’t give people not technically adept a choice to mess up their game if it takes a technically adept person to be able to make the best choice. So, timestamps is not enough in the following edge case:
If a person has an “old” farm that they’ve worked on for months, and a new farm they’ve barely used there’s a good chance the old farm will have more progress if it was allowed to be stored locally. So, recovery should account for the newest farm might not be the best/most advanced farm. In this case perhaps allowing the person to see what each farm has in terms of game time, item and item counts and progress could present them with enough info to choose. Or allow them to try both and decide which to keep. But this is only if farms can be stored locally. If they are all stored on the main server, only race conditions (where both copies are open at once) would require a comparison/reconciliation function.

For iAPs (gold) I would probably include a “purchased” and “spent” column so you could see if a person’s balance was accurate. To prevent iAP bought in one farm from being copied to another, I would mark the iAP’s account source, so a person couldn’t transfer iAPs to themselves. Also, allowing iAPs to be transferred to another person would also necessitate a “deposited,” “withdrawn” & “accountID” to tag who gave how much to who (again this means a relational table with many-to-many joining tables). Then you’d have to script a comparison/accounting portion to make sure no one abuses it (say you give away 500g, so people open multiple accounts and transfer it all to a primary), and more importantly: no one loses any iAPs. I have heard of kids losing iAPs and being angry and so frustrated they stop playing a game.

The end goal is for a game to be fun, and the end goal for a dev is for people to use their software. Allowing users to do destructive things that destroy time spent &/or money is not fun, and any sort of frustration like this is a disincentive to play, and ultimately runs counter to the mission to have people use your software—whatever the intended purpose of it is: game, creation app, productivity app, etc.

[noivad]

The short version of part of that is: “trust your user not to be trusted ” or “the only way to make something fool-proof is to make foolish actions impossible.”