DEV Community: Winston

Godot Engine: Extendable Editor

Winston — Mon, 05 Aug 2019 22:47:33 +0000

In this series I want to share a few things that I love about the Godot Game Engine. Today's post is about extending the editor itself.

When using open source software I sometimes hear the statement "You can do anything and adjust it to your needs since it is open source". While this may be true, it can be very hard to actually adjust things to fit your needs. However it can also be very easy! Godot is great to extend. You have multiple methods available to adjust it to your needs. It feels like the engine was made with extendability in mind.

The Godot Editor is basically a game running in the Godot Engine. When you are already familiar with Godot then it is really easy to get started with extending the editor itself.

There are multiple methods to extend the editor. They range from easy to very complex (but powerful).

GDScript Tool Mode

This method is one of the easiest methods to extend the editor. You can add the tool keyword to the top of any script. Every script with this keyword will not only run in the game but also inside the editor (when a node with that script is in the scene). What you can do with this is a bit limited as the script must be attached to a node in a scene. This method is really useful to create helpers for yourself.

I use this method quite often to quickly add a preview that updates itself based on some values. Here is a small example from one of my games:

tool
extends BaseEnemy

export(ENEMY_COLOR) var color := ENEMY_COLOR.RED setget set_color

func set_color(new_value: int):
    color = new_value
    set_enemy_sprite(SPRITES[color])

Here is what the code does: Whenever the enemies color property is changed the sprite is updated to match the new color. This allows to immediately see the changes you make inside the editor.

Plugins in GDScript

Plugins are much more powerful than the toolmode. In contrast to tool scripts they are executed when the editor starts and the plugin is enabled. They are not part of your scenes, instead they run independently inside the editor. Here are a few things you can do with plugins:

Add custom node types
Add docks and menu items to display custom UI Elements in the editor
Make a custom importer/exporter for your own format
Manipulate nodes in the currently edited scene

I personally used plugins to create a custom map editor for a game.

C++ Modules

This is the most powerful method I have used so far. You can create your own engine modules in C++. Godot uses scons for building. Godots build system and structure makes it relatively easy to add your own modules.

You can basically access everything with C++. Additionally C++ does run faster than GDScript. In most cases this is not really important. However I ran into two cases where I needed to use C++:

Extending a physics body. GDScript simply wasn't fast enough for my usecase.
Using thirdparty C++ libraries. I needed methods to operate on graphs (like shortest path, checking if graph is directed, checking if it is acyclic and so on). I didn't want to built this all by myself, so I added a thridparty C++ library as a module.

It is nice to have this possibility. However for most things GDScript is sufficient.

Thank you for reading! ✨

This is the third post in my series "Things I love about Godot". I already have some ideas for the following posts. If you have any questions or suggestions please let me know! If you would like more details or a tutorial regarding a specific aspect feel free to ask.

Godot Engine: TSCN

Winston — Tue, 30 Jul 2019 20:58:20 +0000

In this series I want to share a few things that I love about the Godot Game Engine. Today I will write about the TSCN file format.

In fact this post is not only about the TSCN format. It is about the fact that most file formats in godot are human readable text formats.

What is TSCN?

TSCN is the file format used by godot to store scene files. The format is explained very well in the official documentation. I will not cover these details here.

It basically is a text file specifying the contents of a scene. It contains the complete node tree of the scene and can also contain subresources.

Other files stored as text format

Most things in godot are stored (or can be stored) in plain text:

Resources (.tres files)
Project Settings (project.godot file)
Import Settings (.import files)
Scene files exported by other applications (.escn files)
probably some more that I have missed

Performance

The TSCN files are stored as binary .scn files in the internal .import folder. This way they load very fast.

Why I love the text files

I use git for all my projects. The text file format works perfectly with git. Every change I do in my scenes can be tracked by git. While every little change in the scene can be tracked this can also be too much. I like to group logically connected changes together to not clutter my git history too much.

