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 platform 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 functionnalities or contribute to them since Godot is Open Source). 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 scene and objects to make use the assets in the game context.

Nodes and scenes

Godot 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 scene 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 ambiant sound, imagine how difficult it could be to redefine each instance how the asset will mix. 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 to that object. Then instead of using directly the asset in the scene, you’ll use the object created as an instance. The good thing is that changing the original will change the instances, which makes it very easy to improve the game step by step.

The game is not only a series of scene, it is more a kind of a tree, scene containing other scene, that will contains other scene or assets, etc.

Finally, when creating scene, there will be a need the define the functionnalities 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 at the end thinks clearer. It also makes the game more optimized because each type of element will have capacities that will use memory : the more capacities, the more memories needed. Having an accurate approach helps the game works on tinier or older machines and in any case make 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, usefull node type are limited (node2d, textureFrame, animation, sounds…) that will be mixed in object scene and stage scene to make the game more pleasant.


The last thing we could say about Godot’s concept is scripting. Because all the game 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 objects will have a script associated. In a point-and-click, since interaction type are standardized, Escoria templates provides ready to use script that will need to be attached to scene and objects. After that, everything will be done in the Escoria scenario, without the need of any other programming. It will be part of this book to explain how to use those predefined actions.

Il y a une erreur de communication avec le serveur Booktype. Nous ne savons pas actuellement où est le problème.

Vous devriez rafraîchir la page.