Godot Game Engine Conceptually

Godot is a game engine, with an advance integrated development environment for making complex games.

When getting into a new big piece of technology it is useful to find ways of latching onto other known technologies to more quickly get a handle on how it works.

Godot itself has great documentation, which actually talks about its principles.

There are also tons of Godot tutorials. My attempt here is to help a beginner get a birds eye view of how it all works. Otherwise you can get lost in the details.

Scene Graphs All the Way Down

For people who have done 3D programming before you are probably familiar with Scene Graphs. Open Inventor, Coin3D and many other 3D rendering frameworks are based on this idea. Basically it is a tree structure of objects which describe how something should be rendered.

In the last years component based design as in Unity3D and data-oriented design has been all the rage.

Let us make it clear, Godot is not like that. It has more in common with older scene graph based systems. You got scene made up objects which must all be some subclass of the Node type.

But the big idea in Godot is that scene graphs are reusable. You can store scene graphs as templates, and then create instances of these scene graphs which can be assembled into new scene graphs.

And everything is literally a scene graph in Godot. You can create sophisticated GUIs not just some 3D character or 2D sprite game. The GUIs will be scene graphs as well. Not only that but an individual button or slider can be a scene graph which was made separately, stored and instantiated.

So in Godot the workflow is really centered around this idea. You can build a scene graph and realize “hey that subgraph of my scene graph would be neat to have over here as well!” Then all you need to do is to save that subgraph as a scene graph file. Then you instantiate this scene graph file twice for each place you use it.

So in Godot you will typically organize your game around folders for each sub-scene graph. The folder will contain a description of scene graph along with assets it uses.

This is really useful to grasp right away as it can seem confusing at first that a button or a sprite can be a scene. But yes in Godot they can. It isn’t all that different from the Win32 API where every GUI component is in fact a window. A window is the concept reused all over the place.

Project, Scene and Script Files

The files specific to Godot that you deal most with are the following files:

• .tscn which contains descriptions of a scene. This could be a single game object like a player. The whole game, just the GUI, an enemy, a button or just about anything.
• .godot your project file. Typically named project.godot. This ties everything together.
• .gd script files. These contain GDScript code which is basically the files containing all the code in your project.

Because there are no fundamental difference between a scene for a button or a whole game level, you typically have to specify in your project what scene you want to run. In fact you can switch between running different scenes separately.

Scripts Are Attached to Nodes to Perform Subclassing

In Godot you can customize nodes by attach a script to them. Conceptually this causes a subclass of that Node to be made. So E.g. if you insert an Area2D node called foobar in your graph and attach a script to it called say Player, then any function trying to do something with foobar will see its type as Player.

So adding a script to a node is a way of adding properties and functions to an existing node type. You can also override member functions defined in the node you are “subclassing”.

Basically this is a way of modifying and adding behavior to a node. This explain also why unlike Unity3D you can only attach one script. Your node can obviously not be multiple different types at the same time, so having multiple scripts would not work.

The workaround would be to simply add some dummy child nodes with scripts on them if you need more script files.

Relation to C++ Subclassing

Keep in mind that a lot of the stuff in Godot exists as C++ classes, so don’t confuse these two things. Conceptually attaching scripts work like subclassing seen from the point of view of your GDScript code.

The classes seen from GDScript are not C++ classes in that they are highly dynamic with properties which can be added, removed and looked up at runtime. For those familiar with Objective-C it is more like that. Alternatively it is like classes in Smalltalk, Python or Ruby. Stuff that is highly dynamic.

Overall Coding Workflow

Godot is very object-oriented in its behavior. Interestingly I am not a big fan of object-oriented programming but I think the paradigm works really well in Godot.

The subject-observer pattern is used a lot. If you have used the Qt C++ GUI toolkit or GTK+ used in Gnome you should be familiar with this concept. There we have the idea of signals and slots.

An object can emit a signal which will trigger a call on a method in some other object. This triggered method is called the slot in Qt and GTK+ terminology.

The benefit of this approach is that object sending a signal does not need to have any idea of who is receiving the signal. In GUIs this is very practical. A button cannot know who wants to react to a click. It cannot point to a concrete class which should get a particular method called.

One could point to an abstract class, but then we would still have the problem that multiple buttons cannot call functionality on the same target class without causing the same method to be called. Signals and slots solve this problem.

The way you use this in Godot, is basically that child scenes define some signals they emit different things happen. E.g. a scene representing a player space ship could emit a signal when it hits an asteroid or runs out of fuel.

That can inform the main game of what is going on, and let it take an action. Perhaps e.g. show a game over screen. We don’t want the space shit to know about game over screens. By sending signals it doesn’t have to. It leaves it to others to handle that it hit an asteroid.

Overall Scene Workflow

Godot is all about combining nodes to create scenes or add scenes to scenes to create scenes.

Comparison with Unity3D

How does this compare to other game engines? In Unity3D a game is made up of game objects and components. You create e.g. a bullet or space ship as a game object. And then you attach components to it depending on the behavior you want. If you want the bullet to be able to collide with things you add a collider component. If you want it animated while it moves you add an animator object.

In this model a game object is simply a container for components that give the actual behavior and abilities.

In Godot scene nodes serve the purpose of both game objects and components in unity. Abilities like collision, animation and rendering are just subtypes of Node.

However the nodes will be organized slightly different. If you want your game object to move due to physics forces, such as an angry bird or bad piggy then your root node needs to be a physics object. It cannot be a sub-node because parents nodes move their children around, while children move relative to their parent. A child node which is moved does not cause a parent node to move. This is kind of the whole idea of a scene graph.

Consider a scene graph representing a car. The car wheels are sub-nodes, thus when the root node is move, all the wheels move with the rest of the car. However the front wheels can still twist and turn relative to the car body.

Comparison with GameMaker

In game maker the world is made up of sprites, game objects and rooms. The sprites give appearance to a game object. The rooms typically represent the game level or environment your characters are in.

In Godot all of these things are just scenes made up of one or more nodes. Godot has a Sprite node which can render an image onto the screen. But much like GameMaker it is quite dumb. It cannot deal with collision detection, being clicked or simulating physics behavior such as falling or bouncing.

Rooms are just scenes. The closest approximation in Godot would be the TileMap node which allows you to compose something that looks like a room or level by combining multiple tiles from a tile set.

The benefit of Godot is that something like a user interface can be composed of nodes specifically designed for that purpose, while at least Game Maker when I used it years ago had to fake that with combining tiles in a room.