Hi All,

I am a game programmer, I have developed couple of HTML5 games, few games for Android. Presently I am working on a card game ( with around 100 cards) so asset management will be a pain.

I have developed card games like blackjack , but since I was only dealing with 52 cards, I designed the game using classes and objects, a card is an object with a face value , a suit and an .jpeg. It was pretty much copy and paste with a replace all , so it was easy writing a huge class deceleration file.

Okay coming to my question, what is the best practice followed to declare assets in similar games , like buildings with costs, hit value etc. I am inclining towards classes and objects ( as its my comfort factor and easy for me), but if we talk about performance and ease of upgrading game etc what is being followed ? Another option I am exploring is XML/database i.e. every card will have a different xml/row, but not sure about their implementation do you read the all the files/whole file during run time or at the start of the game , store it in an array ? this sounds more complex than object and classes.

Please suggest what you guys have followed and how that worked out during various versions of your game.

thanks

Using a database to store that initialization information has one big problem, you need a database engine in the platform runing, which usually doesn't exists. Using XML or other file format is a good choice, you can always read another file.

Depending on amount of information you need, one big file can be a problem if it's too big, but in your case I'd use just one file and store everything about the cards in there. It's easier and faster to load one file called "cards.xml" for example, than loading >100 files each named after one card (you'll need to write in code or some other XML file all the file names, or put everything inside a folder called cards and iterate over the folder).

Our game does not work with cards, but we do have weapons, enemies, etc. We read all the data from JSON files. In my opinion, JSON files have a nicer and more readable syntax than XML, and the conversion is really simple as well. I would recommend using a similar system. JSON is actually a Javascript format, so I assume it should be fairly easy to interpret in Javascript. I personally also think using a separate file per card would be the nicest way of doing it, and just use I/O code to loop through all files in a directory.

If you write an interepreter, you can probably parse the XML/JSON files into an object. I am not aware of the limits of Javascript, but you could use a form of reflection to map the attributes from JSON to a class directly. This is an example in C#. The JSON file for a sound effect could look like this:

{
  "file": "ogg/clang.ogg",
  "volume": 0.8,
  "minPitch": 0.9,
  "maxPitch": 1.1
}

Using a library, we automatically parse this to the following class:

sealed class SoundFileJsonRepresentation
{
    public string File = null;
    public float Volume = 1.0f;
    public float MinPitch = 1.0f;
    public float MaxPitch = 1.0f;
}

An argument for using a database would be that it is optimised for indexing and searching for cards, so if you wish to store decks that point to card IDs, databases would be better for that. If you load the cards manually, you might have to write your own datastructures to deal with this.

For small projects - XML Files definitely. With a database backed system, you have to have a database. So either host servers yourself, host them on the user's machine, or pay to have them hosted.

If you use C#, the built in XML Serialization modules are super convenient. I talk a little bit about Data-Driving games towards the end of this blog entry:

http://www.gamedev.net/blog/1922/entry-2260314-the-week-of-awesome-ii-sifting-through-the-aftermath/

- Eck

If you need multiple users to connect to and access data which may change at any time, use a database.

If you need to protect the integrity of your data and have a way to update it across the board for all users, use a database.

If you don't care about players tampering with the game data stored on their local disk (ie, it's their fault if they break the game), then you can just store the config/data files on their local machines and load it into memory when the game loads.

When it comes to storing the data, whether you use XML or a SQL table, you'll need to figure out some way to map the stored data to your internal class variables. I can't really tell you how to do this since it's very dependent on how you want to manage your data. Generally, what I do is create two methods in each class which needs to be persistent, and each method is responsible for saving and loading its state to some location.

Class MyGameObject
{
    int myValue = 5;

    public void SaveObject(string path)
    {
         //saves myValue to disk by writing "5" to the file in the given path
         SaveValueToFile(path, myValue);
    }

    public void LoadObject(string path) //<-- could also be a constructor arg
    {
        //loads the value from disk and sets it
        int diskValue = GetValueFromFile(path);
        
        //sanity check on the loaded value
        if(diskValue < 100 && diskValue >= 0)
            myValue = diskValue;
        else
            myValue = 5;
    }

}

Another option I am exploring is XML/database i.e. every card will have a different xml/row, but not sure about their implementation do you read the all the files/whole file during run time or at the start of the game , store it in an array ? this sounds more complex than object and classes.

If by "database" you mean SQL-driven relational database, then no way. Such a database will usually have far too much overhead for this type of work.

If by "database" you mean using a collection or container class (as you mentioned "an array" and "copy and paste"), then yes, that is a great solution.

XML as a serialization tool is one of many good solutions for keeping your data separate from code.

The typical solution is to store the data in a file, perhaps XML or some other format, and during a loading phase pull the data into containers in your code. That way you can modify the data without touching the code. The process is often called "data driven".

Yes, a data driven solution start out being more complex than encoding all the values in source code. For small projects it is easier to keep it all in code. As the project grows the overhead of manipulating the data grows, and very quickly it becomes more cost effective to keep the data outside the program.

Here are some ideas:

1. Use a database during games only if you have an according backend, that is , if you have a server-side game where you can expect the installation of a db.

2. If you target updateable data-structure, use type-/namesafe data structures (eg. xml,lua,json).

3. Using a db for designing your game is a good idea, write an exporter to convert the db data into your target format.

For example, I use open office base, which provides you with a simple sql database, export capability (written in basic) and the ability to simply design GUIs for your data (very handy !). You don't need to install any db, it is all handled by OO and saved in a single file (which represents your database, which is portable).

For storage, you can always use google protocol buffers.

SQLite, on the other hand, has the benefit of storing all your data in one file (zip can do that, too). However, unlike zip, SQLite allows you to patch (that is, add, delete and/or modify items without rebuilding the entire file) that file in a relatively straightforward way. Contrary to what others have said, SQLite is an example of one of the embedded database engines. It is fast enough - you are not going to load from disk all the time, anyway.

I personally dislike XML and JSON, but they are fine if you are OK with the clumsy syntax. XML was never meant for humans to write (it was always meant for tools - with the benefit that humans can read it); since protobufs support both text and binary, I see no sense to write the code yourself. While JSON is terser, it still requires you to manually map the parsed tree to code.

Hi Guys,

Thanks for your response, and as I anticipated every one of us have some concerns about a particular type of technology, which is good as I wanted to hear your experience of working with different things.