design question: data driven: best methods?

You could use a format such as JSON, parsers should exist for all major languages and it is human readable essentially like the key-value pairs.

{
  "key" : "value",
  "key2" : "value"
}

Although your question is not very specific, here are 3 popular methods that won't let you down:

1. JSON, with a parsing library available in most languages. JSON is easier to read and edit, smaller than XML and works with RESTful APIs and internet technologies all over the world now.

2. XML. XML is also easily consumed and parsed in most languages. It is older and somewhat clunkier, but it is still being used in many commercial game engines as a general data format.

3. Design a database using SQLite. This is a file based database format that can be easily consumed in C++ and most other languages. If you know SQL and relational database concepts, this is a powerful way to store and query your game data.

My opinion is that writing custom text file parsers is a waste of time compared to these options, unless you have to do something so extraordinary with it that it makes it impossible to use all of these methods.

My opinion is that writing custom text file parsers is a waste of time compared to these options, unless you have to do something so extraordinary with it that it makes it impossible to use all of these methods.

Couldn't agree more. I've seen too many projects (including my own) waste time and effort in designing a custom file format, library, or even scripting language to do what could be done just as well with existing languages, libraries, and tools. If your goal is to make a game, use existing technology to speed up your development process. Designing these custom solutions does not, in every case I've seen, make your game any better or more fun to play. There is no shame in taking short cuts (as long as they're legal of course). All your players will judge you on is how well your final product plays.

Agree with the other posters, unless you have some super specific need there is no reason to create your own format. I'd go with JSON if size and human readability aren't super important or XML if you are going to need to be editing values by hand. But probably shouldn't be doing that since something like C# and WinForms or WPF would be trivial to create a viewer.

You may find this video useful.

You may find this video useful.

that appears to be about data ORIENTED design, not data DRIVEN design. the two are distinct, yet similarly named and often confused things.

You may find this video useful.

that appears to be about data ORIENTED design, not data DRIVEN design. the two are distinct, yet similarly named and often confused things.

My opinion is that writing custom text file parsers is a waste of time compared to these options, unless you have to do something so extraordinary with it that it makes it impossible to use all of these methods.

agreed. the number of turn key low cost / free text file parsers such as json parsers makes writing your own a waste of time, unless you're like me, and can write your own faster than you can decipher the docs from an unsupported PD 3rd party lib. i've actually done that a few times, written my own code cause it was faster than figuring out some obtuse 3rd party design.

but text based data files are slower than binary, and therefore only called for if the data file must be somewhat human editable. when the data file doesn't need to be human edited, such as with a custom editor, binary is preferred for shorter load times.

also, things like json and xml only get you a pre-defined file format and some parser code (various read and write routines). you still have to write code to get the data into your game's variables.

You could use a format such as JSON

so add to the list:

3rd party text file key-value pair format:

--------------------------------------------

easier to read, as each value is identified with its variable name.

can be edited with text editor

don't have to write a parser.

i've used all methods except the key-value format in the past. in the past, instead of going to the effort required to use a key-value library, i'd just use a custom file format and regular read and write routines. reading key value pairs is just as much work, cause its the same basic thing (for each var, read it in), just with a pre-defined file format and the accompanying read and write routines.

each method has its uses. plain text or text with comments is good for simple stuff like a list of meshes to load. or a list of wavs, anis, textures, models, materials, etc.

and needless to say, built-in editors are really nice. although they are probably overkill for use with constants that won't change once their proper value is determined (base HP for an Orc, stuff like that).

Question would be how much data are we talking about and how often is it to be modified and by whom...

Complexity of the data also - as in objects with sub objects (variable schema/hierarchical) which can be bothersome in simpler existing libraries.

Figure the time involved between the development and test versus the utility of the editing system (manual file or wizard and format/data verifier) for the total amount of data involved.

This includes overhead work of the code to convert/translate to/from the programs internal data (structs/objects etc...) to whatever external data storage.

data file bloat is probably a minor issue these days (and maybe delays of loading the data). from experience (in the olden days) XML can be some of the most bloated and awful txt to manually look at/edit and wasnt always the fastest thing to load/dump when there was ALOT of data

Question would be how much data are we talking about and how often is it to be modified and by whom...

Complexity of the data also

indeed. such criteria seem to dictate best method.

i'd sure hate to have to edit an entire level in XML - i used to do hand coded POVray development. a C like language is NOT the easiest way to edit a 3D scene! .

i guess its like everything else in games, you use the easiest solution you can get away with for whatever the case at hand may be.