Creating Point and Click Games with Escoria
Basic Concepts in Godot
Godot Structure
Godot Engine is a full game engine that relies mainly upon 3 parts:
- the runtime engine, which plays your game data in the current platform, and effectively runs the game.
- the export process, which helps have the game work for different platforms and takes care of the specificities of each.
- the graphical editor, which is the most visible part, that helps place and configure the world, the players and the items.
The game design team has few reasons to spend time on the runtime and the export engine (unless they want to add specific functionalities or contribute to them since Godot is Free Software). The effort of creating games, especially point-and-click, will be made mostly in the editor in which the scenes will be created and objects placed.
To use the editor, one will mainly have to :
- get assets, essentially pictures for objects and players, music and sounds
- create Godot scenes and objects to use the assets in the game context.
Nodes and scenes
Godot's logic relies on two main concepts: nodes and scenes.
A scene is similar to a theater stage, where your game is running. Going this way, you can define your point-and-click game as a series of scenes in and between which the player will move and interact with the items placed in.
But if you have an animated item that produces an ambient sound, imagine how difficult it could be to redefine how the asset will mix in each instance. In fact, to help you make your work reusable, you can also imagine any object as a scene itself. In this scene you will import everything which is constitutive of that object. Then instead of using directly the asset in the scene, you’ll use create an instance of that object. The good thing is that changing the original will change all the instances, which makes it very easy to improve the game step by step.
The game is not only a series of scenes, it is more a kind of a tree, one scene containing other scene, that will contain other scenes or assets, etc.
Finally, when creating scenes, there will be a need the define the functionalities we’ll use. Godot has to know if what we add is a label, a static image, an animated image, a sound, a script…This specialized approach will help prevent errors in the game because, in fact, the user can grab an object represented by a picture but more rarely an object can only be a sound. Having a special type of element makes thinking clearer. It also makes the game more optimized because each type of element will have capabilities that will use memory: the more capabilities, the more memory needed. Having an accurate approach helps the game works on tinier or older machines and in any case makes the game more fluent.
In Godot, the default element types are called Nodes. There is plenty of them and this certainly the most difficult part of Godot to know which node to use for a situation. Hopefully, in a point-and-click, useful node types are limited (Node2d, TextureFrame, animations, sounds…) and will be mixed in object scene and stage scene to make the game more pleasant.
Scripts
The last thing we could say about Godot’s concept is scripting. Because all games have interactions and conditions of interactions, scripting help define how they happen. Godot scripting language is called GDscript, and is inspired by Python. In most games, scripting will require programmers knowledge and each player or object will have a script associated with it. In a point-and-click, since interaction types are standardized, Escoria templates provide ready-to-use scripts that will need to be attached to scenes and objects. After that, everything will be done in the Escoria scenario, without the need of any other programming. This book explains how to use those predefined actions.