UnnyWorld: Obduktion

Nach der Schließung unseres UnnyWorld-Spiels baten viele befreundete Entwickler, ein Post-Mortem-Spiel zu schreiben. Ich habe mich entschlossen, konkrete Beispiele zu nennen, von denen sich während der Entwicklungsphase ein anständiger Betrag angesammelt hat. Es werden Fehler berücksichtigt, die wir gemacht haben. Ich werde versuchen, ein paar nützliche Tipps zu geben.



Zuvor veröffentlichte ich einen Artikel „Drei Jahre Entwicklung meines MMO“ , der sich mehr mit der Suche nach Investitionen, dem Team und unserem Weg zum „Erfolg“ befasste. Leider (oder zum Glück?) Musste das Projekt geschlossen werden. In diesem Artikel werde ich versuchen, die gemachten Fehler zu überprüfen und möglicherweise zumindest ein paar nützliche Tipps zu geben.

Über das Spiel auf den Punkt gebracht

Hernyworld kann herkömmlicherweise in zwei Teile unterteilt werden: City Builder und Arena.
Der Teil über den Erbauer ist ein gewisser Clash of Clans. Sie haben Ihren eigenen Planeten, den Sie ausrüsten müssen. Und Sie können andere Planeten angreifen, um Ressourcen zu stehlen.



Greife andere Spieler an, du bist einer deiner Charaktere und du kontrollierst es.

Arenen - typisches MOBA 3v3 mit verschiedenen Modi (Flagenerfassung, Punkterfassung usw.).



Jeder Charakter hat seine eigenen Zauber, die mit anderen Spielern kombiniert werden können.


Vor dem Kampf kannst du Zauber ändern.



Der gesamte Spielzyklus sieht folgendermaßen aus:

1. Zum Pumpen von Zaubersprüchen werden Schriftrollen benötigt, die von der Brust fallen. Truhen können auf verschiedene kostenlose Arten erhalten werden (für eine Liga, um den Battle Royal zu gewinnen usw.) oder gekauft werden.
2. Um den Zauber zu pumpen, musst du den Aufbau des Helden auf ein bestimmtes Level bringen und verbessern.
3. Um das Gebäude des Helden zu verbessern, müssen andere Gebäude (Hauptgebäude, Altar usw.) verbessert werden.

Das heißt, wir haben versucht, das Regime des Planeten und der Arenen irgendwie in Einklang zu bringen. Wir haben wahrscheinlich alles falsch gemacht.

Fehlen eines klaren Plans und einer klaren Strategie

Ja, viele Dinge wurden ständig besprochen, aber sie wurden fehl am Platz erkannt, ohne gründlich zu analysieren, was überhaupt getan werden muss.

Infolgedessen versuchten sie, alles auf einmal zu tun. Benötigen Sie ein Gildensystem, wenn das Spiel eineinhalb Benutzer hat? Hmm, kaum.

Benötigen Sie ein System, mit dem Sie ein benutzerdefiniertes Match erstellen und dort Freunde und Mitgilden einladen können, wenn das Spiel eine kleine CCU hat? Nicht sicher.

Während des Entwicklungsprozesses haben wir viele Dinge versucht, um etwas zu tun, das zu diesem Zeitpunkt wahrscheinlich nicht getan werden musste. Infolgedessen wurden die wirklich notwendigen Dinge nicht umgesetzt.

Mangel an Erfahrung

Weil Bevor wir hauptsächlich mit Single-Play-Spielen gearbeitet haben, sind wir bei der Auswahl der einen oder anderen Technologie auf eine große Anzahl von Rechen gestoßen.

Lassen Sie uns ein wenig über den technischen Teil der Frage sprechen.

Technologieauswahl

Eine kleine Klarstellung. Wir sind größtenteils reine Kundenentwickler. Vom gesamten Team hatten nur wenige Personen Erfahrung mit Servertechnologien. Über die Verwaltung schweige ich generell. Ich werde versuchen, bestimmte Technologien mit jeweils einer kleinen Zusammenfassung durchzugehen.

Welcher Cloud-Anbieter soll verwendet werden? AWS? Azure? Weiche Schicht

Zu dieser Zeit gab es keinen grundsätzlichen Unterschied. Außerdem hatten wir einen Kredit für SoftLayer als Startup.

Oh, Boi, wenn du nur wüsstest, wie schlimm die Dinge sind:

- Saport ist mit dem Problem nicht besonders vertraut. Es gab Fälle, in denen ich mich wegen eines Problems auf einer bestimmten virtuellen Maschine an sie wandte (ich konnte keine Verbindung herstellen usw.). Auf die ich die Antwort erhalten habe:

