6 Tips to Better Organize your Godot Projects

In this Godot tutorial you'll learn simple tips to organize your game projects and create self documenting scenes.
----
Godot 3 course: gdquest.mavenseed.com/courses
Tips:
00:25 Use the scene structure to describe functionality
04:55 Write short and descriptive names
05:28 Your folder hierarchy is part of your project's code architecture
06:39 Use the built-in tools to refactor your structure (move to and rename)
07:57 Nodes are chunks of behavior, resources are your data
10:25 Naming tips for files
This video is supported by:
- Gamblify: www.gamblify.com/
- Pineapple Works: pineapple.works/
- Echo86: www.echo86.com/
Subscribe for more tutorials! kzbin.info?sub_con...
Twitter ► / nathangdquest
Instagram ► / nathan_gdquest
This video is licensed under the CC-By 4.0 license: creativecommons.org/licenses/...
You can attribute it to "GDQuest and contributors - www.gdquest.com/"

[@Gdquest]

Also use built-in nodes whenever possible. Because: 1. They save you development time, especially when prototyping 2. All Godot users rely on them so they're often well-tested, mostly bug-free 3. They come with nice icons that make your project easier to read (e.g. Camera2D has a camera icon) 4. They're written in C++ so they'll run fast And building upon the video you can see a lot of these structure notes are about clarity and simplicity. The video doesn't show that in practice there's a lot of refactoring involved: that's the process of reordering your files, your scenes, and your code to improve the project's architecture. Do you have any extra questions? Suggestions? Please leave a comment!

[@shinpachithestraight8781]

Hi! Just wondering if there is a complete GDScript list available in PDF format?

[@ferdc2916]

Hi, thanks for the tips. Do you have a more in-depth tutorial about this, with an especific game (shmup, platformer, etc)? I would like to know how to set up every element, and how you import / instance scenes in other scenes. It would be great if the game has more than one level, main menu and pause menu, so I could understand how to change beetwen them. Maybe I'm asking too much, but all tutorials have just one level, and the explanations don't go beyond main character, a couple of platforms, enemies and dying. Thanks for Godot!

[@isaac8228]

I have a folder I called "assets" where I store all .png and texture files and a "src" where I store all scene files. Is this okay or should I change it? Thank you in advance :)

[@SpellMenderDev]

replying bc yt algo. want more of your content to show up on my yt page. thanks for making these tutorials!

[@ShadeKirby500]

This is a tutorial I needed! I often get really confused about how to set-up folder / scene structures, it helps to know all this.

[@FunCubing3x3]

The graphic comparing Declarative to Imperative programming was really instructive. I have been trying to get a clear understanding of the difference for a while now. Finally I get it.

[@connorhillen]

Really appreciate these more engineering driven tips! One of the biggest problems I had going into Godot 2 was that the limited community made it difficult to follow any kind of standard practice. I'd love to see standards built from all of these tutorials as Godot grows and begins getting used by more teams. Great video!

[@Gdquest]

It's hard to figure out general best practices as each project may be completely different. But I've been studying this a lot more lately and started seeing that a lot of designers and developers (including myself) focus on adding features, content, and have brittle code organization. There's a lot of design work and experience/trial and error involved in coming up with scalable, flexible abstractions for your game. The tips in this tutorial are concrete. They're here to help you better organize your game. But the exact way you'll do this depends on you and on your needs. Here's one among an infinite amount of design problems. Should I have a base Character and inherit from it to create a Fighter, a Wizard, etc.? It's sensible to think that Zorn the Wizard IS a Wizard and a Character in English. In this case Zorn would extend Wizard that already extends Character. 3 levels of inheritance. It can work. In Godot, each scene would build upon its parent. You can also say that Zorn is a Character and he has a job: Wizard. You can encapsulate the job in a separate, self-contained scene, have it manage the skills and properties of a Wizard. Say you have Monsters that are not Characters, but you want to design a Wizard Goblin. Then you're glad you had these Job objects you can plug into anything. The first example is thinking of code a bit in a human way, using natural language. In general you want to think about game objects as little machines that solve specific, byte-sized problems, that you can connect and aggregate together to solve more complex and higher-level problems, like making a good game. Why talk about all this? Both solutions are valid and lead to 2 different folder, scene, and script structures. character/ |-- Character.tscn |-- character.gd |-- wizard/ |---- Wizard.tscn |---- wizard.gd |---- zorn/ |------ zorn.tscn |------ zorn.gd |------ sprites Or character/ |-- Character.tscn |-- character.gd |---- zorn/ |------ zorn.tscn |------ zorn.gd |------ sprites jobs/ |-- Job.tscn |-- job.gd |-- wizard/ |---- Wizard.tscn |---- wizard.gd

