PlayFab-Nutzung: Bewährte Methoden

Mit dem nutzungsbasierten Preismodell von PlayFab zahlen Sie nur für die tatsächliche Dienstnutzung Ihrer Titel. Dies wirft jedoch eine offensichtliche Frage auf: Wie optimieren Sie diese Titel am besten, um Geld zu sparen, während Sie trotzdem alle benötigten Features implementieren? In diesem Dokument gehen wir auf diese Details ein und sprechen über bewährte Methoden, die Sie bei der Planung im Voraus unterstützen.

Bevor Sie Ihre Titel aus dem Entwicklungsmodus in den Livemodus verschieben, können Sie die Verbrauchseinheiteninformationen auf der Registerkarte Abrechnungszusammenfassung des Game Managers überprüfen. Eine gute Ausgangsmethode besteht darin, die Verbrauchseinheiten regelmäßig mithilfe eines separaten Titels zu bestätigen, um die Nutzung der Verbrauchseinheit für reale Spieleraktivitäten zu überprüfen. Sie können mehrere Titel im Entwicklungsmodus verwenden, sodass Sie Titel während der Entwicklungsphase erstellen können, in denen Sie einen Prüfpunkt für diese Verwendung durchführen möchten, und diese Titel löschen können, nachdem Sie fertig sind.

Es gibt sechs Verbrauchseinheiten: Events, Profile, Content and Configuration, CloudScript, Insights und Multiplayer Services. Die beste Möglichkeit, mit der Optimierung eines Titels zu beginnen, besteht darin, die einzelnen Verbrauchseinheiten, die er verwendet, zu betrachten und zu sehen, wie er sich im Laufe der Zeit ansammelt. Dadurch können Sie schnell einige offensichtliche Verbesserungen ableiten. Weitere Informationen zu Verbrauchseinheiten finden Sie unter Preise für Verbrauchseinheiten.

Ereignisse

Es gibt zwei Arten von Ereignissen in PlayFab: PlayStream und Telemetry.

PlayFab verarbeitet PlayStream-Ereignisse, um zu überprüfen, ob sie von Ihnen definierte PlayStream-Aktionen auslösen, und um die Benutzersegmentierung zu aktualisieren. Einige PlayStream-Ereignisse werden automatisch als Ergebnis von Aufrufen von Dienstfeatures wie Authentifizierungs- und Statistikupdates generiert. Titel können eigene benutzerdefinierte Ereignisse generieren, um diese Funktionalität zu erweitern.

Telemetrieereignisse werden von PlayStream nicht verarbeitet. Diese Ereignisse werden für Analysen verwendet und werden direkt an das Data Warehouse gesendet. Telemetrieereignisse werden in PlayFab nicht automatisch generiert. Dabei handelt es sich um benutzerdefinierte Ereignisse, die vom Titel generiert werden.

Bei beiden Ereignistypen erhöhen größere Nutzlasten von Daten die Gesamtauslastung der Verbrauchseinheit. Sie können diese Gesamtnutzung reduzieren, indem Sie sicherstellen, dass Sie nur die benötigten Daten senden. Eine grobe Anleitung ist, dass jedes ereignisbasierte Ereignis die betreffende Verbrauchseinheit um 1 pro 1 KB Daten im Ereignistext erhöht.

Um auszuwählen, welcher Ereignispfad am besten zu Ihrer Nutzung passt, sollten Sie einen klaren Plan für die Verwendung der einzelnen von Ihnen generierten benutzerdefinierten Ereignisse haben. Ereignisse, die nur für die Offlineauswertung des Titels benötigt werden, sollten die Telemetrieroute durchlaufen. Dies kann dazu beitragen, die Kosten erheblich zu senken, da die Überschreitungsgebühren für Telemetrieereignisse weniger als die Hälfte des PlayStream-Werts betragen.

Wenn Sie eines der vorgefertigten SDKs verwenden, ist es wichtig zu beachten, dass einige Analysedaten zum Benutzerverhalten automatisch generiert werden, wie in der Referenz zum PlayStream-Ereignismodell beschrieben. Um optionale Ereignisse zu deaktivieren, ändern Sie die Analyseeinstellung auf der Registerkarte Einstellungen/Datensammlung Ihres Spiels im PlayFab-Spiel-Manager. Auch wenn es eine gute Idee ist, die Option "PlayStream-Ereignis generieren" für Ihre CloudScript-Ausführungen während des Debuggens aktiviert zu haben, sollten Sie dies vor der Liveschaltung deaktivieren. Im Fall von CloudScripts, die durch die PlayStream-Aktion ausgelöst wurden, können Sie diese jederzeit später aktivieren, wenn Sie ein Verhalten in der Natur debuggen müssen.

Profil

