Godot 3: Top 7 Things You Wish You Were Told

in #gamedev7 years ago (edited)

7a513682290ccfa5.jpg
The all the things you should have been told about Godot~
TL:DR An admission of how dumb I was when I first started.

Autoload

More often then not, games need single entities to manage scene switching, hold/load data, or other managerial type tasks. Godot's answer is AutoLoad!
Screenshot (3).png
Project->ProjectSettings-> AutoLoad
Name:Name of Node At Runtime
Path: ScriptPath
Sing: Enable Singleton

*Also note that the order displayed will be the child order at runtime.

From there you can select which scripts get loaded at the root node of your project. The main scene will be loaded under all your autoloaded nodes as the last child of root.

Then calling these nodes is as easy as grabbing the root node from any script.
Screenshot (4).png
This example demonstrates calling a SceneManager from a button script~

Built In Scripts

Often in godot(especially in scenes were you are testing), you will want to use scripts, but do not want to clutter your workspace.
Screenshot (11).png
In this case, be sure to check the built in script option. With this option enabled, the script is packed in with the scene and can be found by clicking the script icon next to the node it is attached too.

Organization

In Godot 3, the engine is so flexible you will often find yourself with a lot of clutter. Even looking at projects on github, most projects are unkempt and disorganized. While this is not a problem for smaller projects, the moment you start to scale, the clutter becomes a nightmare. Be sure to properly organize your project in such a way that it makes sense for you and is clean.
Screenshot (12).png
For example I like to keep different systems silo'd in their own folders to avoid confusing myself.

setget

setget is the key word for setters and getters of your properties. It is useful for updating children nodes when a top level property is updated. Syntax is as follows:
Screenshot (10).png

call_deferred(String call):

call_deferred is one of the single most important functions to keep your entire project from breaking. For example, if you have a property on a script and its setget modifies the properties of its children.
Screenshot (3).png
This will always through a nil error because when the scene is being built, RichTextLabel.text does not exist in the context of the scene yet.

Screenshot (7).png
However updating the text this way will work because call_deferred runs late. It is best to use call_deferred when you are experience nil errors at runtime. Also useful in your _ready() functions.
**you can pass arguments like this
call_deferred("do_the_stuff", arg1, arg2)

Passing tables as arguments

When building systems, you will need a way to pass multiple arguments to nodes. Making functions like : do_all_the stuff(dogs, cats, noodles, dexterity_multiplier, people_i_do_not_like, .......) is messy and prone to breaking. It is easiest to pass dictionary tables. You can keep everything you need in these kind of arguments, including more dictionary tables. It also plays well with JSON, so you can use this method to save and load data. When you pass tables, remember you are passing a reference. Remember to use duplicate() to create a copy in memory.

Declaring a dict table:
Screenshot (14).png
The following is an example in my Stats.gd in an rpg project:
Screenshot (13).png
Here I packed modifiers into one table and unpack them in a for loop.

What important things did I miss?
Did you find any of these suggestions helpful?
Leave comments, suggestions, feedback, and catmemes below~
Helpful links:
AutoLoad
GD Script Overview
Godot 3.0 Docs

Edits
Top How Evermany Things I should have covered but didn't:
-Using arrays as stacks, queues, and lists(also includes how to implement a custom sorter)
-Naming conventions (correct case, things make sense in how they are named)
-Comprehensive overview of Project Settings-> General tab

Coin Marketplace

STEEM 0.26
TRX 0.20
JST 0.038
BTC 96662.00
ETH 3660.13
USDT 1.00
SBD 3.84