Nach einigem hin und her habe ich mich durchgerungen, mir doch mal die Godot-Engine zu Gemüte zu führen. Wir haben wohl dafür noch keinen Faden, deshalb mache ich den mal zum Erfahrungsaustausch auf.
Bisher bin ich etwas zwiegespalten: Die technischen Möglichkeiten sind durchaus beeindruckend, der „batteries included“ Ansatz ist auch nett, und der Editor ist trotz einiger rauher Ecken brauchbar. Was mich nervt ist die Sprache: GDScript ist gelinde gesagt gewöhnungsbedürftig, und ich merke, wie verwöhnt ich von Java oder Kotlin bin. Auch die Kommunikation zwischen den Szenen und eine vernünftige Gliederung des Codes fällt mir schwer - aber vielleicht ist das eine Sache, die mit der Erfahrung kommt. Ich kämpfe jedenfall ständig gegen meinen Instinkt, das „Model“ vom „View“ trennen zu wollen…
Erfahrung hab ich keine - aber Godot ist mir als Engine trotzdem bekannt. Meines Wissens nach sollte diese btw auch C# unterstützen. Ich würde es mir zumindest mal anschauen (C# ist wirklich ne tolle Sprache!).
Ich hab noch nicht mit Godot gearbeitet - glaube aber, dass ich in Unity eine ähnliche Vorgehensweise habe wie Leute es bei Godot gewohnt sind. Denn für mich klingt es, als ob Godot und Unreal sich da ziemlich ähnlich sind (und ich hab mein Vorgehen ja durchaus von Unreal übernommen). Denn Godot und Unreal behandeln Ihre Assets mehr als Bausteine. In Unity sieht man aber häufig ziemlich heftige Abhängigkeiten (was imho eine ziemlich beschissene Architektur ist).
Aufgrund dessen würde ich erwarten, dass der Einstieg in Godot einfacher und sich „richtiger“ anfühlt - als bei Unity. Deswegen weiß ich auch gar nicht, ob ich hier viele Tipps geben kann, weil du mit Godot aus architektonischer Sicht schonmal einen der imho größten Fehler gar nicht erst begehen wirst.
Deswegen vllt mal etwas, wie ich meine Sachen aufbaue. Ich denke du wirst auch oft genug eigene Komponenten schreiben. Zu Anfang hatten die bei mir schon z.T. Spiellogik mitbekommen. Es ist extrem verführerisch das zu tun! Deswegen würde ich generell drauf achten Komponenten so dumm wie möglich zu halten! Ich versuche mittlerweile immer im Hinterkopf zu haben die Dinger so zu schreiben, dass ich sie in ein anderes Projekt möglichst einfach kopieren könnte. Generell würde ich auch immer drauf achten, dass die Komponenten Data-Driven sind.
Natürlich kommst du früher oder später nicht um Logik drum rum. Aber diese würde ich bewusst in einem eigenen Layer halten. In meinem Fall sind das eigentlich immer irgendwelche Graphen (FlowGraph, FiniteStateMachineGraph, BehaviorTreeGraph). Was dir da Godot bietet weiß ich nicht, aber könnte natürlich auch eine (oder mehrere) dedizierte Komponenten sein. Und spätestens hier merkst du dann den Vorteil einer Architektur die DataDriven ist. Deine Logikschicht kann sich einfach an deine „Dummen“ Komponenten ran hängen und Ihren Job machen.
Und solltest du mit FSM (FiniteStateMachines) arbeiten, dann kann dir ein DataDriven-Design gerade bei sowas wie SaveGames auch das Leben extrem erleichtern. Den Zustand einer FSM zu speichern ist (je nach FSM) nämlich gar nicht so einfach.
Hoffe ich konnte ein wenig helfen - Bin auf jeden Fall mal gespannt, was du zu Godot zu berichten hast!
Meiner Erfahrung nach funktioniert das klassische MVC Modell zwar gut bei GUIs aber eher weniger bei Spielen. Hier sind die Modelle dann meist doch eher auf Performance aber auch durch technische Limitationen sehr einfallsreich gelöst, und wenn es eine komplexere MVC Variante mit anderen Abhängigkeiten ist. Auch wenn Skat jetzt doch eher einer normalen GUI ähnelt als den Anforderungen an reale Spiele.
Unitys neues Modell setzt z.B. nicht mehr auf OOP sondern auf ein „Data-Orientated“ design (DOTS).
Mit Godot kenne ich mich aber überhaupt nicht aus. Keine Ahnung wie die das jetzt genau machen.
Ja, das deckt sich mit meinen Erfahrungen. Sowas wie MVC/MVVM kannste eigentlich vergessen (hat lange gedauert, bis ich das einsehen wollte ^^). Selbst von sowas wie DI hab ich mich verabschiedet (und ich LIEBE DI-Frameworks!).
Godot hat fertige Objekte wie Vektoren oder Sprites. Eine Szene erlaubt es, einen Root-Node und Kinder (auch andere Szenen) drunterzupacken und zu konfigurieren. So weit, so gut. Jeder Knoten innerhalb einer Szene kann auch ein Skript haben, um komplexeres Verhalten zu erlauben. Auch schön. Aber jetzt kommt es: Das Skript pappt nicht einfach lose am Knoten dran, es erweitern ihn. Skripte sie sind also im Prinzip dasselbe wie Klassen in Java - normalerweise anonym, aber man kann die erweiterten Objekte auch benennen, also eigene Typen basteln. Habe eine Weile gebraucht, um das zu raffen.
Bei den Abhängigkeiten wird es kompliziert: Entweder kann man sich durch den Objektbaum hangeln, oder man verwendet Signale (Observer Pattern). Der Daten-Austausch zwischen verschiedenen Top-Level-Szenen ist nicht so schön, weil es keine Konstruktoren oder so gibt, man kann aber durchaus eine Szene in einer anderen konfigurieren, bevor man zu dieser wechselt. Es gibt auch sowas wie globale Szenen („Autoloads“), die applikationsweiten State halten können.
Mein Eindruck vom Objektsystem ist durchwachsen, aber langsam macht es wenigstens ein bisschen Sinn, vielleicht werde ich noch warm damit.
Was mich geärgert hat ist, dass Godot keine eingebauten Unit-Tests hat, insbesondere weil ich schon öfter refactored habe, und dann lief der Krempel auf einmal nicht mehr.
Es gibt zwar fertige Lösungen dafür, aber es geht auch Marke Eigenbau für kleinere Spiele:
Eine Szene wie „Test“ erstellen (die natürlich nirgendwo referenziert wird), Typ ist egal
Ein Skript „Test“ dranhängen
Darin Testmethoden schreiben, Fehler mit push_error() werfen
Testmethoden in _ready() aufrufen
Tests können dann über den Szene-Player ausgeführt werden
Ach ja, eine neue Erkenntnis: Für Bewegungen wie die der Karten sind Tweens viel bequemer als der AnimationPlayer. Letzterer ist eher für die Animation von Spielfiguren oder so geeignet.
- Bin auf jeden Fall mal gespannt, was du zu Godot zu berichten hast!