Das Profil ist praktisch "alles über den Spieler", einschließlich allgemeiner Elemente wie Bestand, gespeicherte Daten und Statistiken. Es enthält auch die Metainformationen, die Sie verwenden, um einzigartige Erfahrungen durch die LiveOps-Funktionen in PlayStream zu fördern, z. B. die oben erwähnte Benutzersegmentierung. Darüber hinaus sind einige Legacyfeatures auf Titelebene, z. B. Titeldaten, Kataloge und Speicher, in dieser Verbrauchseinheit enthalten, da ihre Datenimplementierung praktisch mit Benutzerdaten identisch ist. Da dieser Satz von Metern von allen Spieleraktionen und aktionen für Spieler gesteuert wird, ist es überwältigend, dass es die größte Optimierungsplanung erfordert.

Die wichtigsten Faktoren, die zur Nutzung beitragen, die von den Preiseinheiten erfasst wird, ist die Menge der Daten, die gelesen, gespeichert und geschrieben werden, und wie häufig Sie die APIs aufrufen, die getaktete Daten generieren.

Weitere Informationen zu den spezifischen API-Aufrufen, die zu "Drehung" für diese Verbrauchseinheiten führen, finden Sie unter Preise für Verbrauchseinheiten.

Wir beginnen mit Benutzerdaten und Statistiken, da ihre Nutzungsmuster ähnlich sind, und dann werden wir über die Verwaltung des Spielerbestands sprechen.

Daten und Statistiken

Beim Auswerten der Nutzung von Benutzerdaten gilt die gleiche Näherungslogik wie für Ereignisse – mit jeweils 1 KB erhöht sich die Verbrauchseinheitsanzahl um 1 . Beachten Sie jedoch, dass jedes "Element" eines Aufrufs für die Zwecke dieser Berechnung als unterschiedlich betrachtet werden sollte. Jedes Schlüssel-Wert-Paar in einem Aufruf zum Aktualisieren von Benutzerdaten wird separat gezählt. Bei Lesevorgängen gilt diese 1-KB-Berechnung für die zurückgegebenen Gesamtdaten, unabhängig von der Anzahl der Schlüssel-Wert-Paare. Dies bedeutet, dass das Schreiben von 10 Schlüsseln mit jeweils 100 Bytes 10 "Ticks" der Profilschreibeinheit ist, da jedes Schlüsselwertpaar schreiben mindestens 1 KB beträgt, während ein Lesevorgang dieser 10 Schlüssel 1 "Tick" ist, da es sich um eine Gesamtmenge von 1 KB handelt. Genauere Informationen zu den Nutzungen finden Sie unter Preise für Verbrauchseinheiten.

Statistiken sind etwas komplexer, da sie das Profil aktualisieren und sich auch auf Bestenlisten auswirken können. Im Allgemeinen können Sie sich jede Statistik, die aktualisiert wird, als vollständige Profilaktualisierung vorstellen, während Lesevorgänge auf der Gesamtgröße der in jedem Aufruf gelesenen Daten basieren. Und da der Speicherpreis pro Gigabyte (GB) berechnet wird und Statistiken in der Regel jeweils nur wenige Bytes verbrauchen, konzentrieren wir uns auf Lese- und Schreibvorgänge.

Da die Gesamtdatengröße wichtig ist, ist die Optimierung der erste Schritt. Glücklicherweise gibt es dafür eine Vielzahl bekannter Techniken– die Verwendung von Enumerationen oder IDs anstelle von geschriebenem Text für Elemente, das Packen großer Daten als Binärdaten oder sogar die Verwendung von Bitfeldern, um Daten in kleinere Räume zu packen. Danach besteht der nächste Schritt darin, sorgfältig zu bewerten, wann Sie diese Lese- und Schreibaufrufe ausführen müssen.

Wenn Sie aus der PC- oder Konsolenentwicklung kommen , insbesondere von Einzelspieler-Spielen, kann dies ein neues Muster sein. In diesen Umgebungen müssen Sie jedoch vorsichtig mit Ressourcentreffern und Garbage Collection auf dem Clientgerät sein, da diese zu kritischen Zeiten zu Leistungseinbußen führen können. Wenn Ihr Titel Ressourcen verwendet, die sich in der Cloud befinden, ist es notwendig, diese Logik zu erweitern, um zu berücksichtigen, dass jeder Ressourcentreffer neben den Leistungskosten auch echte Kosten hat.

Wie bestimmen Sie die optimale Häufigkeit von Lese- und Schreibvorgängen? Zwei der häufigsten Bedenken von Entwicklern, die Daten und Statistiken häufiger aktualisieren möchten, sind der Schutz vor Cheating und das Speichern rechtzeitiger Informationen auf serverseitiger Seite entweder für Interaktionen zwischen Spielern oder zur Verhinderung von Datenverlusten, wenn das Spiel unerwartet beendet wird.

Cheat Protection

Obwohl es den Anschein hat, dass Sie Ihre Back-End-Daten ständig aktualisieren müssen, um die grundlegende Sicherheit zu gewährleisten, sind häufige Updates selten erforderlich, wenn Ihr Spiel keine vollständige serverautoritative Kontrolle der Sitzung erfordert. Zunächst ist die grundlegende Frage, wie viel Sicherheit Sie tatsächlich benötigen.

