Would Love More Directory Structure Examples

[GuyPaddock]

The current directory structure guidelines are on the right track, but painfully vague. I'd love a lot more examples in that section. For example, we aren't sure where best to put UI-related stuff in the folder structure prescribed. We're thinking likely Core/UI.

As another example, where should input actions go? We don't want to put them in a folder called Core/InputActions/ because section 2.6 indicates that you should not create folders specific to the type of an asset. I considered Core/Input/ so that all input-related content can go there (e.g., binding contexts, etc.) but I'd also expect that the input actions and binding contexts that go with a particular UI context would go with that context. So, perhaps, Core/UI/<Name of Screen> would be better?

[detilium]

I disagree with the proposal of placing user interface elements within the Core folder. As stated in section 2.5, this section should only be relevant to engineers, and non-engineers shouldn't have a reason to enter the folder:

"This creates a very clear "don't touch these" message for other team members. Non-engineers should have very little reason to enter the Core folder."

Considering the existing example project content structure, I propose a new subfolder within the GenericShooter project folder, simply called UserInterface. This would contain all assets types as defined in section 1.2.11. In my opinion, UI related functionality does not contain in any of the existing folders.

Example

|-- Content
    |-- GenericShooter
        |-- UserInterface

I have not thought about potential subfolders.

[detilium]

On second though, maybe the following structure would make sense:

|-- Content
    |-- GenericShooter
        |-- UserInterface
            |-- Fonts
            |-- HUD
            |-- Menus

[GuyPaddock]

I disagree with the proposal of placing user interface elements within the Core folder. As stated in section 2.5, this section should only be relevant to engineers, and non-engineers shouldn't have a reason to enter the folder:

I don't believe the narrow reading of the engineer vs. non-engineer distinction is useful or helpful in any way. The distinction should be over which team or people own the folder or sub-folder, not whether they're a game designer, "engineer", game developer, etc. If we are speaking strictly, engineers wouldn't be working in Blueprint, they'd be working in C++, so they wouldn't have anything in the Core folder and, based on the passage you cited, therefore there would be no need for a Core folder in the project at all.

Instead, I read the guideline more broadly: the "Core" folder as an indication that elements in that folder can be used by anyone on the project (which, incidentally, does require going into the folder), but should only be changed by people on the project who know that what they change will effect everything in the project because they are foundational. Given that I am working on a plugin project that provides foundational, base UI elements that are used throughout other projects that depend on the plugin, and that these elements are low-level, "core" UI functionality, I see no objection to UI being in this structure.

Really, what I'm looking for out of this spec is a fully fleshed out, thought out structure for what an organized project looks like. There are a loose assortment of guidelines here, but nothing cohesive. More examples--along with the thinking behind those examples--would be helpful. Fewer rules, more guidelines.

[GuyPaddock]

On second though, maybe the following structure would make sense:

|-- Content
    |-- GenericShooter
        |-- UserInterface
            |-- Fonts
            |-- HUD
            |-- Menus

This structure would seem to violate the sprit of section 2.6 that discourage you from organizing assets in folders based solely on their type. Specifically, you're organizing the fonts, HUD, and menus into their own separate folders instead of keeping assets that are referenced by one another together. No?