Save Game Data in Flixel – FlxSave the Safe and Easy Way!


Saving game data is super important.  If you get sloppy and mess it up then all sorts of awful bugs can creep in.  That’s one of the reasons I’ve always hated the way that Flixel deals with saved game data.  They exposed too much and dealing with FlxSave still feels like dealing with shared objects (flash cookies).  You shouldn’t have to deal with details like that when all you really want to do is get and set your save game data.


Something like this would be nice…


FlxSaveWrapper to the Rescue…

FlxSaveWrapper encapsulates FlxSave and provides a safer/easier interface.



SaveGame example


Here’s SaveGame, which is an example of how you might use the above class.


To keep things simple, the only saved data used here is “highScore”.  However, you can easily add additional members by mimicking what I did here – create getter and setter functions and then use the setter function in defaults().


Notes on Encapsulation, Abstraction and Data Hiding

(Feel free to gloss over this section if you’re short on time)


I went on a bit of a tangential soap-box-rant here, so let’s consider this section optional.  Seriously though, keeping these topics in mind as you code really will help you reduce bugs and improve the quality of your code.  If you’re interested in honing your expert programmer skills then pay close attention here.  If you’d prefer to just get on with it then either skip or gloss this part…


In the previous code, take note that the only access the game has to “highScore” is through this SaveGame class. I could easily have made everything public but I didn’t do that for several reasons. Perhaps the most important reason was to ensure the integrity of the save data through proper encapsulation and data hiding.  It doesn’t matter how good of a programmer you are, you’re human.  Sooner or later you’ll be tired or sick and will screw up… you do NOT want that to happen to save game data! The last thing you want is a mailbox full of hate mail from player complaints that saved games were lost or corrupted by an oversight or power outage, so keep that data protected!


By only allowing access to “highScore” through a getter and setter, we also gain the ability to maintain our save data behind the scenes whenever a new value is set.  Currently the only other thing that the game has (and needs) access to is the defaults() function, which was included in case you want to allow the player to reset their local high score to its original value somewhere in the game. It’d be very tough to mess up a system like that, even when you’re not at the top of your game!


Another advantage to these layers of abstraction is that it forces all the actual reading and writing of your game data to take place in one sensible class, in this case, SaveGame.  You are effectively localizing related code.  This makes changing and adding things later on A LOT easier – you don’t have to try to hunt random bits of code down or remember how all the pieces fit together.


Anyway, that’s enough about the importance of keeping save data safe and the numerous advantages of encapsulation, abstraction and data hiding…


Using the SaveGame is now soooo Simple!


Here’s how to use the SaveGame class (this should look familiar)…


Notice that all the actual saving, loading and defaulting is done behind the scenes, where you don’t have to worry about it at all!  Better yet, it doesn’t even feel like you’re dealing with shared objects, does it?


Your Turn…


If you found this helpful, please help to spread the word by clicking any of the quick share-buttons below.  This will also encourage me to write similar blog posts in the future.


And as always, if you have any questions or helpful tips/resources, please feel free to leave a comment below.  It only takes a moment and self promotion is encouraged if topics are related.

Thank you for your support!
-John Hutchinson (Level X Games)
3 thoughts on “Save Game Data in Flixel – FlxSave the Safe and Easy Way!
    • That depends a lot on the game and platform.

      For some games, automatic/invisible saving is simply a better design decision. For example, in a racing game with check points that you cross while you play, you wouldn’t want the play experience to be stifled by system dialogs, pop-ups and the like.

      In certain games, you can get the best of both worlds by letting the player change the default path in a settings menu or asking them when they start a new game. Again, it depends on the game.

      It also depends on what technology the game is running in. If it’s a browser or mobile game, for example, then you have to deal with very strict security restrictions which only allow you to save at one specific location.

      If it’s a cross platform game then you also need to insure that your solution is simple and consistent enough to work on all platforms.

      I agree that being able to changed the save location is great for many games though! But that’s just not how Flixel’s FlxSave class is designed to work and I suspect that trying to force shared objects to do that would be more trouble than it’s worth.

      Anyway, thanks for the comment and happy coding! 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

1 × four =