Hi,

I'm finishing a small game prototype with c++,

now still considering about game data for character attributes, levels/stages info, and saving game progress.

Currently for character attributes (like health, damage, size(width & height), weapon, shieldpower.. etc),

i put it directly harcoded in character class. Example:

class Foe1

{

public:

Foe1();

void Moving();

void Attack();

private:

int Size_W = 50;

int Size_H = 80;

int Max_Health = 200;

int Max_ShieldPower = 100;

int DamagePower = 50;

string WeaponType = "TypeA05";

}

also with Foe2, Foe3... have same attributes, but with different value.

For levels/stages info, i put into separate files (in xml),

so everytime to begin new level i will load the level attribute/info from my level01_data.xml, level02_data.xml... file.

My question:

** Is this ok to put all those harcoded attribute at class?

..or should i put the attribute value in separate data file, then load it when everytime creating a Foe instance?

** To save data in separate file, for char.attributes or game progress,

i'm considering to save those into encrypted files or using (maybe)a light-weight database tools.

Which method is probably better? (considering the balance of "runtime loading process" and "data management issue" )

This far my program run ok and smooth,

but somehow i feel my codes are bit crowded

To do modification at next month or 2 months again, i'm affraid to fix certain things may not simple.

Any opinions & suggestion are welcome, thank you..

** Is this ok to put all those harcoded attribute at class?
..or should i put the attribute value in separate data file, then load it when everytime creating a Foe instance?

It is okay to hardcode *default* values, but you should load the attribute values from a data file into a common Foe instance.

Foe1, Foe2, Foe3 are not okay. Anytime two classes are identical except for the values of variables, that almost always means you should pass the values into the class as constructor parameters.

For example, if you give 'Foe' a custom constructor:

class Foe
{
   public:
      Foe() = default;
      Foe(int sizeW, int sizeH, int maxHealth, int maxShieldPower, int damagePower, string weaponType)
: Size_W(sizeW), Size_H(sizeH), Max_Health(maxHealth), Max_ShieldPower(maxShieldPower), DamagePower(damagePower), Weapon_Type(weaponType) { }

      //.....
}

...and then do this:

const Foe Bat(...values for bats...);
const Foe Goblin(...values for goblins...);
const Foe Grue(...values for gree...);
const Foe Sheepsie(...values for sheep...);

You can later do this:

//std::vector<Foe> allFoes;

void GameWorld::createNewBat(Position position)
{
    Foe newBat = Bat; //Create the new foe using 'Bat' to initialize basic Bat-like values for it.
    newBat.SetPosition(position);
    
    allFoes.push_back(newBat);
}

** To save data in separate file, for char.attributes or game progress,
i'm considering to save those into encrypted files or using (maybe)a light-weight database tools.
Which method is probably better? (considering the balance of "runtime loading process" and "data management issue" )

A) You don't need your files to be encrypted.
B) You absolutely don't need a database.

I'd save it as binary into a basic custom binary file format, or use a text format like XML (since you are already using XML) or JSON or YAML, or even just a basic "var = 27" map-like file.

In my own game, I save my files in a text-based format for development, but then save them in a binary-based format for when releasing the game. I automatically keep the two in sync using programming magic, otherwise it'd be a nuisance to keep any files saved in a binary format from breaking any time I changed the variables in the class.

For your first game, this is overkill, so I'd definitely suggest sticking with a text-based format. It's just much easier during development, and most likely fast enough for your needs anyway.

key there.

All depends on if you need to learn and are willing to learn data base and or like most good c c++(programmers) people they should already know how to save to file with out much learning time.

as well as the amount of time you have allowed for this process. and also using data base you need to install on user systems.

Nope forgot all about portability so yeah get a third party lib to do it for you.

Hi all, thank you for responses.. now i've got some perspectives..

@Servant of the Lord :

I've already plan to do encryption/encode, or to-binary method(as yours), or maybe compression,

in the case: not to let data to be in plain text, just it..

Sure i notice one consequence is i have to provide another program, for me only,

