Euer nächstes Feature

Matches

Rundenbasierte Spiele mit expliziten Revisionen, undurchsichtigem Zustand und getrennten Ergebnisberichten.

SDK: developSpielersession erforderlich

Unity

Euer sichtbares Ergebnis

Koordiniert mit zwei Spielersitzungen eine Lobby, abwechselnde Züge und unabhängige Abschlussberichte.

Video folgt

Für diesen Schritt fehlt noch das Video. Die Anleitung und der MCP-Auftrag sind bereits nutzbar.

Rundenbasierte Matches

Dasselbe Projekt vorbereiten

Wählt im Dashboard dasselbe Projekt wie in eurer Spielkonfiguration.
Matches →
Für die erste Anfrage ist keine weitere Definition nötig. Ein leeres Ergebnis ist gültig, solange passende Spieldaten fehlen.
Verwendet zwei getrennte Spielersitzungen: Lobby erstellen, beitreten, mit expliziter Reihenfolge starten, abwechselnde Byte-Zustände senden und das gleiche Endergebnis unabhängig melden.
Dieses erste Beispiel liest Daten. Es erstellt keine Gruppe, keinen Match und kein Objekt. Eine leere Liste ist eine gültige erste Antwort.

Feature einbauen

Ihr könnt die Anleitung vorab ansehen. Zum Ausführen braucht ihr einen aktiven Projekt-Key. Projekt vorbereiten

SDK installiert, Projekt-Konfiguration importiert und Spieler angemeldet.

Dieses SDK-Beispiel nutzt develop. Prüft, ob die nötigen APIs in eurem installierten SDK verfügbar sind.

Verbindet zuerst den vorgesehenen Spieler über den Schnellstart. Ruft ReadMyMatches() ausdrücklich über einen Button oder eine Szenenaktion auf. Allein das Öffnen der Datei sendet keine Anfrage.

Assets/Scripts/MatchesDemo.cs

horizOn-Aufruf

1using UnityEngine;

2using PM.horizOn.Cloud.Manager;

4public sealed class MatchesDemo : MonoBehaviour

6 // Initialize/connect and restore the existing player in the Quickstart first.

7 // Invoke explicitly. The SDK also enforces the returned polling cadence.

8 public async void ReadMyMatches()

9 {

10 var user = UserManager.Instance.CurrentUser;

11 if (user == null || !user.IsValid()) return;

12 var result = await MatchesManager.Instance.GetMatches(user.UserId);

13 if (!result.IsSuccess) { Debug.LogWarning(result.ErrorCode); return; }

14 Debug.Log($"Ledger revision: {result.Data.revision}");

15 foreach (var match in result.Data.recent)

16 Debug.Log($"Match {match.id}: {match.status}");

17 // Recent may include an active match after this player's forfeit.

18 // Respect result.Data.pollAfterSeconds; no background poll or automatic timeout.

19 }

20}

21// Full two-player recipe: SDK Examples/MatchesExample and MatchesSampleStore.

22// ReadLedger/ReadMatch -> SaveCreateAfterLedgerReview/SaveActionAfterMatchReview.

23// ApplySavedIntent sends one durable original body/revision. Unknown create is reconciled.

24// Never replace a pending original with the revision from a later read.

25// ReportResult uses the original finalStateRevision/result bytes/sorted winnerIds.

26// Ordinary consensus is not trusted victory proof. Ranked runs use Validated Actions.

Vollständiges SDK-Beispiel öffnen ↗

Zwei Spieler, ein ursprünglicher Zug

Verwendet zwei getrennte Spielersitzungen: Lobby erstellen, beitreten, mit expliziter Reihenfolge starten, abwechselnde Byte-Zustände senden und das gleiche Endergebnis unabhängig melden.

Speichert die genaue Anfrage vor dem Senden. Lest nach einer Zeitüberschreitung den aktuellen Zustand und gleicht ihn ab. Ersetzt niemals still die Revision oder die Originalabsicht.

Berichte verwenden die unveränderliche Revision des Endzustands. Übereinstimmung ist kein vertrauenswürdiger Siegbeleg; Widersprüche oder fehlende Berichte bestimmen keinen Gewinner.

Ranglistenläufe benötigen ein bestätigtes Ranglistenmatch und die bestehende Validated-Actions-Pipeline. Gewöhnliche Matchberichte vergeben keine Belohnungen.

PHP unterstützt gewöhnliche Match-REST-Routen. Ranglistenprüfung und Echtzeit sind nicht verfügbar und liefern gegebenenfalls FEATURE_NOT_SUPPORTED.