Gemeinsamen Monster-Raid erstellen

Sie erstellen einen Echtzeit-Raid, in dem mehrere Mitglieder dasselbe Monster angreifen und die Ergebnisse teilen, bis dessen Lebenspunkte 0 erreichen. Der gemeinsame shared-resource-Handler von Webspace verarbeitet Angriffe, Änderungen der Lebenspunkte und die Belohnung pro Aktion zusammen auf dem Server.

Bevor Sie beginnen

Sie benötigen die Berechtigung, Schemas und APIs bereitzustellen.
Die Berechtigungen send und receive der Echtzeitfunktion müssen den Mitgliedern erteilt werden, die sie nutzen sollen.
Die API zum Erstellen von Raid-Zielen konfigurieren Sie so, dass nur Administratoren sie verwenden können.

Mit dem fertigen Schema starten

Spielschema für gemeinsame Ressourcen (.sfn) herunterladen: Die Datei enthält die Spalten und Berechtigungen der drei in diesem Dokument verwendeten Tabellen sowie die Konfiguration des shared-resource-Handlers. Alle Sprachversionen dieser Anleitung verwenden dieselbe Datei mit Tabellen- und Spaltenbeschreibungen auf Englisch.

Laden Sie die Datei herunter, legen Sie sie in einem Teamordner oder persönlichen Ordner ab und öffnen Sie sie im Schema-Editor.
Prüfen Sie in den Bereitstellungseinstellungen von API-Erstellung die Datenbankkennung. Ändern Sie den Standardwert resource_game in eine neue Kennung wie monster_raid_team_a, damit er sich nicht mit einer vorhandenen Datenbank überschneidet.
Prüfen Sie die Berechtigungen und die Handler-Konfiguration und stellen Sie das Schema anschließend bereit.

Diese Datei ist ein Beispiel für die Backend-Struktur gemeinsamer Ressourcen. Da includeClient auf false gesetzt ist, wird keine Spieloberfläche automatisch erzeugt, und auch anfängliche Monsterdaten sind nicht enthalten. Sie müssen eine Oberfläche, die die folgenden APIs und WebSocket-Ereignisse nutzt, separat erstellen und auch das Raid-Ziel anlegen.

Daten in drei Tabellen aufteilen

Die Struktur für gemeinsame Ressourcen trennt die folgenden drei Arten von Daten.

Tabelle	Gespeicherte Inhalte
`game_resources`	Monstercode, Status, aktuelle und maximale Lebenspunkte, Version und Belohnungsgegenstand
`game_actions`	Aktions-ID, angreifendes Mitglied, angewendeter Schaden, resultierende Lebenspunkte und Belohnungsmenge
`game_inventory`	Gegenstände und kumulierte Mengen pro Mitglied

Die Aktions-ID in game_actions unterscheidet Wiederholungsversuche. Wird dieselbe Aktions-ID erneut gesendet, werden Lebenspunkte und Belohnung nicht doppelt angewendet.

Echtzeit-Handler konfigurieren

Schalten Sie die Echtzeitfunktion ein und wählen Sie als Ereignis-Handler shared-resource. Mit den Standard-Tabellennamen hat die Handler-Konfiguration folgende Struktur.

{
  "resourcesTable": "game_resources",
  "actionsTable": "game_actions",
  "inventoryTable": "game_inventory",
  "actionPower": 1,
  "rewardPerAction": 1,
  "maxClientAmount": 1,
  "broadcast": "namespace"
}

Ist broadcast auf namespace gesetzt, erhalten alle Clients, die mit demselben Echtzeit-Namespace des Webspace verbunden sind, das Ergebnisereignis gemeinsam. Bei actor wird das Ergebnis nur an das Mitglied gesendet, das die Aktion ausgeführt hat.

Raid-Ziel erstellen

Rufen Sie mit Administratorberechtigung game_resources/create auf, um das Monster zu erstellen.

{
  "code": "RAID-1",
  "kind": "monster",
  "status": "active",
  "current_value": 10000,
  "max_value": 10000,
  "version": 0,
  "reward_item_code": "monster-core"
}

Beim Öffnen der Oberfläche lesen Sie die aktuellen Lebenspunkte und die Version über die Abfrage-API von game_resources. Auch nach einer neuen Verbindung oder einer wiederhergestellten Verbindung können Sie die REST-API erneut abfragen, um die Oberfläche am aktuellen Serverstatus auszurichten.

Angriff per WebSocket senden

Nachdem ein angemeldetes Mitglied die Echtzeitverbindung abonniert hat, sendet es das Ereignis resource-game.act.

{
  "type": "webspace:send",
  "data": {
    "dbName": "monster_raid_team_a",
    "event": "resource-game.act",
    "payload": {
      "actionId": "attack-00000001",
      "resourceCode": "RAID-1",
      "amount": 1
    }
  }
}

Für dbName verwenden Sie die bei der Bereitstellung festgelegte Datenbankkennung.

actionId ist ein 8 bis 80 Zeichen langer Wert aus lateinischen Buchstaben, Ziffern, _ und -. Wird amount weggelassen, gilt 1; wenn Sie einen Wert senden, verwenden Sie eine Ganzzahl innerhalb des Bereichs von maxClientAmount des Handlers.

Nach Abschluss der Verarbeitung sendet der Server resource-game.action-applied.

{
  "actionId": "attack-00000001",
  "resourceId": 1,
  "currentValue": 9999,
  "version": 1,
  "rewardQuantity": 1,
  "duplicate": false
}

Die Oberfläche ändert die Lebenspunkte erst, nachdem sie dieses Ergebnis erhalten hat. Anfragen, in denen ein Client resource-game.action-applied direkt sendet, werden abgelehnt.

Lebenspunkte und Belohnungen anzeigen

Prüfen Sie, ob resourceId das aktuell angezeigte Monster ist.
Prüfen Sie, ob version größer ist als beim vorherigen Ergebnis.
Aktualisieren Sie die Anzeige der Lebenspunkte mit currentValue.
Ist currentValue 0, zeigen Sie den Status „gemeinsam besiegt“ an.
Persönliche Gegenstände fragen Sie erneut über game_inventory/list ab.

Auf game_inventory wenden Sie eine Eigentümerberechtigung an, sodass Mitglieder nur ihre eigenen Daten lesen können. Leiten Sie aus rewardQuantity im Ergebnisereignis nicht die Bestände anderer Mitglieder ab.

Hinweise

Angriffsstärke und Belohnung werden nicht durch Client-Werte, sondern durch die Handler-Konfiguration auf dem Server bestimmt.
Ressourcenänderung, Aktionsprotokoll und Gutschrift der Belohnung werden in einer einzigen Transaktion verarbeitet.
Die aktuelle gemeinsame Struktur vergibt Belohnungen pro Aktion. Ranglisten für das Besiegen oder Belohnungen ausschließlich für den Besieger müssen Sie separat entwerfen.
Eine verzögerte Antwort gilt nicht als Erfolg. Durch eine erneute Prüfung mit derselben actionId verhindern Sie eine doppelte Anwendung.