Best Practices for Data Storage in AS3

[Skye McCloud]

This is not really for coding specifically, but for data storage for AS3.

Long story short, I've been working on a game the past few days where there is to be a LARGE amount of stored data. By a large amount, I'm talking something like 200+ entries of around 12 fields.

The game is being designed with the intent of playing it online (per say), so I can't rely on storing specially made files on one's computer (Not that I think I could and do it in a way where players cannot modify it). I also do not want to rely on a stored XML file on the internet or on a database, because if the website that has this data goes down or if the person loses internet access, then the game becomes unplayable.

So, I need to store this data in the game itself, but I am unfamiliar with the best way to go about doing this. I've normally worked with outside sources for data storage, as they were designed in closed environments (aka intranet) or the website that the SWF would be on would also be where the database used is stored. Neither apply to this game, as the game will likely be put up on Flash portals like Newgrounds.

Any tips on the best way to go about this?

[justkevin]

Your question as asked doesn't make sense. You want to store persistent information for a game, but don't want to store it on the player's computer or online? Where would that leave?

I think the solution you are looking for is a server app, either implemented via a web app or a socket server that connects to a database. That's how online multiplayer games work.

[Skye McCloud]

Well, what I mean is, I'm not going to offer a version to be saved on one'a computer to play, nor am I going to convert it into an AIR app. It'll be on various Flash portals. The game is not multiplayer, it just won't be normally downloadable (unless they download the SWF itself)

Because of this, I need a way to store the information, that's not relying on a 3rd party website (such as my own) and does not rely on a database which I wouldn't have access to.

