I love your tutorial style, I whould really love to hear your insghts into signals, inheritance, etc... Godot is modular by design but it's rare to find tutorials that focus on the "glue" instead of the pieces, and I will argue that it's the most important thing to grasp at the start.
This is one of the most helpful videos on godot I've ever seen yet, probably even beyond Godot, and the fact that it's less than 10 minutes makes it even better. Thank yoU!
theres a 3rd option that works well with a large team: assets/ for binaries like sprites, models, which is hierarchal src/ for text (scenes, scripts, etc) which is modular this allows the programmers to worry about sorting their files in an object oriented way, and the artists can just dump all their foliage textures in assets/textures/foliage (never go more than 3 folders deep)
If you're emphasizing a scalable approach, it would be a good idea to show a large project. I would argue that feature folders are always more scalable than trying to fit everything into assets/scripts/etc. It's easier to think about things grouped together and easier to see when too much is shared in a project. Spaghetti between sub-features isn't as big of a deal as an out-of-control project.
yes. one of my first Godot projects used the assets/scripts/scenes structure, and it became really confusing really fast. i never want to touch that project ever again. now i use only the feature-based structure.
I find the hierarchical system difficult to modify if you want to work on different components of an object at the same time. It is also much more difficult to reuse in other projects. I prefer to use a hierarchical modular system, for example: modules/ characters/ player/ enemies/ npcs/ shared/ This way, if you want to take the player to another project, you only have to take the player and shared folder.
I too like to keep my assets within the same folder as their object's scene and scripts. But most tutorials recommend them in a top-level "asset" folder. Glad to know I wasn't doing it "wrong".
Hierarchical structure can be useful if you're working with a decently large dev team, so artist only mess with the assets folder, developers with scenes and scripts, musicians/sound designers with sound and so on and so for. But for a solo dev doing small projects modular is the way to go in my opinion, it depends on what allows you to organize better what you're working on easily
This is a topic that i don't see enough of, im currently making a complex management game and the hardest part is definitely organisation. Would love to see a video on how to keep scripts organised too!
Hey Andrew hello again! I think the voice audio in this video is still a bit low but much better than before, you definitely improved that. Useful tips, waiting for more Godot videos!
i like keeping my scenes and their scripts together while every asset (such as style, textures, sprites, sfx) in the separate asset folder. if my character uses components (like walking, talking, interactive, combat), i have a separate components folder. Many different actors can make use of several components that are shared. assets/ custom_ressource style images audio content/ actors components stages systems I'll be using this structure until it no longer works but so far it's all cool (especially in cases where many actors share common resources). And in case of inheritance, i also keep children together with their parent and make it apparent with a proper naming system
well made! I have used the second method for a project before, but never really considered the modular method. Just starting a new game and I think ill give the modular method a shot as that seems easier to understand for solo dev. piecing and parting out later on or even testing in new projects sound much easier this way
i think where is also better way - grouping by components, for example. player has criteria to be a player, he has input controller, movement behavior, and firing behavior, movenent and firing| has a lot of creatures and could be shared, npcs could have different input (ai input instead of user input), and could only walk, enemy could have enemy ai input, and could walk and fire, so it look really modular, also you might group files in "bundles" a set of external plug and play asssets, like bundle for fps, bundle for rpg and so on which could contain solid, tested, modules to warm up development
It is worth mentioning that you don't have to type out the folder in the script window. You can just drag the item from the file system window into the script window. You know...for all those people out there who value their time, and aren't masochists.
In my opinion, stick with the modular structure, if you have an NPC and a Player that both use the same assets or other resource, create an actors folder have shared resources in there and then have modular folders for player and NPC that contain only the things that they need. Another alternative is to just duplicate the assets/resources so you have a 1:1 relationship between module and asset. To some, this seems bad but it does allow you to easily update in the future if you decide to change one of the assets for one of the modules. Duplication is not always the enemy and is often not truly duplication.
I keep assets separate like this but I put scripts and scenes together. These always seem to be 1:1 so I'm not sure what benefit there is in having scripts in an entirely separate folder hierarchy. Surely it would be tedious creating a duplicate hierarchy for scripts when Godot defaults to putting them in the same directory. This also helps when reattaching a script to a scene.
Yeah, there's no need to be so rigid. I like having a core folder for mechanics (base classes, custom resource structures, etc), an assets folder for reusable stuff (skill scripts extending the base one in core, entity scenes, maps...), and a content folder for one-off stuff which bring everything together (missions, dialogue, etc.) aka the actual game
If you have scripts used by several scenes could be good having a shared folder for them, but yeah for scripts that are only for a single scene like player movement i think is better just let them together with their respective scenes
Hmmm... I just started using Godot last week and this is one of the first problems I can see coming after the usual "how do I" newb stuff... I can't say your video convinced me much 😅 but please correct me if I'm missing something: in addition to the classic hierarchy vs composition problem that can't really be solved without proper component support in the language/engine (yes, I'm a big fan of the ECS approach) in Godot we also have the find nodes from different scenes problem. I'm trying to see how much work would it take to create a dungeon crawler game a friend of mine was making (in GameMaker 😱) when his programmer ran away: up to now Godot was fantastic, with a *lot* of high quality and very useful "nodes" that allowed me to put together a very simple prototype in hours, however I need a split user interface with a 3D area, a minimap, character body, inventory, message area (half the game uses a visual novel approach) and organizing cameras, viewports, their references (as Remote reference or getting nodes in GDScript) make me think this problem doesn't have a good solution, only "less wrong" ones... What are your thoughts and those of the community about this? 😀
Create an entities structure and then player and NPCs can both inherit from entitites. TADA! This is the exact reason that Data Structures and Algorithms is still a course in a comp sci degree. Data structure matters.
Good tutorial. I would say an easy way around cross modular references though, is to follow the single responsibility principle with your assets. The downside is that you bloat the project with copies of the same assets, but I could also see myself changing, for example, the NPC sprites as my development progresses. This way, you can make changes independently. I like the idea of modules like this. This way you can make player controllers and easily reuse them in future projects. 👌
This is part of essential development, naming should be a conscious decision in everything you do as a programmer. It is far too easy to take shortcuts when giving something a name and scope. The classic example is 'var x = 1' this is a big mistake and if you get into this habit your game/program will quickly become unmaintainable. There is no such thing a shortcut here if you don't decide what your doing before you create x or define 1 you have already failed. A more creative approach would be 'var playerPositionX = input.x' there is no use of magic numbers or strange temporary variable even if they are local scope. This helps for self documentation. Simply said decide the scope then decide the name before typing a single character. Also avoid acronyms like pPosX this might make sense to you but your co-worker may not immediately known what 'p' or even 'Pos' means. The code should read like a well form sentence. Consider grammar when naming like verb, adverb, adjective noun eg makePlayerCharacterRunFastLeft(). Sometimes you will use set or get as verbs. The second tip is scaffold your code by starting with a bunch of comments describing what you intend to do. Eg '// I need to set player x and y position based on user input from controller, i may need to consider position from keyboard or mouse' by writing this before writing the code you have to think critically about the problem before starting the code. Another hint, is planning even a little bit of planning at the start of the project goes along way like this video discusses choosing how the ten's of thousands of resources are stored at the start saves massive amounts of refactoring at the end. I usually start any project of scale larger than a proof of concept with a design brief. This describes a brief outline in a form of specification then detailed description of each specification and risk mitigation such as im not sure i can use feature x on mobile among other things. One good tool for this is to use markdown and programs like Obsidian. This way your documents are easily readable and searchable by your IDE in the case of Godot and viewable by anyone with a text editor. Naming as discussed in this video does not stop at the variable but continues to the function the class the file the resource this needs to be a conscious and intentional choose. I like using camel casing for variables and functions and caps casing for files and types including classes. All caps for constants with underscore to separate words. This method allows quick searching in many editors for example PlayerCharacterClass can be searched using PCC if the IDE supports it. It should almost be possible to search your entire game by logic alone. Also you must always use version control this is a given in this day but GIT is essential. Don't comment out old code delete it if you commit and manage code in a VCS you can always find the old code and restore it but if your search finds commented out code it will increase your cognitive load.
"search finds commented out code it will increase your cognitive load". so first you make good readable code then you comment it out. Then you restructure it to use reusable functions in a less readable way. Then you replace the workings of those functions with optimize code that uses harder to read things like bit-wise, pointers, and other tricks that you have to get in a mind set to read. like ##if a>=b: ## return a ##else: ## return b return a ^ ((a ^ b) & -(a < b)) I think having the old branching commented out code makes the line more understandable, I would much rather have something with too many commented junk then something with too few. if it bugs you, you could just make something to remove those lines from a file and replace them with a ##CommentedLines152to163 that way you can put them back in the right place after you are done. make tools to help your self.
@@Amipotsophspond Hi I'm not sure i understand what you mean, but commented-out code is prone to errors. For example, you comment out some old code and make changes in the new code but the comment out code does not get updated later you decide to restore the code but any fixes or changes you may along the way, is vary likely to break the old code. This makes the old code redundant along with this reason and the comment above there is no need to keep old code. As for optimizations, naming has zero impact as the compiled code will be using pointers and memory addresses not names. The problem is alot of programmers are taught to take shortcuts, like x and y this shows how bad the education out there is. As there is never shortcuts in programming nothing is free, and assumptions cause bugs.
Thanks ! After fiddling with the design I often find my self with a lot of assets in the folders that are not used in the actual game. Is there a good way to identify that assets ?
You have a good "youtubable" face so maybe take a bunch of photos and have a folder ready for thumbnails if you'll put your face on the thumb. Just so they're not all the same lol