[@connorhillen]

Definitely good points! I've been TA'ing/teaching some early level game development and software engineering and we regularly hear students asking for the *right* way to structure their code and their projects, and tend to get frustrated when we can't give them a straight answer. It really depends on the game and the team, and in the end is really just about being consistent and using what patterns you can to maintain that consistency. It's good to see some concrete patterns being shown so that new entrants to Godot and to game programming in general have some kind of toolkit. Usually I refer people to _Game Programming Patterns_ , as it's an excellent free book on software design patterns, but it can go over people's heads when they try to think like that at a higher level. I really appreciate the great work! The comparison between the scene tree, project structure, and traditional OOP certainly helped myself and I'm sure it will be really helpful for other newbies trying to get their bearings. A great video as always :)

[@sosasees]

Thanks very much for suggesting the scene-category-based project structure (characters, debug, monsters). I already suffered a little bit of the consequences of an asset-type-based folder structure (scenes, scripts, sprites) in my small prototypes, since I'd much more often have to switch between assets related to the same scene instead of the same asset type (I didn't really notice it until I watched this video), and it already was a little bit painful (but I didn't truly notice this either until I watched this video) even though my latest prototype was finished in just 2 levels. I was watching this right as I am transitioning into making my next prototype. Thanks very much for curing a pain I didn't really know I had before.

[@TheChexmo]

Is there any continuation of this topic? Most tutorials focus in "do this to achieve that" and forget about the fact that producing games is actually producing software, and software development need of these kind of knowledge that improves your projects from its structure and even its architecture.

[@Lmfaocj]

I was stuck on something else completely. And saw this on my recommended and it helped me with figuring out what I was stuck on and helped me learn good practices that I can use for readability. Thank you very much for the video.

[@darkwave22]

The church of Emacs sends its blessings.

[@Gdquest]

Ahoy!

[@auxencefromont1989]

The apostasy of vim sends its malediction

[@eli1882]

Neovim > Emacs

[@AFE-GmdG]

One VS-Code to rule them all

[@willnationsdev]

9:29 I might be wrong, but I'm pretty sure you can also click on the "Current Animation" line in the AnimationPlayer's Inspector to open up whatever Animation you have been working on. And then from there, you can click Save As...to save the animation as a .tres. That way, if you forget setup your own animation at the beginning, you don't have to re-implement anything.

[@valterbushido3468]

Nah, that guy made tons of crappy videos without any depth of understanding what he was suggesting to people. That "reuse" he was speaking later is also "huuuge".... mistake :)

[@ralacerda12]

Great video! I like to write everything since I can add comments to script but not to nodes in a scene, but in the end what I think is important is consistency, if you change the scale of one sprite from the editor, don't change the scale of another one using script, really easy to later on forget where you changed which. Do you like using emacs to edit scripts or is the godot editor good enough for you?

[@Gdquest]

Consistency is good, setting some rules for yourself. I definitely agree with that. Then, good code should be mostly self-documenting. I'd say doing everything your can from the interface has some advantages: 1. If you connect two objects with a signal, an icon appears 2. If you override a value, an icon appears 3. If you override a value on an inherited scene, you can see it as well 4. It makes for a simple to follow -> all the initial values of my objects' properties, all their base state is handled in the editor, while all the changes in state at runtime are hidden in the code, be it Godot's C++ sources (e.g. AnimationPlayer updating an animation every frame) or game mechanics in GDscript. I use Godot's editor because it's tightly integrated. If there was a complete emacs package/spacemacs layer for Godot 3 I'd probably use this outside of tutorials.

[@TitlePending]

This is perfect as my team has been debating about the best way to set up files for Ludum Dare 41

[@ghostlack]

Oldie, but goodie. Nice tips!

[@unfa00]