In other words, I want everything contained in the SWF that Flash pops out (At least, this is what I assume I'm after. That way, the data sticks with the SWF no matter whee it goes), but I've NO idea on what the best practice is for this.

[justkevin]

In that case it sounds like you want to use Local Shared Objects (just Google that phrase) which are like cookies, but for Flash apps. These are stored on a user's computer, but tied to a specific Flash application (like your game).

It's technically not stored in the Flash app itself, but an external .sol file on the user's computer. A technically savvy user can modify these if they want, but that's true with any application that doesn't store its data on the server.

[Skye McCloud]

Oh, no no, it's not shared objects. I know about shared objects and I'm using one for such data. What I'm talking about is a database-like amount of data.

As an example... the game I'm building is a micro-RPG. So I would have a huge list of enemies, where each enemy has stats, abilities, etc etc. Now, I know how I'd build that into a database or even an XML file, but what is the best method for building it directly into Flash?

[gamingPC]

Well, I would just make a class per enemy. every object will have its own data with it.

so you got

enemy1.hp
enemy2.hp
enemy3.hp
enemy4.hp


each object is also representing its own class.
so every one of them has a diffrent value.

[Skye McCloud]

I thought of that, but... what if I end up making, like, 100 different enemies? That's a LOT of classes.

[gamingPC]

I thought of that, but... what if I end up making, like, 100 different enemies? That's a LOT of classes.

sure, but the 100 different enemies are what bring the " a LOT". Its a database that makes the a LOT possible.

now think about it, do you know any game that has 100 enemies inside it?
have it? now, do you think its got all its parts inside of it?


you should try to have some arrangement with every site that will feature the game.
I know Armor Games has a Multi-Player game called Colony, perhaps they will set you up.

[Skye McCloud]

In an RPG, they technically would, but they would save artwork development time by making "species", where there would probably only be 30-40 different species, of which they'll then make three to four versions of each (using recolour skins or sprites). In that respect, the idea of a class works. I can then store arrays in each "species" where the differences would be.

That might work... hmm... I'm wondering if there might be better solutions.

The concept of using arrays for data storage could work, and I could just make the classes based on species. This would reduce the amount of data in a single class, and would let me find what I need to modify much easier... I think... I just want to make sure I'm not missing a "better idea", if one exists.

[justkevin]

Oh, no no, it's not shared objects. I know about shared objects and I'm using one for such data. What I'm talking about is a database-like amount of data.

As an example... the game I'm building is a micro-RPG. So I would have a huge list of enemies, where each enemy has stats, abilities, etc etc. Now, I know how I'd build that into a database or even an XML file, but what is the best method for building it directly into Flash?

Oh, I thought you were asking about how to store persistent game data, like player info.

Why not use XML? E.g,:

<enemies>
<enemy name="Orc" health="150"/>
...
<enemy name="Dragon" health="2500"/>
</enemies>

[gamingPC]

Oh, I thought you were asking about how to store persistent game data, like player info.

Why not use XML? E.g,:

<enemies>
<enemy name="Orc" health="150"/>
...
<enemy name="Dragon" health="2500"/>
</enemies>

have you read anything he said?

its going to be a game on sites that feature games, so XML and SQL Databases are not available.

[justkevin]

have you read anything he said?

its going to be a game on sites that feature games, so XML and SQL Databases are not available.

You don't need a database for XML. You can either embed xml directly in the swf, or tie it to a constant.

Embed (if you're using Flex Builder or Flash Develop):

[Embed(source="test.xml", mimeType="text/xml")]
protected const EmbeddedXML:Class;

var x:XML = XML(new EmbeddedXML());

Tied to constant:

public static const MONSTER_XML:XML = 
<monsters>
... Lots of monster data here ...
</monsters>;

[moagrius]

kind of a weird thread...

you can either save data externally (xml, txt, sql, whatever), or not...

if he's just asking "what's the best way to define data inside the flash app itself", it doesn't really matter. you can use inline xml (like justkevin said), or arrays and objects... flat indexed arrays is probably faster, but the difference for 200 (or 2000) value objects is going to be minimal at best. use 200 classes if you want, it's not a big deal - the code will compile lickety-split anyways.

if you're going to be doing lots of crazy traversal and want to take advantage of E4X, so you can do silliness like monsters.trolls.(hp > 300).(armor < 10).(@region == "swamp).stats.@hitpoints, then use XML.

if it's really just a list of monster hit point values, use simple arrays - if it's a group of props, use arrays of objects.

"best practices" would probably want a class per monster, then save instances in arrays...

bottom line is that 200 monsters is not going to be a lot of data, so don't fret : )

my 2 cents

[Skye McCloud]

You don't need a database for XML. You can either embed xml directly in the swf, or tie it to a constant.

Embed (if you're using Flex Builder or Flash Develop):

[Embed(source="test.xml", mimeType="text/xml")]
protected const EmbeddedXML:Class;

var x:XML = XML(new EmbeddedXML());

Tied to constant:

public static const MONSTER_XML:XML = 
<monsters>
... Lots of monster data here ...
</monsters>;

If I'm reading this right, then then when I compile the game into a SWF, it will just technically store a copy of that XML IN the SWF, right? If that is right, then that's probably what I'm after.

And it wasn't my concern on if it'd be a lot of data, but on how difficult it'd be to modify down the road. Say I find the game is too easy, and I want to make enemies c through n tougher. I wanted to be sure the method I used would be best for organizing it, to make it easier to make such tweaks, etc etc.

[gamingPC]

If I'm reading this right, then then when I compile the game into a SWF, it will just technically store a copy of that XML IN the SWF, right? If that is right, then that's probably what I'm after.

And it wasn't my concern on if it'd be a lot of data, but on how difficult it'd be to modify down the road. Say I find the game is too easy, and I want to make enemies c through n tougher. I wanted to be sure the method I used would be best for organizing it, to make it easier to make such tweaks, etc etc.

you should define your question better, or I didn't get it.

Best Practices = Class per Enemy.
Comfortable = XML, Arrays.


I came out a dum dum .
Oh well, I suppose at some point I"ll think smart.

[Skye McCloud]

Oh, no no, I technically did want best practice. I may end up just doing the class method, because each has their pros and cons:

XML Pros - Easier to search for enemies that are within a level range for random fights, one file to manage
XML Cons - Lots of lines, inability to give a species a "base stat" and apply modifiers based on level unless they're all hard coded in (which means that if an entire species of enemies becomes too weak or too strong, I have to manually edit for every enemy in that species)

Class pros - Ability to create base enemies, creating a standardized species that can be easily altered across the board with some minor tweaks
Class cons - Lots of files, possibly inability to group enemies by a level range (would require a lot more coding anyway)

[joshstrike]

Think procedural. Make the enemy classes invoke a base class and extend it in a procedural way. Store the algorithms, not the output. There's no reason to ever put out an .swf larger than 500k. If worse comes to worst and we're talking about reams of dialog in an rpg and gigantic level maps, maybe you should break the game into episodes... casual gaming sites are specifically built to prevent long-running games with lots of stored data. If it's not a casual game, the logic should be secured on a server along with the info.

If you know the game StarCraft and the sequel, those were huge games with tons of planets and a fair number of characters, persistent game data and everything, that were less than 1024k each, because everything in the environment was generated on the fly based on certain rules.

Edit: This was my 1,000th post. It only took a 9 1/2 years =)

[justkevin]

Oh, no no, I technically did want best practice. I may end up just doing the class method, because each has their pros and cons:

XML Pros - Easier to search for enemies that are within a level range for random fights, one file to manage
XML Cons - Lots of lines, inability to give a species a "base stat" and apply modifiers based on level unless they're all hard coded in (which means that if an entire species of enemies becomes too weak or too strong, I have to manually edit for every enemy in that species)

Class pros - Ability to create base enemies, creating a standardized species that can be easily altered across the board with some minor tweaks
Class cons - Lots of files, possibly inability to group enemies by a level range (would require a lot more coding anyway)

You can still give base stats as well as instance stats. What I did in my last game was every game entity had an initFromXML method. Entities are first initialized from their default XML (or their "species xml" if you prefer). If I wanted a particular entity instance to have different stats from the default, it would then initialize from the instance xml, which overrode only the attributes that it defined.

This is quite flexible, because it allowed me to define lots of different enemies using the same class, just with different attributes and components. Stats, weapons, and images were defined via the xml.