About "Save" System



I’ve started to test my game, from the beginning to the end.
But the problem is, my game operates offline I guess.
And when I refresh the web page, or close the tab, my game restarts, or starts from the beginning.
It’s hard to test when it resets the scenes; because I can’t test the game in the same day. It has to “save” that page i mean.
Do you know how can I solve this thing?
All I want to have is a page saving game that I can test.
If I want to reset the game, I can do it in the stats menu but it already restarts itself when I close my PC.
Thanks =)))

Seas of Malice (Character Creation + 3 locations partially done, WIP)
Older development thread (The Aegis Saga - Blood)

@Mert, I’ve tried a few different things regarding saving the game so that I can close the browser and come back to the game later. It’s not an exact science. I can implement a save system, but the restoration of the game typically only restores the game to the beginning of a scene. Restoring to the middle of a scene should be possible, but I can never get it to work the way I really want it to. For that, I usually have to resort to the built-in “password” system.

For your purposes, the “password” system built into ChoiceScript should work decently well if you set it up correctly, as I’ll describe forthwith. To use the password system, you first have to add “restore_password” as a valid ChoiceScript command. There are several ways to do this, but one of the easiest ways that doesn’t involve editing any of the JavaScript files is to modify your index.html file itself. To do this, open your index.html file (the one in the “web/mygame” folder) in your favorite text editor. Look for the line that reads <script src="../navigator.js"></script> and under that line, enter the following code:

Scene.validCommands["restore_password"] = 1;

This now allows you to use the \*show_password and \*restore_password commands (the \*show_password command is already enabled by default). To make use of these commands effectively, you have to call \*show_password in a scene at the place where you want to save your game. Where you put this call is up to you, but I would suggest that when you use it, you use the following block of code for it:

<em>Some text here that reminds you where you are in the game.</em>

Wherever you put the above block of code, when you get to that part of the scene, you’ll see a huge text area with a bunch of gibberish inside. The gibberish is the “password” for your saved game. Copy the password and save it to a file, because you will use that same password later to get back to that place in the game. You can put the above block of code in several places, which allows you to save off any number of passwords, each representing a different place in the game. So, figure out where you want to be able to save and restore, and that’s where you place the above block of code in your scene files.

Now, to be able to restore your game using one of these passwords, you will need to make use of the \*restore_password command. You can put this command wherever you like, but the one place that makes the most sense is right at the beginning of your first scene, so that when you start up your game the next day, you can jump directly to where you left off. Here is the ChoiceScript code I’d recommend that you place at the beginning of your first scene for this:

Do you want to restore a game?
    *goto regular_start
    *goto regular_start
*label regular_start

Following that, you have your regular game code.

Now, when you start up the game and you have a saved password you want to use to restore your game, you’ll select Yes as your first choice, after which you’ll be presented with another huge text area into which you will paste one of your saved passwords. You’ll then click Next, and your saved game will be restored. Or you can click Cancel and the game will start up regularly.

A couple of warnings: When you edit a scene file, you could be invalidating any existing passwords that apply to that scene file. Also, if you modify mygame.js, you could be invalidating all of your existing saved passwords.

Basically, your standard mode of operation should be to delete all of your old passwords and start your game over from the beginning after you make any changes to your game. You might be okay to use an old password after certain changes, but it’s just safer to start over with a clean slate after you make any changes.

Hope this helps.

Older development thread (The Aegis Saga - Blood)
The outbreak [wip]

Wow, the password it creates is long! Great for testing, but not practical as a game mechanism.


@andymwhy, agreed, but @Mert was asking for something to use for testing purposes, and it works fine for that.

There’s also a persist.js file that has been mentioned in other threads about saving the game. It looks like it’s meant to be used for saving the game according to the type of device the game is being played on, but I’ve not figured out how to use it.


@eposic Thanks =)) I’m now working on your solution.
And by the way, I’m very curious about one thing: In the Choice Of Games games, like Choice of Romance, there is a save system as you know. What makes it save? Online playing? Or another thing?


@eposic I’ve done as you said. But there is a problem: When I say “Yes” to restore password, that huge text area comes, I paste the password that is given, and press next button. But it again comes to that yes/no page (it says “do you want to restore a game?” again).


I think your *label was put incorrectly, or you did the wrong *goto_scene.


@Daisuke I did something wrong thats for sure =) But is there another way to save the last page? I mean, all Choice of Games products have this saving property.


@Mert Choice of Romance uses the *save_game command to write out a savefile to CoG’s server if choice_save_allowed is true, and then retreives it with *restore_game but I haven’t been able to find any documentation on it so far, nor have I had the time yet to actually try and test it out.


Thanks @P_Tigras


Forget about Choice of Romance =)) @P_Tigras , lets say, all CoG products has a game saving property right? Like the new one, “Heroes Rise”. It saves the last page. When you close the tab, or refresh the current page, it doesn’t starts over the beginning scene. Or, doing “back & forward”, still shows the last page. What causes this? Or, will it be work for my game also?