This is very helpful. I see a big need for refactoring my projects as they grow - it's really hard to have a good idea how to structure the directory tree for all scripts and resources when you don't have much experience, so being able to fix that later is very important. I wouldn't be happy be be haunted by my rookie mistakes 2 years in the future, because I couldn't fix my folder structure later. It'd also scare me to start any project at all. Thanks fully Godot allows this and gives us tools to do this. I'd love to see more videos form you about managing assets and files on disk - you seem to have a lot of experience working on big projects in Godot, so I'd love to see what is your decision process to organize things the way you do and some ideas you have on that. Thank you for great videos - I'm learning a ton from you, and Godot is a fantastic tool for game makers big and small.

[@Gdquest]

Thanks! I actually don't have any experience working with large projects in Godot ^^. I have just been working as a designer for a few years. The asset structure is meant to represent the projects architecture: if there are actors, or characters, databases, levels, etc. I treat the filesystem like the scenes: if the actors can have an inventory, or put the inventory folder and all related assets inside the actors folder. as I'm working, if I feel like I want or I need to reuse any resource or branch of a scene, I will save it in the file system and try to place it the best I can. But you often end up moving things around to keep the project clean as it scales. A lot of it comes from object-oriented programming: I try to follow the single responsibility principle to keep script shorts, and make sure that if I have to change a mechanic or how a given system works, it is easy to find the node and script I need to edit.

[@11clocky]

I understand grouping scenes with scripts, because they represent different halves of objects in your game (declarative and imperative). But I prefer to keep resources in their own separate folders (fonts, sprites, etc.). The reason for this is because I very often have different objects that share resources, especially fonts.

[@Gdquest]

I mix and match these myself. Anyway as the project grows you can move things around, Godot fixes dependencies for you

[@arthurbourdot8765]

Very usefull advices, thank you !

[@LohkYcarh]

Great explanations! I would be very interested to learn some of your tips about Dev Architecture and your best practices concerning the design patterns usages in Godot.

[@Gdquest]

Design patterns are tools you don't want to use if possible. Godot has built-in features so you don't need the observer, Singleton, and a few optimization patterns handled by the engine on the backend. I've mostly used the state machine and command with it. Ah it does have some tools so you don't need the command pattern e.g. for input

[@LohkYcarh]

@@Gdquest I would be very interested to know which way you use to provide generic components having overridable behaviors. I do not speak of inheritance, to prefer an aggregation way. I have read a few about the autoload, to provide dependency injection. My interrogations about patterns would concern the guidestyle to write clean and efficient source code with godot. Maybe I should speak of that on a specific dedicated discord, like yours by example.

[@VitoChiarellaNibodhika]

Great video, but if you don't mind me asking, could you share your emacs configuration? I loved the powerline setup and the way the checkboxes look on org-mode.

[@Gdquest]

It's all from spacemacs: spacemacs.org/

[@scribblingjoe]

What about Image data? Do resource files store image or sound data, or do they refer to the data wherever it may be stored?

[@gendalfgray7889]

How structure will change if player and monster can use an item that have separate script for it behaviour?

[@efed7129]

How do you do the range of that object? Which node do you use?

[@jaysanprogramming6818]

Based on their icon, I assume he used simple Node2D nodes probably with simple draw functions. Look at the documentation under Custom drawing in 2D.

[@galacticquasar9944]

Hey! I tried moving my script to a different folder to better organise my files, but it can't find the script and now it doesn't work

[@SpellMenderDev]

i like bacon and godot and other things as well but this is by far the godot tutorial. this comment might seem like nonsense, because my comment is meant to weigh the yt algo so I see more of your content on my yt home page. last time I'm going to do this. Promise. Thanks for your content.

[@stickmf]

do you have any contact methods because I can team up with you in your next game

[@harrysanders818]

2 days of discovering and learning Godot, and I am running around like a mind blown zombie full of euphoria...

[@xyonblade]

I notice a lot of people who do videos have the node tree on the right side of the window instead of the default on the left, is this all just preference?

[@Gdquest]

It's because it was on the right side in older versions of Godot.

[@samwholearns3023]

Is declarative code essentially just abstraction?

[@algorev8679]

This tutorial was incredibly informative. Now I understand more why Godot has such a great reputation.

[@Gdquest]

More people should try it for teaching :)

[@valterbushido3468]

10:10 Why do you reuse the resource when you can, and probably should, reuse the entire scene (just make a scene for each reusable node)? To me your approach looks like antipattern.

[@gerrygadget]

Is this video still useful for Godot 3.2, or do we need a new one?

[@benvella1728]

From what I can tell it does still appear valid

[@mzaxnav4153]

