Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm working on a basic roguelike using HTML5 and jQuery, and I've come across a problem.

The way the game currently stands, the system only saves the game state every time the user moves between floors - to minimize overhead. The peril of this is that, if the user gets in trouble, they can simply close the window and return to their game at the beginning of the current floor. This drastically reduces the difficulty of the game (and almost defeats the purpose of a roguelike) - but it's unreasonable to save the game state with every single player movement or attack.

I've researched ways to save the game state on browser window close, but I'm not happy with them. My question is this: assuming "saving a game state" means a moderately heavy ajax/post request, how do I thwart this cheating behavior? Is there a known methodology to quantify incremental/procedural changes to a 2d map, as opposed to saving the entire map state? Please note, I'm not asking for "the most efficient way" - I'm looking for existing methodologies to rectify my inexperience.

share|improve this question
Very generic and general JavaScript programming question. I voted down but then I rethought since it's kind of interesting if you consider how you'd do it if you could not trigger an on-unload event. – Tim Holt Feb 9 '13 at 6:43
Maybe I'll rephrase it to address that problem directly =) – CodeMoose Feb 9 '13 at 6:47
@TimHolt - edited per your suggestion – CodeMoose Feb 9 '13 at 7:07
up vote 7 down vote accepted

The obvious solution is to send every player command to the server as it's made and have the server log them; that way, if the game is aborted for any reason, the logged commands can be replayed to restore the game to the point where it left off.

Of course, when a proper save is made, the old command log can be thrown away (although you could also save it to allow replays of old games; if you do that, you may want to include timestamps in the log for real time replay). You may also want to automatically make a full save after n commands have been made since the last save (where, say, n = 1000) to avoid excessively long replays if the player stays on the same level too long before closing or crashing the game.

If your game involves random numbers (and, being a roguelike, it probably does), you'll also need to make sure that they can be recreated correctly during a replay. One solution is to include every random number in the replay log; another is to use a deterministic pseudorandom number generator and save the seed when the game is saved.

Note that all of these methods can be exploited by tampering with the client, but that's really inevitable whenever you have game logic on the client. As a cheat-proof alternative, you could run the actual game on the server and just have the client send all player commands to the server and receive display updates back. For a roguelike, this may well be feasible. Obviously, this would also solve your state saving problem (although you might still want to implement some form of command logging on the server, both for replay functionality and to allow recovery from server crashes). The downside is that doing this would make off-line play impossible (unless, of course, you also make the server-side code available for players to run locally if they want).

share|improve this answer
AFAIK all RGN's are pseudorandom.. you need specialized hardware to get truly (unseeded) random values. – bobobobo Feb 9 '13 at 15:45
Thanks - you've given me a lot of food for thought! – CodeMoose Feb 9 '13 at 16:53
@bobobobo there's pseudorandom (seeded) and there's cryptographically secure random numbers (unseeded) in the .Net Platform. It may/may not be hardware random, but it's close enough to be unable to just store a seed. – Rangoric Feb 10 '13 at 3:16

See for a more generic asking of the same question.

Also consider saving full game on floor changes, and incremental deltas on each move. Then you can replay the game up to the point of last move.

Assuming there is some use of random number generators, you can generate and re-seed the random number generator at the start of each new floor, and then save it along with the floor. Then you can reseed on load, and should be able to replay the moves with the same sequence up to the last one done.

share|improve this answer
Thanks Tim - once I get in the game dev mindset, it's really easy to bucket anything that touches it into game dev. Props for providing an answer anyway. – CodeMoose Feb 9 '13 at 6:45
No worries - see my revised comment on question too :) – Tim Holt Feb 9 '13 at 6:47
I would have said incremental deltas on each move too. – bobobobo Feb 9 '13 at 15:43

Approaches to, not incremental saves, but finding time for a full save:

  • onunload, as previously mentioned. I have found this to be reliable (but using localStorage, not network, which may change things).
  • Save when your window loses focus.
  • Save periodically: when the last save has not been in n minutes and the user has not made any input in m seconds.
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.