Creating Point and Click Games with Escoria

The Items

Now you have done your first game with Godot and Escoria and have an initial understanding of how it works, let's dive into the fundamental concepts of Escoria that each team member should know - artist, game designer or programmer.

Items are any interactive object on the main scene, and also the objects inside your inventory:

  • An item consists of a scene with the script attached to it
  • Often contains sprites, animations, a clickable area, etc.
  • Global Id can be used to address it, and can be controlled from the game scripts to do many things, for example play animations, change its state, "walk" or "teleport" to a position, have it followed by the camera, etc.
  • Items also respond to actions performed by the user, such as clicking on them with an action ("use", "pick up", "look at", etc.), or when another item is used on them.

Here is an example with the bad bamboo of our mini-game:

Escoria item example

The Item structure

Usually, an item is created by creating a new scene Scene > New Scene which will contain all the relevant nodes. An item scene can have multiple scene structures, each serving a different purpose. The only common characteristic to all items is that they use the script on their root node. The root node is the first in the scene tree, appearing as the "main folder" for all nodes of your scene. The script is located in res://globals; load it at the bottom of the Inspector after creating and selecting the root node of your new item scene.

Items can have different types of root nodes, and different types of children nodes (or none at all). The most common structures can be as the following.

With a Node2D root node

This is the canonical way to structure an item scene. The root can have any children necessary to make the scene look and work the way we want. The script will look for the following children to provide certain functionalities to the items:

  • an AnimationPlayer node, that should be named animation. This is where the script looks for the animations of the item, when directed to play by the script.
  • a Control node, named area. This is the clickable area of the item (if you want more information see the Scene composition in the What you need to know as an artist chapter). The script will receive input from this item. The node can be any type that inherits from Control, including the TextureButton, which can use a click mask to receive clicks on areas with complex shapes.
  • a Position2D node named interact_pos. This is the position where the player character will stand to interact with our item. When not present, the position of the item root node will be used.
  • some node of any Node2D type named _focus_in_focus_out or _pressed: these nodes are shown or hidden when the items gets the mouse focus or when the mouse button is pressed. Usually they are sprites. If the game is played on a multi-touch screen, mouse is assumed to be the first finger.

The old_man item shown above is an example of such an item structure, with just a Sprite node added to display the corresponding picture.

With a Control root node

When a Control node is the root, the script will take all input from the root node, so no area node is necessary. The root node can be any type of Control, for example TextureFrame, or TextureButton. If you use a type that is usually non-clickable (like TextureFrame), remember to uncheck the ignore_mouse property of the node, to enable input on it if necessary. Inventory items are usually implemented as TextureFrame or TextureButton nodes, with the script and nothing else.

Escoria simple inventory item

All other children are used just like the Node2D root scene.

An inventory structure can be quite complex because it's part of the user interface, but the items inside it are simple, if taken individually. We will explain how to build an inventory in the corresponding chapter of this section.

Here is what it look like in our mini-game. Note that inventory items (in orange here) are different items from the game items so they can be handled more easily, even if they share the same sprite (bad_bamboo and inv_bad_bamboo are two items sharing the same sprite):

Escoria inventory example

With a Position2D root node

When using a Position2D as root, your item can be empty; no graphics, no animations, no input. This type of empty items is commonly used as position marker, to move other items to the position of our item, using the item's Global Id. Maybe you don't need to create a specific scene for this type of items, and place your position directly on the game scene.

Escoria empty position item


Item properties

Items have many properties, mostly provided by the script. Properties names are shown uppercase with spaces in the Godot interface (e.g. Events Path) but should be named lower case with dashes in the scripts (e.g. events_path).

The following describes a few important properties.

The Global Id

The Global Id is a unique name we use to register the item in the game, and address it from the scripts. It must be unique. Avoid spaces or special characters in the name, and try to use a descriptive name. The global id is configured by using the global_id property of the item scene.

Escoria Global ID property

The "Active" property

The Active property defines the visibility of the object. When an object is not active, its entire object scene will be hidden, and it will not receive input. Objects are active by default. The active property for each item is stored in the global state of the game, and the savegames. This property can be modified in Escoria scripts with set_active command followed by the global id of the item and a value: the true to make it visible or false to hide.

set_active old_man true
set_active old_man false

The "Events Path" property

Items respond to actions, such as use, open, pick up. When an action is performed on an item, an event will be called on the item, usually with the action name. To implement those events, we provide this information in the .esc script, for example item_name_events.esc, using the events_path property on the item scene. In the script, lines following a line starting with :action_name will be executed (e.g. :use), so you can have multiple responses to multiple actions in a single script.

set_active good_bamboo false

If you want a full example please read our quick start game section describing actions.

It’s important to notice that every item that would receive events should have a .esc file defined in the Events Path.

The State

One of the classic ways to respond to an action is to change the state of an item (opened or closed for example). The state of an item is a string with a name, that is saved in the global state of the game, and on savegames. Whenever an item is instanced in the current scene, the game will set the state of the item to the stored state. If the item has an animation named after the current state, the animation will play when the state is set (an open animation for example). This is used to change the internal parameters or appearance of the item scene.
(Read the Animations chapter for more information on the relationship between state and animation.)

So, to change the state of an item, use the script you created and linked to the item with the Event Path property (for example item_name_events.esc). There is no property for the inspector for the state, and the state string will only appear in the scripts and on the corresponding animation name in Godot. To change the state, we’ll have to use the set_state command in the script.

:use inv_good_bamboo
set_state bamboo_god happy

For example, a light bulb item might have 3 states, "on", "off" and "broken". The scene might have an elaborate animation for breaking the light bulb, glass shattering, sparks particles, etc. But after the "broken" state is set on the light bulb (in Esc script: set_state lightbulb broken), we only want to show the already broken light bulb. When the game is loaded, the "broken" state is set on the light bulb, and the animation simply shows a broken light bulb.

The Animations chapter gives an example on how to use state-based on our mini-game. Notice that the names of the states are completely left to user's wish because states will really depend on the story and the needed interactions.

Other properties

There are of course many other properties as follows:

  • animations: a script with a list of animations to be used when walking, talking, and standing in different angles
  • speed: the speed at which the item moves when told to "walk", in pixels per second
  • scale_on_map: check if you want the item to be scaled by the scale map of the scene
  • light_on_map: check if you want the item to be lighted by the light map of the scene
  • tooltip: the text to be shown when the mouse enters the item, in the tooltip area of the UI
  • action: the default action to be used on the item when no action is selected
  • use_combine: check this if your item needs to be combined with other items when the "use" command is the current command
  • inventory: check if your item is in the inventory
  • use_action_menu: an action menu is a pop-up menu reacting to an item click, we will discuss it in the Verbs & Actions chapter. When an action menu is available, this property enables it when the item is clicked. When this property is disabled, the action defined in the "action" property will be triggered.
  • interact_angle: the angle at which the player will stand when it has to interact with the item
  • talk_animation: the name of the animation to use when the item is talking

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.