Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize folder structure #822

Closed
Barsonax opened this issue May 20, 2020 · 6 comments · Fixed by #827
Closed

Optimize folder structure #822

Barsonax opened this issue May 20, 2020 · 6 comments · Fixed by #827
Assignees
Labels
DevTool Area: Development tools and environment Editor Area: Duality editor or support libraries Usability Related to API and UI usability
Milestone

Comments

@Barsonax
Copy link
Member

Barsonax commented May 20, 2020

Summary

Before releasing v4 we should consider optimizing the folder structure a bit. I propose that we introduce a separation between source code and the duality game engine.

To give a general idea the structure would look like this

root
  Assets (formerly the media folder)
  Source
   Solution.sln
   Launchers
     Gamelauncher
     Gameeditor
   Plugins
     Gameplugin
  Duality
    Data
    Plugins
    rest of the buildoutput....

Duality does use some hardcoded paths so these have to be changed to make this work.

Analysis

  • Simply zipping the duality folder would work for distributing the game.
  • Easier to find the .sln file
  • Easier to ignore certain files with wildcards from source control as files are not mixed together anymore.

EDIT: updated example structure

@Barsonax Barsonax added this to the 4.0 milestone May 20, 2020
@Barsonax Barsonax added Usability Related to API and UI usability DevTool Area: Development tools and environment labels May 20, 2020
@Barsonax Barsonax linked a pull request May 21, 2020 that will close this issue
@Barsonax Barsonax self-assigned this May 21, 2020
@Barsonax
Copy link
Member Author

Barsonax commented May 21, 2020

After discussing with @SirePi we found out that the Media folder actually contains only temporary data that is used so that you can edit resources in external programs. The source of truth is actually still the resource itself. Might sound a bit weird since it does get updated from the media folder but thats just a trick to make it work with a external program.

@ilexp is the above correct?

To make it more clear that this is temporary data I think we should put this folder under duality/temp.

@ilexp
Copy link
Member

ilexp commented May 21, 2020

After discussing with @SirePi we found out that the Media folder actually contains only temporary data that is used so that you can edit resources in external programs. The source of truth is actually still the resource itself. Might sound a bit weird since it does get updated from the media folder but thats just a trick to make it work with a external program.

@ilexp is the above correct?

Yes and no. You can safely delete the Source/Media folder and everything will still work in Duality and the editor. You can even open or re-export most of the builtin Resources via double-click, and the sources will just be extracted again and opened.

However.

This is not true for all Resource importers that can be implemented, and not even for some that currently exist, since importing and exporting are not symmetric operations. It is possible for an import to extract relevant information and omit "design" information that cannot be recreated on export.
For example, if you write a custom audio importer that imports a high quality .wav (? No idea to be honest, I'm not an audio expert) that you use for editing, then delete it and re-export it, you'll get a compressed .ogg at the previously imported quality.
Another example are fonts - for them, there is simply no way to get back the original font files, since they are transformed into bitmap fonts on import. It's not even possible to change font size after deleting the source files anymore.

So, in summary, the Source/Media folder can actually be very important. It may be okay in some workflows and with some Resource types and importers, but in the general case, you need that folder to persist if you want to edit your already imported Resources at their original quality later on. It's somewhat robust to deletion due to export features, but it's not temporary.

@ilexp
Copy link
Member

ilexp commented May 21, 2020

On a different note:

To give a general idea the structure would look like this

Please use PascalCase for folder and file names (and avoid abbreviations of already short words) to match the current convention!

Looks good other than that. Not sure about the Assets folder though - it's better than just Media if it's outside Source, but it give people the wrong impression, especially Unity people. Some wild ideas to start:

  • Source/Assets
  • Import
  • Duality/Import
  • ?

@Barsonax
Copy link
Member Author

Please use PascalCase for folder and file names (and avoid abbreviations of already short words) to match the current convention!

ok

This is not true for all Resource importers that can be implemented, and not even for some that currently exist, since importing and exporting are not symmetric operations

Ah that makes sense. You always want to edit the source data for best quality.

Looks good other than that. Not sure about the Assets folder though - it's better than just Media if it's outside Source, but it give people the wrong impression, especially Unity people. Some wild ideas to start:

Some more idea's

  • Resources
  • AssetImport

I don't think we want to put it under the Duality folder though as you don't need these files anymore when publishing your game. Makes it easier if its already separated by default.

@Barsonax
Copy link
Member Author

Decided to go with Import as name and keep it in the root folder

@Barsonax
Copy link
Member Author

I think for now we should keep DualityLauncher and Editor in the root folder as thats much easier to implement. Moving further discussion about this to #828

@ilexp ilexp added the Editor Area: Duality editor or support libraries label May 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DevTool Area: Development tools and environment Editor Area: Duality editor or support libraries Usability Related to API and UI usability
3 participants