Für einige Spiele, insbesondere solche, die hauptsächlich durch In-Game-Werbung monetarisieren und keine Bestenlisten haben, ist Betrug kein großes Problem. In diesem Fall ist die Vertrauenswürdigkeit der vom Client gesendeten Daten häufig ein brauchbarer Ansatz, da die Sicherheit dieser Daten nicht wirklich ein Problem darstellt. Um Betrugsverhalten zu identifizieren und zu entscheiden, wie Sie damit umgehen möchten, empfehlen wir Ihnen, Prozesse zum Überprüfen der Ereignisse, Daten und Statistiken Ihrer Spieler zu implementieren.

Für andere Spiele, in denen Sie die Integrität des Wettbewerbs unterstützen oder das gesamte Spielerlebnis schützen müssen, ist eine stärkere Sicherheit wichtiger. Abhängig von Ihren spezifischen Anforderungen können bestimmte Ansätze die Häufigkeit von Datenlese- und Schreibvorgängen in diesen Situationen reduzieren.

Wenn es sich bei Ihrem Spiel nicht um Echtzeit handelt, empfiehlt es sich, Informationen über das Spiel des Spielers über einen bestimmten Zeitraum hinweg zu aggregieren – häufig eine "Runde" des Spiels, die mehrere Minuten dauert – und diese Daten dann an ein Skript zu senden, das bestimmt, ob es gültig ist. Die wichtigsten Elemente, die ausgewertet werden müssen, können spielabhängig sein, aber einige Beispiele für gängige Konzepte, die berücksichtigt werden sollten, sind:

• Wie lange ist es seit dem letzten Sitzungsbericht her, und wie lange sagt der Client, dass er in der neuesten Sitzung gespielt wurde?

• Welche Ergebnisse hat der Spieler registriert, und sind sie für diesen Spieler angesichts seines Niveaus, seiner Ausrüstung usw. angemessen?

Für Spiele mit mehr Echtzeitanforderungen, z. B. das häufige Aktualisieren des serverautorisierenden Spielerzustands, ist die Verwendung gehosteter Spieleserver eine bessere Lösung als häufige Updates der gespeicherten PlayFab-Daten. In diesem Modell verbinden Sie den Player beim Starten der Sitzung mit einem Server. Der Server liest alle erforderlichen Daten aus dem Dienst für den Spieler und hostet dann den Simulationszustand für diesen Spieler im Laufe der Zeit, wobei der Client Daten mit dem Server in beliebiger Geschwindigkeit austauscht. Der Server aktualisiert dann den "langzeitigen Speicher" in PlayFab mit den neuesten Daten für den Spieler, entweder am Ende einer Sitzung oder alle paar Minuten, wenn Ihre Sitzungen besonders lang sind.

Dies ist das Modell, das von Echtzeit-Multiplayer-Spielen verwendet wird. Dies ist auch eine gültige Technik für Einzelspielertitel, die serverautorisierende Überprüfungen erfordern. Wenn diese Häufigkeit jedoch nur ein paar Mal pro Minute pro Spieler beträgt, könnte Azure Functions CloudScript die bessere Option sein. Die Gesamten CloudScript-Kosten lassen sich einfach berechnen. Dies sind die gesamt verbrauchten Gigabyte-Sekunden mit mindestens 128 MB und 100 ms pro Ausführung sowie die normalen Berechnungen für alle anderen Dienst-API-Aufrufe, die das Skript verwendet. Wenn Sie beispielsweise einen Gesamtspeicherbedarf von 250 MB zwischen Ihrem Skriptcode und der Variablennutzung im Skript haben, müssten Sie dieses Skript 4 Sekunden lang ausführen (höchstwahrscheinlich für mehrere Benutzer), um 1 GB/s zu erreichen. Wenn Sie in diesem Skriptcode Entitätsobjekte, Titeldaten, Benutzerdaten usw. lesen oder schreiben, müssen Sie den Spin berechnen, den jeder dieser Aufrufe für die Profilzähler hat. Da die Kosten für gehostete Spieleserver davon abhängen, wie viele Server Sie ausführen, und dies wiederum davon abhängt, wie viele Spieler gleichzeitig auf einem Server gehostet werden können, ist es nicht unbedingt trivial, zu bestimmen, wo sich der Break-Even-Punkt zwischen den beiden befindet. Wenn Sie jedoch feststellen, dass Sie Ihre Skripts mit einer hohen Häufigkeit aufrufen und jedes Mal Daten aus dem Dienst lesen und schreiben müssen, ist es sehr wahrscheinlich, dass eine Spieleserverlösung der bessere Weg ist.

Datenzeitachsen

