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:
Here is an example with the bad bamboo of our mini-game:
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 item.gd 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 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.
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 item.gd script will look for the following children to provide certain functionalities to the items:
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.
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.
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):
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.
TO COMPLETE IF WE CAN COMPLETE THE MINI-GAME WITH A DOOR EXAMPLE
Items have many properties, mostly provided by the item.gd 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 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.
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
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.
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.
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.
There are of course many other properties as follows:
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.