Sites


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, whether he is an artist, a game designer or a programmer.

Items are any interactive object on the main scene, and also the objects inside your inventory. Each one consists of :

  • a scene with the item.gd script attached to it
  • often contain sprites, animations, a clickable area, etc.
  • a global id that can be used to address them, 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, they can be 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 wil contain all the relevant nodes. An item scene can have multiple scene structures, that serve different purposes. The only common characteristic to all items is that they use the item.gd script on their root node. The root node is the first in the scene tree, appering as the "main folder" for all nodes of your scene if you prefer. The item.gd 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.

A Node2D as root

This is the "cannonical" 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 item.gd 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 previsously is an example of such an item structure, with just a Node sprite added to show the corresponding picture.

A Control as root

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 item.gd 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 in 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

A Position2D as root

When using a Position2D as root, your item can be empty; no graphics, no animations, no input. These types of empty items are usually used as position markers, 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

TO COMPLETE IF WE CAN COMPLETE THE MINI-GAME WITH A DOOR EXAMPLE

Item properties

Items have many properties, mostly provided by the item.gd script. Properties names are shown upper case with spaces in the Godot interface (for exemple Events Path) but should be named lower case with dashes in the scripts : events_path.

Among all properties, some are more important.

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 global id of the item to display or hide and the value true to make it visible or false any 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 those informations 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 sarting with :the_action_name will be executed (for example :use), so you can have multiple responses to multiple actions in a single script.

:pick_up
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 event should have an 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 animation chapter for more information on state and animation relationship).

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 lightbulb item might have 3 states, "on", "off" and "broken". The scene might have an elaborate animation for breaking the lightbulb, glass shattering, sparks particles, etc. But after the "broken" state is set on the lightbulb (in esc script "set_state lightbulb broken"), we only want to show the already broken lightbulb. When the game is loaded, the "broken" state is set on the lightbulb, and the animation simply shows a broken lightbulb.

The animations chapter gives an example on how to use state based on our mini game. Notice that the name of the state are completely let to user wish because states will really depend on the story and the interactions needed.

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 enable the action menu 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.