Which folder structure to use?

[SimonDarksideJ]

Pitch in on the approach to use for the Folder structure for the template. Mainly whether it is worth creating additional folders to host the platform csproj definitions or not.

Bear in mind, that unless you are writing platform specific code, you are unlikely to need them. However, it is more akin to MonoGame projects of old.

Make your vote, but also comment below as to your reasons why your choice feels better.

Note

There is no right or wrong answer here, structures like this are more about personal feelings, and the end result is your project will build and run just fine!

[KelsamGames]

I think the multi-folder approach is better because it removes any ambiguity as to what is used where, more or less at a glance. In our projects we have multiple platform-specific files that even share the same name, like Program.cs, ContentMangaer.cs, etc. Not that they necessarily have to, you could just as easily name the files "Xbox_ContentManager.cs" for example and achieve the same goal, but the whole point of folders is to provide structure and organization so you don't have to name files that way. Most our platforms also have other specific stuff like android's keystores, manifest, Resources, etc that just organize much better when specifically in a "GameName.Android" folder and not mixed in with every other platforms' stuff.

[SimonDarksideJ]

The Resources folder is also broken up by platform for platform specific deployment/deliverable, separate from the "Game" code/platform. As Resources is related to packaging and publishing in reality. SO it would contain keystores/manifests/etc. It's important to keep that separate and cleaner (especially where some resources are shared)

In the single folder approach, there is a single program.cs for all platforms, and arguably, that could also b done for Multi-Folder too.

About the only "logical" reason for keeping platform dedicated folders for all platforms, is clear delineation / segregation for platform dedicated code.

But we wanted to avoid that being the default, else you have a platform folder with a single file, the csproj.

We welcome all feedback though.

[KelsamGames]

So I guess the difference is you have your stuff separated by platform, per category of stuff. I.e.