Any answers?


@Mert, you probably have two options to get the answers you seek about saving games.

  1. Write Dan Fabulich at support@choiceofgames.com. Dan knows how to set up the saving mechanisms obviously, but it’s not documented that I have found, and one has to wonder if CoG wants to keep it mysterious on purpose.

  2. You can look at the JavaScript files supplied with the ChoiceScript download and try to figure it out, which is what any of us would have to do if we wanted to make use of the game saving mechanisms that currently exist. As may be apparent by now, none of the rest of us on this forum understand the existing save game mechanisms (or maybe some do but simply don’t want to share).

I’ve decided a better use of my time is to work on the actual game than on trying to figure out the save mechanism, because if my game is published by CoG, I’m sure Dan will set up the usual save mechanisms for it to the extent he deems necessary, and that will be good enough for me. If my game is not published by CoG, I’ll figure out something when the time comes. For now, the simple password system is good enough for testing purposes imo, and works better than anything else I’ve tried.


@Mert I came to the conclusion that if CoG wanted all & sundry saving playtest games to their server then they would’ve documented the system they use and thereby made it readily available. They didn’t, which suggests to me that either they also didn’t (and still don’t) see the “need” for this before an actual release version is ready, or they simply don’t want the hassle of having to provide ongoing support for that, especially considering that most player-developed games never even reach a final release version.

I disagree with the former, if that’s the reason–there clearly is a need in some cases–but I have to agree that providing ongoing support for a playtest save system could be a royal pain in the ass for them, with noobs like me making a mess of things and forever running to them for help . . . That’s a hassle they can do without, and I strongly suspect this is the real reason.

Above all, arguably most “standard” CS games don’t really need a hard save system during the development stage–a “soft save” (as documented elsewhere on the forum) should suffice in many cases. The problem is, more new games in development are pushing the boundaries of what has been done before, and the definition of “standard” is no longer quite so clear, nor so limited in their ambitions. Ultimately I think CoG will have to both provide and support a save system for all games in development, or risk losing some of the more ambitious ideas to other, similar, development systems where a save feature is built in and readily available.


@Mert You’re right, games on CoG’s server are now doing something to keep their data persistent that they didn’t do before. Hitting the reload/refresh button no longer sends you back to the beginning of the game. Even if you close all your game tabs, if you go back to the web site and select the game again you’ll be right back where you left off. That’s the upside. The downside is that it used to be possible to have multiple tabs running a game at the same time, with the ability to make different choices in each tab. Now all tabs open to the same game reflect the same instance of the game, and not multiple independent instances of the game. It wasn’t this way in the past.

I can’t tell you how they accomplished this because I don’t know myself. You’d probably have to ask Dan Fabulich as @eposic has suggested.

Regarding the save system in general, I’m in pretty much total agreement with both @eposic and @Vendetta. A hard save really is more convenient than a password save, nevertheless the current hard save is not configured to write to a file on your computer, but to CoG’s server instead, and changing that would require some JavaScript hackery. So I can see why they might not want to make the current hard save system easily available to every single person who tries to create a game. For most of the conceivable games out there, the password system that @eposic has been kind enough to detail is workable if a little cumbersome. I do agree with @Vendetta however that ultimately they will need to come up with a more robust and versatile hard save solution for competitive purposes.


@P_Tigras , @Vendetta , @eposic , thank you so much =)


@P_Tigras, have you tried using multiple browsers to play multiple instances of the same game simultaneously? That is, use IE, Firefox, Chrome, and Safari to have four different instances of the same game going at once? I’ve not tried it, but it seems like it should work, if all of those browsers can be used to play the games.


@eposic Yep, it works if you use different browsers.


@eposic I know you are not working on your save system but do you think I could use it as a DC like mine would really benifit from it during development. Of course if it would require a lt of time to help me implement I would understand if you rather not share it, thanks.


@Lordirish, I will share what I have done so far, but please note that this system does not always return you to the exact same spot where you do the save; it sometimes returns you only to the beginning of the scene. YMMV.

First, I created a JavaScript file that I called ss.js (ss = save system). You place this file along with all the other JS files in your web folder. The contents of this file are as follows:

