Pros & Cons of using single .ini file management?

I'm working on a test project with .ini files. I'm trying to get another perspective on whether or not there are any cons to having a single .ini that contains all of the game management data versus a number of .ini files each containing parts of the game management data. Here is an example:

Single File with all data... The file would contain 100 fighter groups, each fighter group consisting of about 60 fighters, each of the 60 fighters would have their own number/text attributes that interact with private variables for each corresponding character sprite.

VS.

100 separate files... meaning 1 file for each fighter group with 60 fighters per group with each of the 60 fighters having their own number/text attributes that interact with private variables for each corresponding character sprite.

I don't know about the technical side (it will take more ram, more cpu, or not, bla bla) but I see 2 other points there.

First grouping or separating will depend on your engine (like having an ini file in each folder containing the images of the group or something like that or rather a single data.ini in the root folder).

It is somehow a matter of taste.

The other point I see is that through .ini files, ppl will be able to modify the values of the fighters and groups in the notepad. Once again, depending on your engine it might be an issue.

If you want to prevent people from accessing those datas, you may create a simple editor, place all your datas in a hashtable and export it. Than in your game, load the hashtable and there are your datas.

You could still edit those through your editor, but simple notepad edit would be discarded.

For the technical side, I'll let you wait for other peoples answers.

Ini is just text, so there is a possibility of some lag created by a text to number conversion if the file is rather large. That is to say if it will be parsing a lot of data each tick.

Then again you could expect similar results for lots of little files under the same conditions.

I don't know about the technical side (it will take more ram, more cpu, or not, bla bla) but I see 2 other points there.

Yeah, I'm wondering if there is any technical downside. If there is, I doubt it would be major since it's only text and not even text that needs to be triggered in like a split second or anything.

First grouping or separating will depend on your engine (like having an ini file in each folder containing the images of the group or something like that or rather a single data.ini in the root folder).

It is somehow a matter of taste.

The sprites inside the layout are blank, meaning that you'd have two groups of fighters and based on which groups you select, the loop index--based on a global variable--will bring in the correct groups and populate the blank sprite positions at runtime (this I already know how to do). Also, based on the group, Construct will recognize the attributes in the .ini file and change each sprite's private variable attributes to match those in the .ini file. This will only need to take place once per game in the opening fighter group selection screen, so it won't affect actual gameplay.

What I'm not sure about it, is whether keeping all of these things in one file is a good or bad idea, or if separating each fighter group into its own file is a better idea.

The other point I see is that through .ini files, ppl will be able to modify the values of the fighters and groups in the notepad. Once again, depending on your engine it might be an issue.

If you want to prevent people from accessing those datas, you may create a simple editor, place all your datas in a hashtable and export it. Than in your game, load the hashtable and there are your datas.

You could still edit those through your editor, but simple notepad edit would be discarded.

I want them to be able to edit the file. My goal is to make an engine that can be fully edited by the end user even if they don't have Construct or any desire to learn it, so as far as I can tell using .ini's seems to be the path of least resistance to that goal.

SIDENOTE: The post preview function is not working. Please forgive me if this is already a known issue. Thanks

Using different files per group will also help increasing stability. With some efford when trying to read in the data you can manage for your engine to be able to work even if 1 or more of the files are corrupted.

With only one file all is gone if the file is corrupted.

I want them to be able to edit the file. My goal is to make an engine that can be fully edited by the end user even if they don't have Construct or any desire to learn it, so as far as I can tell using .ini's seems to be the path of least resistance to that goal.his is also a statement for multi-file-management. I think the users of your engine will have more fun editing if they don't have to look through one huge file and saving the content of it, everytime they just work on one tiny change.

Ini is just text, so there is a possibility of some lag created by a text to number conversion if the file is rather large. That is to say if it will be parsing a lot of data each tick.

Then again you could expect similar results for lots of little files under the same conditions.

Thanks newt, really good info there. Based on that insight, I'm going to have to be conservative with how much/how often I'm accessing. So far it looks like it's mostly at the selection screen so if I were to keep it just there it wouldn't be a problem, but I've also been leaning towards a real-time system where certain actions during battle overwrites data and saves to the .ini, so that would definitely call for an efficient route.

Using different files per group will also help increasing stability. With some efford when trying to read in the data you can manage for your engine to be able to work even if 1 or more of the files are corrupted.

With only one file all is gone if the file is corrupted.

Excellent point! I didn't even consider corruption, lol.

This is also a statement for multi-file-management. I think the users of your engine will have more fun editing if they don't have to look through one huge file and saving the content of it, everytime they just work on one tiny change.

This too is a good point. At first there weren't going to be many groups, but now that I'm possibly looking at over 100 it would definitely get to be a chore to look through.