Resources/Xbox/*
Resources/Android/*
Game.Xbox.csproj
Game.Android.csproj
ContentManager.Xbox.cs (or as you mentioned these could all be one file, but then would need like compiler #if flags to separate out chunks)
ContentManager.Android.cs

Instead of

Xbox/* (including Resources/, platform code, bin/obj, etc - all in one place for the platform you're currently working with)
Android/*

Which doesn't really make sense to me I guess. Because then every time you have something else to separate by platform, it has to have a new parent-level folder for that thing, then a bunch of subfolders for each platform (or file prefix naming conventions, in-file compiler flags, etc).

[KelsamGames]

So, really, I guess my point is just the argument that a "real" project will eventually have more than just one .csproj and a single .cs platform-specific file. But, Tom does a ton of porting of games and says he runs into that a lot, so maybe it's just me :P

[SimonDarksideJ]

The main issue with how the templates are today is that you have:

• 5 sets of application icons
• 3 duplicate program.cs and 2 invariant
• individual identity per project

It gets complicated.

I don't think you would create multiple ContentManagers through. That is better managed in a single builder. That is more about organising content

The idea behind resources is to have those things that are not really going to change in the lifecycle of your project under one folder. You set it once and each project pulls from this shared core folder, especially identity.

The rest of your "Games" active development folder, for the most part, will be a single source. It's really only consoles that are most likely to have code differences in a few places, or extra plugin's for a specific vendor.

Best idea is to try installing each template and generate a title with it using the options, then seeing how you use that from Visual Studio/VSCode/Rider and see what fits.

Ultimately both approaches work, and we've been testing these for weeks now, so it's just what everyone feels comfortable with, and the community is helping to "set the default" for al time!

[Bletraut]

Is this the version with a Single-Folder or with Multi-Folder?

[SimonDarksideJ]

That would be considered the multi-folder approach, as you have a dedicated folders for each "Platform" project.
But if those folders only have a program.cs and csproj in them, then it's no different to the flat approach, just with more folders.

[Bletraut]

The folders contain a few platform-specific files (such as FileDialog), but there are very few of them.

[AlanDavison]

This is extremely tough, because I genuinely like both. I think for the project I'm in the process of spinning up right now, I might use a middle ground approach with a tweak, just for the sake of experimentation:

.
├── Content
│   ├── Assets
│   │   └── readme.txt
│   ├── BuildContent.targets
│   ├── Builder
│   │   └── Builder.cs
│   └── Content.csproj
├── Resources
│   ├── Icon.bmp
│   ├── Icon.ico
│   ├── Identity.props
│   ├── macOS
│   │   ├── Icon.icns
│   │   └── Info.plist
│   └── Windows
│       ├── app.manifest
│       └── app.WindowsDX.manifest
├── Source
|   └── Game1.cs
├── Platform
│   ├── DesktopGL.cs
│   ├── DesktopVK.cs
│   └── WindowsDX12.cs
├── BlankGameTest.DesktopGL.csproj
├── BlankGameTest.DesktopVK.csproj
├── BlankGameTest.sln
├── BlankGameTest.slnLaunch
├── BlankGameTest.WindowsDX12.csproj
├── Directory.Build.props
├── Directory.Packages.props
├── README.md

With the .csproj files tweaked with:

<ItemGroup>
  <Compile Include="Source\**\*.cs" />
  <Compile Include="Platform\$(MonoGamePlatform).cs" />
</ItemGroup>

It definitely falls apart considering mobile platforms, though. I think (purely for me personally) I would prefer, for the multi-folder approach, to keep the .csproj files in the solution root, and move the platform folders into a Platforms folder, and then include everything from there from within the .csproj files.

For some reason, a bunch of folders visible in the project root feels a lot untidier than a bunch of .csproj files for me. Whereas all of the #if conditionals for the single folder approach also feels a bit off for me. Totally necessary for that approach though, no doubt.

[KelsamGames]

Sure, but to release on any console you have to have at least some platform-specific code because you are required to do things for that platform that MG currently doesn't provide (show the current user's gamertag, handle achievements/trophies, etc). So I'd say it's still worth thinking about up-front. Across our 3 commercial releases, 2 of them have multiple platform-specific code files and such. The other only doesn't because it's little more than a game-jam game.

[SimonDarksideJ]

That's fine, for platforms that require dedicated content, those will include it, likely using the platform above.
But no sense forcing it out of the box when most won't need it.
And for those that do, there will be docs, and guidance.

[SimonDarksideJ]

Oh and remember, unlike the startkit, if you only select DesktopVK and dx 12, then you only get the files relevant for those platforms. The android and ios files are ONLY added by the template if you select those platforms

[AlanDavison]

The bottom line I think really is that there is no way for a template to perfectly cater to...

• Games targeting platforms with zero platform-specific code needed for launchers.
• Games targeting some platforms with zero platform-specific code needed for the launcher projects, and some platforms (console, a future web export, etc.) that do need platform-specific code.

...without either a structure that might need to be tweaked (the single folder approach), or a structure with more noise than is necessary.

You could definitely make the template conditional depending upon which platforms are selected at creation time. DesktopGL, DesktopVK, and WindowsDX12 only? Default to a current single folder approach with a single Game1.cs and Program.cs. If it includes some more involved/complex platforms like mobile/consoles (hypothetical on there ever being a version of this template in the private NDA forks or whatnot), go multi-folder.

But I most certainly wouldn't want to be tasked with maintaining a template like that. That would not be a pretty thing under the hood.

[SimonDarksideJ]

My point is, if you examine the template, it is already conditional. And adding new platform extensions (which the Console varieties have MANY) should not be that difficult.

The critical path, which you've alluded to, is to set the standard, so everyone knows what to expect.

• The default template without platform exceptions - that is what the template does today
• Define a pattern for adding platform extensions - I think your proposal above sets the correct standard.

Like I said, follow the instructions in the template, install it and generate a project. I'm going to try and recod a few variations in the week for examples.