Ein häufiges Thema, das wir unter Entwicklern mit hohen Schreibraten gehört haben, ist, dass sie besorgt sind, dass der Spieler den Fortschritt verliert. Wenn der Spieler das Spiel beendet, bevor er speichern kann und der lokale Zustand nicht verwendet werden kann, wenn das spiel das nächste Mal gespielt wird, oder wenn dieser Zustand zwischen Geräten wechseln muss, möchten Sie, dass die gespeicherten PlayFab-Zustandsinformationen für den Spieler so aktuell wie möglich sind.

Bei vielen Spielen können Sie dieses Problem beheben, indem Sie einen regelmäßigen, seltenen Takt von Updates für den Dienst haben (z. B. alle 15 Minuten). Aber auch die Einbeziehung zusätzlicher Logik zum Verlängern oder Verkürzen dieser Häufigkeit kann hilfreich sein. Beispiel:

• Schließen Sie eine "wichtige Update"-Außerkraftsetzung ein, die einen sofortigen Schreibvorgang verursacht, und setzt den Timer zurück, wenn der Spieler aktiv etwas Wichtiges ausführt, damit er nicht verloren gehen kann.

• Wenn Ihr Spiel ohne Spielereingaben fortgesetzt wird, sollten Sie erwägen, den Taktzeitraum zu verlängern, wenn lange keine Eingabe erfolgt ist. Dies ist besonders wichtig für Leerlaufspiele, bei denen Spieler sie häufig über Nacht laufen lassen.

• Geben Sie Spielern die Möglichkeit, ein Update direkt zu erzwingen, z. B. eine Schaltfläche in einem Benutzermenü. Achten Sie in diesem Fall jedoch darauf, die Rate zu drosseln, mit der Anrufe tatsächlich vom Clientgerät an PlayFab erfolgen, damit ein Spieler, der diese Schaltfläche immer wieder trifft, nicht jedes Mal einen Anruf generiert.

Wenn der Client beim nächsten Spielen des Spiels über die Zustandsinformationen verfügt, können Sie den Zeitstempel lokal mit den Daten aus dem Dienst vergleichen und entscheiden, welche Er verwenden soll, oder dem Spieler sogar die Option zur Auswahl geben.

Die Profilinformationen eines Spielers können für mehr als nur sich selbst relevant sein. In einigen Spielen benötigen Sie es möglicherweise, um spielerübergreifend abzufragen, sei es, um den Wettbewerb anzuspornen oder um die Spielerfahrung durch asynchrone Freundschaftsinteraktionen, Herausforderungen usw. direkt zu beeinflussen.

Für den Wettbewerb sind Bestenlisten eine ideale Möglichkeit, diese Spannung zu erzeugen, indem eine Teilmenge von Informationen über andere Spieler (oft diejenigen, die dem aktuellen Spielerergebnis nahe sind) über einen einzigen Aufruf des Diensts geteilt werden. Da es möglich ist, andere Profilelemente, z. B. Statistiken und Tags, mithilfe der Einschränkungen für die Profilansicht zurückzugeben, können Sie einen umfangreichen Satz von Informationen zu diesen anderen Spielern präsentieren. Es ist jedoch wichtig, die Liste aller Spieler in der Bestenliste nicht zu durchlaufen und zu versuchen, zusätzliche Informationen von jedem zu lesen, da dies die Gesamtzahl der Profillesevorgänge schnell multiplizieren würde, was Ihre Kosten in die Höhe treiben würde.

Bei Spielen, die spielerübergreifende Daten direkt in der Sitzung verwenden, besteht die häufigste Optimierung darin, nur die Informationen über die wenigen spezifischen Spieler zu lesen, mit denen der lokale Spieler interagiert. Bei Echtzeit-Action-Spielen erfolgt dies in der Regel auf dem Server, auf dem die Sitzung gehostet wird. Bei anderen , z. B. Spielen, bei denen Spieler sich gegenseitig angreifen können, besteht die gängigste Vorgehensweise darin, entweder alle Daten auf das lokale Gerät zu lesen oder dem lokalen Spieler nur die Teilmenge der Daten des anderen Spielers zu senden, die der lokale Spieler kennen sollte. Spiele, die das erste ausführen, verwenden serverseitige Logik, um die endgültigen Ergebnisse auszuwerten, die der Client sendet. Spiele, die letzteres tun, aktualisieren die Daten im Verlauf der Sitzung iterativ mit mehr Daten, wenn der lokale Spieler Zugriff darauf haben sollte. Aber auch dann verwenden sie serverseitige Logik, um die Endergebnisse auszuwerten. Auch hier ist der Tipppunkt bei der Entscheidung, ob dies über ein Skript oder auf einem gehosteten Server erfolgen soll, auf die Häufigkeit heruntergefahren. Wenn es mehr als ein paar Mal pro Minute dauert, ist es besser, einen gehosteten Server für den Teil der Sitzung zu verwenden, der diese Daten erfordert.

Wirtschaft und Bestand

