Jump to content

  • Log In with Google      Sign In   
  • Create Account


How to efficiently divide files up?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
11 replies to this topic

#1 Durakken   Members   -  Reputation: 501

Like
0Likes
Like

Posted 15 March 2014 - 12:13 AM

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?

 



Sponsor:

#2 glportal   Members   -  Reputation: 318

Like
2Likes
Like

Posted 15 March 2014 - 01:15 AM

Hello Durakken,

 

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

 

Sincerely

Henry



#3 frob   Moderators   -  Reputation: 18819

Like
8Likes
Like

Posted 15 March 2014 - 01:22 AM

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.


Edited by frob, 15 March 2014 - 01:24 AM.

Check out my personal indie blog at bryanwagstaff.com.

#4 Durakken   Members   -  Reputation: 501

Like
0Likes
Like

Posted 15 March 2014 - 02:22 AM

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.



#5 fastcall22   Crossbones+   -  Reputation: 3926

Like
1Likes
Like

Posted 15 March 2014 - 03:30 AM

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

WW91J3ZlIGdvdCBhIHNlY3JldCBib251cyBwb2ludCE=


#6 frob   Moderators   -  Reputation: 18819

Like
1Likes
Like

Posted 15 March 2014 - 05:26 AM

We've always done ours with a simple macro that people run manually. That approach looks identical.
Check out my personal indie blog at bryanwagstaff.com.

#7 Durakken   Members   -  Reputation: 501

Like
0Likes
Like

Posted 15 March 2014 - 09:43 AM

 

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



#8 wintertime   Members   -  Reputation: 1595

Like
1Likes
Like

Posted 15 March 2014 - 02:42 PM

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.


Edited by wintertime, 15 March 2014 - 02:43 PM.


#9 Durakken   Members   -  Reputation: 501

Like
0Likes
Like

Posted 16 March 2014 - 10:33 AM

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



#10 Krohm   Crossbones+   -  Reputation: 2952

Like
1Likes
Like

Posted 17 March 2014 - 01:34 AM


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
Yes, absolutely. You are producing at least 3KiB of data for each row/monster/item, not a good workflow at all. This is going to be an hell to manage and tune.

#11 Durakken   Members   -  Reputation: 501

Like
0Likes
Like

Posted 17 March 2014 - 05:19 AM

 


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
Yes, absolutely. You are producing at least 3KiB of data for each row/monster/item, not a good workflow at all. This is going to be an hell to manage and tune.

 

 

lol yeah... I assume I could just not use an editor other than notepad to add and maintain the file, but that would be rather tedious.

And the number was actually 6000+ 30 some other cells.

 

I've already figured a better way of doing what I am going to do... similar results, but better for what i want and probably for handling overall.



#12 wintertime   Members   -  Reputation: 1595

Like
0Likes
Like

Posted 17 March 2014 - 08:22 AM

You could just type the table in transposed form (at least in LibreOffice rows are unlimited and OpenOffice is nearly the same program), that may even use the screenspace better while typing it in.

Or split the giant table into more than one table. That may even help to reduce repetition in the data.

 

If you like to you could write a tiny program convert it into transposed form or combine tables.


Edited by wintertime, 17 March 2014 - 08:24 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS