   Game Data Tool
  In different game projects, time and again I see structured data being stored in text files, which is not in and of itself a bad thing, but I believe it can be done better.I would like to write a game data management tool.Some advantages of storing data in text files, are that it is simple, and human readable, and easy to version control.  Disadvantages are that the layout of data in text files tends to either be one element per file, or one huge long list of elements, and if each element is spread over several lines, you can't easily compare one element to all the others.I'd like my data management tool to take the advantages of text files, and add to them, and overcome the disadvantages mentioned. The tool should be able to enforce types, for example, to prevent accidental badness in the data.I'm envisioning some kind of database-like tool, with tables of data, types, and relationships.Examples of the data types I would like it to cater for include:Keyboard/Gamepad controller mappingsLevel data (name, filepath, type of level, etc)Zone data (name, filepath, which level it belongs to, type of baddies that can be spawned in this level)Weapons data (name, weapon type, ammo, etc)In fact, anything that you have multiple different types of.If you're editing level data for example, you should be able to compare that level at-a-glance to all the other levels - to spot inconsistencies, or patterns, or typos, or missing information.  You should also be able to jump directly to a table of Zones which belong to that level.My biggest concern with the database approach is version control.  Data changes during the lifetime of a project, and even the data structures themselves change too.  I don't know how to do this easily with existing databases.  Does anyone here?One approach would be to store the data tables in individual text (probably xml) files.  This way the data can be version controlled in a human readable way.  The disadvantage would be this would probably take a lot of effort to get off the ground, unless there already exists something off-the-shelf?Another concern would be user interface.  Having used Microsoft Access databases and also databases with web page frontends, I much prefer the application approach to the web approach - I just find web pages too slow...Positive and negative feedback, criticisms, answers and ideas all welcome, thanks.   
  Which editors have you used that you would like to improve upon?   ;  I've mocked up a very small example of the direction I'm going with this editor:But more typically, I see data looking like this:ControlMap   Name Default   Jump A   Run B   Attack X   Special Y   Shield LTrigger   Dive RTriggerEndControlMapControlMap   Name Custom1   Jump B   Run A   Attack Y   Special X   Shield RTrigger   Dive LTriggerEndControlMapBut with far more elements per control map (including multiple keypresses) and far more control schemes.  Imagine the same with levels, zones, characters, weapons, music, sounds, shaders, movies, etc, etc, etc.   ;Quote:Original post by bzroomWhich editors have you used that you would like to improve upon?I've used notepad (and notepad2 and notepad++), Excel, Access, and web pages fronting bespoke databases.  None are quite what I'm looking for.The plain text files fit great in version control systems because you can look through the history and see exactly which line changed when.But most of the data that I see looks like it would fit best in some kind of table or hierarchical structure - notepad just doesn't do that data justice - it's just more awkward than it needs to be to compare similar data, spot mistakes, add new entries, describe the hierarchy, etc, etc.Spreadsheets seem a step in the right direction in terms of data layout, but databases have further advantages in that you can clearly define relationships between the data, enforce data types.But my main stumbling block at the moment is the revision control of both data and schema.   ;  So, a text-based data format with graphical tools? What are we looking at here besides format design?   ;  If you are building the editor yourself then you should store the data like this:ID, DATA_TYPE, NAME, VALUE, PARENT_ID, COMMENTAnd then create your own intelli sense to help with maintaining the data. Or use a property grid.This dataset:0, STRING, Players Status, NULL, NULL, The player's stats1, NUMBER, Health, 100, 0, The players health2, NUMBER, Ammo, 50, 0, The Players weaponsWill look like thisPlayer Status  - Health = 100  - Ammo = 50Then you can have combo types, where then COMBO_ITEM's parent id will equal the id of the combo. This allows the editor to know what choices are available.This dataset:0, STRING, Players Status, NULL, NULL, The player's stats1, NUMBER, Health, 100, 0, The players health2, NUMBER, Ammo, 50, 0, The Players weapons3, COMBO, Current Weapon, 4, 0, NULL4, COMBO_ITEM, Rocket Launcher, NULL, 35, COMBO_ITEM, Machine Gun, NULL, 3That will looks like this:Player Status  - Health = 100  - Ammo = 50  - Current Weapon = 4 (But the IDE allows you to choose between weapons with using the descriptions)You could then expand on it and add default values for datatype and max length etc, just like a normal database.So now your game can make calls to the library....GetProperties(int id) - returns an array of "property"GetProperty(int id)GetOptions(int id) ... and so on and so on.... I forgot to add...ID, DATA_TYPE, NAME, VALUE, PARENT_ID, COMMENT, VERSIONNow you can add a version number to your property each time it changes and only pull back the highest version number for each ID.ID+VERSION = Unique Primary Key   ;  For databases, you could use sql dumps (including schema and data) as your data format.For textual data, I usually use .csv or plain text files, in combination with some Python scripts. It's a powerful combination when it comes to processing or checking large amounts of data, and it plays nice with version control.I recently also started to store data as Python code: no need to write parsing code, just execute the 'data' file. For example, this file is loaded into this data structure, with hardly any parsing code at all, only a little post-processing. Granted, it's not a lot of data, so it's still doable to write by hand - for larger amounts of data, I would write some quick tools.I hope that gives you some inspiration. A custom database tool with strong typing, type-specific data entry and customizable output format sounds very interesting, but it'll probably take a lot of work to write a quality tool like that, so it may not be the most pragmatic solution.   