Bestand und Wirtschaftlichkeit im Allgemeinen erfordern einen anderen Ansatz. Es ist nicht zu vermeiden, dass, wenn ein Spieler etwas von echtem (Geld) oder wahrgenommenem Wert (virtuelle Währung oder verbrauchsbare Container) aufgibt, er implizit erwartet, dass die Transaktion berücksichtigt wird. Für jedes Spiel mit In-App-Käufen ist eine Inkrementierung des Profilzählers für einen Kauf, der vom Spieler mit realer Währung getätigt wird, ein trivialer Preis. In vielen Arten von Spielen sind Bestandsaktualisierungen nur selten genug, um ihre Gesamtnutzung zu erhöhen. Aber für diejenigen mit häufigeren Bestandsaktualisierungen – auch wenn Sie keine Monetarisierung im Spiel haben – gibt es Optimierungstricks, um Ihre Kosten zu senken.

Eine bewährte Methode besteht darin, den Bestand nur im wörtlichen Sinne als relativ begrenztes Inventar zu betrachten. Beispielsweise kann es in einem inkrementellen Spiel (oder "Leerlauf") verlockend sein, sich jede Ressource, die der Spieler erwirbt, als Element vorzudenken, wobei die Gesamtzahl jedes Mal erhöht wird, wenn der Spieler eine andere davon kauft. Dieses Modell bricht jedoch schnell zusammen, da Sie die Häufigkeit berechnen, mit der Spieler diese Aktionen ausführen. Sofort müssten Sie es damit zu tun haben, dass jeder Spieler in einer Sitzung hunderte oder sogar tausende Male auf die Verbrauchseinheit trifft. In solchen Situationen ist es besser, diese Elemente als Benutzerdaten zu betrachten und mithilfe der Empfehlungen im Abschnitt Profil oben für den Dienst zu aktualisieren.

Wenn es um Spiele geht, die höhere Aktualisierungsraten für den Bestand haben, sind wir wieder bei der Frage der Datenzeitachse. Beispielsweise kann ein Aktionsspiel die Anzahl der Aufzählungszeichen eines Spielers nachverfolgen, aber die Back-End-Daten für diesen "Stapel" von Aufzählungszeichen müssen nicht bei jedem Pull des Triggers aktualisiert werden, insbesondere dann, wenn der Spielzustand auf einem gehosteten Server verwaltet wird. Stapelbare Elemente bieten einen Leistungs- und Kostenvorteil, da Sie viele virtuelle Instanzen eines Elements als einzelne tatsächliche instance mit einer Anzahl darstellen können. Häufig können Sie Änderungen an Stapeln von Elementen im Laufe der Zeit aggregieren und sie am Ende einer Sitzung oder in regelmäßigen Abständen während der gesamten Sitzung aktualisieren. Wenn Sie einen Stapel aktualisieren, ist es eine gute Idee, Player Item Management - Modify Item Uses aufzurufen, um zu überprüfen, ob Sie einfach die Anzahl des Stapels ändern können, anstatt N Instanzen des Elements hinzuzufügen, die jeweils zum Hinzufügen zum Stapel verarbeitet und dann bereinigt werden müssen.

Bestimmte Spielgenres, z. B. sammlerbare Karte Spiele, müssen den Spielerbestand von Natur aus mit einer etwas höheren Rate aktualisieren. Aber auch hier gibt es immer noch Möglichkeiten, Bestandsänderungen zu aggregieren und die Gesamtnutzung auf den Profilzählern zu reduzieren. In Spielen, die Droptabellen verwenden, verwendet der Entwurf beispielsweise häufig einen Container, der einen oder mehrere "Pulls" aus jeder der verschiedenen Drop-Tabellen enthält. Wenn es sich bei diesen Pullvorgängen nur um eine gelegentliche Aktion handelt, sind die inkrementellen Kosten in der Regel gering genug, um keine Bedenken zu verursachen. Wenn Spieler jedoch viele dieser Container sammeln und in kurzer Zeit Vielfache öffnen können, können Sie eine Option "Open N" oder sogar "Open All" (Alle öffnen) bereitstellen. In diesem Fall verwenden Sie PlayFab CloudScript mithilfe von Azure Functions oder Ihrem benutzerdefinierten Spielserver, um entweder Die Spielerelementverwaltung – Zufällige Ergebnistabellen für die Gruppe der Drop-Tabellen abzufragen oder Spielerelementverwaltung – Zufällige Ergebnistabelle auszuwerten, ohne die Inventarelemente zu generieren. Sie können dann den Spielerbestand wesentlich effizienter aktualisieren, indem Sie nur bei Bedarf Instanzen hinzufügen und dann die Anzahl der Elementstapel für den Rest aktualisieren.

Inhalt und Konfiguration

