Bewährte Methoden und Checkliste für den Start

Hier sind einige bewährte Methoden für verschiedene Phasen des Spiellebenszyklus, um PlayFab Multiplayer Servers (MPS) optimal zu nutzen:

Entwicklung

• Verwenden Sie LocalMultiplayerAgent (LMA) für iterative Tests auf Ihrer lokalen Arbeitsstation. Dies spart Zeit und Geld und vereinfacht das Debuggen, da alle Artefakte lokal ausgeführt werden. Das Tool ist Open Source und Beiträge / Verbesserungen sind immer willkommen. Weitere Informationen zur Verwendung finden Sie hier

• Legen Sie fest, dass Ihr Spielserverprozess beendet wird, wenn seine Spielsitzung beendet ist, z. B. wenn das Spiel endet oder wenn der letzte verbundene Spieler das Spiel verlässt. Wenn Ihr Spiel es Spielern ermöglicht, sich erneut zu verbinden, warten Sie zunächst einen kurzen Aktivierungszeitraum ab. MPS beendet keine Spielsitzung für Sie. Ein Server bleibt aktiv, bis sein Prozess beendet wird. MPS entfernt keine aktiven Server, wenn Ihr Build herunterskaliert wird, sodass ein Server, der nie beendet wird, weiterhin die Kapazität verwendet, für die Sie bezahlen. Wenn der Prozess beendet ist, ersetzt MPS ihn durch einen neuen Server. Weitere Informationen finden Sie unter Lebenszyklus eines Multiplayer-Servers.

• Starten Sie einen Timer, wenn Ihr Server aktiv wird, z. B. wenn die ReadyForPlayers Methode des Game Server SDK (GSDK) zurückkehrt true. Wenn innerhalb weniger Minuten keine Verbindung mit dem Player hergestellt wird, beenden Sie den Vorgang. Auf diese Weise bleibt ein Server, dem niemand beitritt, aus welchen Gründen auch immer, nicht auf unbestimmte Zeit aktiv. Richte das Timeout danach aus, wie lange deine Spieler normalerweise brauchen, um eine Verbindung herzustellen.

• Registrieren Sie einen GSDK-Rückruf zum Herunterfahren, der die vom Server benötigten Bereinigungen durchführt und den Prozess dann beendet. Das GSDK beendet den Prozess nicht für Sie. MPS ruft Ihren Rückruf auf, wenn Sie die ShutdownMultiplayerServer-API aufrufen. Rufen Sie diese API nur im Notfall auf, z. B. um festgefahrene Spielserver zu beenden. Verwenden Sie sie nicht, um Spielsitzungen unter normalen Umständen zu beenden. Ihre Spielserver sollten sich eigenständig beenden, wie weiter oben in diesem Abschnitt beschrieben. Wenn der Prozess 15 Minuten nach einer Anforderung zum Herunterfahren immer noch ausgeführt wird, beendet MPS ihn zwangsweise. Weitere Informationen finden Sie unter Ordnungsgemäßes Herunterfahren Ihres Spielservers.

• Verwenden Sie Zeitpläne, um konkrete Zeitpläne aufzustellen, um die Kosten des standingBy-Servers zu sparen. Wenn z. B. alle Tests und Validierungen während der Geschäftszeiten durchgeführt werden, kann der Zeitplan so festgelegt werden, dass Standbyserver nur während der Geschäftszeiten bereitgestellt werden. Für das Einrichten von Zeitplänen fallen keine zusätzlichen Kosten an.

• Verwende VM-Metriken oder deine eigenen Profiler , um zu entscheiden, wie viele Spielserver auf einer VM der von dir gewählten Größe ausgeführt werden sollen. Auslastungstest mit jedem Server auf der VM Aktiv und voller Spieler. Server auf derselben VM können fast zur gleichen Zeit zugewiesen werden und ihre Spielsitzungen starten. Beziehen Sie also diesen Fall in Ihre Tests ein. CPU-Spielraum lassen: Auf einem virtuellen Computer, dessen CPU überlastet ist, können die Zuordnungen langsam sein oder fehlschlagen.

• Verwenden Sie Serverprotokolle und Absturzabbilder für eine tiefere Analyse.

Startbereitschaft

• Passen Sie Ihre Zuordnungsanforderungen auf Buildaliase an. Sie helfen bei der nahtlosen Migration von Spielclients zu neueren Spielservern im Rahmen von Serverupdates und können auch bei der Verwaltung von Kontingentproblemen helfen (siehe unten).

• Verwenden Sie die QoS-Beacons , um die nächstgelegene Region für einen Spielclient zu verfolgen und diese für Zuordnungen zu verwenden. Diese können auch mit PlayFab Matchmaking kombiniert werden, um Clients mit ähnlichen Latenzen zu gruppieren und einen Server zuzuweisen, der ihnen am nächsten ist.