Wir haben das Auto neu gestartet, jetzt ist alles in Ordnung

- Es gab Fälle, in denen die virtuelle Maschine stundenlang hochgefahren war . Wie Sie sehen, habe ich 4 Stunden gewartet, aber die virtuelle Maschine wurde nie erstellt.



- Häufige Wartung.



- Es kommt vor, dass ein Auto ohne Vorwarnung neu startet oder ein privates Netzwerk unterbrochen wird.

Infolgedessen wechselten sie zu Azure. Es gab keine derartigen Probleme. Der Support reagiert schnell und hilft immer, wenn etwas passiert.

Gut: -

Schlecht: Sie haben nicht alle möglichen Optionen richtig analysiert. Aber der Server ist der wichtigste Teil für ein Online-Spiel = /

Sie müssen also die Spielinstanzen auf dem Server starten und durch ein API-System werfen, nachdem Sie den Spieler für die gewünschte Instanz autorisiert haben. Was machen wir jetzt Nehmen wir eine schlüsselfertige Lösung, die dieses Geschäft je nach Auslastung verwaltet. Wow, da ist etwas namens Kubernetes. Stimmt, sie ist in der Beta ... Aber versuchen wir es trotzdem!

Wenn wir die Tatsache verwerfen, dass Sie Erfahrung benötigen, um mit dieser Technologie zu arbeiten, konnte sie trotz der grundlegenden Einrichtung dieses Geschäfts fallen. Einige Dienste fielen aus usw.

Was gibt es sonst noch? Mesosphäre und Apache Mesos! Bei ihm ist alles gleich, ohne Erfahrung ist es schwierig. Wenn etwas abfällt, können Sie das Problem ohne Tamburin nicht beheben.

Infolgedessen haben sie alles selbst geschrieben. Die Instanzen beginnen mit dem Supervisor, ebenso wie der kleine Manager darüber (geschrieben in Java). Java-Anwendung ttl'it in den Dienst der Ermittlung des Status (die Anzahl der freien Räume auf Instanzen, etc.). Wenn Sie autorisieren und anfordern, mithilfe dieser Informationen zu Instanzen einen Raum für die API zu erstellen, wird die Anforderung an den richtigen Knoten gesendet, wodurch der Raum auf der richtigen Instanz ausgelöst wird.

Das heißt, Instanzen werden immer vorab ausgeführt. Mit einem Mangel erheben wir einen neuen VPS.

Gut: analysierte die Alternativen.

Schlecht: Ich habe viel Zeit mit dem Prototyp verbracht. Bei der ersten Version mussten Sie überhaupt nicht über diese Dinge nachdenken, sondern haben die Instanzen einfach ohne Beschwerden gestartet. Es war möglich, die Instanzadressen auf dem Client im Prototyp direkt fest zu codieren.

Wir haben www.consul.io für den Discovery-Service verwendet. Dies ist wahrscheinlich eine dieser Lösungen, die wir nicht bereut haben. Es stimmt, es gibt solche Probleme, wenn die Konfiguration beim Neustart unterbrochen wird. Dies ist jedoch selten und mit einem ungeplanten Neustart des Autos. Im Allgemeinen war es für die ganze Zeit eine Freude, mit dem Konsul zusammenzuarbeiten.

Gut: Sie haben eine vorgefertigte Lösung gefunden, aber nicht selbst etwas gesägt.

Für die Bereitstellung wurden ursprünglich Bash-Skripte verwendet.


Später habe ich die gesamte Bereitstellung auf Ansible übertragen. Ich kann bis heute nicht genug bekommen. Anfangs gab es natürlich Probleme. Das System ist jedoch recht einfach zu erlernen und die Dokumentation in großen Mengen.

Gut: Schreiben Sie schnell ein Bash-Skript, ohne dass spezielle Kenntnisse erforderlich sind.

Schlecht: Beim Wechsel zu einem normalen Bereitstellungssystem musste ich fast alles wegwerfen, was zuvor geschrieben wurde.

Für die Kommunikation zwischen ihren Diensten haben wir www.rabbitmq.com ausprobiert . Aber er konnte in ein paar Tagen einfach so vom Thema abweichen. Infolgedessen haben sie es auf einfache Weise getan - alle Dienste interagieren entweder über reine TCP-Sockets oder über http-Anforderungen mit Keep-Alive, wenn Sie Anforderungen nur in eine Richtung senden müssen.

Gut: analysierte die Alternativen. Wir haben eine gute Lösung gewählt.

Schlecht: mangelnde Erfahrung mit Technologie. Es ist nicht erforderlich, Dinge in die Produktion zu ziehen, die Sie bei Problemen nicht beheben können.