Wenn das Profil in erster Linie den Player, Inhalt und Konfiguration in erster Linie den Titel. Eine Reihe von Komponenten auf Titelebene, z. B. Pushbenachrichtigungen, E-Mail-Dienste und Titelnachrichten, sind alle in dieser Verbrauchseinheit enthalten. Darüber hinaus ist dies die Verbrauchseinheit, die verwendet wird, um die Verwendung von Entitätsdateien nachzuverfolgen. Ebenso werden Anforderungen für die URLs für das Hochladen und Herunterladen von CDN-Dateien auf dieser Verbrauchseinheit nachverfolgt. Es ist jedoch wichtig zu verdeutlichen, dass die CDN-Kosten getrennt sind und basierend auf der Gesamtzahl der heruntergeladenen Gigabytes abgerechnet werden, wie unter Content Delivery Network (CDN) beschrieben. Die Berechnung der Inhalts- und Konfigurationslese- und Speicherzähler ähnelt den Profile-Verbrauchseinheiten, da sie auf der Größe der Daten basieren, obwohl die Einheiten offensichtlich deutlich größer als 1 KB sind. Für die Inhalts- und Konfigurationsschreibeinheit basiert sie ausschließlich auf der Gesamtzahl der Schreibvorgänge, wobei jeder die Verbrauchseinheit um 1 erhöht.

Nebenbei ist das Entity File-System der empfohlene Dienst für große Daten, unabhängig davon, ob es dem Titel, einer Gruppe oder einem einzelnen Player zugeordnet ist. Bei Spielen mit großen Datenspeichern pro Spieler ist das Entity File-System im Allgemeinen kostengünstiger. beachten Sie jedoch, dass sich die Häufigkeit dieser Updates auf die nachverfolgte Nutzung auswirkt. Es empfiehlt sich, die Anzahl der benötigten Dateien anhand der Häufigkeit zu optimieren, mit der sie aktualisiert werden müssen.

Im Hinblick auf die Optimierung der Kosten für die Inhalts- und Konfigurationsmessung ist die Häufigkeit, mit der Ihr Titel seine eigenen, selten ändernden Konfigurationsdaten anfordern muss, am wichtigsten. Dies sind in erster Linie Titeldaten, die häufig verwendet werden, um Aspekte Ihrer Spiele zu verwalten, die für alle Benutzer identisch sind, z. B. Spielbilanz/Optimierungsdaten, Leistungsdefinitionen, Lokalisierungsdaten usw.

Wenn Sie bei Spielen, die CloudScript verwenden, feststellen, dass für jeden Aufruf eines Skripts eine Abhängigkeit von diesen Daten auf Titelebene besteht, sollten Sie erwägen, diese Daten direkt in das Skript einzufügen. Sie können dies erreichen, indem Sie sie einfach als hartcodierte Daten im Skript selbst definieren oder statische Variablen als Mittel zum Zwischenspeichern verwenden, um die Informationen aus dem Dienst einmal pro virtuellem Computer (VM) instance zu lesen. Auf diese Weise werden die Daten auf Titelebene geladen, wenn ein bestimmter virtueller Computer Ihr Skript zum ersten Mal ausführt, und von dieser VM bei nachfolgenden Ausführungen wiederverwendet. Drei Dinge zu beachten: Erstens wird das Skript von vielen verschiedenen Benutzern verwendet, sodass nichts als konsistent für einen einzelnen Benutzer zwischen den Ausführungen betrachtet werden sollte. Zweitens muss die Verarbeitung der Daten als zustandslos angesehen werden, da ein einzelner Spieler bei jedem Aufruf auf verschiedene Computer treffen könnte. Und schließlich müssen Sie das Alter dieser Daten nachverfolgen und sie in regelmäßigen Abständen erneut laden, um sicherzustellen, dass Sie über die neueste Version verfügen.

CloudScript

Dies ist eines der wichtigsten "Erweiterungsgelenke" des PlayFab-Diensts, mit dem Sie serverautorisierende Logik von einem Clientgerät oder server aus ausführen oder sogar über PlayStream-Regeln auslösen können (z. B. wenn ein Spieler ein Segment betritt). Im Gegensatz zum Hosten benutzerdefinierter Spieleserver zahlen Sie nur für die Gigabyte-Sekunden (GB/s), die das Skript ausführt, mit mindestens 128 MB und 100 ms pro Ausführung. Wenn Ihr Skript also insgesamt 250 MB Speicherplatz (zwischen Skriptcode und Daten) verwendet, müsste es insgesamt 4 Sekunden ( wahrscheinlich über mehrere Ausführungen hinweg ) ausführen, um auf ein GB/s zu gelangen.

Da sich die Anwendungsfälle für CloudScript im Allgemeinen auf das Ausführen von Aktionen im Namen Ihrer Spieler beziehen, haben wir in den letzten beiden Abschnitten zu Profil- und Inhalts-/Konfigurationszählern den Großteil der Überlegungen für Optimierungen behandelt. Die Gesamtanzahl der Ausführungen für einen Titel wird jedoch auch im Rahmen der Messung der CloudScript-Nutzung nachverfolgt. Daher ist es hilfreich, zu überprüfen, wie oft Sie CloudScript pro Spieler aufrufen müssen. Bei einigen Spielen ist es möglicherweise wesentlich kostengünstiger, einen gehosteten Spieleserver zu verwenden, um einen "heißen" Datenspeicher für aktive Spieler zu verwenden, anstatt zu versuchen, einen Datenspeicher in iterativen Aufrufen an CloudScript zu verwalten.

