I really want to know how many game designers prefer to work with a huge table for all items, another table for all skills, and even another table for all mobs in a MMORPG. And these tables may grow to several hundred MBs with thousand records, but most records only use a few fields in a table.
I know some game designer works in this way. Are there any better method?

@bummzack: SQLite is a relational database. Excel is a spreadsheet. A RDB may be (poorly) replaced by a spreadsheet program, but you can't replace a spreadsheet program with just an RDB.
–
user744Jan 8 '11 at 13:23

(I have endless professional anecdotes about why Excel is great/horrible for this kind of thing, which I might write up in a day or two if I think I can do it without getting sued, but I'm hoping someone has a more evidence-based answer.)
–
user744Jan 8 '11 at 13:42

1

I guess I misinterpreted the context here. I thought this would be used as in game data-source and not as a "design-tool".
–
bummzackJan 8 '11 at 16:31

Has anyone thought of using XML files for this purpose?
–
James PoulsonJan 9 '11 at 5:22

5 Answers
5

I didn't want to answer here, but when i saw another answer/comments i changed mind. SQL is not very good solution of this. SQL defines tables and inserts lots of data into that tables. This is not that case. When creating/testing game design you are mostly want to check if the huge system is balanced. That means lots of tables which affect each other. Nothing good for SQL actualy - or it is, but not easy to handle, bacause you have to do programming which is not necessary. And game designer doesn't have to know it.

As game programmers/developers we can disdain excel and its usage for anything, but it is pretty good tool for this case, especialy when game designer can use it well and the document is well created.

I cant recommend any other tool, but i can say that i know professional game designers who use excel too. So i assume it is common tool.

Yes, excel is a common tool. The point of the question is:"a single huge table for all items", items include equipments, consumes, etc. Is it necessary to divide the huge one into small ones? Even separated config file for each item? I'm afraid the huge table may hurt their eyes :o)
–
Huang F. LeiJan 8 '11 at 14:02

Sorry i don't know this. I'm engine programmer. I just wanted to say "Hey why are you all saying SQL and making jokes of excel, when it is common tool?". Question is good and i am interested in some sofisticated answer, better than mine is.
–
NotabeneJan 8 '11 at 14:10

My original SQl answer was due to me missing out the 'game designer' part of the question and I deleted it because it would be misleading.
–
The Communist DuckJan 8 '11 at 15:44

I agree with most answerers that sometimes spreadsheets can make decent dev tools, especially for designers.

If you are interested in taking this approach further, the Resolver One spreadsheet program uses python for scripting, making it easy to set up a spreadsheet for designers that both does complex modelling and exporting to a game-friendly data format. I find it much easier to work with than Excel's VBScript.

Excel is an excellent solution.I had been wondering how this should be done. But thinking about it, Excel is while a very popular tool and quite adequate for this duty, I would not recommend this practice. Additionally, actual database, as @notabene suggests, brings a lot of extra overhead that you really don't need. I see a couple of options, one of which is akin to using Excel:

Open Office Calc: free. There is also a MySql connector download (open source I believe) for Calc.

serialized data: either XML or
binary (encrypted)

...either way, free and you have complete control.

I personally would be inclined to go with binary serialized and encrypted data. Two reasons:

game data cannot be easily tampered
with

I can work with datatables rather
than Xml serialization of datasets,
i.e. I have the option.

Is there a need for a dedicated, true game-oriented data library? Maybe...unless someone knows of such a library already in existence.

To the point of the OP's question, look at each pagecsv file as a single data table - akin to a table in a database. Each page file should contain related data:

Skills, or

Gear, or

NPC stats

This helps you keep a high level of organization which will be very important as data content grows, game content expands, etc.

Edit
After actually attempting to use .ODS (OpenOffice Calc file) and connecting from an application, it is actually not possible as initial posts on OO site implied. I could not find anything specifically showing teh codez on implementation.

Also, using Excel files might be okay while developing a game so data can be tweaked without overhead from a database. However, and this is important, if you plan on doing this, you must have MS Office installed so you can reference Microsoft Excel Interop COM. This may be beneficial at first, but I wouldn't want to remove or change a bunch of code to get an application ready for Alpha, Beta, or RC. A very simplified library would take more effort than I could see being useful.

I am going to use .CSV files for early stage data storage. There are some drawbacks, but overall I feel this is a much better option. Everything is contained within my libraries. .Net has very useful classes for reading these text files. Also, as .CSV files, the data is easily manipulated; and, for later stages of development, all I need to do is have my data files serialized to XML, then later to serialized encrypted binary.

I don't mind downvotes at all...except when I don't know why. Is there something incorrect about the options I provided or my advice on organizing a spreadsheet? Or did someone just not like my options?
–
IAbstractJan 8 '11 at 22:22

I gave you -1 because you compared a spreadsheet to a disk data format, and then made statements like "game data cannot be easily tampered with". A program/interface and a disk data format are not really comparable, and making your game data binary does very little to dissuade modders. Also, your proposed spreadsheet schema is horrible, since it keeps all the data in one file. Certainly skills and NPCs should be in separate files; perhaps all NPCs should be in separate pages in the same file, although if you use a locking RCS that's going to be horrible too.
–
user744Jan 10 '11 at 10:52

I disagree. Take Open Office Calc with the MySql connector. Sure you can create a different file for each. But I wouldn't expect to keep my data in this format once I have a RC.
–
IAbstractJan 10 '11 at 14:43

If designers are using Excel, they will pass data between each other in formats like .xls or .csv. If you don't want to lose that data into an Outlook black hole or when their computer crashes, you need to teach them to keep it in the RCS.
–
user744Jan 10 '11 at 15:49

So long as the nature of your data permits it to be stored in a spreadsheet without jumping through too many hoops it makes a very good format, especially for development work. In the end you may want to store it in other formats for use but the spreadsheet gives you a very powerful editor which can be VERY nice if you decide to change how you handle something!

If you're using Excel go get a copy of ASAP utilities--it makes the spreadsheet into an even better editor.

Well, for me, I thing speartesheet programs can't handle such stuff correctly and effectively. RDB was design, actually, to handle huge data and tables. Modern RDB were designed to handle the 'Huge' kind of things and they are doing it very good.

The point is, to get the best output of the RDB you need to design your database in the correct way. If your data schema was poor, or did not cover all the data of your project, you will end with a very bad results, performance, and output.

The idea of RDB is to break down huge table into smaller ones so that you can improve performance and readability. If you have a very huge table (attributes wise or even records wise) or a lot of repartitions, and you don't use most of them, that means your design of the DB has some errors.

In your question Huang F. Lei, if I were asked to design a MMORPG database, I will not add all the skills in one table and all mobs in one table. I will divide the skills according to their classes and usage into multi tables. Each skill type will have its own table or even tables. For mobs, I will either divide them according to their types, or according to their location in different worlds. And so on.

This way I can shrink the table sizes, make it easier for me to track the data, and improve the DB performance.

In Excel, on the other hand, all the data will be 'crumbed' in one place. and to find one piece of data is almost impassable, epically when you have a repeated data. In addition, as the data grow in size, the opening time of the file will increase.

At the end, Excel - in my opinion - is a very poor way to handle huge related data.

You are right,but this is not correct answer. If you read question carefuly or read another answers or comments you will know that question is about game design,not storing data.
–
NotabeneJan 9 '11 at 9:39

I know its about the design and red the questions and answers. What I understand is that, Huang F. Lei, is trying to chose between RDB and spreadsheet. My answer trying to show the difference between the two!
–
Ali AlbahraniJan 9 '11 at 10:13

Cite: Huang F. Lei:" Yes, excel is a common tool. The point of the question is:"a single huge table for all items", items include equipments, consumes, etc. Is it necessary to divide the huge one into small ones? Even separated config file for each item? I'm afraid the huge table may hurt their eyes :o)"
–
NotabeneJan 9 '11 at 13:29

2

Thanks for your answer:o) The question is about how game designer provides data for making game, not about how programmer store/access player's data in game.
–
Huang F. LeiJan 9 '11 at 15:16