Wo ein Skript wohnt
Dasselbe Skript verhält sich unterschiedlich, je nachdem, woran Sie es hängen. Die Ebene zu wählen ist meist wichtiger als der Code.
| Gehängt an | Läuft, solange | Stirbt, wenn |
|---|---|---|
| Ein Objekt | dieses Objekt auf dem Bildschirm ist | es verborgen, deaktiviert oder gelöscht wird |
| Eine Szene | diese Szene aktiv ist | die Szene verlassen wird |
| Einen Space | der Besucher in diesem Space ist | er in einen anderen Space wechselt |
| Das Projekt | immer, in jedem Space | er geht |
An einem Objekt
Die Voreinstellung und die richtige Wahl für Verhalten, das zu einem Ding gehört: eine Tür, die aufgeht, ein Gegner, der verfolgt, ein Button, der reagiert.
Sein ctx.entity ist dieses Objekt, und es hört in dem Moment auf, in dem das Objekt aufhört — was
eine Stärke ist. Sie räumen nie hinter dem Skript eines Objekts auf, das es nicht mehr gibt.
An einer Szene
Im Abschnitt Scripts der Szene hinzugefügt. Nehmen Sie es für Logik über die Szene als Ganzes: eine Einleitung takten, zählen, wie viele Sammelstücke übrig sind, entscheiden, wann der Besucher weiterdarf.
Es startet, wenn die Szene aktiv wird, und stoppt mit ihr — in einem AR-Projekt startet es also bei der Erkennung.
An einem Space
Im Abschnitt Scripts des Space hinzugefügt. Dieses überlebt Szenenwechsel, und darum geht es: ein Punktestand, der drei Szenen überdauert, ein Timer für den ganzen Besuch, ein Controller, der entscheidet, welche Szene als Nächstes kommt.
Eine Entity mit Verhalten und ohne Elternobjekt gehört zu keiner Szene. Sie läuft weiter, während Szenen kommen und gehen, und jedes adressierte Ereignis erreicht sie irgendwann — die Route ist Objekt, dann Szene, dann Space.
Am Projekt
In den Projekteinstellungen hinzugefügt. Es wird in jeden Space eingespeist, ist also da, wohin der Besucher auch geht.
Greifen Sie danach, wenn etwas einen Space-Wechsel überdauern muss: die Entscheidungen des Besuchers, ein Gesamtfortschritt, Analytics.
Was was überlebt
| Gespeichert in | Einen Szenenwechsel | Einen Space-Wechsel | Ein Neuladen |
|---|---|---|---|
einer Variablen in init | wenn das Skript lebt | wenn das Skript lebt | nein |
ctx.store | ja | nein | nein |
| einem Global | ja | ja | nein |
einem @space:-Global | ja | nein — bewusst isoliert | nein |
Nicht store, nicht Globals, gar nichts. Muss ein Wert beim nächsten Mal da sein, schicken Sie ihn
irgendwohin zu sich, solange der Besucher noch auf der Seite ist.
Die Wahl, in einer Frage
Worüber handelt diese Logik im kleinstmöglichen Sinn?
- über ein Objekt → an das Objekt;
- über diese Szene → an die Szene;
- über den ganzen Besuch → an den Space, oder an das Projekt, wenn es mehrere Spaces gibt.
Alles „sicherheitshalber" auf Projektebene zu legen funktioniert, und dann funktioniert es nicht mehr: Ein Projektskript kann keine bestimmte geladene Szene voraussetzen und steckt am Ende voller Existenzprüfungen, die ein Skript auf Objektebene nie gebraucht hätte.
Patches folgen derselben Regel
Ein Patch lässt sich ebenfalls an jede dieser Ebenen hängen, mit identischen Lebensdauern. Ein Patch auf Projektebene ist der übliche Weg, einen globalen Controller zu bauen, ohne Code zu schreiben.
Weiter: Die ctx-API