Thank you sooo much for this video I'm showing it rn to this shitty programmer I used to work with that was trying to force me to separate everything into types and even without knowing this I instinctively felt it was wrong and refused to do it. This just proves that my intuition was right because this is exactly how I wanted to organize my folders in the first place.
This is what I have started to do as well. Originally I followed what others did -- organizing by type -- but that didn't really make sense to me and I wanted modularity and scalability, so I began organizing my project structure by function. This makes the most sense to me. Thank you for the video explanation.
The "by type" structure has it's place. If you're working in a team, then it's likely that you are programming in /scripts folder, or artist in /models folder, etc. You can think of it as separation by the department. You'll likely have /scripts/camera/ folder, and it will be vastly different compared to the engine/camera/ folder. And /models/camera/ will be for camera (that an ingame reporter holds) assets that are totally unrelated to your camera scripts (that control viewport). And Martin C. has it wrong, as always. Did you actually see any plans for any building? They are separated by the industry. Separate plans for the brick and mortar construction, separate plans for wiring, separate plans for... for... for... . In the floor plan of my house, I CANNOT see all the things that are in say bathroom at once. It's not possible. I have to first pick, if I'll look at the tile laying diagram, or electricity diagram, or plumbing diagram, or heavy construction diagram, or lights diagram... The diagram, where I'd see at a glance, where the toilet is, where the lights are, where the outlets are, where the water goes, etc. at once, this kind of overview that he proposes? That one doesn't exist. The way he differentiates the church from the office? That happens AFTER he opened the project documentation and picked one of the many floor plans to compare. He effectively compares "models" folder of one game with the "models" folder of another one. He just skipped the first step in his presentation. That being said, I do use the proposed structure when possible/feasible. I like it and I prefer it for "solo" like projects. I'm with you on that.
Indeed, I have heard arguments about how working in a bigger team is more suitable to use the folder by type, a more familiar structure made simple, bigger projects can segment blocks of data to allow teams to work easily with data grouped in folders, aka by type for example, but I can also see how to solve this problem by creating a new management layer on top of your folders that would list the folders as we would need them, like listing by type, getting all scripts from a bunch of by function folders from assets of a project, You know a good example that could help your argument, the Godot engine itself is a big monster with thousands of contributions, and their source code structure is made of folders like data, script, modules, scenes, ak somewhat more close to by type, so bigger projects with bigger teams are indeed easily managed by type structure, I don't have a opinion formed about Martin, in that video he sparked this idea so I used as a basis example for the video, depeding on your point of view everything can change, but I stand for the objectivity of using folder grouped by function in Godot, and possibly other software with similar context. Treating the project data like assets, I think they are more efficient to operate that way, the best way to use the structure I propose is to mix them both based on the context of the project and it's data or team, and you can easily create something like folder groups that you can manage folders by function listed under a alias you choose. Talking about diagrams of a building, if you have a building project made in a engineer software, I am sure you can request a view of only the electricity, plumbing or only the structure, but that's not relevant, that was just a simple metaphor I used to show how useful the structure by type of folders could be. Lastly, given that the majority of Godot users are working in small teams or solo projects, I think that working in projects using folders by function is much more suited,
@@nanotechgamedev The big issue with the feature folder is when your model artist creates a new model. Where does he place it? Characters/shoes, props/shoes, accessories/shoes, attachments/shoes, shoes/model... ? And what if the shoes are props in store, but also accessories of character and also attachments for rear view mirror of a car? And his decision is now something that the rest of the team has to live with. If it's in Models/... no one has to care. He can have his own subfolder structure, that's fitting for his workflow. It's fine, he gets to rule that folder. Programmer doesn't have to care as long as he gets the resource url. And any and all systems can use that shoe without issues. Using type folders Is, in OOP sense, Composition over Inheritance, IMO. The previous paragraphs illustrate that issue pretty much verbatim. PS: the plans were just the example, because they are separated by that from the get-go. You cannot get the plans for "everything in kitchen" (feature folder equivalent), but you can get plans for "wires in whole building" (type folder equivalent). So, while it's a nice illustration, it's like looking at "models" from one project and comparing it to "models" from other project. And that will, actually, be somewhat illustrative of both projects. PPS: Over the years, I've started to dislike many Martin's takes, but you're right, that's of topic.
Thanks, it was developed at that stage in 3D and rendered in 2D using Godot 3.x on my journey of learning Godot, and it is sadly a legacy project now due to how much I improved since then, but I have plans for the story, design, workflow and assets, it isn't a abandoned project. The gameplay I want is real time strategy combat action with RPG elements in a futuristic world, very much similar to fallout original games but more leaning towards science fiction, heavily inspired towards a old game called "Cybermercs: The Soldiers of the 22nd Century", which I played a lot as a kid: th-cam.com/video/speuB4Owg-E/w-d-xo.html
You can organize your scripts in subfolders, though. You don't need to keep a million scripts in the base scripts folder. Also, having several "main" scripts will make your scripts list a little more confusing to look at when there's more than one of them open. Anyway, there are problems, though. The main reasons why I personally ditched any organization that lumps different file types together are: 1- Godot's icons are all the same color, so I have to squint in order to tell scripts apart from scenes and resources and not double-click the wrong thing when I want to open one of them. 2- having scenes and scripts all over the place makes it harder to mentally keep track of where they are, and/or may require you to do more going back and forth between folders in order to reopen scripts or scenes. It's also harder for someone else trying to follow your code in your repo, when scripts are all over the place. The same can apply to other things that you need frequent access to, like scenes or 3D models, or that other people might want to easily locate in your project, like textures or shaders (or anything else). The main project folder doesn't need to look complicated and cluttered. My projects usually just look like this: res addons assets (models, textures, etc) resources (themes, shaders, curves, collision shapes, etc, etc) scenes scripts Scenes and resource are actually assets too, but I like separating them from other assets (textures, sounds, models, etc), because they are engine-specific assets, and are also more frequently accessed. There are pros and cons to everything. But I personally do this because I've had more friction with other methods. One concern I have with organizing by function, is that it might require restructuring files as the project grows, as what things are may not be obvious in the beginning, or may change during development, and what you initially presume they are may turn out to be wrong. E.g., you might consider items entties, but then you change that later. Or you might be developing an app, and not a game, and nothing is really obvious to you.
Yea, the structure thing is and it feels very rigid and static for a by function folder system, you cannot go renaming things at random or at a later stage of the project decide to change them very easily, for me this works great in a project where you know how things should be, you can build the structure that the final stage of your project will need to have, but for prototypes this is a nightmare because every major decision you make you will spend time re-managing the structure and connecting them back, That's why a folder by type works great for prototyping, because it's a ambiguity box we can very easily manage, the rule it's simple, their type groups them. Then later you can group them in subfolders to provide a better logic, but I found that if you plan to make modular code, this starts to become a issue, because you will need the same structure to be used by different objects, and duplicating systems is hard to maintain, the scripts code starts to get duplicated by the scene assets, graphical resources or other type of objects, A by function folder however can be completely isolated from another container, and we can easily port them to other projects, the trade off is a more rigid structure to your folders and possibly more work managing it, since now they are organized in a more static way, and with more modular code you will need more objects that will connect objects, so this also is an issue, for someone that wants to use the folder by function, I would heavily advise to understand exactly what you want and expect for your project to work like, I agree, both have their pros and cos, I like the freedom that the folder by type gives but dislike how unorganized they become later, I also tried to organize with subfolders and some standard names but disliked the duplication of common structures for resources that was being used by a common object in a common way,
@@nanotechgamedev I have opened exceptions. For example, in a 3d racing prototype, I have all the cars organized by function. But this was meant as a temporary thing, really, just because while prototyping, I've been needing the ability to create a new car by just copy-pasting the folder and changing some stuff, so I could try out different ideas for car implementations. But I personally haven't felt much need to do that. It's been pretty rare. Recently I turned some custom camera scripts into a module, but then I also made it into an addon, which ofc bundles everything together. But I only did that because it came to a point where I was 100% sure I needed an easier way to have in multiple projects. It grew naturally into an addon over time (years), it wasn't premeditated. But yea, I mean, we all have different ways of doing things. I generally don't do much modular stuff. I did a flashlight for an FPS controller in a modular way, only because I wanted to test different FPS controller implementations while using the same flashlight, but I didn't feel any need to organize the files by function. At least not yet.
This was an interesting take but it also has some fundamental flaws. 1. It's built on the premise each object can be divided into a single function, but as your app grows more complicated and you start using coding practices like design patterns for reusable code, it can become unmaintainable. 2. Martin C explanation that you should tell what an app does by its folder layout can also be interpreted as NOT approaching it from a programmer's perspective. He says you don't need to know what the building is made up of as his analogy but that is from a layperson's point of view. If you are going into the code, you are looking to fix or extend it, as such, you are not a layperson but a BUILDER. A builder needs an overview of everything. 3. Different people work on a game, localising a folder using an object-based approach makes it harder for multiple people (especially non programmers) to work on the project. So lets give an example for each. 1. Say I have a 2 player game, with 2 characters but 1 controller input. Well then, you might create a folder for each character and one for the input. Now the character has an attack problem, you have to know that you shouldn't just check each character folder but also the input folder. However, what if you have used a finite state machine design pattern to program the attack - this state machine is also used for enemy attacks. As such you can't put it in the character folder as it is reused by both player and enemy so you probably made a core folder. Now when you are investigating the character's attack problem, you need to check Core, Character and Input folder which is not intuitive unless you know how the app was put together. But remember, this structure prevents you from knowing that, it tells what the app DOES not what it is made from! To use Martin C's analogy, you have been called into the church to repair the roof. You can see it's got a hole in it. But you don't know what you need to fix it as you don't know all the parts that made it. You don't have the material list, you just know the problem. But as alluded to above, because you don't know what it's made from, you can't just go to the "Roof" folder as the fix could be in the "Beam" (as in wooden beam) folder. And before you argue, the beam folder would also be in the Roof folder, beams could also be used in the floor and walls so may not be in the Roof folder hence the conundrum. 2. The above leads nicely to the main problem with this approach when you are going in to fix or extend the app, you can no longer see how it is put together, especially the code. So if there are interfaces, abstract classes, basically code which is designed to be reusable across multiple parts of the game, this layout can breakdown very quickly where it is difficult to decide where certain logic should go. 3. If you're an artist, you don't know where to put your art assets when you add them to the game following this approach - you have to search every folder looking to see if your asset has a dedicated folder. Same for musicians, VFX etc. If you're a new person to a team, you also don't know where to start to maintain your section. You have to scour the entire application because you never know if an object will have your role or not. Everyone has their own preference and if you're a one-man dev team who does everything, this may be a viable approach but pretty much all professional apps and multi-team game development follow the usual approach because it's tried and tested. This post isn't to say, don't ever do the above, it's bad, blah blah blah. It may well work for you, but just be aware that it comes with its own pitfalls.
I would do things differently, you can understand that a perfect structure will never exist for any project, specially for a game since it's a abstract thing with a lot of complexity parts and software code, The building analogy is very shallow and basic, so seeing how subjectivity can creep on it, I don't think it's important to discuss it in more detail trying to justify it or apply it to software coding which is completely different, so I am going to focus more on the logic and code side of things, For the character example I would do things differently, I would build a input player control module so the player can pass input commands to a character object, this character object is a different folder where it will have as subfolders the two different character as assets, the character object is the same for both, this is a OOP principle, if I want them to behave completely different, their behavior is a code asset I will isolate as script extensions not pre-built inside of their base character object, this can be done with what I call modules in other videos until Godot has officially traits, the finite state machine can be part of the character object with main functions, but I would split the thinking behaviors in a additional finite state machine to be a AI processing object, that can also control other object types not only characters, this is the way I like to work with a somewhat RPG objects problem, if I had a attack problem, it would be inside the character object code, AI Processing (NPC brains) Player (Input and Player Brain) Characters (Objects and Assets) > main.gdscript (Base character) > Human (Behaviors or assets) >> Human_main.gdscript (Main human base behavior) >> Bandit >> Josh >> Merchant > Turrets >> Turret_main.gdscript (Main turret base behavior) > Animals I am aware that isn't a one size fits all, and for everything that doesn't work we can try to have a workaround to support it, this for a folder system by type or by function, for every different project will need a different workflow to exist, every game company that decided to build their own game engine is completely different from another, no "standard" way can be defined for software programming aside from things like OOP or some other fundamental logic principle, And this is my current challenge with Godot programming, to know when and when not to abstract things, specially with a folder by function system where you will need "connector" objects like script interfaces extensions, with a folder by type system it is much more simple to do it because it provides ambiguity, so yea, there isn't a 100% solution, but I think that the idea of doing it by type can provide some interesting results, specially for smaller teams which are the main players for Godot current eco system,
In the Godot 4.3 videos, the main editor interface font is a ttf font called Jura-Bold, for the code in the script editor it is otf font called Spleen 2.1.0, using the spleen-16x32 version, the main font is size 20 and the code font size 22, default display scale of 1,
I came to a different project structure. Here's a problem - game end up with health and stats that needs to be in resources, based on character type/class. That needs to be iterated a lot, so it's better to keep them together. I have on top level - assets, autoload, scenes, scripts, resources. Each have their own hierarchy.
That is a great point I didn't thought about, the by type category lists provide a shortcut for fast access to specific files, although if you are constanly having to open resources files to edit attributes, you might want to come up for a system that allows you to edit a bunch of things easily, if you didn't watched I made a gamedata video series here on my channel using csv formats exported from a spreedsheat editor, Libreoffice Calc, macros included for the export,
I tried OOP approach long long ago, but eventually I hit the obstacle that i dont know how to deal with files that are commonly use. e.g. materials that use by multiple kinds of objects. e.g. component script that use by multiple kind of objects like movement or detect ..etc. how do you deal with those cases in your OOP project structure?
As they are organized by function, having a "common" folder can be better to manage, if multiple objects use it, they should be in a parent folder out of these objects, that is the challenge with this type of structure, the assesment of when they should be or not together, and how to connect them if it's the case, if you want to use modular code with this structure, it becomes a constant issue to expect,
i just recently reorganized my Godot project from the type way to the functionality way last month. it's so much better
Thank you sooo much for this video I'm showing it rn to this shitty programmer I used to work with that was trying to force me to separate everything into types and even without knowing this I instinctively felt it was wrong and refused to do it. This just proves that my intuition was right because this is exactly how I wanted to organize my folders in the first place.
This is what I have started to do as well. Originally I followed what others did -- organizing by type -- but that didn't really make sense to me and I wanted modularity and scalability, so I began organizing my project structure by function. This makes the most sense to me. Thank you for the video explanation.
It's funny that everybody does it, because it somewhat makes sense, but we never thought about why to do it like that,
The "by type" structure has it's place. If you're working in a team, then it's likely that you are programming in /scripts folder, or artist in /models folder, etc. You can think of it as separation by the department. You'll likely have /scripts/camera/ folder, and it will be vastly different compared to the engine/camera/ folder. And /models/camera/ will be for camera (that an ingame reporter holds) assets that are totally unrelated to your camera scripts (that control viewport).
And Martin C. has it wrong, as always. Did you actually see any plans for any building? They are separated by the industry. Separate plans for the brick and mortar construction, separate plans for wiring, separate plans for... for... for... .
In the floor plan of my house, I CANNOT see all the things that are in say bathroom at once. It's not possible. I have to first pick, if I'll look at the tile laying diagram, or electricity diagram, or plumbing diagram, or heavy construction diagram, or lights diagram...
The diagram, where I'd see at a glance, where the toilet is, where the lights are, where the outlets are, where the water goes, etc. at once, this kind of overview that he proposes? That one doesn't exist.
The way he differentiates the church from the office? That happens AFTER he opened the project documentation and picked one of the many floor plans to compare. He effectively compares "models" folder of one game with the "models" folder of another one. He just skipped the first step in his presentation.
That being said, I do use the proposed structure when possible/feasible. I like it and I prefer it for "solo" like projects. I'm with you on that.
Indeed, I have heard arguments about how working in a bigger team is more suitable to use the folder by type, a more familiar structure made simple, bigger projects can segment blocks of data to allow teams to work easily with data grouped in folders, aka by type for example, but I can also see how to solve this problem by creating a new management layer on top of your folders that would list the folders as we would need them, like listing by type, getting all scripts from a bunch of by function folders from assets of a project,
You know a good example that could help your argument, the Godot engine itself is a big monster with thousands of contributions, and their source code structure is made of folders like data, script, modules, scenes, ak somewhat more close to by type, so bigger projects with bigger teams are indeed easily managed by type structure,
I don't have a opinion formed about Martin, in that video he sparked this idea so I used as a basis example for the video, depeding on your point of view everything can change, but I stand for the objectivity of using folder grouped by function in Godot, and possibly other software with similar context. Treating the project data like assets, I think they are more efficient to operate that way, the best way to use the structure I propose is to mix them both based on the context of the project and it's data or team, and you can easily create something like folder groups that you can manage folders by function listed under a alias you choose.
Talking about diagrams of a building, if you have a building project made in a engineer software, I am sure you can request a view of only the electricity, plumbing or only the structure, but that's not relevant, that was just a simple metaphor I used to show how useful the structure by type of folders could be. Lastly, given that the majority of Godot users are working in small teams or solo projects, I think that working in projects using folders by function is much more suited,
@@nanotechgamedev
The big issue with the feature folder is when your model artist creates a new model. Where does he place it? Characters/shoes, props/shoes, accessories/shoes, attachments/shoes, shoes/model... ? And what if the shoes are props in store, but also accessories of character and also attachments for rear view mirror of a car?
And his decision is now something that the rest of the team has to live with.
If it's in Models/... no one has to care. He can have his own subfolder structure, that's fitting for his workflow. It's fine, he gets to rule that folder. Programmer doesn't have to care as long as he gets the resource url. And any and all systems can use that shoe without issues.
Using type folders Is, in OOP sense, Composition over Inheritance, IMO. The previous paragraphs illustrate that issue pretty much verbatim.
PS: the plans were just the example, because they are separated by that from the get-go. You cannot get the plans for "everything in kitchen" (feature folder equivalent), but you can get plans for "wires in whole building" (type folder equivalent). So, while it's a nice illustration, it's like looking at "models" from one project and comparing it to "models" from other project. And that will, actually, be somewhat illustrative of both projects.
PPS: Over the years, I've started to dislike many Martin's takes, but you're right, that's of topic.
your Voltzen game looks really cool
Thanks, it was developed at that stage in 3D and rendered in 2D using Godot 3.x on my journey of learning Godot, and it is sadly a legacy project now due to how much I improved since then, but I have plans for the story, design, workflow and assets, it isn't a abandoned project. The gameplay I want is real time strategy combat action with RPG elements in a futuristic world, very much similar to fallout original games but more leaning towards science fiction, heavily inspired towards a old game called "Cybermercs: The Soldiers of the 22nd Century", which I played a lot as a kid: th-cam.com/video/speuB4Owg-E/w-d-xo.html
I really like your videos! Love the RTS guide too!
You can organize your scripts in subfolders, though. You don't need to keep a million scripts in the base scripts folder. Also, having several "main" scripts will make your scripts list a little more confusing to look at when there's more than one of them open.
Anyway, there are problems, though. The main reasons why I personally ditched any organization that lumps different file types together are:
1- Godot's icons are all the same color, so I have to squint in order to tell scripts apart from scenes and resources and not double-click the wrong thing when I want to open one of them.
2- having scenes and scripts all over the place makes it harder to mentally keep track of where they are, and/or may require you to do more going back and forth between folders in order to reopen scripts or scenes.
It's also harder for someone else trying to follow your code in your repo, when scripts are all over the place. The same can apply to other things that you need frequent access to, like scenes or 3D models, or that other people might want to easily locate in your project, like textures or shaders (or anything else).
The main project folder doesn't need to look complicated and cluttered. My projects usually just look like this:
res
addons
assets (models, textures, etc)
resources (themes, shaders, curves, collision shapes, etc, etc)
scenes
scripts
Scenes and resource are actually assets too, but I like separating them from other assets (textures, sounds, models, etc), because they are engine-specific assets, and are also more frequently accessed.
There are pros and cons to everything. But I personally do this because I've had more friction with other methods.
One concern I have with organizing by function, is that it might require restructuring files as the project grows, as what things are may not be obvious in the beginning, or may change during development, and what you initially presume they are may turn out to be wrong. E.g., you might consider items entties, but then you change that later. Or you might be developing an app, and not a game, and nothing is really obvious to you.
Yea, the structure thing is and it feels very rigid and static for a by function folder system, you cannot go renaming things at random or at a later stage of the project decide to change them very easily, for me this works great in a project where you know how things should be, you can build the structure that the final stage of your project will need to have, but for prototypes this is a nightmare because every major decision you make you will spend time re-managing the structure and connecting them back,
That's why a folder by type works great for prototyping, because it's a ambiguity box we can very easily manage, the rule it's simple, their type groups them. Then later you can group them in subfolders to provide a better logic, but I found that if you plan to make modular code, this starts to become a issue, because you will need the same structure to be used by different objects, and duplicating systems is hard to maintain, the scripts code starts to get duplicated by the scene assets, graphical resources or other type of objects,
A by function folder however can be completely isolated from another container, and we can easily port them to other projects, the trade off is a more rigid structure to your folders and possibly more work managing it, since now they are organized in a more static way, and with more modular code you will need more objects that will connect objects, so this also is an issue, for someone that wants to use the folder by function, I would heavily advise to understand exactly what you want and expect for your project to work like,
I agree, both have their pros and cos, I like the freedom that the folder by type gives but dislike how unorganized they become later, I also tried to organize with subfolders and some standard names but disliked the duplication of common structures for resources that was being used by a common object in a common way,
@@nanotechgamedev I have opened exceptions. For example, in a 3d racing prototype, I have all the cars organized by function. But this was meant as a temporary thing, really, just because while prototyping, I've been needing the ability to create a new car by just copy-pasting the folder and changing some stuff, so I could try out different ideas for car implementations.
But I personally haven't felt much need to do that. It's been pretty rare.
Recently I turned some custom camera scripts into a module, but then I also made it into an addon, which ofc bundles everything together. But I only did that because it came to a point where I was 100% sure I needed an easier way to have in multiple projects. It grew naturally into an addon over time (years), it wasn't premeditated.
But yea, I mean, we all have different ways of doing things. I generally don't do much modular stuff. I did a flashlight for an FPS controller in a modular way, only because I wanted to test different FPS controller implementations while using the same flashlight, but I didn't feel any need to organize the files by function. At least not yet.
This was an interesting take but it also has some fundamental flaws.
1. It's built on the premise each object can be divided into a single function, but as your app grows more complicated and you start using coding practices like design patterns for reusable code, it can become unmaintainable.
2. Martin C explanation that you should tell what an app does by its folder layout can also be interpreted as NOT approaching it from a programmer's perspective. He says you don't need to know what the building is made up of as his analogy but that is from a layperson's point of view. If you are going into the code, you are looking to fix or extend it, as such, you are not a layperson but a BUILDER. A builder needs an overview of everything.
3. Different people work on a game, localising a folder using an object-based approach makes it harder for multiple people (especially non programmers) to work on the project.
So lets give an example for each.
1. Say I have a 2 player game, with 2 characters but 1 controller input. Well then, you might create a folder for each character and one for the input. Now the character has an attack problem, you have to know that you shouldn't just check each character folder but also the input folder. However, what if you have used a finite state machine design pattern to program the attack - this state machine is also used for enemy attacks. As such you can't put it in the character folder as it is reused by both player and enemy so you probably made a core folder. Now when you are investigating the character's attack problem, you need to check Core, Character and Input folder which is not intuitive unless you know how the app was put together. But remember, this structure prevents you from knowing that, it tells what the app DOES not what it is made from!
To use Martin C's analogy, you have been called into the church to repair the roof. You can see it's got a hole in it. But you don't know what you need to fix it as you don't know all the parts that made it. You don't have the material list, you just know the problem. But as alluded to above, because you don't know what it's made from, you can't just go to the "Roof" folder as the fix could be in the "Beam" (as in wooden beam) folder. And before you argue, the beam folder would also be in the Roof folder, beams could also be used in the floor and walls so may not be in the Roof folder hence the conundrum.
2. The above leads nicely to the main problem with this approach when you are going in to fix or extend the app, you can no longer see how it is put together, especially the code. So if there are interfaces, abstract classes, basically code which is designed to be reusable across multiple parts of the game, this layout can breakdown very quickly where it is difficult to decide where certain logic should go.
3. If you're an artist, you don't know where to put your art assets when you add them to the game following this approach - you have to search every folder looking to see if your asset has a dedicated folder. Same for musicians, VFX etc. If you're a new person to a team, you also don't know where to start to maintain your section. You have to scour the entire application because you never know if an object will have your role or not.
Everyone has their own preference and if you're a one-man dev team who does everything, this may be a viable approach but pretty much all professional apps and multi-team game development follow the usual approach because it's tried and tested. This post isn't to say, don't ever do the above, it's bad, blah blah blah. It may well work for you, but just be aware that it comes with its own pitfalls.
I would do things differently, you can understand that a perfect structure will never exist for any project, specially for a game since it's a abstract thing with a lot of complexity parts and software code,
The building analogy is very shallow and basic, so seeing how subjectivity can creep on it, I don't think it's important to discuss it in more detail trying to justify it or apply it to software coding which is completely different, so I am going to focus more on the logic and code side of things,
For the character example I would do things differently, I would build a input player control module so the player can pass input commands to a character object, this character object is a different folder where it will have as subfolders the two different character as assets, the character object is the same for both, this is a OOP principle, if I want them to behave completely different, their behavior is a code asset I will isolate as script extensions not pre-built inside of their base character object, this can be done with what I call modules in other videos until Godot has officially traits, the finite state machine can be part of the character object with main functions, but I would split the thinking behaviors in a additional finite state machine to be a AI processing object, that can also control other object types not only characters, this is the way I like to work with a somewhat RPG objects problem, if I had a attack problem, it would be inside the character object code,
AI Processing (NPC brains)
Player (Input and Player Brain)
Characters (Objects and Assets)
> main.gdscript (Base character)
> Human (Behaviors or assets)
>> Human_main.gdscript (Main human base behavior)
>> Bandit
>> Josh
>> Merchant
> Turrets
>> Turret_main.gdscript (Main turret base behavior)
> Animals
I am aware that isn't a one size fits all, and for everything that doesn't work we can try to have a workaround to support it, this for a folder system by type or by function, for every different project will need a different workflow to exist, every game company that decided to build their own game engine is completely different from another, no "standard" way can be defined for software programming aside from things like OOP or some other fundamental logic principle,
And this is my current challenge with Godot programming, to know when and when not to abstract things, specially with a folder by function system where you will need "connector" objects like script interfaces extensions, with a folder by type system it is much more simple to do it because it provides ambiguity, so yea, there isn't a 100% solution, but I think that the idea of doing it by type can provide some interesting results, specially for smaller teams which are the main players for Godot current eco system,
Hey, what software did you use for making the demo?
For the diagrams that is Draw.io, for the video editing that is Kdenlive,
That editor font really stood out to me. Which one is it??
In the Godot 4.3 videos, the main editor interface font is a ttf font called Jura-Bold, for the code in the script editor it is otf font called Spleen 2.1.0, using the spleen-16x32 version, the main font is size 20 and the code font size 22, default display scale of 1,
I came to a different project structure.
Here's a problem - game end up with health and stats that needs to be in resources, based on character type/class. That needs to be iterated a lot, so it's better to keep them together.
I have on top level - assets, autoload, scenes, scripts, resources. Each have their own hierarchy.
That is a great point I didn't thought about, the by type category lists provide a shortcut for fast access to specific files, although if you are constanly having to open resources files to edit attributes, you might want to come up for a system that allows you to edit a bunch of things easily, if you didn't watched I made a gamedata video series here on my channel using csv formats exported from a spreedsheat editor, Libreoffice Calc, macros included for the export,
I tried OOP approach long long ago, but eventually I hit the obstacle that i dont know how to deal with files that are commonly use.
e.g. materials that use by multiple kinds of objects.
e.g. component script that use by multiple kind of objects like movement or detect ..etc.
how do you deal with those cases in your OOP project structure?
probably by use "common" folders? like, if a material is shared by some/all guns, then make a common folder in the guns' parent folder, etc.
As they are organized by function, having a "common" folder can be better to manage, if multiple objects use it, they should be in a parent folder out of these objects, that is the challenge with this type of structure, the assesment of when they should be or not together, and how to connect them if it's the case, if you want to use modular code with this structure, it becomes a constant issue to expect,
What app are you using to draw the structure
Draw.io for the diagrams and Kdenlive to edit the videos,
This.
YOUR folders suck. Mine are perfectly okay. Also, not going to listen to someone who writes "folders [multiple] suckS"