Adressage

Nous avons deux composants «controller» distincts, un dans chaque GameObject, rien d’anormal puisque chaque GameObject crée un nouveau contexte de dénomination. </div>

Puisque le destinataire du message se trouve en dehors du GameObject «bean» (l’expéditeur), le code doit indiquer quel «controller» doit recevoir le message. Il doit spécifier à la fois l’id du GameObject cible ainsi que celui du composant. L’adresse complète du composant devient « buddy#controller » et cette adresse se compose de deux parties distinctes.

• Première partie: L’identité du GameObject cible («buddy»),
• Le caractère séparateur GameObject/Composant (“#”),
• Deuxième partie: L’identité du composant cible (“controller”).

En revenant à l’exemple précédent contenant un seul GameObject, nous voyons qu’en laissant de côté l’identifiant du GameObject de l’adresse cible, le code peut adresser des composants dans le GameObject actuel.

Par exemple, "#body" désigne l’adresse du composant “body” dans le GameObject actuel. Ceci est très utile car ce code fonctionnera dans n’importe quel GameObject, tant qu’un composant “body” est présent.

Collections

Les Collections permettent de créer des groupes ou des hiérarchies de GameObjects et de les réutiliser de manière contrôlée. Vous utilisez des fichiers de collection comme modèles (“prototypes” ou “prefabs”) dans l’éditeur lorsque vous peuplez votre jeu avec du contenu.

Supposons que vous souhaitiez créer un grand nombre d’équipes bean/buddy. Un bon moyen de le faire est de créer un modèle dans un nouveau fichier de collection collection file (nommez-le «team.collection»). Créez les GameObjects d’équipe dans la collection et enregistrez. Ensuite, placez une instance de team.collection dans la collection principale et donnez à l’instance un identifiant (nommez-la “team_1”) :

Avec cette structure, le GameObject “bean” peut toujours faire référence au composant “controller” dans “buddy” par l’adresse "buddy#controller".

Ajoutez une deuxième instance de “team.collection” (nommez-la “team_2”), le code exécuté dans les composants du script “team_2” fonctionnera tout aussi bien. L’instance du GameObject “bean” de la collection “team_2” peut toujours adresser le composant “controller” dans “buddy” par l’adresse "buddy#controller".

Adressage relatif

L’adresse "buddy#controller" fonctionne pour les GameObjects dans les deux collections car il s’agit d’une adresse relative. Chacune des collections “team_1” et “team_2” crée un nouveau contexte de dénomination, ou “namespace” (espace de nom). Defold évite les collisions de noms en prenant en compte le contexte de dénomination créé par une collection pour l’adressage:

• Dans le contexte de dénomination “team_1”, les GameObjects “bean” et “buddy” sont identifiés de manière unique.
• De même, dans “team_2”, “bean” et “buddy” sont également identifiés de manière unique.

L’adressage relatif fonctionne en ajoutant automatiquement le contexte de dénomination actuel lors de la résolution d’une adresse cible. Ce qui est très utile et puissant car vous pouvez créer des groupes de GameObjects avec du code et les réutiliser efficacement tout au long du jeu.

Raccourcis

Defold fournit deux raccourcis pratiques que vous pouvez utiliser pour envoyer un message sans spécifier l’URL complète:

.

Shorthand resolving to the current game object.

#

Shorthand resolving to the current component.

For example:

   -- Let this game object acquire input focus
   msg.post(".", "acquire_input_focus")

   -- Post "reset" to the current script
   msg.post("#", "reset")

Les chemins des GameObjects

Pour comprendre correctement le mécanisme de dénomination, regardons ce qui se passe lorsque vous créez et exécutez le projet :

1. L’éditeur lit la collection en partant de la racine (“main.collection”) et tout son contenu (GameObjects et autres collections).
2. Pour chaque GameObject statique, le compilateur crée un identifiant. Ceux-ci sont construits sous forme de «paths» (chemins) commençant par la racine et descendant dans la hiérarchie de la collection jusqu’au GameObject. Un caractère ‘/’ est ajouté à chaque niveau.

Dans l’exemple ci-dessus, le jeu se déroule avec les 4 GameObjects suivants :

• /team_1/bean
• /team_1/buddy
• /team_2/bean
• /team_2/buddy

local my_id = go.get_id()
print(my_id) --> hash: [/path/to/the/object]

local spawned_id = factory.create("#some_factory")
print(spawned_id) --> hash: [/instance42]

local spawned_id = factory.create("#some_factory")
local pos = vmath.vector3(100, 100, 0)
go.set_position(pos, spawned_id)

local other_id = hash("/path/to/the/object")
go.set_position(pos, other_id)

-- This will not work! Relative addresses must be given as strings.
local relative_id = hash("my_object")
go.set_position(pos, relative_id)

-- Send "hello" to the manager script and team buddy bean
msg.post("main:/manager#controller", "hello_manager")
msg.post("main:/team_2/buddy#controller", "hello_buddy")

-- Construct URL object from a string:
local my_url = msg.url("main:/manager#controller")
print(my_url) --> url: [main:/manager#controller]
print(my_url.socket) --> 786443 (internal numeric value)
print(my_url.path) --> hash: [/manager]
print(my_url.fragment) --> hash: [controller]

-- Construct URL from parameters:
local my_url = msg.url("main", "/manager", "controller")
print(my_url) --> url: [main:/manager#controller]

-- Build from empty URL object:
local my_url = msg.url()
my_url.socket = "main" -- specify by valid name
my_url.path = hash("/manager") -- specify as string or hash
my_url.fragment = "controller" -- specify as string or hash

-- Post to target specified by URL
msg.post(my_url, "hello_manager!")