CSPROJ names, with the Game name or not?

[SimonDarksideJ]

It is a personal preference as to whether each project name should also contain the name of the game (even though it is also the solution name) or not, or whether "by default" it should just list the platform.

Either approach works and has no effect on the building or running of the title, it is just a matter of personal preference.

So, we are gathering feedback on how the "default" template should name the projects "out of the box"

[KelsamGames]

IMHO...

Semantically it makes no sense to omit the game name from the project. It quite literally is the project/build of that game, for that platform. Everything inherits/references this name as well, including the resulting built binaries that absolutely should be named something more descriptive than "DesktopGL.exe".

Furthermore, especially now even with just the ContentBuilder project, there are often sibling projects to just the actual game's projects that are not game builds. Dev tools and such. Keeping the game name in the projects serves to identify them as actual game builds and not just some other thing (like ContentBuilder, some dev tool, etc) that also happens to fall within the same solution.

[SimonDarksideJ]

The AssemblyName is what drives the "exe" name for the project. so DesktopGL.csproj, with an Assembly Name of "MyAwsomeGame" will generate "MyAwesomeGame.exe" in a bin folder for that platform.

Would love to learn more about your "Tools" discussion, can we setup a separate discussion on that to detail it more. I agree, with "Content" effectively being a tool now, that could spawn a discussion about "Solution" tools and how they should be organised.

[KelsamGames]

The AssemblyName is what drives the "exe" name for the project. so DesktopGL.csproj, with an Assembly Name of "MyAwsomeGame" will generate "MyAwesomeGame.exe" in a bin folder for that platform.

Ah, my mistake.

Would love to learn more about your "Tools" discussion, can we setup a separate discussion on that to detail it more. I agree, with "Content" effectively being a tool now, that could spawn a discussion about "Solution" tools and how they should be organised.

Sure, there's not much to tell though. Simply that in our projects we have "sibling" projects for various things. Like a project for rebuilding and copying assets to a specific build so the artist can iterate on things themselves. A tool for balancing audio levels. A tool for defining collision polygons. A tool for generating release builds for all platforms and doing specific stuff to the output. Things like that. That said, none of that needs to live in the same solution as the game. So again, just a personal taste thing.