search

AdamsLair / duality

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

There doesn't seem to be a way to open or save a project #776

Closed Shadowblitz16 closed 4 years ago

Shadowblitz16 commented 4 years ago

Summary

There doesn't seem to be a way to open or save a existing project in the file menu

How to reproduce

-Open duality editor -Goto the mainmenu->file -See there is a save all but no save or open

Workaround

Analysis

SirePi commented 4 years ago

This is a side effect of the "one folder = one project" philosophy behind Duality. Opening another project would essentially mean "close this instance and open the one in the selected folder"

ilexp commented 4 years ago

Yep, that's it. To open another project, you start the editor instance from its folder.

Closing this, since I don't think the intention of this was to change the fundamental design here, and the underlying question has been cleared up by @SirePi.

Shadowblitz16 commented 4 years ago

@ilexp can this be reopened its still not clear why this can't be added. I don't see the benefit of only having 1 project. there doesn't seem to be a way to open a existing one instead of creating an entirely new one every time the editor is ran

EDIT: also its not very clear on how to load a existing project.

Shadowblitz16 commented 4 years ago

Ok so I now know how to open projects. you have to run the dualitor executable inside the project folder.

this seems wrong can this be changed to actually use a project system?

ilexp commented 4 years ago

It's not the standard approach, but there are good reasons for it too - like allowing each project to stick with its exact configuration of plugins and modules, and not forcing them to use some shared centrally installed version. Not requiring a central installation is also a feature.

While theoretically possible to change this, there's not really a great reason to do that right now, all impacts considered.

Shadowblitz16 commented 4 years ago

@ilexp The project can stick with the exact configuration with this method too just have the project have a asset and a addons folder this is a major usability issue and might actually be steering people away from using this

ilexp commented 4 years ago

this is a major usability issue and might actually be steering people away from using this

It's a different approach, yes, but I don't see how this is inherently less usable. Your project forms a self-contained unit with everything it needs to run and be edited. You can copy it around freely, move it to different machines, check it in and out of version control across devices without the need to install some software in a specific version on all of them. Overall, I'd consider this a plus 🙂

Barsonax commented 4 years ago

Our current approach ensures there are no global dependencies. This a big plus as it makes it possible to just download a project and open it without any problems with different installed versions.

With v4 our current approach makes even more sense as a duality project will basically be a bunch of a package references, your code and some resources. You can check this all into source control which makes it easy to see what changed in the past as there are no binaries.

Shadowblitz16 commented 4 years ago

@ilexp you can do that with any other file structure too. @Barsonax all that would be needed would be a core addon in the addons folder. that would be the engine. then you could new, open and save your project anywhere on system of move it in the file explorer.

not only does it clean up the project folder but it also implements a common file menus

ilexp commented 4 years ago

@ilexp you can do that with any other file structure too.

Let's assume there was a system-wide installation folder with the editor and engine, and a few different project folders somewhere else on the same machine. This is the typical way how applications work, and also the one where you would expect an "open project" menu item.

If you copy one of the projects to a different machine (manually or via version control), it won't work - because engine and editor are missing. To make it work, you'd now have to install the exact same version of engine and editor on that other machine, which is a complex issue in a package-based modular setup like ours. Next, imagine if you have not one project, but multiple projects, using different version configurations of the various packages. It will be very difficult and tedious to keep track of this.

On the other hand, the current system simply doesn't have this issue. You copy the project, and it's all in there, fully self-contained. Done.

And of course there's also the point Barsonax mentioned, the next step in this approach is to fully rely on VS package management and enable projects to be created and managed completely using native tools.

Shadowblitz16 commented 4 years ago

@ilexp your not listening to me. the whole engine can be in the plugins folder under /plugins/core/ENGINE FILES HERE

it has nothing to do with the menu at all

ilexp commented 4 years ago

As far as I can see, this issue turned into a proposed paradigm shift in how projects are managed with Duality, which I think we have discussed. You did not expand on or respond to the points I mentioned, and I seem to not understand what you are talking about - so I'm honestly not sure where else to go from here. I'd be fine with concluding here for now and leaving this as-is.