6 Tips to Better Organize your Godot Projects 

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

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!

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 :)

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

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

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 :)

Ahoy!

The apostasy of vim sends its malediction

Neovim > Emacs

One VS-Code to rule them all

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 :)

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.

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.

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

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

@@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.

It's all from spacemacs: spacemacs.org/

More people should try it for teaching :)

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.

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

From what I can tell it does still appear valid

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.

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.

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 (RU-vid'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.

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.

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.