Core, eine experimentelle neue Technologie zum Erstellen von Videospielen

 (github.com/damn)
2 Punkte von GN⁺ 2024-09-09 | 1 Kommentare | Auf WhatsApp teilen

  • Was ist coreCore?

    • coreCore ist eine experimentelle Methode zum Erstellen von Videospielen in Form eines Action-RPG-Spielentwicklungswerkzeugs, einer Engine und eines Eigenschaftseditors
    • Es verwendet ein einfaches Komponentensystem, wobei Komponenten Clojure-Vektoren in der Form [keyword value] sind
    • Verschiedene Entitäten bestehen aus Clojure-Maps
    • Seiteneffekte im Spiel werden über Komponenten wie [:tx/foo param] verarbeitet, was einer Datomic-Struktur ähnelt
    • Der gesamte Spielzustand wird in einem einzigen Atom namens app/state gespeichert, und Entitäten existieren ebenfalls als Atome innerhalb des Haupt-Atoms
    • Der gesamte Inhalt der Anwendung wird in resources/properties.edn gespeichert, mit malli-schemas validiert und kann per GUI bearbeitet werden

  • Screenshots

  • So startet man die Entwicklung

    • Den folgenden Befehl eingeben:
      • lein dev
    • Die Anwendung startet und führt außerdem Folgendes aus:
      • Startet einen NREPL-Server
      • Beim Beenden der Anwendung (ESC im Hauptmenü) lädt clojure.tools.namespace geänderte Dateien neu und startet die App erneut
      • Tritt ein Fehler auf, muss die JVM nicht neu gestartet werden; stattdessen den Fehler beheben und dev-loop/restart! aufrufen
      • In VIM kann man die F5-Taste mit folgendem Befehl belegen: nmap <F5> :Eval (do (in-ns 'dev-loop)(restart!))

  • Code-Lizenz

    • Bereitgestellt unter der MIT-Lizenz

  • Asset-Lizenz

Zusammenfassung von GN⁺

  • coreCore ist ein Werkzeug, mit dem sich Action-RPG-Spiele einfach erstellen lassen und das mithilfe eines einfachen Komponentensystems den Spielzustand verwaltet
  • Der gesamte Spielzustand wird in einem einzigen Atom gespeichert, und Eigenschaften lassen sich über eine GUI bearbeiten, was für Entwickler nützlich ist
  • Es wird unter der MIT-Lizenz bereitgestellt, die verwendeten Assets sind jedoch proprietär
  • Ähnliche Werkzeuge mit vergleichbaren Funktionen sind RPG Maker und Unity

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-09-09
Hacker-News-Kommentare

  • Cool. Ich habe zwar noch nie ein Spiel veröffentlicht, sehe aber immer gern unterschiedliche Ansätze zur Spieleentwicklung.
    Bisher war Bevy anfangs gut, konnte aber in der Umsetzung viele Probleme haben und unübersichtlich werden; bei Unity war der Ansatz mit GameObjects und komponierbaren Komponenten am praktischsten, weil einem die Engine nicht im Weg steht und Spaghetti-Code leichter zu vermeiden ist.
    Godot mochte ich nicht. Eine schlechte objektorientierte Hierarchie, eine mäßige eingebaute Sprache, und die „Signals“, die Spaghetti reduzieren sollten, haben es eher noch vermehrt. Pygame ist für kleine Projekte ziemlich gut, und man kann auf eine prozedurale Basis selbst objektorientierte oder funktionale Schichten setzen.
    Clojure kenne ich nicht, aber interessant finde ich den Versuch, in einem Bereich, der typischerweise gut zu Objektorientierung zu passen scheint, eine funktionale Implementierung zu nutzen.

    • Als professioneller Spieleentwickler, der mit Unity und Godot echte Produkte gebaut hat, kann ich der Einschätzung zu Godot und Unity überhaupt nicht zustimmen.
      Godots Signals sind gegenüber der mangelnden Modularität der eingebauten Unity-Klassen ein großer Fortschritt. Godot und Unity haben im Grunde dasselbe Scene/Node/Component-Modell, aber meiner Meinung nach macht Godot es besser.
      Unitys Stärken sind der 3D-Renderer, das eingebaute PhysX, das il2cpp-Backend für C#, der Profiler, die allgemeine Laufzeit-Performance und die Konsolenunterstützung. Godots Design ist dagegen kohärenter, während Unity sich seit etwa 2018 in zehn Richtungen aufgespalten anfühlt.
    • Ich bin kein Spieleentwickler, aber Godots objektorientiertes Design gehörte zu den besseren, die ich ausprobiert habe.
      Heute arbeite ich eher im Embedded-Bereich mit C++ und nutze Objektorientierung nicht mehr so viel, aber ich habe Programmieren mit C# gelernt und bin daher mit Vererbung recht vertraut.
    • Godot ist hervorragend, und ich glaube, in etwa fünf Jahren wird es das Blender der Spieleentwicklung sein. Version 4 ist praxistauglich und kann die meisten Indie-Projekte stemmen.
      Der Bereich, in dem Unity vorne liegt, sind „Triple I“ und „Double A“, weil seine 3D-/Performance-Funktionen, Tools und Add-ons besser sind. Für AAA-Projekte ist keines von beiden die beste Wahl.
      Für 2D- und einfache 3D-Spiele sehe ich inzwischen keinen Grund mehr, Unity zu verwenden, und ich denke, Godot wird langsam vorbeiziehen, während Unitys Marktanteil stetig sinkt.
    • Als kommerzieller Entwickler habe ich früher Unity genutzt und nutze jetzt Godot. Die Kritik an GD Script und Signals kann ich nachvollziehen; ich umgehe das mit C#-Event-Handling.
      Am frustrierendsten sind Nodes und Dinge im Editor, bei denen unklar ist, ob sie Bugs oder Features sind, und es fühlt sich stark so an, als sei Godot ursprünglich für „kleine“ Projekte gemacht worden.
      Deshalb nutze ich den Editor fast nur für den Aufbau von Scenes und die grobe Hierarchie. Meine üblichen Tools sind Emacs+C# LSP, zum Debuggen VS Code, und für Anpassungen am Scene Tree der Godot-Editor.
    • Ich habe Godot ziemlich ernsthaft ausprobiert und es gibt Gründe, es nicht zu mögen, aber GDScript ist meiner Meinung nach keiner davon.
      Im Grunde ist es Python mit Slot/Emit-Semantik und Editor-Integration, und das ist eher gut. Besser, das steckt in der Sprache, als ein komplexer Integrationsweg über Build-System, Metadaten und externe Konfigurationsdateien.

  • Es heißt, man könne Spieleentwicklung einfacher machen, und dann werden haufenweise Fachbegriffe wie Clojure Vectors, Datomics, Atoms, Transactions und Malli Schemas in den Raum geworfen. Kann das jemand erklären?

    • Wenn man den Einführungstext etwas glättet: Core ist ein experimentelles Tool, das die Erstellung von Action-RPGs vereinfachen will.
      Spielelemente und Eigenschaften werden als einfache Datenstrukturen dargestellt, und der gesamte Spielzustand wird in einem Container (app/state) gespeichert, um Verwaltung und Aktualisierung zu erleichtern.
      Außerdem bietet es eine GUI zum Bearbeiten von Spielinhalten, die in einer einzelnen Datei (resources/properties.edn) gespeichert sind, damit auch Nicht-Programmierer leichter damit arbeiten können; Malli-Schemata sollen die Daten validieren, die Konsistenz der Inhalte sichern und Fehler reduzieren.
    • Fairerweise wird nur gefragt, ob Spieleentwicklung einfacher werden kann. Die Antwort ist vermutlich eher „nein“.
    • Das unvermeidliche „Einfachheit ist nicht dasselbe wie Leichtigkeit“: https://www.youtube.com/watch?v=SxdOUGdseq4
      Ein Clojure Vector ist im Grunde eher so etwas wie eine Liste. Ein Atom ist eine veränderbare Referenz auf eine unveränderliche Datenstruktur und kann als eine Art Pointer mit bestimmter Update-Semantik gesehen werden.
      Eine Transaction ähnelt einer Datenbanktransaktion: Mehrere Datenstrukturen werden gleichzeitig geändert, aber nur committed, wenn alle Operationen erfolgreich sind; andernfalls wird zurückgerollt oder erneut versucht.
      Ein Malli Schema ist eine Form von Typprüfung in einer dynamisch typisierten Sprache, und Datomic ist eine nicht-SQL-Datenbankimplementierung auf Basis unveränderlicher Datenstrukturen, die Änderungen nicht destruktiv überschreibt, sondern nur anhängt, sodass man zu jedem früheren Zeitpunkt zurückspulen kann.
    • Die Sprache Clojure hat ein eingebautes Modell zur Zustandsverwaltung, und dieses Projekt versucht, dieses Modell auf Spieleentwicklung anzuwenden.
      Meiner Meinung nach lernt man dieses Modell am besten, indem man sich den Vortrag „Are we there yet“ von Clojure-Schöpfer Rich Hickey ansieht.
    • Ein Clojure Vector ist eine eingebaute Datenstruktur der Sprache und sieht etwa so aus: [1 2 3].
      Ich nutze das, um Seiteneffekte wie [:tx/foo 3] zu konstruieren, und nenne sie, ähnlich wie bei Datomic, Transaction. Dabei ist :tx/foo ein Keyword und identifiziert das Verhalten einer Komponente eindeutig.

  • Ehrlich gesagt denke ich, dass dieses Projekt praktisch gescheitert ist. Es ist ein überdesigntes Durcheinander ohne klare Struktur.
    Das größte Problem ist, dass es überhaupt keine Spezifikation gibt. Entweder wurde keine Spielgeschichte entwickelt, oder vielleicht dachte man, ein Spiel brauche keine Story. Also hat man einfach wie verrückt in Clojure gecodet, weil das Spaß gemacht hat.

    • Fairerweise gibt es auch unter erfolgreichen Projekten viele, die ein überdesigntes Durcheinander ohne klare Struktur sind.
      Es ist gut, etwas Cooles versucht zu haben, und es ist ein Bereich, der viele Menschen interessiert.
    • Allein anzuerkennen, dass es einfach ein unterhaltsames Hobby war und vielleicht nicht so simpel ist wie behauptet, bringt einen schon weiter als viele andere. Ich hoffe, du hast aus dem Projekt viel gelernt.

  • Als Spieleentwickler wirkt dieses GitHub auf mich lächerlich. Es kommt fast wie eine Parodie auf die akademische Selbstversenkung rüber, die Spieleentwickler nicht mögen. Die hässlichen Screenshots setzen dem Ganzen noch die Krone auf.

    • Passt es dann nicht vielleicht einfach schlecht zu dieser Seite? Hacker News dreht sich im Allgemeinen um interessante neue Ideen, nicht nur um inkrementelle Verbesserungen an C++ und Unity.
      Mir fallen ein paar Spiele ein, die aus genau so einer seltsamen akademischen Selbstversenkung entstanden sind. Jonathan Blow aus dem Geschwisterkommentar gehört auch dazu, und als ich dieses Projekt sah, musste ich sofort an Braid denken.
      Prozedurale Generierung war früher ebenfalls ein Elfenbeinturm-Thema, und auch jeder Fortschritt bei 3D-Grafik begann anfangs mit völlig unrealistischen Papers aus Konferenzen. Vieles, was heute in Spielen Mainstream ist, war einst eine akademische Nischenidee.
    • Ich finde die Screenshots nicht „hässlich“, stimme aber zu, dass das README funktional nutzlos ist. Es gibt weder Dokumentation noch Beispiele und auch keine Erklärung, warum man es verwenden sollte.
      Es scheitert schon an der grundlegenden Aufgabe zu vermitteln, was es überhaupt tut.
    • Es hat auch Wert, etwas intellektuell Anregendes zu bauen. Selbst wenn man 100 Stunden damit verbringt, Clojure-datomics zu bauen, und nur eine Stunde Level-Content erstellt, ist eine Stunde mehr als null Stunden.
      Wenn man aus Langeweile sonst gar nichts gebaut hätte, ist das sogar ein Gewinn. Das ähnelt der Logik, mit der Jonathan Blow bei der Indie-Entwicklung Jai verwendet.
    • Es steht ja auch dabei, dass es experimentell ist.

  • Ich bin überrascht, dass dieses Repository trotz der so knappen Dokumentation ziemlich viel Diskussion ausgelöst hat. Wenn man sich den Code ansieht, wirkt es eher wie ein Projekt als wie eine Game Engine.
    Der property editor ist interessant, aber ich habe den Eindruck, dass dieser Beitrag eher wegen des Titels empfohlen wird als wegen des Inhalts.

  • Schön. Es freut mich, einen Entwickler zu sehen, der wie ich Spieleentwicklung mit Clojure macht. Manchmal macht man sich die Arbeit damit selbst schwerer :)
    Ich entwickle derzeit einen 3D-Multiplayer-TPS-Shooter in Clojure. Falls es jemanden interessiert, gibt es hier eine Demo: https://prototype-game.pages.dev
    Bald werde ich auch einen Blogbeitrag über die Entwicklungsreise veröffentlichen.

    • Einer meiner liebsten Momente im Internet ist, wenn mehrere Leute einen virtuellen Raum betreten, spontan herumlaufen und den In-Game-Chat benutzen.

  • Ich mag Clojure, aber ist eine funktionale Sprache mit unveränderlichen Datenstrukturen für Videospielentwicklung nicht eine etwas seltsame Wahl?

    • Es ist durchaus machbar und bringt interessante Trade-offs mit sich.
      Das sind einige meiner Lieblingsartikel zu funktionaler Spieleentwicklung:
      https://prog21.dadgum.com/228.html
      https://prog21.dadgum.com/23.html
      https://prog21.dadgum.com/24.html
      https://prog21.dadgum.com/25.html
      https://prog21.dadgum.com/26.html
    • Es fühlt sich ziemlich natürlich an. Da Clojure auf der JVM basiert, verwendet dieses Projekt intern libgdx, kann auf allen Plattformen bereitgestellt werden und hat ein großes Ökosystem an Bibliotheken.
      Den Rest kann man mit Lisp ohnehin fast beliebig machen. Dank Clojures Umgang mit unveränderlichen Datenstrukturen und seinem hervorragenden Protocol-System (https://www.freshcodeit.com/blog/clojure-protocols-and-the-e...) ließ sich das gesamte Spiel leicht in separate Komponenten aufteilen.
    • Tim Sweeney scheint mit Verse in UEFN ebenfalls in diese Richtung zu setzen. Verse geht eher in Richtung eines zugänglicheren Haskell.
    • So seltsam ist es nicht. Das nächste AA- oder AAA-Spiel wird es zwar nicht verwenden, aber Unveränderlichkeit sieht man auch in sehr interaktiven Bereichen wie React-Reducern oder Redux häufig.
      Clojure hat ein besseres Performance-Potenzial als Ruby oder Python, und beide wurden tatsächlich schon in kommerziellen Indie-Spielen eingesetzt.
    • Funktionale Programmierung wurde in der Spieleentwicklung kaum überhaupt ernsthaft ausprobiert. Es gibt zu wenig Überschneidung zwischen der Spielebranche und der Forschung.
      Studios sind natürlich risikoscheu und bevorzugen vertraute Strategien wie Objektorientierung oder ECS für große Mengen an Entitäten.
      Persönlich glaube ich, dass funktionale Programmierung gut passen könnte, aber zuerst muss man eine Architektur finden, die reale Probleme der Spieleentwicklung löst. Man sollte mit kleinen Experimenten anfangen, und Game Jams eignen sich dafür perfekt.

  • Es gibt bereits eine kommerzielle Plattform zur Spieleerstellung namens Core, die auf Unreal Engine 4 basiert.
    https://en.wikipedia.org/wiki/Core_(video_game)

  • Der Name scheint schlecht gewählt zu sein. Er wird in diesem Bereich schon verwendet: https://www.coregames.com/create

    • Das war auch mein erster Gedanke. Vor allem, weil man dort Spiele innerhalb eines Spiels erstellt, kann man es ebenfalls als „neue“ Art betrachten, Spiele zu schreiben.

  • Es wäre interessant, Daten zu „Zeit/Komplexität, die in die Game Engine gesteckt wurden“ im Verhältnis zu „Komplexität/Interessantheit des entstandenen Spiels“ zu analysieren.
    Als Spieleentwickler würde ich erwarten, dass der Ertrag neuer Spiele aus einfachen Template-/Engine-Systemen einer abflachenden logarithmischen Kurve folgt.
    Anders gesagt: Je besser man die Keksmaschine macht, desto weniger vielfältig werden die Kekse.