Includes

Bars

2009-09-09

Email-Based Browser Game Save File System

I was halfway through reading this Kotaku article when I came across this:
Then, a man who'd been waiting in line for nearly half an hour for a turn at the microphone put it something like this: "[I define] ‘Gamer' as someone dedicated to the perfection of fun. You can't do that in 10 [minute intervals]."

There was an audible hiss from the crowd and the panelists shifted uneasily. Was this guy saying casual gamers didn't count as gamers, or just classifying all short gaming experiences as casual games?
Now, if this were true -- if "casual" games were inherently incapable of perfecting fun and therefore not worth people's time -- then every single game made at the Global Game Jam this year (including the one I helped make) would be devalued simply because the games weren't supposed to have a play time longer than 5 minutes.

Naturally, I was rather upset by this, and then the following occurred to me:

A lot of the "casual game disgust" browser games get is based around the fact that no browser game allows you to save your progress, close the browser, and continue the game later unless the game uses either:
  • a password encoded with the save state,
  • browser cookies, or
  • a server-side permanent user account system
Practically no one in this day and age is going to want to remember an encrypted password for a browser game. Additionally, written passwords have to be short enough to write down, and as such can only save a very limited set of data.

Sometimes, cookies can't or won't save. Even if a cookie is saved, you would only be able to continue your game on the computer the cookie was saved on. Even then, there's a risk that the cookie will be accidentally deleted for some reason.

Server-side permanent user account systems are incredibly expensive. Not only do they have to have a large capacity, they also have to have an insane processing speed. Very few (if any) small-time browser game developers are going to have that kind of funding available.

I propose a browser game (possibly procedurally generated) that uses the player's own email account as a save file storage/retrieval system.

Here's how the process would work. When you start a new game, you enter an email address and a password. Then later, when you save your game, an email is sent to the email address you specified. This email would contain several pieces of information:
  • your email address (stored in the "to" field inherently, but also encrypted in the email body)
  • your game password (encrypted and in plain text the first time you save, encrypted any time after)
  • your game save data (always encrypted)
So basically you'd receive an email that looks like gibberish.

If you quit and then want to continue where you left off, the game would ask that you reply to that email and make no changes to its contents (asking you to be sure to remove all reply formatting added by your email provider). When this reply is sent, a server-side timer starts counting down (say... 5 minutes). You have until the timer expires to open the browser game and login. If the timer expires, you have to send the email again to restart the timer.

What actually happens when you send the reply is your username (your email address, sent in the "from" field of the email, and also encrypted in the email body), your password (encrypted), and your save data (encrypted) are copied into the server-side database, but ONLY FOR THE DURATION of the timer. When you log in, the game data is loaded into the browser client and deleted from the database (it's deleted when the timer expires anyway).

This method has many advantages, some of which include:
  • No need for a permanent user database in the traditional sense (all server transactions are on countdown timers, and all interactions consist of email handling or record checks)
  • All save files are stored by the player
  • Player can store an infinite number of save files (all of which are conveniently timestamped)
  • No chance of server-side save file loss or corruption (if the game goes down temporarily, there's no chance your save data will be corrupted)
  • Save files are portable between games (if a sequel or update is released, save files for the first game can be easily ported to the sequel or update)
  • Save files can be encrypted in any way the developer wants (and can be as long as the developer wants)
  • More effort can be put into the game's development (think Chrono Trigger in a browser game)
  • Save files are safe even if email is intercepted (thief's email address would not match encrypted email address, and even if the email address is spoofed they'd have to intercept every save file email sent to that account to keep playing)
I don't know if browser games (java, flash, w/e) are even capable of behaving in the way I've described, but if they are, I believe the potential for this system is staggering.

AFTERTHOUGHTS (2010-01-27):

Encrypted URL saves are a form of save-data-encoded-password, which can also be stolen and shared with everyone, and are therefore undesirable.

A common concern I've fielded about this could be considered its most obvious flaw, the potential for save hacking. I fully recognize that when you give the player direct access to the save data (encrypted or not) it's very possible for the player to somehow decrypt and modify the save data for the purpose of cheating.

My answer to this is two-fold.

First, there's the question of risk. Since the developer can encrypt the save data in any way they wish, they are in complete control of how secure the save data is. For example, there's no reason a developer couldn't enforce a semi-permanent user account system which hash-checks "recent" saves. If the loaded game was hacked, it won't have the same hash result as the original legitimate save. (If you wanted to load an old save in this variant, you'd either wait for the hash check to stop watching your account or simply email the game provider with a request to remove the watch.)

Additionally, there's the question of worth. There's no reason games made with this system should ever have online multiplayer (with persistent character data). Hotseat or split-seat (simultaneous) multiplayer, sure, but not online (AFAIK, no online multiplayer game would dare give the player unchecked direct access to their character data). As such, there's no more or less incentive for a player to cheat than with any other game ever made which supports cheat codes. Yes the possibility's there, but what's the point? Whoopty-doo, you hacked a single-player game to give yourself $1M of in-game currency. Congrats, you just ruined the experience. It's not like you can show it off to your friends except through screenshots and YouTube.

2 comments:

  1. Actually, a lot of Flash games I've played on Kongregate have save game systems.

    Flash actually has its own set of cookies.

    Another idea that could work would be that it sends you a link to a page that includes the encrypted information and creates a new cookie with that (no matter what system you're on)

    I think that it is definitely possible from conversations I've had with Flash developers. Not sure about other plugins and how they save.

    ReplyDelete
  2. @micheal lubker:

    The big problem I see with URL-based saves is anyone with the URL has your save.

    ReplyDelete