HN-Veröffentlichung: Ich stelle meine Game Engine als Open Source bereit

 (github.com/moddio)
2 Punkte von GN⁺ 2023-12-22 | 1 Kommentare | Auf WhatsApp teilen

Moddio Game Engine 2

  • Moddio ist eine Game Engine mit Fokus auf Multiplayer.
  • Sie enthält integrierten Netzwerkcode mit Serverautorität, Snapshot-Interpolation und clientseitiger Abstimmung.
  • Unterstützt mehr als 50 gleichzeitige Spieler oder über 300 bewegliche Objekte auf einer VM für 5 Dollar im Monat.

Demo

  • Im Lieferumfang enthalten: Box2D-Physik-Engine, Netzwerkcode mit Serverautorität, Inventar- und Item-System, eingebaute Attribute (HP, Energie usw.) und Regenerationsraten, Dialogsystem, Shop, Unit-Steuerung, clientseitig vorhergesagte Projektile und Unit-Bewegung, Unit-KI und A*-Pfadfindung, mobile Steuerung usw.

So führt man das Spiel aus

  • Node 18 oder höher wird benötigt.
  • Nach dem Einrichten des Repositorys in das Verzeichnis /src wechseln, game-sample.json in game.json umbenennen, dann ins Root-Verzeichnis zurückkehren und den Server starten.
  • Das Spiel kann nun unter http://localhost:80 gespielt werden.

So erstellt man ein neues Spiel von Grund auf

  • Moddio-Spiele werden mit dem Moddio Game Editor erstellt und bearbeitet, der unter https://www.modd.io verfügbar ist.
  • Nach dem Erstellen eines Spiels kann ein game.json exportiert werden, das in einer lokalen Installation verwendet werden kann.
  • Die exportierte Spiel-JSON in game.json umbenennen und in das Verzeichnis ./src verschieben.

So kann man beitragen

  • Moddio ist unter der MIT-Lizenz vollständig kostenlos und Open Source.
  • Wer mehr darüber erfahren möchte, wie man Contributor wird, sollte die Seite zum Beitragen besuchen.

Credits

  • Verwendet werden unter anderem die Isogenic Game Engine, Phaser, PlanckJS, uWebsocket, Box2D, Kenney-Assets und Hero Icons.