• Nutzen Sie die gesamte geografische Abdeckung von PlayFab MPS, um sicherzustellen, dass sich die Spielserver immer in der Nähe Ihrer Spieler befinden. Erwägen Sie die Verwendung mehrerer Regionen in einem geografischen Gebiet, um bei regionalen Ausfällen eine höhere Verfügbarkeit zu ermöglichen. Wenn Sie beispielsweise Server in Nordeuropa und Westeuropa haben und beide Regionen in der Zuordnungsanforderung (in der Prioritätsreihenfolge) angeben, kann eine Zuordnung, die in einer Region fehlschlägt, in der nächsten Region der Liste erfolgreich sein.

• Wenn Sie gegen einen Build-Alias zuweisen, listen Sie alle Regionen, die Ihren Spielern ein akzeptables Erlebnis bieten, in PreferredRegionsder Reihenfolge ihrer Präferenz auf. MPS testet Ihre Regionen in dieser Reihenfolge, und die Buildgewichtungen entscheiden nur, welcher Build eine Anforderung innerhalb einer Region bedient. Ein Build mit einer Gewichtung von 0 wird nie verwendet, auch nicht als Fallback. Weitere Informationen finden Sie unter Fallback auf andere Builds und Regionen.

• Wenn RequestMultiplayerServer mit dem MultiplayerServerTooManyRequests Fehler fehlschlägt, hatte keiner der Builds einen StandingBy-Server in einer der angeforderten Regionen. Trotz seines Namens bedeutet dieser Fehler nicht, dass Ihre Anforderungen gedrosselt sind. Gehen Sie folgendermaßen vor, um dies zu vermeiden:

  • Listen Sie mehrere nahe gelegene Regionen in PreferredRegionsauf.
  • Stellen Sie Ihre Standbyserver auf die erwartete Spitze ein.
  • Legen Sie die maximale Anzahl von Servern für jede Buildregion mit einem Spielraum über Ihrem erwarteten Spitzenwert fest. MPS erstellt keine Server, die über dieses Maximum hinausgehen, selbst wenn der Standby-Modus abgelaufen ist.

• Fordern Sie das Kontingent rechtzeitig vor der Markteinführung für jede VM-Familie und -Region an, die in Ihren Builds verwendet wird. Wenn Sie einen neuen Build ausrollen, verwenden der alte und der neue Build gleichzeitig Kerne, bis die Server des alten Builds leer sind. Fordern Sie daher ein ausreichendes Kontingent für beide an. Um Ihre Kapazität zu verteilen, sollten Sie Builds mit unterschiedlichen VM-Familien unter demselben Alias platzieren, damit Zuordnungen auf eine andere VM-Familie in derselben Region zurückgreifen können.

• Es kann Fälle geben, in denen die VM-SKU für Ihren Spielserver nicht in allen Regionen verfügbar ist, in denen das Spiel gestartet werden soll. Verwenden Sie in solchen Fällen entweder Aliase, um Builds nach SKUs und Regionen aufzuteilen, oder verwenden Sie Regionsüberschreibungen innerhalb eines einzelnen Builds, um eine andere VM-SKU nur für diese Regionen auszuwählen.

• Verwenden Sie Dynamic StandingBy , um Spielserver basierend auf dem Bedarf hochzuskalieren. In Kombination mit der standardmäßigen statischen standingBy-Konfiguration kann dies eine kostengünstige Möglichkeit bieten, eine hohe Nachfrage während des Starts zu bewältigen.

• Richten Sie vor dem Start die Überwachung für Ihre Spielserver ein. Aktivieren Sie VM-Metriken , um CPU-, Arbeitsspeicher-, Festplatten- und Netzwerkmetriken für Ihre VMs in Game Manager anzuzeigen. Verwenden Sie für eine erweiterte Überwachung VmStartupScript , um Ihre eigenen Überwachungstools auf Ihren VMs zu installieren. Das VmStartupScriptGallery-Repository enthält Beispiele, die VM-Metriken und Spielserverprotokolle an Dienste wie Azure Monitor, Application Insights und Azure Data Explorer senden.

Veröffentlichungstag

• Verfolgen Sie den erfolgreichen Start Ihres Spiels mit den Dashboards und Ereignisströmen in PlayFab Game Manager. Nehmen Sie sich Zeit zum Feiern, Sie haben sie sich verdient!

Nach dem Start

• Spiele neigen dazu, in einen Nachfragerhythmus zu fallen, der wiederum in Zeitpläne zusammengesetzt werden kann. Verwenden Sie die Zeitpläne zusammen mit Dynamic StandingBy für eine kostengünstige Spielskalierung nach dem Start.

• Verwenden Sie Build-Aliase für Spieleserver-Updates und die schrittweise Gestaltung des Datenverkehrs für die neue Spielerfahrung.

• Wenn Sie einen Alias zu neuen Builds verschieben, setzen Sie die Standbyserver der alten Builds auf 0, damit MPS seine im Leerlauf befindlichen VMs freigeben kann. Löschen Sie die alten Builds erst, nachdem ihre aktiven Server leer sind. Halten Sie außerdem die Regionen, die Ihre Clients anfordern, mit den Regionen synchron, in denen die Builds des Alias bereitgestellt werden. Wenn keiner der Builds des Alias in einer der angeforderten Regionen bereitgestellt wird, schlägt die Anforderung mit MultiplayerServerNotFoundfehl.