Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

Advanced search

998842 Posts in 39181 Topics- by 30593 Members - Latest Member: Ham

April 21, 2014, 06:40:13 AM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Storing Game Data
Pages: [1]
Author Topic: Storing Game Data  (Read 555 times)
Level 0

View Profile WWW
« on: March 03, 2013, 06:27:04 PM »

I'm currently working on a prototype for an RPG style game.  I'm realizing pretty quickly that these types of games could end up with a lot of static data used to represent game elements like weapons, armors, skills, status effects, etc.  I'm not talking about media, just the data behind these objects like names and stats.  I was considering using an SQLite to store this data when I create it, and then load the database at runtime. It seemed like a better idea than having a bunch of small data files.

Has anyone else used this technique, or perhaps have a better way of managing this data?

Level 0

View Profile
« Reply #1 on: March 03, 2013, 06:37:50 PM »

I use google spreadsheet / microsoft excel to define and manage this data.
The spreadsheet makes it nice because I can categorize groups of values into different sheets.
So for instance, I could have a 'weapons' sheet, an 'armor' sheet, etc and they define all of the names, stats, economy, etc.

Then I run an exporter on this that spits it out a bunch of json files that can be loaded by the game directly.
When I'm ready to ship the json files get processed into a binary form.

Google Spreadsheet is nice if you need to collaborate with someone else. But Google can go down sometimes, is unreliable sometimes, etc. Especially if you are working with a very very large spreadsheet. Excel is nice because you don't have to deal with Google deciding to be stupid one day, but its harder to collaborate.

You can also use the spreadsheet interface to help you manage the data easier.
1. You can setup formulas that may help you keep balance in check.
2. You can colorize columns, rows, individual cells based on 'status'. eg, "Stuff in green is done."
3. You can have 'notes' attached to rows or columns explaining what its for.
« Last Edit: March 03, 2013, 06:44:18 PM by xgalaxy » Logged
Level 3

Greater Good Games

View Profile WWW
« Reply #2 on: March 04, 2013, 05:06:55 AM »

Personally, I would be much more likely to go with the suggested Excel to JSON approach than to implement a SQLite database in my game.  SQLite isn't a horrible approach, per say, but it's probably overkill and will end up with more overhead than necessary, which is also outside of your control.  With the JSON approach, you are in charge of the reading of the files(you can have multiple files, if ever needed for load speed), you are in charge of the memory usage(you can convert all the read in data to native types instead of strings), and you are in charge of the access method(you can convert all the read in data to structures for quick access instead of doing SQL queries).

Owner/Programmer at Greater Good Games makers of Break Blocks
Currently developing It Hungers and Swipe Attack(UDK)
Level 0

View Profile WWW
« Reply #3 on: March 04, 2013, 10:57:02 AM »

The spreadsheet definitely looks like the way to go for simplicity. I really also like the idea of using them to easily create and edit the data during development and testing. Thanks for the replies!

« Reply #4 on: March 06, 2013, 12:49:58 PM »

I think if you are going to have a very large dataset and plan on doing a lot of complex queries, then SQLite might be worth it.

Sounds like you have everything under control, but XML is something worth considering since there are a lot of well maintained parser libraries out there.
Level 5


View Profile WWW Email
« Reply #5 on: March 15, 2013, 11:53:08 AM »

What engine/framework are you using? For example if you were using XNA that has some very nice XML serialization stuff built in   Big Laff

So long and thanks for all the pi
Level 4

View Profile WWW Email
« Reply #6 on: March 16, 2013, 02:57:12 AM »

I have been writing RPGs a lot and I would say it's an overkill (unless you are making an MMORPG, but that's a different kind of beast). To be clear, I'm a great fan of SQL and I use it a lot in my games, I just don't find it practical for a single player RPG for reasons listed below.

You have these fixed things: skills, status effects, spells. All of them should be hardcoded. These rely too much on code, so from my experience treating them like data is unpractical. These are simply too unique from each other to represent them as data.

You have these flexible things: items, monsters, quests/dialogues, map. Of them map has to be a separate non SQL structure (for numerous reasons, for starters try doing pathfidning using SQL Smiley), quests are best implemented as a scripting language. Which leaves only items and monsters that are reasonable to be made via SQL. But since you already need a scripting language for quests and dialogues you could simply add one "defenie" script which defines all items and monsters.

Europe1300 - Realistic Historical Medieval Sim
Pages: [1]
Jump to:  

Theme orange-lt created by panic