Voraussetzungen für die Integration

In diesem Abschnitt wird die Integration zwischen dem Playable und dem YouTube Playables SDK beschrieben.

1. Playables SDK laden

Im Spiel MUSS firstFrameReady aufgerufen werden, wenn im Spiel ein Ladebildschirm oder ein Splash-Screen gerendert wird, der dem Nutzer explizit mitteilt, dass der Ladevorgang läuft.
Das Spiel MUSS gameReady aufrufen und DARF gameReady nur aufrufen, wenn das Spiel für die Nutzerinteraktion bereit ist (z. B. im Hauptmenü oder wenn das Spiel bereit ist).
Im Spiel DARF gameReady nicht aufgerufen werden, solange dem Nutzer noch nicht interaktive Elemente angezeigt werden (z. B. Splashscreens oder Ladebildschirme).

YouTube entfernt den Lade-Spinner erst, wenn diese API aufgerufen wird.

Das Spiel MAY verwendet sendScore, um die Punktzahl des Nutzers zu senden.
Wenn das Spiel sendScore zum Senden von Punktzahlen verwendet, MUSS es der sendScore-Spezifikation entsprechen und MUSS dafür sorgen, dass die gesendete Bestpunktzahl mit der Bestpunktzahl im Spielstand übereinstimmt.

Das Spiel MUSS saveData aufrufen, um den Fortschritt zu speichern, wenn Nutzer wesentliche Fortschritte im Spiel erzielt haben (z. B. einen Levelwechsel), bei denen die Spielmechanik den Nutzer glauben lässt, dass sein Fortschritt gespeichert wird.
Im Spiel DARF kein anderer Mechanismus zum Speichern des Nutzerfortschritts verwendet werden. Mit dieser Funktion können Spieler das Spiel zu einem späteren Zeitpunkt fortsetzen.
Das Spiel MUSS auf loadData warten, bevor saveData aufgerufen wird. Wenn saveData aufgerufen wird, bevor loadData erfolgreich abgeschlossen wurde, wird die Anfrage abgelehnt. So wird verhindert, dass das Spiel zuvor gespeicherte Daten überschreibt.
Das Spiel MUSS Cloud-Speicherdaten aus früheren Versionen des Spiels ohne Fehler oder Abstürze verwenden können.
Das Spiel SOLLTE die Cloud-Speicherdaten verwenden, um den Fortschritt des Nutzers in allen Spielversionen beizubehalten, in denen der Nutzer erwartet, dass seine Daten verwendet werden.
Spiele SOLLTEN den Fortschritt des Nutzers bei wichtigen Spielmeilensteinen automatisch speichern, um Datenverlust zu verhindern. Ein letzter Flush-Speichervorgang wird ausgeführt, wenn ein Nutzer das Spiel beendet. Er erfolgt nach dem Best-Effort-Prinzip und kann nur bis zu 64 KiB an Inhalten speichern.

Das Spiel MUSS die Audioeinstellungen des Systems und die Taste „Stummschalten“ berücksichtigen.
Das Spiel MUSS die Audioeinstellungen und die Taste „Stummschalten“ von YouTube berücksichtigen. Dazu müssen isAudioEnabled und onAudioEnabledChange verwendet werden.
Das Spiel MUSS die Lautstärkeregelung auf dem Gerät berücksichtigen.
Der Spielsound DARF NICHT unerwartet wiedergegeben werden.
Wenn die Stummschaltung von YouTube aktiviert ist, DARF kein Ton ausgegeben werden und die Steuerelemente für den Spielton DÜRFEN die Audioausgabe nicht beeinflussen.
Wenn die YouTube-Stummschaltung nicht festgelegt ist, KANN die Audioausgabe durch die Spielaudio-Steuerelemente beeinflusst werden.
Im Spiel SOLLTE NICHT eine Taste „Stummschalten“ angezeigt werden. Nutzer sollten sich hier auf die YouTube-Funktionen verlassen können.
Das Spiel KANN separate detaillierte Audioeinstellungen haben, z. B. für Musik und Soundeffekte. Es MUSS jedoch alle anderen Anforderungen an die Audioeinstellungen erfüllen.

Unterschiedliche Audioeinstellungen für Hintergrund, Soundeffekte und Dialoge

Das Playables SDK bietet Callbacks für plattformübergreifende Pausen- und Fortsetzungsfunktionen.

Das Spiel MUSS die gesamte Ausführung nach dem Aufruf von onPause pausieren und MUSS die Ausführung erst fortsetzen, wenn onResume aufgerufen wird. Die Ausführung umfasst alle Playable-Funktionen wie Game-Loop, Musik, Interaktionen, Netzwerkaufrufe und Rendering.
Im Spiel DARF NICHT die Page Visibility API oder ähnliche Web-APIs verwendet werden. Es DARF nur das Playables SDK onPause und onResume verwendet werden.
Das Spiel SOLLTE den Nutzerfortschritt speichern, wenn onPause auftritt.