Meinung von GN⁺

  • Die Moddio Game Engine ist auf die Entwicklung von Multiplayer-Spielen spezialisiert und bietet leistungsstarke Funktionen, die viele Spieler zu niedrigen Kosten unterstützen.
  • Sie ist Open Source und entwickelt sich durch Beiträge der Community kontinuierlich weiter, wodurch sie auch für angehende Software Engineers gut zugänglich ist.
  • Da viele für die Spieleentwicklung benötigte Funktionen bereits integriert sind, bietet sie Entwicklerinnen und Entwicklern eine Umgebung, in der sie schnell Prototypen erstellen und testen können.

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-12-22
Meinungen auf Hacker News

  • Auf dem Registrierungsbildschirm der Android-App wird man aufgefordert, Google-Nutzername und Passwort in etwas einzugeben, das wie ein Webformular innerhalb der App aussieht; als Nutzer hat man keine Möglichkeit zu wissen, ob die App das Passwort mitliest.
    Normalerweise scheinen Apps einen Flow zu verwenden, bei dem man zu einem Login-Bildschirm weitergeleitet wird und anschließend zurückkehrt; ich frage mich, ob die Umsetzung dieses Patterns schwierig ist. Vielleicht ist das auch ein Problem durch Cross-Platform-Support.

    • Im Prinzip ist das keine besonders schwierige Sache. Ich arbeite mit Autoherstellern, bei denen sich Nutzer mit einem OEM-Konto anmelden müssen; theoretisch ist alles compliant, aber in der Praxis funktioniert vieles nicht, und Korrekturen dauern lange.
      Die oben beschriebene Methode sollte allerdings wirklich nicht vorkommen; ich dachte, Google hätte das bereits verboten.
    • Das nennt man OAuth 2.0, und mit etwas wie Okta ist die Implementierung einfach.

  • Nutzer dazu zu bringen, eine Game Engine zu übernehmen, ist nie einfach, und besonders schwer, wenn sie Closed Source ist.
    Wenn man sich die Spiele-Galerie auf der Website ansieht, scheint das bisher ziemlich gut gelungen zu sein; ich frage mich, ob ein paar Freunde sie erstellt haben oder ob es eine recht aktive Community gibt.

    • Die Kombination aus guten Features, leichter Erlernbarkeit und niedriger Einstiegshürde kann ziemlich weit tragen.
      Man kann sich eine Struktur vorstellen, bei der schon ein paar Tage oder sogar nur ein paar Stunden Casual-Aufwand zu sinnvollen Ergebnissen führen. Man denke an Flash.
    • Es gibt eine aktive Community, und täglich werden 150 bis 300 neue Spiele erstellt.
      Dass die Einstiegshürde sowohl für Spieleentwickler als auch für Spieler niedrig ist, hilft definitiv. Kein Download und keine Registrierung nötig.

  • Nur anhand des Titels hätte ich nicht gedacht, dass es um modd.io geht. Das ist ein beliebtes Framework/eine beliebte Plattform zum Erstellen von IO-Games.

    • Ich spiele viele Games und habe früher auch mal welche verkauft, aber den Begriff habe ich noch nie gehört. Was ist ein IO-Game?

  • Ich bin auf einen Brains-Server gegangen und war neugierig, wie die Erfahrung mit etwa 50 Spielern ist. Wie bei WebSockets zu erwarten, wirkten die Bewegungen etwas ruckelig, und weil ich an etwas Ähnlichem arbeite, war ich auch an der Netzwerkkompression interessiert.
    Ich bin nicht sicher, ob LZ-String-Kompression allein ausreicht. Bei 50 Spielern werden etwa 20 KB pro Sekunde verwendet, während Warzone bei 150 Spielern nur etwa 48 KB pro Sekunde nutzt. Wenn es keine unbegrenzten Daten sind, können die Cloud-Bandbreitenkosten ziemlich ins Gewicht fallen.
    Interessant fand ich auch, dass der komprimierte Byte-Buffer wie 埒愑䣔橤㤰゙㟍稦獦ঙ惝䓇強栛䳌۬䌃̩佼 aussieht. Ich weiß nicht, ob LZ-String-Kompression normalerweise solche Ergebnisse liefert, aber es wirkt ziemlich ungewohnt.
    Jedenfalls gibt es im Networking-Bereich viel Raum für Verbesserungen, um potenzielle Kosten zu senken. Das Gesamtprojekt ist sehr beeindruckend und gut gemacht.

    • Bei unseren WebSockets sind die Bewegungen ziemlich tight: https://gooberdash.winterpixel.io/
      Der Schlüssel sind clientseitige Vorhersage und ein Rollback-Networking-Algorithmus. Unser Game-State ist bei 30 Hz etwa 1 KB groß und passt daher normalerweise in ein einzelnes Paket, sodass WebSockets auch nicht allzu schlecht sind. Natürlich wäre ein unzuverlässiges Protokoll besser.
    • Kannst du etwas genauer erklären, was du mit „wie bei WebSockets zu erwarten, wirkten die Bewegungen etwas ruckelig“ meinst? Ich habe einige „IO-Games“ gespielt, und abgesehen von Spielern mit gelegentlich starker Latenz wirkten sie ziemlich flüssig.
      Vor ein paar Monaten habe ich WebSockets ein wenig getestet, und soweit ich es verstanden habe, hat die Nutzung von TCP für latenzempfindliche Kommunikation wie bei Spielen erhebliche Nachteile. Der TCP-Header ist mehr als doppelt so groß wie bei UDP, es gibt zusätzliche Control-Pakete, und die Übertragung neuer Daten wird verzögert, während alte Daten erneut übertragen werden. WebSockets laufen ebenfalls auf TCP und haben daher dieselben Nachteile.
      Trotzdem heißt es oft, TCP garantiere die Zustellung von WebSocket-Nachrichten, aber ich konnte Paketverlust reproduzieren. Am Ende bleiben also die Nachteile bestehen, und wenn man tatsächlich garantierte Zustellung braucht, muss man darüber selbst etwas bauen; dann hätte man die benötigten Nachrichten vermutlich gleich von Anfang an auf UDP aufbauen können.
      Ich habe abgesehen von ein wenig Herumprobieren kaum Wissen und Erfahrung mit Networking, also bitte entsprechend einordnen.
    • CJK-Zeichen machen einen sehr großen Teil der druckbaren Unicode-Zeichen aus. [1] Die zwei größten Blöcke enthalten U+3400 bis U+4DBF und U+4E00 bis U+9FFF.
      Der betreffende String wird als \u57d2\u6111\u48d4\u6a64\u3930\u3099\u37cd\u7a26\u7366\u0999\u60dd\u44c7\u5f37\u681b\u4ccc\u06ec\u4303\u0329\u4f7c dekodiert.
      [1] https://en.wikipedia.org/wiki/CJK_Unified_Ideographs

  • Ein sicherer Weg, ein Spiel niemals fertigzustellen, ist, mit dem Schreiben einer Engine anzufangen.
    Eigene Technologie zu bauen ist durchaus möglich, aber in jedem Schritt sollte diese Technologie auf das eigene Projekt zugeschnitten sein und nicht auf eine allgemeine Spieleplattform.

    • Ich sollte einen Blog starten!
      Mit „einen Blog starten“ meine ich hier, von Grund auf eine neue Blog-Engine zu bauen.
    • Kannst du genauer erklären, welchen Teil von modd.io du meinst? Meinst du, es sei das Ergebnis eines gescheiterten Versuchs, ein Spiel zu bauen?
    • Die meisten Leute, die eine Engine verwenden, wollen vermutlich von Anfang an gar kein Spiel bauen, sondern in Wahrheit eine Engine bauen.

  • Bei Node.js-basierten Multiplayer-Backends habe ich gesehen, dass sie bei steigender Zahl von Verbindungen irgendwann nur noch im Schneckentempo laufen. Mich würde interessieren, wie ihr dieses Problem gelöst habt.
    Wäre in so einem Fall eine Alternative wie Go nicht besser?

    • Ich bin mir nicht ganz sicher, warum. Was Verbindungen angeht, dürfte dank Nodes Event Loop I/O-Blocking bei HTTP-Request/Response kein Problem sein.
      Ich glaube auch nicht, dass das Backend für das Frontend rechenintensive Physikarbeit erledigt.
    • Wir verwenden uWebSockets(https://github.com/uNetworking/uWebSockets). Es ist in C geschrieben, bietet aber ein Interface, das man aus NodeJS nutzen kann.
      In einfachen Tests war die Performance deutlich besser als bei anderen beliebten WebSocket-Bibliotheken, die schnell langsamer wurden.
    • Bei den meisten IO-Games dürfte der Flaschenhals I/O sein. Der Genre-Name kommt zwar von der Top-Level-Domain, wirkt aber wie ein Wortspiel.
      Deshalb fühlt sich Node wie eine gute Wahl an.
    • Skalierbarkeit kann durchaus ein echter Faktor sein, besonders bei vielen Verbindungen. In unserem Fall haben wir das Backend so optimiert, dass es eine beträchtliche Zahl gleichzeitiger Verbindungen effizient verarbeiten kann.
      Jedes Spiel ist auf maximal 64 Spieler begrenzt, aber bei Tests mit über 100 Verbindungen haben wir keine Performance-Probleme gesehen. Jedes Spiel läuft in einem isolierten Container.

  • Mich würde die Motivation interessieren, eine neue Engine zu bauen.
    Wenn man ins README schaut, sind ziemlich spezifische Dinge eingebaut, etwa ein Waffensystem (Nahkampf/Projektile), Shops, clientseitig vorhergesagte Projektile und Einheitenbewegung.
    Ich frage mich, warum man so etwas fest in die Engine einbaut und nicht als kopierbare Plugins umsetzt. Viele Spiele brauchen solche Features natürlich nicht – ist das also eine Game Engine? Oder eine Engine für FPS/RPG/andere bestimmte Genres?
    Ich habe nichts gegen die Technik an sich, aber die Frage „warum?“ bleibt. Wofür ist das gedacht? Warum sollte man das statt Three.js plus eigenem Server verwenden?

    • Danke für die Frage. Wir haben bewusst entschieden, die Engine meinungsstärker zu strukturieren als andere modulare Alternativen, weil wir die Entwicklung von 2D-Multiplayer-Spielen extrem schnell machen wollen.
      Zum Beispiel haben wir in 2 Stunden ein einfaches MMORPG gebaut: https://www.youtube.com/watch?v=GZVsxkALR5U
      Aus unserer Sicht gibt es einen Zielkonflikt zwischen Benutzerfreundlichkeit und Anpassbarkeit. Wir haben uns für Ersteres entschieden, um die Lücke zwischen Multiplayer-Spielen, die als schwer zu entwickeln gelten, und Entwicklern von Casual Games zu verkleinern.
    • „Wofür ist das gedacht?“
      Vermutlich nicht für dich, sondern für Leute, die genau solche bestimmten Spiele bauen wollen. Nicht jede Engine muss universell sein.

  • Ich hatte ein paar Hobbyprojekte, zu denen das hier gut passen würde. Ich kann programmieren, aber bei Hobbyprojekten gibt es Momente, in denen ich mich nicht so stark darauf konzentrieren möchte; deshalb wirken Low-Code und ein interaktiver Editor für Hobbyentwickler attraktiv.
    Am meisten freue ich mich persönlich auf Karten- und Welterzeugung. Es sieht so aus, als wäre der beste Weg, ein Spiel als JSON zu exportieren, es per Programm zu verändern und wieder zu importieren – stimmt das?
    Allerdings ist das etwas einschüchternd. Die unveränderte Tutorial-Welt hat 3500 Zeilen JSON, da gibt es viel zu verstehen.
    Mein erster Ansatz wäre, absichtlich Änderungen im Editor vorzunehmen und zu schauen, wie sich das JSON verändert. Ich müsste auch einen guten JSON-Diff-Viewer finden. Das dürfte helfen, die Stellen zu finden, die ich anfassen möchte. Assets und Kartentiles würde ich wohl im interaktiven Editor zusammenstellen.
    Mich würde interessieren, ob dieser Ansatz sinnvoll ist und ob es hilfreiche Tools dafür gibt.

    • Wir empfehlen nicht, das JSON direkt zu bearbeiten. Es ist ziemlich schwer lesbar und aufgebläht. In modd.io gibt es Actions, mit denen man Karten direkt verändern kann.
      Ein Creator aus unserer Community erzeugt Karten dynamisch mit ChatGPT. Er baut ein Versteckspiel, sendet einen Prompt, der ein 2D-Karten-JSON erzeugen soll, und lädt diese Karte bei jeder neuen Runde. Da es noch nicht veröffentlicht ist, kann ich das Spiel leider nicht teilen.
      Außerdem baut ein Community-Mitglied gerade einen Interpreter für unser Game-JSON. Beispiel: https://pypi.org/project/pymodd/

  • Schön zu sehen, dass mehr solcher Open-Source-Projekte auftauchen. Es überrascht mich, dass es nicht einmal 100 GitHub-Stars hat.

    • Nicht falsch verstehen, ich frage aus echtem Interesse: Warum ist es überraschend, dass es weniger als 100 GitHub-Stars hat?
    • Vielleicht, weil es gerade erst veröffentlicht wurde.