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 :
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 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.
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:
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.
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 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):
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.
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 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 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 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
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.
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.
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.
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.
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.