A question for SLUDGE users. (Ini files.)

[Trumgottist]

I'm about to implement the saving of settings made in the startup window. The most straightforward way to do that would be to simply write all settings to the ini file, replacing the old file. This would destroy any other entries in the ini file. Games will still be able to write their own settings in ini files with other names, but not in the main ini. I don't think that would break any existing games, but I'm asking for your input anyway before implementing it.

[Erwin_Br]

I have no problem with that. New users might be confused, though, when they try to write things to the main ini and their settings vanish. So maybe it's possible to trigger a compiler warning when you try to do that, or something?

Also, where is this ini going to be stored on the Mac? Inside the app package?

And, where is it going to be stored on Windows? Vista/Windows 7 don't allow applications writing stuff inside the Program Files folder.

[Trumgottist]

A compiler warning would be tricky, but a note in the relevant help file section would be needed.

--

Currently, the ini file lives next to the game file regardless of where that is. On a Mac, the normal way of distribution is to put everything in the app package. That already works: If you put a gamedata file in there, the engine will use that instead of asking for a file, just as the Windows version does. (It looks in the MacOS folder though, where the executable is. It would be more proper to have it in the Resources folder which is meant for such things.)

But you're right that the current setup isn't ideal for modern Windows versions. (The rule against writing in Program Files has been there since XP, unless you were running as admin.) I did some trickery with the Frasse installer - placing the data file in Application Data and setting up the shortcut to the game accordingly instead of relying on the gamedata thing - to work around it.

Let's think about how things should work on Windows. The parts we have are:
* Engine files.
* Game data file.
* Ini file (currently next to the data file)
* Save games and other game made files (currently in an optional sub folder next to the data file).

Where should things go?

[Kickaha]

On OSX an application shouldn't write into its app bundle.  That is not officially approved.  So if you are going to modify the ini file it shouldn't be in the app bundle.

[Trumgottist]

Oh? Thanks, I didn't know that. In that case, the writeable files (ini files, saved games and stuff) ought to be stored elsewhere there too.

I propose %AppData%\SLUDGE Games\GameName\ on Windows and ~/library/Application Support/SLUDGE Games/GameName/ on OSX. (Or should it be GameName directly, skipping "SLUDGE Games"?)

Maybe that setup should only be used for "gamedata" files and keep the writable files next to the .slg files to make things easier for the game makers that may want several game projects with the same name during development? Or should it be consistent and always store the writables away in appdata?

[Erwin_Br]

I'd say keep it consistant and tidy and move all external files to that folder.

I would also prefer not to use "SLUDGE Games" in the path filename, simply because your players will probably not know what SLUDGE is, and where that strange folder suddenly came from. The name of the game will do, and is easily recognizable as well.

For the Windows version you can take a similar approach, I think. "App Data" will be "Documents and Settings/Application Data" or something, if I remember right.

[Squinky]

Agreed. SLUDGE Games isn't necessary, just GameName should be okay.

[Trumgottist]

For the Windows version you can take a similar approach, I think. "App Data" will be "Documents and Settings/Application Data" or something, if I remember right.

It's "Documents and Settings\username\Application Data", or
"SHGetFolderPath(NULL, CSIDL_APPDATA, NULL, 0, szAppData)" to be specific. (Sometimes, MSDN is quite useful.)

The main reason I considered adding "SLUDGE Games" was to reduce clutter (also that MS recommends to "append [company name]\[product name]\[version] to the returned path") but I suppose it's not really needed, and the risk that someone names their SLUDGE game the same as something else shouldn't be that big.