Einblicke

Diese Verbrauchseinheit ist mit allen Analysefunktionen des PlayFab-Diensts verknüpft, von der Ereigniserfassung und dem Export bis hin zur Ereignisverlaufssuche und Data Explorer Abfragen. Ihre Nutzung hängt davon ab, wie schnell Ereignisse verarbeitet werden müssen, wie viele Ereignisdaten gehostet werden sollen (für Abfragen im Game Manager) und wie viel Sie den Dienst verwenden, um Ihre Daten auszuwerten, entweder über Data Explorer Abfragen oder Visualisierungssoftware, die Sie direkt mit Ihren Daten verbinden. Diese Verbrauchseinheit wird sowohl von Aktivitäten im Spiel (Ereignisse) als auch von Aktivitäten außerhalb des Spiels (Analysen) beeinflusst.

Letztendlich bedeutet dies, dass die Kosten für Insights davon abhängen, wie viele Ereignisdaten Sie von Spielern erhalten und wie viele Analysen Sie für diese Daten verarbeiten. In Bezug auf bewährte Methoden gelten die obigen Hinweise zu Ereignissen für erstere, während Sie bei letzterem Ihre Kosten auf zwei Arten kontrollieren können. Erstens und am einfachsten ist, dass Sie den Gesamtspeicher auf der Registerkarte Insights-Verwaltung des Spiel-Managers für Ihren Titel festlegen können, um zu steuern, wie viele Ereignisdaten insgesamt Sie in PlayFab aufbewahren. Als Nächstes können Sie auf derselben Registerkarte die Leistungsstufe für Ihren Titel festlegen. Dies bestimmt die Gesamtmenge der CPU-Ressourcen, die Ihrem Titel zugeordnet sind, und wie viele Daten für Abfragen im Ereignisverlauf "heiß" gespeichert werden. Wie viel Sie jeweils benötigen, hängt von den Anforderungen Ihrer Datenanalyseteammitglieder ab. Daher ist es am besten, dies mit ihnen zu überprüfen, um zu verstehen, welche Einstellungen Sie haben sollten.

Informationen zu Insights und deren Verwendung finden Sie unter Was ist PlayFab Insights?

Informationen zu bewährten Methoden für Insight finden Sie unter Best Practices & FAQ.

Multiplayer-Dienste

Dies ist die einfachste von allen, da die Preise völlig unverändert sind. Kurz gesagt, gehostete Multiplayer-Server und der Party-Dienst wurden immer auf Nutzungsbasis in Rechnung gestellt.

Speziell für gehostete Spieleserver können Sie Ihre Kosten minimieren, indem Sie die Anzahl der Serverkerne optimieren, die Sie zu einem bestimmten Zeitpunkt ausführen müssen, um so viele Spieler wie möglich zu unterstützen.

Wenn niedrige Pingzeiten auf diesen Servern wichtig sind, können Sie auswählen, in welchen Regionen die Server ausgeführt werden sollen. Bei den meisten Spielen sind die größten Konzentrationen von Spielern auf bestimmte Schlüsselregionen beschränkt, aber wenn Sie eine weit verstreute Spielerpopulation haben – insbesondere wenn Sie sich in der langen Spielzeit befinden – müssen Sie die Kosten für die Ausführung von Servern in jeder Region in der Nähe Ihrer Spieler im Vergleich zu den Auswirkungen längerer Pingzeiten auf die Teilmenge der Spieler in Bereichen mit wenigen Spielern abwägen. Eine Sache, die dabei helfen kann, besteht darin, sicherzustellen, dass Sie unseren QOS-Dienst verwenden, um die Regionen auszuwählen, in denen Spieler platziert werden sollen, und dann zu bestimmen, was Ihr Cut-off für die Mindestanzahl von Spielern ist, die Sie in einer Region spielen müssen, damit sie lebensfähig ist.

Um Sie durch die Entwicklung zu bringen, ohne die Kosten zu verursachen, stellen wir eine beträchtliche Anzahl kostenloser Serverstunden in unserem Hosting-Dienst bereit, und unser Party-Dienst ist für alle Entwicklungsmodustitel kostenlos. Es ist auch erwähnenswert, dass unser Party-Dienst auch kostenlos für alle angemeldeten Xbox Live-Spieler ist, und für Titel in unseren Standard-, Premium- und Enterprise-Tarifen bieten wir ein großzügiges Maß an Konnektivität, Sprache und Cognitive Services (Sprachtranskription und Übersetzung) ohne zusätzliche Kosten an, um die Einhaltung von CVAA (21st Century Communications and Video Accessibility Act) zu unterstützen.

Verwalten Ihres Live-Spiels

