Wir finden es mit unserem technischen Vorsprung heraus
Für das Bildungsprojekt der Bank of Russia haben wir ein auffälliges Web-Spiel "Das Geheimnis des verlorenen Sparschweins" erstellt . Sie macht Schulkinder auf das Thema Finanzkompetenz aufmerksam, führt die Begriffe ein und bringt ihnen bei, wie man mit Geld klug umgeht. Das Spiel wurde nicht nur von Kindern, sondern auch von Erwachsenen aus verschiedenen Städten Russlands gemocht - mehr als 30.000 Menschen spielten es.
Wir haben unseren technischen Leiter lange Zeit gebeten, uns über die Entwicklung des Webspiels zu berichten. Er erzählte nicht nur, sondern schrieb auch einen feurigen Artikel über unsere Erfahrungen in diesem Projekt, über die auftretenden Schwierigkeiten und über gemeinsame Hacks bei der Entwicklung von Browsergames. Das Ergebnis ist Material voller Nützlichkeit. Weiter lesen.
Ein Web-Spiel unterscheidet sich grundlegend von einem normalen Computerspiel und einer normalen Website in einem Browser. In einem normalen Spiel sind alle Spielressourcen offline verfügbar. Die Spiel-Engine kennt Informationen über den Prozessor, den Speicher und die Grafikkarte des Computers. Eine normale Site erfordert nur wenige Computerressourcen. Bei Problemen können Sie die Seite einfach neu laden.
Wir hatten Annahmen über die Funktionen eines Browsergames - erhebliche Einschränkungen der verfügbaren und verwendeten RAM-Größe (zum Beispiel wird im TOR angegeben, dass 1 GB RAM für mobile Geräte ausreichen sollte), das Gleichgewicht zwischen der Qualität der Spielressourcen (Bilder, Texturen, Sprites, Sounds, Videos) und deren Download-Geschwindigkeit.
Hinzu kamen die Anforderungen des Clients: Das Spiel muss in allen deklarierten mobilen und Desktop-Browsern (einschließlich IE 11) mit möglichst geringen Hardwareeigenschaften ausgeführt werden. Diese Anforderungen beruhten auf der Tatsache, dass das Spiel bei jeder Gelegenheit gezeigt werden sollte, auf jedem Gerät, das zur Hand war - zum Beispiel in der Schule.
Wie der Motor gewählt wurde
Wir hatten bereits Erfahrung in der Spieleentwicklung, daher wurden die Anweisungen für die Auswahl einer Engine sofort angegeben:
- Phaser — /.
- Unity Web — .
- LibGDX, Godot, PlayCanvas.
Unbekannte Optionen fielen aus einem offensichtlichen Grund aus - sie mussten gemeistert und studiert werden, was in gewisser Weise Angst machte, obwohl es nicht unmöglich schien. Die Unity-Option wurde deaktiviert, weil die Engine- und Exportbeschränkungen beispielsweise die Verwendung von Audio in IE 11 nicht zuließen. Außerdem war das aus Unity exportierte Javascript sehr umfangreich und IE 11 ist beim Parsen und Ausführen von Code viel langsamer als moderne Browser.
Daher wurde beschlossen, eine neue Version der Phaser-Engine zu verwenden (zum Zeitpunkt der Entwicklung war es die Version Phaser 3.11). Wir haben uns für diese Engine entschieden, auch weil die gesamte Logik und das Rendern Software sind, was bedeutet, dass wir absolut jeden Aspekt des zukünftigen Spiels im Code steuern können.
Wie sie geschrieben haben
Am Anfang hatten wir keine ausgeklügelte Mechanik, aber wir wussten, dass es definitiv ein Plattformer sein würde. Aus diesem Grund haben wir uns entschlossen, zumindest einen Prototyp zusammenzustellen, um unser Wissen über die Engine aufzufrischen und ungefähre Messungen der verbrauchten Ressourcen und der Belastung des Browsers vorzunehmen.
Wir haben aus den Beispielen "Charakterbewegung" und "Kachelkarte" in der Dokumentation fertig genommen, zusammengestellt, gestartet - es funktioniert: Der Charakter geht, springt, bewegt sich auf Plattformen. Wird auf allen verfügbaren Geräten gestartet - funktioniert immer noch. Virtuelle Steuertasten aus dem Beispiel "Virtuelle Tasten" hinzugefügt und auf dem Handy gestartet - funktioniert immer noch. Wir haben einen kleinen Mechaniker hinzugefügt - Schlagen, Feind, Schaden zufügen und erhalten, Münzen sammeln - war genug für den Prototyp.
Im Prototyp gab es sogar etwas mehr als nötig. Zum Beispiel wurde die Mechanik zur Steuerung von zwei Zeichen implementiert, zwischen denen Sie jederzeit wechseln können.
Nach einem erfolgreichen Prototyp hatten wir ein Verständnis dafür, wie die Architektur implementiert und der Code organisiert werden würde. Wenn wir über den Infrastrukturteil sprechen, dann arbeitet dies mit der Engine in Bezug auf das Laden von Ressourcen, das Erstellen von Spielobjekten und das Wechseln von Bildschirmen. Die Spiellogik selbst ist die Implementierung von Charakteren, die Implementierung von Mechanismen der Interaktion mit Beute, Fallen und Feinden.
Der Entwicklungsstapel wurde als typisch für ein ähnliches Projekt angesehen - Webpack, Webpack-Dev-Server, Babel, Babel / Preset-Typoskript.
Welche Schwierigkeiten gab es?
Es gab Schwierigkeiten bei der Erfüllung der Leistungsanforderungen und bei der Teamkommunikation. Ich musste mit neuen Werkzeugen arbeiten und Materialien in neuen Formaten aufeinander übertragen, sodass beim ersten Mal nicht immer alles reibungslos funktionierte.
Im TOR wurde beispielsweise festgelegt, dass das Spiel versucht, die Leistung des Geräts beim Start zu ermitteln, und bei geringer Leistung eine entsprechende Benachrichtigung angezeigt wird. In dieser Phase stehen wir vor zwei Problemen. Erstens gibt der Browser praktisch keine Informationen zu diesem Thema. Zweitens hängt die Leistung eines bestimmten Browser-Tabs zu einem bestimmten Zeitpunkt stark von externen Faktoren ab - wie viele Tabs geöffnet sind, ob auf anderen Tabs schwere Websites vorhanden sind, ob der Browser minimiert ist.
Es wurden mehrere theoretische und praktische Hypothesen getestet, aus denen die endgültige Lösung hervorging. Die Lösung lautet wie folgt:
- Auf dem Ladebildschirm des Spiels, auf dem der Fortschritt zwischen 0 und 100% liegt, endet das tatsächliche Laden von Ressourcen bei 92%.
- Danach wird außerhalb des Bildschirms eine Szene erstellt, auf der schwere Animationen und ein wenig Physik platziert werden.
- Innerhalb von 5 Sekunden wird dann die durchschnittliche Renderzeit eines Frames gemessen.
- Danach wird eine Entscheidung über die Leistung des Geräts getroffen und der Fortschritt erreicht 100%.
Sehr wichtig war die Anforderung, dass das Spiel in IE 11 voll funktionsfähig sein muss, was ebenfalls zu Unannehmlichkeiten führte. Es stellte sich heraus, dass bei laufenden Entwicklertools die bereits langsame Ausführung von Javascript in diesem Browser noch langsamer wurde.
Das heißt, Sie sind mit den Bremsen im Spiel konfrontiert, öffnen die Entwicklertools, um den Grund zu finden, und das Spiel wird noch langsamer.
Spielmechanik
Die Spielmechanik selbst ist unkompliziert und weitgehend von bestehenden Spielen inspiriert.
Die Hauptfigur ist zum Beispiel ein einteiliges Animationssprite zusammen mit einer Waffe. Diese Lösung wurde gewählt, um zu vermeiden, dass Swing- und Waffenanimationen nicht synchron sind. Daher erfolgt die Schadensprüfung wie folgt: Zum Zeitpunkt bestimmter Frames der Aufprallanimation (Frame ab dem dritten ungefähr) berechnen wir die Schnittfläche, die für mehrere weitere Animationsframes gültig ist. So ist es uns gelungen, den realistischen Betrieb der Waffe zu erreichen.
Der Nachteil dieser Entscheidung in der Animation der Hauptfigur war, dass Sie für jedes Geschlecht auf jeder Ebene einen eigenen Satz vorbereiteter Animationen mit Waffen benötigen. Und auf der zweiten Ebene war ein weiteres zusätzliches Set erforderlich - in Kredit-Sneakers. Insgesamt haben wir für jeden Charakter vier vollständige Animationssätze erhalten.
Eine andere lustige Sache hier ist, dass wenn Sie eine Waffe für den letzten Kampf auswählen, Sie tatsächlich den gesamten Charakter aus dem entsprechenden Level auswählen. Alle Helden mit einem Schwert tragen normale Turnschuhe.
Die Mechanik, die Schlüssel aus der Truhe zu ziehen, war interessant. Für den Schlüssel, der gefangen werden musste, wurde der Auslösebereich kleiner als das visuelle Sprite des Schlüssels gemacht und auch zufällig leicht zur Seite versetzt. Dies führte zu dem gewünschten Effekt „Mein Schlüssel wird nicht beim ersten Mal zusammengebaut“ - manchmal müssen Sie mehrmals versuchen, den Schlüssel zu sammeln, um zum Bereich seiner Betätigung zu gelangen. Ansonsten war es zu einfach, obwohl in der endgültigen Version der Triggerbereich dennoch leicht vergrößert wurde, um den Prozentsatz erfolgloser Versuche zu verringern.
Alle anderen Mechaniken sind tatsächlich gleich - sie lösen die Annäherung und Überschneidung der Charaktere und Spielobjekte zu bestimmten Zeitpunkten und Animationen aus.
Die Mechanik mit dem Drachen der Versicherung, der Flug über den Abgrund und die letzte Schlacht waren etwas komplizierter. Die Techniken waren die gleichen, aber Pausen und Inaktivität wurden zusätzlich orchestriert, um die Animationen anderer Charaktere zu diesem Zeitpunkt zu reproduzieren.
Schlussfolgerungen und Ratschläge
Entscheide dich sehr früh für ein Genre.
Spiele im Web sind ein echtes Phänomen mit einem eigenen Publikum und eigenen Regeln. Solche Spiele müssen nicht installiert werden. Sie ermöglichen es Ihnen, kurze Spielsitzungen zu arrangieren. Sie ziehen mehr Mechaniker an als sie aussehen.
Tipp - Behandeln Sie die Entwicklung von Webspielen wie ein echtes Spiel, nicht nur ein weiteres "Skript auf der Seite". Testen, profilieren und vermeiden Sie Speicherlecks und CPU-Overhead. Spieler und ihre Gerätebatterien werden sich freuen.