function getGameValueFn() {
  if (!stats || !stats.scene) {
    alert("Sorry, the game cannot be saved.");
    return false;
  var password = computeCookie(stats.scene.stats, stats.scene.temps, stats.scene.lineNum, stats.scene.indent);
  password = stats.scene.obfuscate(stats.scene.name + password);
  return password;

function loadGameCallback(password) {
  if (!stats || !stats.scene) {
    alert("Sorry, the game cannot be loaded.");
    return false;
  var token = stats.scene.deobfuscatePassword(password);
  var icol = token.indexOf("{");
  var scene_name = token.substring(0, icol);
  var token = token.substring(icol);
  var state = null;
  try {
    state = eval("state="+token);
  } catch (e) {
    alert("Sorry, your game could not be loaded.");
  saveCookie(function() {
      clearScreen(function() {
        restoreGame(state, scene_name, /*userRestored*/true);
    }, "", state.stats, state.temps, state.lineNum, state.indent);

In your index.html file in your mygame folder, you then include this file like any of the other JS files are included, as follows:

<script src="../ss.js"></script>

Okay, so this is the foundation of any save system I’ve tried so far. The getGameValueFn function returns a password (or false on failure), and the loadGameCallback function accepts a password and attempts to restore the game accordingly. What is left to be done is to invoke them when you want to save or restore the game, and to keep that password around somehow so that it can be passed in to the loadGameCallback when you want to restore the game.

For this, I resorted to using my HTML5 localStorage save system that I wrote a year or two ago and have used elsewhere on the web for various purposes. It makes use of jQuery, so you have to point to jQuery and to my save system file in your index.html file. To do that, you can include the following lines in your index.html file:

<script src="http://code.jquery.com/jquery-1.7.2.min.js"></script>
<script src="http://eposic.org/js/storageSystem.js"></script>

There is a good deal of code in both of those JS files that you won’t need, but if you link to them from the sites as shown above rather than hosting them on your own server, everyone will be using the same code, which will support caching in an optimum fashion. A lot of people already have jQuery cached in their browsers, possibly without even being aware of it, because they’ve visited a site before that uses jQuery and linked to it using the URL I’ve shown above.

Okay, so a couple more steps to go. The way that I chose to make the save/restore functionality available to the user is to put links at the bottom of the page, where they are always accessible, rather than showing them only at certain times within the game. @Lordirish, you’ve already seen this in my Castle of Chaos game (which, by the way, has an ending now, if you ever make it to grid point x=999, y=999, though further work on the game has been postponed for the foreseeable future). Placing links into the game for the purpose of saving and restoring the game involves editing the index.html file and plopping in some HTML code at the bottom of the page (or wherever it is you want the links to appear). I usually put it right above the line in the index.html file that looks like this: <div id="mobileLinks" class="webOnly">

The HTML code I use for the save/restore links looks something like this:

<div id="sa" style="display: none;">
  <a href='#' id='save_game1'>Save Game 1</a>
  | <a href='#' id='save_game2'>Save Game 2</a>
  | <a href='#' id='save_game3'>Save Game 3</a><br />
  <a href='#' id='load_game1'>Load Game 1</a>
  | <a href='#' id='load_game2'>Load Game 2</a>
  | <a href='#' id='load_game3'>Load Game 3</a><br />

The display: none style attribute will prevent the links from being displayed until later JS code massages the links. As they are, the links simply reload the current page, but with the last remaining step of the process we will use jQuery to make those links do what we want, and to then show them to the user.

So, the last step in this process is to write the JS that hooks everything together and activates it all. In your index.html file, go back up to the place in the header where you included those extra tags aforementioned. Remember, there are three JS files you pulled in: ss.js, jquery-1.7.2.min.js (from the jQuery server), and storageSystem.js (from my eposic.org server). Somewhere after those three files are included, enter the following JS code:

var game_ns = "<em>namespace specific to your game/server</em>";
(function($) {
  $(function() {
    if ($.Eposic.SS.isSupported()) {
      // show the div containing the buttons for saving and loading
      var game_ss = $.Eposic.SS.get(game_ns);
        game_ss.save(game_ns, "1", getGameValueFn());
        alert("Game 1 saved");
        return false;
        var game_val = game_ss.load(game_ns, "1");
        if (game_val) {
        } else {
          alert("You do not have a game saved to slot 1");
        game_ss.save(game_ns, "2", getGameValueFn());
        alert("Game 2 saved");
        return false;
        var game_val = game_ss.load(game_ns, "2");
        if (game_val) {
        } else {
          alert("You do not have a game saved to slot 2");
        game_ss.save(game_ns, "3", getGameValueFn());
        alert("Game 3 saved");
        return false;
        var game_val = game_ss.load(game_ns, "3");
        if (game_val) {
        } else {
          alert("You do not have a game saved to slot 3");

I’m not going to explain this code line by line. Note however, that this code looks to see if the Eposic storage system is supported by the user’s browser, and if it isn’t, then nothing is done, which results in those links for saving/restoring the game not being shown. The user won’t even know what they are missing.

If the Eposic storage system is supported (which basically means that the computer/device supports HTML5 localStorage), then the links are displayed and set up to actually do something. When a save link is clicked, it will get the current password for the game and save it using my Eposic storage system. When the corresponding restore link is clicked, it will restore the game saved to the same slot (1, 2, or 3 – yes, you can save up to three different games at the same time).

A word about the game_ns variable: You can use this save system in different games on your server, but the value of the game_ns variable must be different for each game, or you’ll have the games saving over each other.

You can also enable more slots to save games to by following the pattern established for the 3 slots I’ve demonstrated.