to scan-read the encrypted data file, so that i can do modification of some attributes when necessary,

then save again back in encrypted.

And why to use database tool, from what i imagine is so i can just save/read data, or prepare some initial attributes

without do encryption or compression again, just use the tables,

and then put database password that i can hardcode inside program.

@ankhd :

I'm considering some pros & cons for using database tool with c++..

Maybe, perhaps, i don't know yet,... that the data someday can be ported(too) for use in another program(java,c#), maybe

that the data someday can be ported(too) for use in another program(java,c#), maybe

Human-readable text files are an ideal database format for portability. If you want to compromise, use a semi-readable format like JSON or XML.

that the data someday can be ported(too) for use in another program(java,c#), maybe

Human-readable text files are an ideal database format for portability. If you want to compromise, use a semi-readable format like JSON or XML.

Hi,

Yes i agree about readable informations, especially from developers point of view.

Currently i use data file in xml format.

But i'm thinking about to keep couple things not to be touched/changed by the players,

that we want them to play the game from the start button which we provide for them,

and let the game itself interracts with the database/data-file.

So players don't have to concern/open for data that we(developers) don't mean to share details to them.

Except if somebody means for hacking, cheating some attributes value, they will use their own efforts & tools (not a suggestion ).

Except if somebody means for hacking, cheating some attributes value, they will use their own efforts & tools

Ignore hacking/cheating. You can't prevent it. Data debuggers make it trivial to change values in the running game, regardless of how you stored the initial values.

As for hardcoding, I'm going to be the lone voice saying if it's working for you, then don't necessarily change it just for that sake of changing it. The advantage of storing data in separate files is the ability to edit them without recompiling, and/or the ability to use external tools to edit them. If you don't have specific external editing tools, your compile times are fast, and you are the only person editing values, then defining constants in code is by far the simplest solution...

XML if you have only a few files and they are not huge.

Another solution...
Having a compact file based database like sqllite is good if you have to store a lot of information. I would forget about anything more than a file based db...I work on a product that uses mssql and properly installing it and configuring it is difficult for most of our customers.

In your case I would go with XML though. I would also recommend you take the time to write xsd files to validate your XML files. XSD also serves as excellent documentation too.

Usually parsing and loading files is a slow process. Many file formats require decompression to be used. Other file formats like XML are memory-expensive and compute-expensive to parse and validate.

In the AAA world, there are frequently multiple formats accepted:

First, there is a final packed format. These are designed to be loaded directly into memory without any processing. Dump it in a big block of memory, fix up some pointers to point inside the memory, and use it immediately.

Second, there is support for development formats. These are the intermediate files, perhaps raw images or textures or model Collada files or wav files. Better engines will monitor the directory tree and swap out the files while the game is running when the files are changed. These are not preferred because they take more time and effort to parse, but they save significant dev time by allowing artists, modelers, animators, designers, and audio to iterate quickly. They can make a change in their tools, save the file, watch it change in game, make another change, save, and iterate rapidly.

Third, there may be support for modding tools or development tool attachments. These may load and process their own file formats or build data dynamically on the fly.

The exact details of your file formats are up to you. Use what works for your process.

Hi,

@swiftcoder :
As for hacking/cheating issues, i leave it alone. yes, players can track in memory when game in running by using certain tools.
Regard to purpose of separate data details from program,
so i think to re-arrange which data to be harcoded in program, and others to be put in separated data file.

@timothyjlaird :
If not in urgency and not necessary, or the data not so massive,
i prefer to use simple data file, either plain text or converted in binary(or maybe the simple base64).
Use mssql or maybe mysql will make player busy in installation & configure the db service.
I'm thinking something easier, as you mentioned guess i'll find out about sqlite. Thank you.

@frob :
I used to set-up my program to load data every start each of a scene/stage,
when change next scene, i'll load again from another stage data file.
Currently, i load when only needed, depend on situation of current gameplay progress/state.
Is final-packed-format mean to load all everything(stages,object attributes)
from the start of the game? (i have not tried this before)

Thanks all..