I am making a pokeclone game... so I need to make a file to list all the monsters, moves, and the leveling rates... Should I separate these into 3 files? 2? or 1?

The above is just copy pasted from my last topic, but I figure that it is likely noone saw it because they answered the original question and moved on I guess I have to make a new topic which I don't like to do if the topic is roughly the same...

to expand a bit...

Should I have the monsters and skills all in one file, or should i separate them into 2 files... same question for character data and pet save data...or all pet data and active data... Cuz if you have followed the conversation in game design, the pet data will have to have "genes", but these genes are only used at one point in the game really and constantly having them loaded seems like it might be a problem, but I don't know.

So is there a rule of thumb with these things and should i separate these files up or just have them all in one?

Hello Durakken,

my suggestion is to split the file by responsibilities http://en.wikipedia.org/wiki/Single_responsibility_principle

Sincerely

Henry

Divide the data however it makes sense for your game.

Maybe having one big file is good for your design. Maybe having lots of little files is good for your designs. Your design, your engine, your decisions.

My preference is to have a single file for each data table while you are developing it. You can have tools that bundle the files up into smaller pieces for the final distribution.

The data we typically just keep in Excel spreadsheets. When the designers change the data they use a macro to extract the data and generate an XML document. Some of the tables were four or five columns wide with only one or two rows initially with sample data, eventually growing 20 or 30 rows. Some of them were several hundred columns wide and many thousand rows. Both the xls and xml files live in version control. Some fancy parts of the game engine (kudos to whoever writes the file monitoring in all the engines I've worked on) monitors the files for changes. When the change is detected, it broadcasts an event to whoever registered the watch on the file; the system that registered it automatically reloads the tables when a change is detected, then sends out an event to the system that the data has been updated. Upon getting the notification, any interested listeners can refresh themselves, so that means the GUI can refresh, the battle rules system can refresh, and anything else that cares can refresh. When the game is packaged for distribution files get moved around and pulled into a compressed file system, and the xml spreadsheets are cleaned up into a more simple binary representation.

Sorry for the distraction on hot reloads. They are important because they can save hundreds of hours and lots of frustration at the end of development. A 10-second refresh is so much nicer than a 5-minute restart.

So ultimately I recommend one end of the pipe has data tables in xls. On the other end of the pipe you have data tables as arrays in code. Magic happens in the middle. Keep each table specific to the task at hand, whatever that task happens to be. The magic of the toolchain in between is entirely up to you.

I see what you're saying... I don't have Windows office nor a xml exporting program to do that with so i see what you're saying, but does little good for me ^.^ It does answer my question though, just wish I knew a way to convert open office or google sheets files to xml easily.

It does answer my question though, just wish I knew a way to convert open office or google sheets files to xml easily.

It does answer my question though, just wish I knew a way to convert open office or google sheets files to xml easily.

If you know PowerShell, you can download your Google spreadsheet into an excel file, then you can write a script in PowerShell using the EPPlus library to extract information form the file and into an xml file.

Or you could use a text editor and do some skillful copy, paste, and multi-line edits to craft your xml...

I see...nope I don't know anything about powershell

You can download LibreOffice Calc for free and use that, no need to use Excel. I think the easiest format to read in a simple table is csv, no need for xml in that case.

>.> So ran into a new problem...

The maximum number of columns in Open Office Calc is 1024... I need more than 3000 for what I'm doing... or I need to come up with another way for what I'm doing to work