Code-Frameworks
Wie Fabled deinen Code ausführt
Verfolge ein Projekt von der Quelle bis zum Spiel: was wann läuft, wie das Ledger funktioniert und was ein Szenario beweist.
Von der Quelle zum Spiel
Dein Projekt durchläuft fünf Schritte. Nur der letzte ist das Spielen. Die Schritte davor ändern nie einen laufenden Charakter.
- Schreiben
Du bearbeitest die Quelldateien im Quelltext-Editor. Noch läuft nichts.
- Prüfen
Prüfen und Vorschau kompiliert deine aktuellen Änderungen und führt jedes Szenario aus, gespeichert oder nicht. Probleme erscheinen im Bereich Probleme. Nichts wird veröffentlicht.
- Speichern
Projekt speichern hält die Quelle als neue Version deines Spiels fest. Vorbereiten funktioniert nur mit einer gespeicherten Version, also speichere vorher.
- Vorbereiten
Mein Spiel vorbereiten baut private Frameworks, Frames und Inhalte aus der gespeicherten Version. Der Server prüft das Projekt erneut, und sein Urteil zählt.
- Spielen
Ein Spieler erstellt einen Charakter aus deinem Framework. Der Konstruktor baut ihn, und Aktionen verändern ihn.
Was wann läuft
| Teil | Wann er läuft | Was er tut |
|---|---|---|
| Konstruktor | Einmal, wenn aus dem Framework ein Element erstellt wird. | Macht aus den Eingaben die Startwerte. Er schreibt nie. |
| Ledger-Funktion | Wenn das Element gebaut wird, in der Reihenfolge, in der das Schema die Funktionen deklariert, und nach jeder Aktion noch einmal. | Leitet einen Wert aus gespeicherten Werten ab. Eine Aktion kann ihn nicht schreiben. |
| Aktion | Wenn ein Spieler eine Schaltfläche nutzt, die sie aufruft. | Schreibt mit ledger.set und ledger.add ins Ledger. |
| Frame | Immer, wenn der Bogen angezeigt wird. | Liest gespeicherte Werte und zeichnet sie. Seine Schaltflächen rufen Aktionen auf. |
| Szenario | In Prüfen und Vorschau, nie im Spiel. | Baut ein Element, führt Aktionen aus und vergleicht jeden Wert und jeden Schreibvorgang. |
Das Ledger
Die Werte eines Elements werden nie direkt bearbeitet. Jede Änderung ist ein Schreibvorgang in seinem Ledger. ledger.set ersetzt einen Wert, und ledger.add addiert zu ihm. Szenarien listen diese Schreibvorgänge auf, so siehst du genau, was eine Regel tut.
Ein abgeleiteter Wert kommt aus einer Ledger-Funktion, deshalb darf eine Aktion ihn nicht schreiben. Die Prüfung lehnt das ab:
which is a non-writable state fieldDer Konstruktor gibt ein Feld, das eine Ledger-Funktion ableitet, trotzdem zurück, mit einem Platzhalter wie 0. Die Ledger-Funktion ersetzt den Platzhalter, wenn das Element gebaut wird. Ein Szenario vergleicht seine expectedValues mit den Werten, nachdem die Ledger-Funktionen gelaufen sind. Schreibe dort also den abgeleiteten Wert, nicht den Platzhalter.
Ledger-Funktionen laufen in der Reihenfolge, in der das Schema sie deklariert, und jede sieht die Ergebnisse der früheren. Deklariere eine Funktion nach den Funktionen, deren Felder sie liest. Hier liest total das Feld base, wird aber zuerst deklariert, also liest es den Platzhalter:
{
"ledgerFunctions": [
{
"id": "total",
"name": "Total",
"field": "total",
"source": "rules/total.ts"
},
{
"id": "base",
"name": "Base",
"field": "base",
"source": "rules/base.ts"
}
]
}expectedValues.total: expected 11, constructor returned 1Nutze eine Ledger-Funktion für einen Wert, der anderen Feldern folgen muss und den keine Aktion schreibt. Nutze einen Konstruktorwert für eine Zahl, die dem Charakter gehört und die Aktionen ändern, zum Beispiel hp. Der Konstruktor berechnet sie nur einmal, eine spätere Änderung der Felder, aus denen sie kam, verschiebt sie also nicht.
Was ein Szenario beweist
- Der Konstruktor gibt die Werte zurück, die du erwartest.
- Jede Aktion macht genau die Schreibvorgänge, die du auflistest.
- Abgeleitete Werte stimmen, auch nach einer Aktion.
- Jede Datei wird genutzt, und das ganze Projekt kompiliert.
Ein Szenario beweist nicht, wie ein Bogen aussieht oder wie sich eine Regel im Spiel anfühlt. Probiere dafür das vorbereitete Spiel aus.