Où vit un script
Le même script se comporte différemment selon ce à quoi vous l'attachez. Choisir le niveau compte généralement plus que le code.
| Attaché à | Tourne tant que | Meurt quand |
|---|---|---|
| Un objet | cet objet est à l'écran | il est masqué, désactivé ou supprimé |
| Une scène | cette scène est active | on quitte la scène |
| Un space | le visiteur est dans ce space | il passe à un autre space |
| Le projet | toujours, dans chaque space | il s'en va |
Sur un objet
Le choix par défaut, et le bon pour un comportement qui appartient à une chose : une porte qui s'ouvre, un ennemi qui poursuit, un bouton qui réagit.
Son ctx.entity est cet objet, et il s'arrête à l'instant où l'objet s'arrête — ce qui est une
qualité. Vous ne nettoyez jamais après le script d'un objet qui n'existe plus.
Sur une scène
Ajouté dans la section Scripts de la scène. Servez-vous-en pour la logique concernant la scène dans son ensemble : enchaîner une introduction, compter combien d'objets à collecter restent, décider quand le visiteur peut avancer.
Il démarre quand la scène devient active et s'arrête avec elle — dans un projet AR, il démarre donc à la détection.
Sur un space
Ajouté dans la section Scripts du space. Celui-ci survit aux changements de scène, et c'est tout l'intérêt : un score qui traverse trois scènes, un minuteur pour toute la visite, un contrôleur qui décide quelle scène vient ensuite.
Une entity avec un comportement et sans parent n'appartient à aucune scène. Elle continue de tourner pendant que les scènes se succèdent, et tout événement adressé finit par l'atteindre — l'itinéraire est objet, puis scène, puis space.
Sur le projet
Ajouté dans les réglages du projet. Injecté dans chaque space, il est donc là où que le visiteur aille.
Recourez-y quand quelque chose doit survivre à un changement de space : les choix du visiteur, un compteur de progression global, les analytics.
Ce qui survit à quoi
| Stocké dans | Un changement de scène | Un changement de space | Un rechargement |
|---|---|---|---|
une variable dans init | si le script vit | si le script vit | non |
ctx.store | oui | non | non |
| un global | oui | oui | non |
un global @space: | oui | non — isolé exprès | non |
Ni store, ni les globals, ni quoi que ce soit. Si une valeur doit être là la prochaine fois,
envoyez-la quelque part chez vous pendant que le visiteur est encore sur la page.
Choisir, en une question
Quelle est la plus petite chose dont parle cette logique ?
- à propos d'un objet → posez-la sur l'objet ;
- à propos de cette scène → posez-la sur la scène ;
- à propos de toute la visite → posez-la sur le space, ou sur le projet s'il y a plusieurs spaces.
Tout mettre au niveau du projet « pour être tranquille » fonctionne, puis cesse de fonctionner : un script de projet ne peut supposer aucune scène chargée en particulier, et finit donc bourré de vérifications d'existence dont un script au niveau de l'objet n'aurait jamais eu besoin.
Les patches suivent la même règle
Un patch peut lui aussi être attaché à n'importe lequel de ces niveaux, avec les mêmes durées de vie. Un patch au niveau du projet est la façon habituelle de bâtir un contrôleur global sans écrire de code.
Suite : L'API ctx