Online spielen bedeutet, dass Sie einen Chatraum benötigen. Schreiben Sie sich? Es ist unwahrscheinlich, dass es skalierbar ist. Nehmen wir etwas fertig. XMPP? Ejabberd? Scheint gut zu sein. Im Allgemeinen haben wir sowohl den Igel als auch MongooseIM ausprobiert, uns aber schließlich für einen Igel entschieden. Es gab einige Probleme beim Auslösen auf ihren Servern (Pfosten mit Zeitangaben in Nachrichten, Abstürzen usw.). Wir haben uns für die Cloud-Lösung ejabberd-saas.com entschieden . Ja, es ist bezahlt. Aber es hat ohne Probleme funktioniert.

Gut: analysierte die Alternativen. Wählen Sie die entsprechende Option.

Schlecht: Anstatt lokale Probleme zu lösen, haben wir uns für eine kostenpflichtige Cloud-Lösung entschieden. Preise dort ab 200 Euro. Wir hatten mehrere Spielregionen. Für ein Indie-Team ist dies ein sehr erheblicher Betrag, der besser für andere Dinge ausgegeben werden sollte.

Anfangs hatten wir im Allgemeinen kein System zum Sammeln von Metriken auf Servern. Warum verlangsamt sich die Anfrage? Was ist los mit dem Service? Wie viele Zimmer sind jetzt verfügbar? Ja, wir konnten nicht einmal sehen, wie viele Zimmer derzeit verfügbar sind!

Später kam die Erkenntnis, dass etwas getan werden muss. Versucht, Graphite + Grafana zu verwenden. Sogar das Pre-Docker-Image hat dies alles getan: github.com/Suvitruf/docker-grafana-graphite-diamond

Aber es hat nicht geklappt. Ich wollte keine Zeit damit verbringen, wir entschieden uns, das fertige Etwas zu verwenden. Die Wahl fiel auf www.datadoghq.com

Alles in Ordnung ist. Messgeräte, Warnungen, Diagramme. Der Client-Treiber ist fast der gleiche wie für Graphit. Schönheit Aber ... 10 + $ für jeden Host pro Monat. III ... es kommt bei 200 + $ pro Monat heraus.

Die Erkenntnis, dass wir eine Menge Geld dafür angepisst haben, war zu spät. Wir haben uns dennoch entschlossen, dies auf unseren Servern zu tun. Richten Sie www.influxdata.com ein . Infolgedessen verarbeitet ein Auto für ein paar Dutzend Dollar leise Metriken von Dutzenden / Hunderten von Autos.

Gut: Wir haben es schnell versucht. Ich habe eine fertige Alternative gefunden. Sie erkannten (wenn auch spät), dass die Entscheidung falsch war. Richten Sie lokal ein praktisches System ein.

Schlecht: habe das Problem nicht richtig verstanden. Viel Geld ausgegeben.

In Bezug auf Metriken das gleiche Problem mit der Leistung. Zunächst sind wir insbesondere weder Client noch Server in Profilen. Infolgedessen wurden Speicherlecks auf Serverinstanzen des Spiels zu spät entdeckt. Sie konnten nicht sofort feststellen und reparieren. Infolgedessen haben sie geschrieben, dass die Spielinstanz nach dem Erstellen einer bestimmten Anzahl von Räumen neu gestartet wird.

Ein bisschen über konzeptionelle und DG-Lösungen

Ich kann jetzt nicht rechtzeitig die richtige Reihenfolge für all diese Ereignisse erstellen. Ich werde einige wichtige Entscheidungen nennen, die wir getroffen haben.

Aufteilung des Spiels nach Regionen

Die Spieler forderten einen asiatischen Server und einen Server in Südamerika an (bevor sich dieser Server in Europa und den USA befand). Warum machst du es nicht? Habe getan. Infolgedessen waren eineinhalb Benutzer auf 4 Regionen verteilt. Einmal mehrere Regionen, dann müssen Sie ein Transfersystem erstellen. Ist es logisch? Ist logisch.

Gut: ein paar Leute haben einen besseren Ping bekommen (｡ • ́︿ • ̀｡)

Schlecht: viel Zeit für die Erstellung von Regionen, Transfersystemen usw.

Es ist notwendig, auf die Vorschläge / Vorschläge der Spieler zu hören, aber Sie sollten nicht sofort weglaufen und all dies realisieren.

Ersetzen eines quadratischen Gitters durch Verhexungen und erneutes Ausführen von Angriffen auf Planeten

Zuvor sahen die Planeten folgendermaßen aus:



Und die Angriffe:



Der Wechsel zu Hexen hat viele Dinge technisch vereinfacht. Außerdem sah es viel besser aus und es ist einfacher, mit Spielelementen zu arbeiten.

Überarbeitetes Zaubersystem

Früher sah es so aus:



Das Upgrade selbst wurde für Steine ​​durchgeführt, die von den Truhen fielen. Alles war nicht offensichtlich, verwirrend.

Infolgedessen ersetzten sie das Steinsystem durch Schriftrollen wie in Clash Royale.



Um den Zauber zu verbessern, benötigen Sie eine bestimmte Anzahl von Schriftrollen. Alles ist einfach und klar.

Gut: Sie haben einen Problemort bemerkt und ihn überarbeitet.

Schlecht: Anfangs haben sie nicht analysiert, wie die Spieler es wahrnehmen würden. Viele Dinge, die für Entwickler offensichtlich sind, werden von den Spielern auf völlig andere Weise wahrgenommen. Daher muss Feedback zum frühestmöglichen Zeitpunkt eingeholt, Spieletests usw. arrangiert werden.

Einkaufen bei Twitch

Wir haben sogar mit www.twitch.tv vereinbart, Einkäufe im Spiel auf der Spieleseite zu tätigen.



Aber seitdem Niemand hat unser Spiel gestreamt, dann ist die Bedeutung einer solchen Entscheidung im Allgemeinen Null.

Gut: ein potenzieller Ort für einen fairen Geldabzug von Spielern.

Schlecht: Wenn Ihr Spiel nicht gestreamt wird, hat dies keinen Sinn. Nur verschwendete Zeit.

Battle Royale-Modus

Nach dem Hype beschlossen sie, ein solches Regime im Spiel zu streichen. Aber seitdem Es war wenig online im Spiel, dann gab es in diesem Modus fast nur Bots, was alles zu nichts eliminiert.

Über Fehler

In einem solchen Projekt ist es schwierig, keine Fehler zu machen. Es gab viele relativ harmlose GUI-Fehler.



Es gab schwerwiegendere Fehler, zum Beispiel, als Spieler sofort in der Mitte der Arena starben. Wir konnten diesen Fehler lokal nicht wiederholen. Es kam den Spielern gelegentlich vor, aber wir konnten es nicht beheben.

Ein lustiger Fehler, wenn beim Wechseln des Charakters das Modell des vorherigen nicht gelöscht wurde. Infolgedessen war es möglich, eine Party hart zu arrangieren.



Es gab auch Fehler im Zusammenhang mit der Plattform / Engine.

Zum Beispiel kann manchmal die gesamte GUI einfach verschwinden. Wenn Sie jedoch in die Hierarchie der Objekte gehen und einfach auf das Objekt klicken, wird es erneut angezeigt.


Wir haben über dieses Problem Unity berichtet. Sie antworteten, dass sie uns einen Mitarbeiter geben könnten, der für 10.000 USD pro Monat hilft ლ (ಠ_ಠ ლ)

Auf der Facebook-Plattform hatte der Spielraum ein Problem mit der Skalierung, als das Spiel an der falschen Stelle auf den Tachy reagierte.



Dies, ganz zu schweigen von Fehlern in verschiedenen Bibliotheken. Auf einigen Steamworks.NET-Computern kann beispielsweise github.com/rlabrecque/Steamworks.NET/issues/121 abstürzen .

Zusammenfassung

Wir haben fast nicht in Marketing investiert, wir hofften, dass es einen organischen Zustrom von Spielern geben würde. Infolgedessen erreichte das Spiel nicht diese kritische Masse, wonach Bots nicht mehr benötigt würden und es einen organischen Zustrom neuer Spieler geben würde.

Insbesondere war niemand mit Content Management und Kommunikation mit Spielern beschäftigt, es gab keine Newsletter.

Während der Entwicklung ging viel Zeit bei der Auswahl und Erprobung verschiedener Technologien verloren.

Es gab keinen klaren Plan für die Implementierung von Funktionen / Inhalten.

Im Allgemeinen sind die meisten dieser Probleme auf Unerfahrenheit zurückzuführen.

Was weiter?

Unnyworld wurde geschlossen. Wir haben beschlossen, das Projekt im Rahmen der aktuellen Möglichkeiten zu verkleinern.

Ein Artikel behandelt nicht alles. Und was ich für einen Außenstehenden geschrieben habe, mag wie eine inkohärente Reihe von Fakten erscheinen. Leider ist es kein Experte, solche Texte zu schreiben.

Wenn Sie Fragen haben, beantworte ich diese gerne in den Kommentaren oder in einem neuen Artikel.