Consider merging GameEditor / GameLauncher projects in the v4 template

[ilexp]

Summary

Right now, the new v4-alpha2 solution template has a GameEditor dummy project for installing editor executable and dependencies, and a GameLauncher dummy project for the launcher side. Each of them also serves as a startup project for running or debugging them. Merging them into a single project that does both could simplify a lot of things for both new and experienced users.

Analysis

• Running game or editor requires changing the startup project. This is not a regression to v3, but now that we use launchSettings.json, we could simply have two launch profiles in one project instead. This would allow us to use the "Play" button dropdown in VS, which would match its use case and user expectations.
• New users will often start by installing a sample package, but even experienced users occasionally need a plugin here and there. Where do they put it? In the launcher dummy? In the editor dummy? Or worse, in one of their own plugins, breaking the installation scheme?
• If there was only one project in the solution that represented both launcher, editor, and the game as a whole, the question would be simplified or even avoided.
• One downside to consider: It would remove the somewhat natural option to extend the launcher dummy into an actual custom launcher project for specifying a custom app icon and launcher code.

To me, merging the two projects feels like a clear usability improvement. Any points against it? @Barsonax Any technical reasons not to?

[Barsonax]

Good find on the multiple launchsettings in 1 project.

I do think its good to keep the separation between a launcher and a editor project as the launcher doesn't need any editor dependencies. We just need to point out their usage in the docs.

Also in the future we might be adding more build steps such as creating a self contained application and I don't think the compiler will remove all the editor dependencies by itself.

So yes technically we can do it but not sure if its really smart to do.

Adding dependencies to the plugin directly should work just fine btw.

[ilexp]

Good points!

Adding dependencies to the plugin directly should work just fine btw.

Yeah, but if I install a sample with dependencies to both editor and core into my core plugin, then I'm in trouble - it's a pitfall that we should avoid by providing a clear "install all your plugins and packages here" hint in some form.

I do think its good to keep the separation between a launcher and a editor project as the launcher doesn't need any editor dependencies. We just need to point out their usage in the docs.

It depends whether you see the projects as different modules with individual dependencies, or as one representative for the entire game setup, so I think both would work with the right frame of mind.

However, #840 pretty much locks us in with the separate modules view, which is totally valid.

That said, we could still transform the remaining editor launcher dummy project into this "project setup representative", making it clear that this is where to primarily install Duality plugins and samples. We could, for example:

• Rename the editor launcher to ProjectSetup, Project, Workbench or something similar.
• Aggregate all launch settings (game and editor) in the project and remove them anywhere else.
• Feature the project in the docs and getting started guide as "the place to install packages".

Not sure this is the best way to move forward, but right now, and even with #840 merged, there still is this bump in the road for new users that I'd like to flatten out a bit more, other ideas or thoughts appreciated.

[Barsonax]

Yeah, but if I install a sample with dependencies to both editor and core into my core plugin, then I'm in trouble - it's a pitfall that we should avoid by providing a clear "install all your plugins and packages here" hint in some form.

I think its the developers responsibility to think about where dependencies should be put. Its part of your program just as much as the code itself. There are a couple scenarios:

• A coreplugin depends on the plugin so it has to reference it directly.
• A editorplugin depends on the plugin so it has to reference it directly.
• User wants to add a 'global' coreplugin which his coreplugin never uses in any way it so it should go in the launcher project. Samples will probably end up here.
• User wants to add a 'global' editorplugin but his editorplugin never uses it in any way so it should go in the editor project.

All of these are possible with the current setup however if we make it so that all dependencies should end up in 1 project then its no longer possible to have this control. Things might even start to break at runtime on different machines when its a plugin that gets uploaded to nuget due to missing a (implicit) dependency.

We should ofcourse point out in the docs where to put dependencies to help new users find their way.

That said, we could still transform the remaining editor launcher dummy project into this "project setup representative", making it clear that this is where to primarily install Duality plugins and samples. We could, for example:

Aggregate all launch settings (game and editor) in the project and remove them anywhere else.

Since the launcher project is now producing a exe that means that if we move the launchsettings to a separate project the launcher project will default back to its default behavior and crash or dosomethingweird since its trying to launch duality from the bin folder in that project and thus its missing things like the Data folder etc. I think for now having them be separate projects is fine.

Personally I would like to move away from having to do custom launcher configurations in the future. Ideally things should work ootb even if duality gets launched from the bin folder. That should also allow us to clean up the custom msbuild logic we have now in the template which is always good since we ship that logic to all users. However if we want to do this we basically need to:

1. Separate the binaries from the data, we also want to do this if we want to support multi targetting.
2. Make hot reloading work without file lock issues without having to put plugins in a separate folder. We probably have to look at a tool like dotnet watch or similar (or even build something ourselves..). We might also improve the hot reloading logic by automatically reloading on a source change.
3. Rethink how to publish the game as the location of files has changed.

Though some of those points will be quite complex so I don't think that will happen soon.

[ilexp]

All of these are possible with the current setup however if we make it so that all dependencies should end up in 1 project then its no longer possible to have this control. Things might even start to break at runtime on different machines when its a plugin that gets uploaded to nuget due to missing a (implicit) dependency.

👍

The only issue we'd remain with is this:

User wants to add a 'global' coreplugin which his coreplugin never uses in any way it so it should go in the launcher project. Samples will probably end up here.

Some samples have editor dependencies, since they bring along editor plugins or code. We need to find a way to clearly communicate where to put them, and again - the people most in need of the samples are those who probably have the highest chance to stumble over stuff that isn't intuitively clear. That's why my initial thought was to reduce ambiguity, but you're right that dependencies need to be managed explicitly.

Maybe for now we just need a really good docs page on this. In the long run, it could be worth considering a different distribution mechanism for the samples as well, or maybe just usability improvements for the current approach in that specific scenario that we just haven't thought of yet.

Since the launcher project is now producing a exe that means that if we move the launchsettings to a separate project the launcher project will default back to its default behavior and crash or dosomethingweird since its trying to launch duality from the bin folder in that project and thus its missing things like the Data folder etc. I think for now having them be separate projects is fine.

Ah, you're right. Then that's not a good idea.

Though some of those points will be quite complex so I don't think that will happen soon.

Yeah, let's put that one on the backlog for now. One major step at a time 😄

[ilexp]

Closing this, as I think this idea has run out of viable options.