search

AdamsLair / duality

a 2D Game Development Framework
https://adamslair.github.io/duality
MIT License
1.41k stars 289 forks source link

Add project settings and move launcher path to it #852

Closed Barsonax closed 4 years ago

ilexp commented 4 years ago

Ok for me, just a little thing bugging my brain: we have UserData and AppData, so why not ProjectData? 😄

To me, ProjectSettings just triggers the right associations as to what one should expect to find inside, and it's a term that's well known from other software and Unity. It's also too different from UserData and AppData, which are both read or (in case of user data) even written by the game while playing, when ProjectSettings is really an editor / development thing.

Barsonax commented 4 years ago

@ilexp when publishing the game editor files wouldn't be included right?

We have a number of different settings files:

For the game:

For the editor:

And some default variants of these files. We might wanna look into cleaning this up so we treat all these settings in the same way but thats for a different issue https://github.com/AdamsLair/duality/issues/855.

I agree with sirepi that the naming for ProjectSettings.dat might not be optimal. Personally I think since we already have AppData.dat for the game simply calling it EditorAppData.dat makes sense as it has the same purpose but for the editor.

ilexp commented 4 years ago

@ilexp when publishing the game editor files wouldn't be included right?

It depends - it's perfectly valid to deploy the editor with the game to give players a map editor or something. In that case, the project settings / (non-user) editor settings would be included as well. Perhaps cleaned up in some form, but that's a separate issue for later I think.

I agree with sirepi that the naming for ProjectSettings.dat might not be optimal. Personally I think since we already have AppData.dat for the game simply calling it EditorAppData.dat makes sense as it has the same purpose but for the editor.

I still think EditorAppData is rather opaque as a term, not giving you a good idea on its contents, whereas ProjectSettings already gives you a rough direction. I'd rather clean up the naming of AppData and UserData into something more descriptive tbh. UserData should, judging from its contents, rather be a name with something like game options, game settings, or similar. And AppData might be better off with something like system config, engine config, app info.

Edit: Maybe let's move this discussion over to #855? I've commented there with some more thoughts on this. For this PR I'm fine with either choice as long as you guys come to an agreement 👍

DesignTimeData.dat

It's non-global / per-object data that is only relevant in the editor, see here. Right now it only stores whether an object is locked or hidden. Could probably be refactored to be merged into any of the other files, depending on how we define the scope of this info, or stay separate for a while until we happen across a good idea on what else to do with it.

Barsonax commented 4 years ago

For now I will keep the name as is in this PR. Lets change the name to the final name after discussing it in the issue.