I saw spacemacs >.< Org mode :D

[@Altair19979752S]

a little bit too basic the first half of the video video in my view

[@alexandredaubricourt5741]

*#1 TIP: Use C# ;)*

[@Gdquest]

I would advise the opposite. There's no advantage to using C# when it comes to your project's structure. There's reasons for a C# developer to pick C# as they're comfortable with the language already. But we have GDscript, a language designed for gameplay code. Compared to C# it's easier to read, faster to write, it's tightly integrated in Godot, and it will only bring you the features you need to do your job well.

[@alexandredaubricourt5741]

The only theoretical reason to use GD script is that the Godot community has total control over this language, BUT I'm pretty sure that all GD script "Feature" can be achieved with C# through reflection (for instance i made a custom [FromNode] attribute). Now, "GD script is faster to write and is made for game dev", I would agree that GD script is made for game development and it could be a good choice for prototyping but on large & long term project, script languages (such as python, js etc.) lack of maintainability because they are too permissive.

[@Gdquest]

You miss the point. The practical reason to use GDscript for gameplay development is that it's a Domain Specific Language: it's designed for gameplay development, has a feature set dedicated to that and nothing more. While C# is one of the most complex multi-paradigm languages out there. It's not a matter of replicating all the features but of having the tool that's the best fit for the job. You mentioned large-scale projects: I would disagree GDscript couldn't scale in combination with GDnative and/or backend (c++) code but more importantly the vast majority of Godot users don't do large scale projects. You have to prototype a lot anyway to build a game, so if you have trouble with the language and feel you need C# it won't be an issue. In a sizeable team the developers will be in a better position than either of us to decide. Flexibility comes from the fact you have access to multiple languages. Godot has default "front-end" and back-end languages: GDscript and C++. Nothing prevents you from combining two or more for different parts of your game's architecture. Lastly Python, JS are used by companies like Google (KZbin's backend is in Python) and Facebook (React) for large scale systems. They're not "scripting" languages. Again: my issue here is there's a beginners reading us (here, on other communities) and they're easily sent in the wrong direction.

[@alexandredaubricourt5741]

I've been in JS for a few time, and I'll tell you, yes big companies and a lot of peoples use JS, but with numerous extra layer of Lints, transpilers and "code quality tools" to fill the JS "scripty" gape, making the dev flow bloated. (The problem is that JS is the only language running on browser (even is Web Assembly is coming)) Again, Godot hasn't more feature than C#, and I don't think that C# is fundamentally complex, just look over the Godot documentation's examples, you'll see that it's pretty close to GD script in term of complexity. Now, I understand that for beginning in development you'd better go for GD script but i do think that most of the people coming have a programming background. And, as time goes on, Godot is more and more suitable for building "big" games, but anyway it worth trying both.

[@Gdquest]

Again, the point is: use the tool that best fits your needs. Don't just recommend C# without giving people some solid context and arguments. Most Godot users are not experienced developers. And experienced developers don't need our advice, they can pick the right language by themselves. You say you understand that gdscript is better to get started, so it's more accessible, but then you suggest that C# isn't more complex? C# grew in a language that is as complex as C++ if not more. It includes keywords to manage memory by yourself. Tools for low level code. I didn't say that GDscript has more features than C# but the contrary and that's the point: it doesn't have the feature you don't need for gameplay code. It's leaner. You may argue that you don't need to use all the features. I agree. Then better not be tempted to use them in the first place, not be tempted to use multiple paradigms in your gameplay scripts. Another argument in favor of GDscript and making the most out of Godot's architecture (using nodes) is your code is shorter thus easier to read for your future self and colleagues. If you rely as much as possible on built-in nodes, build solid scene hierarchies, and add extra node types as you need them you shouldn't have issues to scale as you're deferring as much work as possible on C++ code encapsulated in the back-end. All in all I would recommend people to pick their own language but to be mindful of their choice. To experiment and to think about what they're doing. And fellow developers to stop telling people to just go for C# and that GDscript is bad without context. I'm not saying this only as a designer who's been in the game industry for years but also as a tutor. I teach and help the people who read these random pieces of advice and it has real consequences. Like people asking me for step-by-step C# tutorials for everything or algorithms they don't need while they should really work on their programming foundations. But they read somewhere that GDscript is slow so they won't even try it, or someone told them that C# is better [for large-scale projects] so they want to use it for the next game jam.