search

UnderwaterApps / overlap2d

Overlap2D Game development toolkit for UI and Level design
Other
780 stars 224 forks source link

Relative paths in export settings #102

Open wam3483 opened 9 years ago

wam3483 commented 9 years ago

Absolute paths should not be used in export settings as it requires developers to store everything on the same file path.

A better solution is for Export Settings to use relative file paths. This will simplify project setup making it easier to collaborate on projects, and make it possible to store export settings in a repository.

Export settings also has information on how assets should be packed. Currently its just the dimensions of the packed file, but in the future this could be expanded for more packed options. These texture packer settings should be versioned as they can affect the performance and size of the game.

azakhary commented 9 years ago

Not sure I understand, how will overlap2d know your actual libgdx project location without absolute paths?

As for the export settings, the information of how asset is packed get's translated into the pack file itself. So it is versioned, because you can access it inside the pack file.

furthermore. I think in the future we should avoid versioning the pack file too in CVS, because it blows up repository in size. A better solution would be to version the input file list, and have o2d provide a command line script, so that you can put packs in .gitignore, and then generate them on the fly when initial images are modified with gradle. This is for production scale cases.

wam3483 commented 9 years ago

Overlap2D doesn't need to know your libgdx project's path, it just needs to output to a relative location rather than an absolute location. This is so when export settings are uploaded to a repository they're not specific to a particular dev's file system. Example: You and I are working on a project. I create an overlap2d project under 'C:\projects' and I export to absolute path "C:\projects\some\path". You pull down my Overlap2D project and now cannot export as that export path doesn't exist for you locally. This problem is solved by relative paths, so export settings would store '\some\path' instead of 'C:\projects\some\path'. Absolute paths are unnecessary and limiting.

Yes, export settings should be versioned I'm not arguing that. I argue relative paths would make versioning export settings more practical as then file system specific content isn't being uploaded into a shared location.

azakhary commented 9 years ago

Got it, agree about making relative to the editor (or at least, giving an option to do both) thinking how to implement it.