Another point I love is that I can search for things easily. Forgot in which file the enemy named "KlingonShip01" was? Simply search in all files in the project directory! As everything is stored in plain sight it is very easy to find things.

Last but not least I love the simple structure of these files. It is not only easy to read, it is also easy to generate. For my current space game I wrote a small python script that generates scenes. It looks up the positions of planets and stars in an online database. Based on this gathered data it generates godot scene files.

Thank you for reading! ✨

This is the second post in my series "Things I love about Godot". I will probably cover the editor interface and more in the following posts. If you have any questions or suggestions please let me know!

Godot Engine: GDScript

Winston — Sun, 28 Jul 2019 15:39:07 +0000

I want to share a few things that I love about the Godot Game Engine. Today I will write about gdscript.

This post is not meant as a tutorial. Check out the documentation to learn more about gdscript. In this post I will point out the things that I love about gdscript.

Integration

When I first started to use Godot I was quite sceptical about gdscript. Why create a new language when there are so many other existing languages? The answer for me is the awesome integration. It is built with the game engine in mind.

There are so many nicely integrated features! Here is a small snippet that shows some of them:

onready var detector = $DetectorArea
export var health = 10.0

remote func apply_damage(amount):
    health -= amount

The onready keyword can be used to delay the initialization of a variable until the node is part of the scene tree. This is very helpful if you need to access another node from the scene tree for the initialization.

The $ is syntactic sugar to access a node in the scene tree by name.

The export keyword is used to make a variable editable in the editor. Example usecase:
Having many enemies with the same behaviour but different amounts of health. You can simply change the exported value for individual instances inside the editor UI!

Godot supports high level multiplayer networking. There are keywords like remote to make functions callable over the network with gdscript.

Syntax

The syntax is inspired by python. As I love python it was very easy for me to adapt to gdscript. Like python gdscript also makes use of indentation.

Optional type hints

The (pretty new) type hints in gdscript are easy to use and completely optional. I often quickly prototype something without type hints. For everything beyond prototyping I use type hints wherever possible.

The editor has a concept of "safe lines". It is perfectly possible to only use types in a few places. Lines where the type check found no errors are marked as safe. This is indicated by a green line number. Lines where the type check can not be performed (because of missing type hints) do not have this green line number. Errors found by the type check are shown directly in the editor.

Often the type can be inferred (making the code much shorter).
Example: var foo := "bar" instead of var foo: String = "bar"

The `match` statement

I like to think of match like an enhanced version of a switch statement. Let me demonstrate some of it's awesomeness with an array named bookshelf:

match bookshelf:
    []:
        print("Empty bookshelf")
    ["The Hitchhiker's Guide to the Galaxy", ..]:
        print("The first book in your shelf is awesome!")
        print("Nothing else is important.")
    ["LOTR 1"], ["LOTR 2"], ["LOTR 3"]:
        print("You own exactly one book.")
        print("It is a book from the Lord of the Rings.")
    [var lonely_book, _ ]:
        print("There are two books.")
        print("The first book is named ", lonely_book)

In the above match statement I used array patterns. The .. is used for open ended arrays. Using var inside a pattern binds the corresponding value to the new variable. The _ wildcard matches anything (and can be part of complex patterns).

There are many types of usable match patterns, from simple values to complex dictionary patterns!

In my opinion match is an extremely powerful structure. However it can lead to code that is hard to read. Use it with care. Think about how and why you use it. I personally love match but often simpler structures can be used. I only worked on two or three actual projects where it made sense to use it.

Thank you for reading! ✨

This is my first blog post here on DEV. My plan is to create a series of posts with things I love about Godot. If you have any questions or suggestions please let me know!

DEV Community: Winston

Godot Engine: Extendable Editor

GDScript Tool Mode

Plugins in GDScript

C++ Modules

Thank you for reading! ✨

Godot Engine: TSCN

What is TSCN?

Other files stored as text format

Performance

Why I love the text files

Thank you for reading! ✨

Godot Engine: GDScript

Integration

Syntax

Optional type hints

The match statement

Thank you for reading! ✨

The `match` statement