Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


#ActualNypyren

Posted 10 October 2013 - 02:09 PM

Most large games I've worked on do it like this:

 

1. The data is entered into a spreadsheet or SQL database using whatever app you want (Excel, OO, Google Spreadsheet, SQL).  You can lay this out however you want (simple row/column grid all the way up to a fully normalized database).

 

2. The spreadsheet or database is scanned for the data, and stored however you feel is most appropriate for your game (custom binary form, protobuf, XML, JSON, etc).  This step typically takes database-style table-based data (i.e. if an inventory item has a variable length list of crafting ingredients, the crafting ingredients would be normalized as a separate sheet/table in the input spreadsheet/database) and turns it into more typical hierarchical data structures (i.e.  "Item.CraftingIngredients[0]").

 

3. The game loads the data into the data structure you feel is most appropriate for your game (a simple list, an associative array with unique IDs, a full-on SQLite database, etc).  Excessively large data sets may be hosted on a web service that can be fetched from 100 items (or so) at a time.

 

 

The large games I've worked on have all used Excel spreadsheets for data entry and associative arrays (Dictionary<string,InventoryItem>) for runtime storage.


#2Nypyren

Posted 10 October 2013 - 02:05 PM

Most large games I've worked on do it like this:

 

1. The data is entered into a spreadsheet or SQL database using whatever app you want (Excel, OO, Google Spreadsheet, SQL).  You can lay this out however you want (simple row/column grid all the way up to a fully normalized database).

 

2. The spreadsheet or database is scanned for the data, and stored however you feel is most appropriate for your game (custom binary form, protobuf, XML, JSON, etc).

 

3. The game loads the data into the data structure you feel is most appropriate for your game (a simple list, an associative array with unique IDs, a full-on SQLite database, etc).  Excessively large data sets may be hosted on a web service that can be fetched from 100 items (or so) at a time.

 

 

The large games I've worked on have all used Excel spreadsheets for data entry and associative arrays (Dictionary<string,InventoryItem>) for runtime storage.


#1Nypyren

Posted 10 October 2013 - 02:04 PM

Most large games I've worked on do it like this:

 

1. The data is entered into a spreadsheet using whatever spreadsheet app you want (Excel, OO, Google Spreadsheet, SQL).  You can lay this out however you want (simple row/column grid all the way up to a fully normalized database).

 

2. The spreadsheet or database is scanned for the data, and stored however you feel is most appropriate for your game (custom binary form, protobuf, XML, JSON, etc).

 

3. The game loads the data into the data structure you feel is most appropriate for your game (a simple list, an associative array with unique IDs, a full-on SQLite database, etc).  Excessively large data sets may be hosted on a web service that can be fetched from 100 items (or so) at a time.

 

 

The large games I've worked on have all used Excel spreadsheets for data entry and associative arrays (Dictionary<string,InventoryItem>) for runtime storage.


PARTNERS