Das deckt die Grundlagen der Meter ab, aber worüber sollten Sie nachdenken, sobald Ihr Titel live ist? Die Verwaltung Ihrer Spielercommunity umfasst in erster Linie Analysen (Insights, im Abschnitt oben) und Aktualisierungen von Inhalten und Konfigurationen. Darüber hinaus müssen die meisten Spiele mit Spielern außerhalb ihrer normalen Interaktionen mit dem Spiel selbst interagieren. Von Re-Engagement-Kampagnen (um Spieler dazu zu verleiten, zurückzukommen), bis hin zu Community-Belohnungen für Meta-Spiel-Aktivitäten und sogar zum Danken der Spieler für ihre eigene Community-Arbeit außerhalb des Spiels ist eine gängige Praxis in diesen Tagen die Verwendung von LiveOps-Techniken , um die Spieler hoch engagiert zu halten.

Ein Schlüssel dazu besteht darin, sicherzustellen, dass Sie Ihre Segmentierung effektiv auf klar definierte Gruppen ausrichten, nicht nur, um die Kosten zu senken, sondern auch sicherzustellen, dass Ihre Logik schnell verarbeitet wird. Nehmen Sie für instance, spieler wieder zu engagieren , um Spieler zu bringen, wiederkommen, nachdem sie für einige Zeit nicht mehr spielen. Eine gute Möglichkeit, dies anzugehen, besteht darin, mehrere abgelaufene Benutzerzeitrahmen zu definieren, z. B. Spieler, die 3, 7 und 21 Tage lang nicht gespielt haben. Für jede können Sie einen anderen Ansatz für die erneute Interaktion verfolgen, beginnend mit einer einfachen "Wir vermissen Dich"-Nachricht und deren Abschluss in einer Nachricht "Hier ist etwas kostenloses Gold/Energie/etc." (natürlich gekoppelt mit dem automatischen Hinzufügen des Kontos des Spielers). Für jeden dieser Methoden wird empfohlen, ein Ein-Stunden-Zeitfenster zu definieren, das auf dem Zeitpunkt basiert, zu dem sich der Spieler zuletzt angemeldet hat, um das Spiel zu spielen. Auf diese Weise zielen Sie nicht nur auf das letzte Mal ab, wenn sie gespielt haben, sie halten auch die Gruppe der Spieler im Segment minimiert, um den Vorgang so effizient wie möglich zu gestalten. Mithilfe einer geplanten Aufgabe, die einmal pro Stunde für jedes dieser Segmente ausgelöst wird, senden Sie die Nachrichten und fügen alle Elemente oder virtuellen Währungen (VIRTUAL Currency, VC) zu den Spielerinventaren hinzu.

Zusammenfassung

Letztendlich sind es die Features, die Ihr Spiel benötigt, die die Nutzung eines Back-End-Diensts wie PlayFab bestimmen. Eigentlich läuft alles auf eine umfassende Frage hinaus: Welche Anforderungen haben Sie an diese Features? Unabhängig davon, ob Sie Die Sicherheit, die Aktualität der Daten, das Maß an Spielerinteraktion/Wettbewerb oder etwas ganz anderes priorisieren, gibt es eine Reihe von Faktoren, die Sie zu einer höheren Interaktionsebene mit Back-End-Daten bringen können. Die Fähigkeit, diese Anforderungen mit einem kritischen Blick zu betrachten und zu erkennen, welche schwierigen Bedürfnisse sind und welche nicht, ist sehr ähnlich wie die Optimierung von jedem anderen Code in Ihrem Spiel. Es ist eine Frage der sorgfältigen Prüfung, wo Ihre Ressourcenauslastung hoch ist, und zu entscheiden, ob Sie dies wirklich benötigen oder ob es Möglichkeiten gibt, diese Logik neu zu gestalten, um die Nutzung zu reduzieren.

Wenn die Interaktion von Spielern in Echtzeit erfolgt, liegt dies an der Komplexität dieser Interaktion. Für die meisten Spiele dieses Typs sind gehostete Server, die den Simulationszustand verwalten und die Back-End-Daten nur am Ende einer Sitzung aktualisieren (oder alle paar Minuten, wenn die Sitzungen lang sind), in der Regel die beste Lösung. Es gibt jedoch viele Fälle, in denen interaktion voll vertrauenswürdig ist, wie z. B. Kooperative Spiele, oder solche, die nur mit (oder gegen) Freunde gespielt werden, wodurch der Anreiz zum Betrügen minimiert wird. Wieder andere haben nur minimale Anforderungen, wie die Daten für eine Sitzung überprüft werden müssen, sodass beide Spieler einfach nach jeder Sitzung ihre Berichte übermitteln können, damit serverseitige Überprüfungen die beiden vergleichen können.

Überlegen Sie bei jedem Spiel ohne Echtzeitanforderung, ob der Spieler wirklich eine Genauigkeit von bis zu einer Sekunde benötigt. In stark umkämpften Spielen mit starker Community-Interaktion kann dies sehr gut der Fall sein. Aber bei vielen Spielen wirken sich Informationen, die ein paar Minuten veraltet sind, nicht auf die Spielerfahrung aus.