Do you fill all your game data in huge excel tables? Are there any better method?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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 page csv 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.

Answer 4

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.

Answer 5

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.