Here are some of my best Godot 3 tips, that I think you should at least give a thought. Surely, all Godot tips listed here may not always work out for you. Or maybe the better solution to a given problem is to not use them. But in general, I did find them very useful. Keep in mind that everything on this site is just my preference. And it is totally fine if you do it your own way.
Tips when structuring your game
The more you think about and plan the structure of your game in advance, the lesser the chance, that you have to start over or make major changes to your structure during development. One time I was working on a game in Godot, and I just went from prototyping the game to building on top of it. As the project grew in scope, realized, that the structure of the prototype was not really convenient anymore.
So, I started over with a fresh project. And I worked on a new, better structure. But soon I figured out, that at some point I would like to add multiplayer to the game. But I would have to make major changes to the structure again in order to make it work. So I once again started to build the project from the ground up. Of course, some of the know-how of structuring a game comes with experience. But I would argue, that if I would have better thought out the structure in advance, it would have saved me some time. So here are a few tips in Godot to structure your game.
Use more than one scene
Look at Scenes in Godot Engine as a part or object of your game, that regularly can show up. Of course, you can decide for yourself, what a scene should consist of. Even though it is not advised, you could cram your whole game into one big, single scene. But a much better approach is to split up your game into different scenes: So, for example, you could make a separate enemy scene. Then, every time this enemy shows up, you can just instantiate this enemy scene.
One scene can also be made out of different scenes. So, for example, if you have a player scene, it can consist of the body scene and the weapon scene. As you will see, the scene system in Godot is a very flexible and versatile way of building your game objects and game worlds.
Your scenes should be able to run, even without the rest of the game
A good practice is, that you build your scenes in a way so that they can run independently of the rest of the game. This is partly possible, if you do not make connections via the scene tree, but rather make use of Signals and let them communicate that way. To be honest, most of the time it is not possible to make every scene runnable, but the more scenes are runnable on their own, the easier it is to rearrange stuff inside your project or sometimes even use the same scenes for different projects.
Signals are a very handy way to notify some node, that something did happen. A lot of nodes already have built-in signals. You can find them in the Node tab (beside the Inspector – check the screenshot). From there you can connect them with your code. One of the most basic usages is connecting a button click to a function.
A big advantage of using signals is, that you can let instances of scenes communicate with each other. But you are also able to run the scene on its own without breaking the game (you will get notified, that a signal is not connected, though).
You can also build custom signals and connect them via your code. For more information, check out my post about signals.
Make use of groups
Right beside the signal tab is the groups tab (Check the screenshot again). There you can add a node to a group. Groups function a little bit like a tag system. You can also add something to a group in your code:
Once a Node or Scene is in a group, you can check if that object is in a given group at any time, like this:
This is very useful if you want to check for collisions with a specific group, for example. Check out this link, if you want to learn more about groups.
Inheritance is a powerful way to structure your game. Imagine you have three different types of enemies in your game. All three enemies have characteristics that they share, and characteristics that are unique to each enemy. Let’s say that the enemies look the same, except, that the first is green, the second is red, and the third is blue.
So one way to achieve that is by creating three unique scenes where you build those three enemies. One green, one red, and one blue. Great, the job is done. But if you want to change something about your enemies, you have to change it in every one of those unique scenes.
The second way is to use inheritance. So first, you would make a parent scene. In our example, this parent scene would consist of an enemy with no color. Then you would make three inherited scenes (check screenshot) of that parent scene and just change the color of the enemy in each scene separately. So now you also have three enemies. But if you ever want to change that enemy scene, you just have to make that change in the parent scene. The inherited scenes will be changed automatically. Have a look here for more information on inheritance.
Make use of Layers and Masks
Layers and masks can help tremendously when you deal with collisions. By setting different layers and masks you can control, which objects are colliding:
- The layer is where the object appears.
- The mask describes what layers the given node will scan for collisions. If an object’s mask does not match the layer of another object, it will ignore that other object.
Consider the following:
- The player node is on layer 1 and masks 2 & 3
- The item node is on layer 2 and masks 1
- The enemy node is on layer 3 and masks 1 & 3
Then the following will be true:
- The player can collide with items and enemies, but not with another player
- Enemies do collide with each other and the player, but not with items
- Items don’t collide with each other or enemies but collide with the player
Godot 3 tips for coding
Even though I mostly follow the rule “write dirty and write fast” I also think, that you should keep some things in mind, when you code in Godot Engine. Those Godot 3 tips and tricks will help you with coding.
Even though you may not consider localizing your game right away, it is good practice to build your game and write your code, which I call localization-ready. This means that you have everything already in place, in case you want to translate your game at some point in the future. It is very easy to make that happen, and it can save you a lot of time afterward.
The only thing you have to do is to connect your in-game texts to your spreadsheet, rather than hard-code every line of dialogue or UI element into the script. Check out this post on localization, to learn more about how to do that.
Use comments in your code
Use comments to write about what is going on in your code. Even though you might exactly know right now, what every part of the code does, it may not be like that one or two years later down the line, when you may think about making an expansion, or some changes to your game. Also, if you are coding in a team and someone has to understand what your code does, it is a lot easier this way. To make a comment in GDScript, just use #.
#This line is just a comment
Naming your functions
This one is not really that important, but it may help to make your code more readable. Try to name your functions in a way, so that you later easily understand what it does. I myself try to name functions dependent on what they do or what they return. For example, if it returns a Boolean, I would start the function with is_. So if I want to check if the inventory is open, I would call that function is_inventory_open(). Or if I have a void function that should purge the inventory, I would call it do_, so it would be called do_purge_inventory or something along those lines.
It is just my personal way, but I would recommend to you, that you find a naming convention that suits you. Once you have found one, try to stick to it since it makes reading your codes much easier.
The export keyword
Export is a keyword that you can write in your variable declaration. What it does is, that it “exports” the variable into the inspector block of the Godot Editor. This way you can change the value directly in the editor, not just in the code. In my eyes, this is very useful for variables that you expect to change, and also for scenes that require you to work a lot in the editor. Check out the following examples. All three are valid forms:
# This would add a variable called "health" to the inspector
# with default value of 10
export var health = 10
# This would add a float called "chance" to the inspector
# with default value of 0.1
export (float) var chance = 0.1
# This would add a variable called "damage" to the inspector
# with default value of 0
export (int) var damage
You can also use the export keyword for whole scenes or textures if you wish to do that:
export (Texture) var wall
export (PackedScene) var player_char
Here you find more info on the export keyword.
More Godot 3 tips to consider
There are a couple of other things I would like to recommend in my Godot 3 tips and tricks post. They are more of a personal preference, but nonetheless, I would like to mention them.
When I started using Godot Engine, I ordered my project folder in a very specific way. All the scripts I put into a “scripts” folder. Every scene, I put it into a “scenes” folder. Then, all the materials I put into a “materials” folder, and so on and so forth. While this worked well enough in the beginning, I soon realized, that it was getting more and more complicated to navigate through the whole “scripts” folder in order to find that one specific script I was searching for.
So I quickly began restructuring my project folders. The best way for me to this date is to order my folder in a way so that every object has its folder (check screenshot). I then put everything associated with this object into its folder. This way I could always find what I searched for. Even in bigger projects. Godot itself also helps with this structure, since it has different symbols for different resource types. So you immediately can identify the script, the scene, or the material in the folder.
Make and use themes
One can not make a post about Godot 3 tips and best practices, and not mention themes. Themes are a very powerful way to change the look of your game.
You can use it to make Control Nodes (so your GUI) look in a specific way. Define your theme and use it for your whole UI. To make a theme, just go to any Control Node and create a new theme (check screenshot). Save this theme, and you can use it for all your other nodes.
Make use of the Input Map
Even though you can check which button was pressed by directly writing it into your code, it is good practice to use the Input Map. You can find it under Project Settings > Input Map (check screenshot).
There you can define your needed actions and also which keyboard key, mouse button click, or game pad button press can be used for the specific action. Check my post on inputs to learn more about that.
Also, this way you can let the player customize the input keys. Check out this simple tutorial for creating an option menu to customize the key bindings.
You may want to use Shortcuts
You can find a list of all shortcuts under Editor > Editor Settings > Shortcuts (see screenshot). There you can learn and change shortcuts, which are useful for you.
Some of the most useful shortcuts for me are the following:
Delete # Delete stuff
Control + C # Copy stuff
Control + D # Duplicate stuff
Control + A # Add child node
Control + W # Close script
Control + F # Find in script
Control + Z # Undo
F # Focus selection
Fly in the 3D Editor
In case you did not know, you can fly around in the 3D Editor by holding down the right mouse button and moving with WASD. Also, you can alter your flight speed with the mouse wheel and speed up your flight with Shift.
That is that
I hope I could help you with my best Godot 3 tips a little bit. But you can also check out the official best practice site for some more information. If you have other Godot tips and tricks, that you want to share, tell me in the comments below. You can also write them to me via mail, and I may add them to my Godot tips post in the future.