Erfahrungen mit Lemmings-ähnlichen Spielen und Godot?

Hallo zusammen,

ich plane aktuell ein neues Puzzle-Spiel für Mobile und möchte mich dabei grob vom Prinzip klassischer Lemmings-ähnlicher Spiele inspirieren lassen: also viele kleine Figuren durch ein Level führen und ihnen an den richtigen Stellen bestimmte Aktionen zuweisen.

Mir geht es dabei vor allem um zwei Punkte:

1. Erfahrungen mit Lemmings-ähnlichen Spielen
Hat jemand von euch schon einmal so ein Spiel entwickelt, prototypisch umgesetzt oder sich technisch näher damit beschäftigt?

Mich würden vor allem Erfahrungen interessieren zu:

• Wegfindung / Laufverhalten der Figuren
• präziser Steuerung auf Touch-Geräten
• Leveldesign und Spielfluss
• Balance zwischen kontrollierbarem Gameplay und bewusstem Chaos
• typischen Problemen, die man anfangs unterschätzt

2. Godot für so ein Projekt
Ich überlege, das Ganze in Godot umzusetzen.

Mich würde interessieren:

• Ist Godot aus eurer Sicht eine gute Wahl für ein 2D-Spiel dieser Art?
• Wie gut eignet sich Godot für viele gleichzeitig aktive kleine Spielfiguren?
• Wie praktikabel ist der Workflow für Tilemaps / Levelbau?
• Wie sieht es mit Kollisionen, Terrain-Interaktion und eigenen Tools für schnelleres Levelbauen aus?
• Gibt es Erfahrungen mit der Performance auf Android/iOS?

Mir geht es ausdrücklich nicht darum, ein bestehendes Spiel zu kopieren, sondern ein eigenes Spiel mit eigener Optik, eigenen Figuren und eigener Identität zu entwickeln – nur eben inspiriert von diesem Spielprinzip.

Falls jemand Erfahrungen mit ähnlichen Projekten, mit Godot in diesem Bereich oder mit typischen technischen Stolpersteinen hat, würde ich mich sehr über Einschätzungen freuen.

Vielen Dank!

Hallo,

vielen Dank, das ist ein sehr guter und wichtiger Punkt.

Genau diese Unterscheidung finde ich auch zentral: Die Figuren sollen keinen optimalen Weg berechnen, sondern eher einfachen lokalen Regeln folgen. Gerade das macht den Reiz des Spielprinzips ja aus.

Ich denke inzwischen auch, dass es eher um ein sauberes Verhaltenssystem geht als um klassisches Pathfinding:

• laufen
• bei Hindernissen reagieren
• fallen
• durch Spielereingriffe den Zustand ändern

Spannend fände ich dabei vor allem, wie man das technisch am besten sauber organisiert, damit es auch mit vielen gleichzeitig aktiven Figuren stabil und gut erweiterbar bleibt.

Falls du dazu aus deiner Unity-Erfahrung noch mehr sagen kannst:
Würdest du so etwas eher über einen klaren State-Machine-Ansatz lösen oder eher stärker datengetrieben aufbauen?

Viele Grüße

Hallo,

vielen Dank, das hilft mir sehr weiter.

So in der Richtung hatte ich es mir inzwischen auch eher vorgestellt: keine große komplizierte KI, sondern eine schlanke State Machine mit klaren Zuständen und dazu einfache lokale Regeln. Gerade der Punkt, Sonderfälle nicht jeweils als eigenen Zustand auszuformulieren, sondern eher mit Parametern zu arbeiten, klingt für mich sehr sinnvoll.

Das datengetriebene Element finde ich auch spannend, vor allem für unterschiedliche Figurentypen oder spätere Fähigkeiten, ohne dass die Grundlogik jedes Mal umgebaut werden muss.

Ich vermute im Moment, dass die eigentliche Schwierigkeit dann weniger in der Wegfindung liegt, sondern eher in einer sauberen Kombination aus:

• Zustandswechseln
• Kollision / Bodenerkennung
• Eingriffen des Spielers zur Laufzeit
• und einer stabilen Levellogik

Falls du dazu noch eine Einschätzung hast:
Würdest du die Figur eher komplett sensorbasiert aufbauen, also mit Boden-/Wandabfragen direkt an der Figur, oder eher stärker über Informationen aus dem Tilemap-/Levelsystem steuern?

Viele Grüße

Hallo,

danke, das klingt für mich sehr plausibel.

Je mehr ich darüber nachdenke, desto sinnvoller erscheint mir genau dieser Ansatz: keine klassische Physik-Welt, sondern ein klar lesbares Levelmodell, auf das die Figuren lokal zugreifen. Das passt vermutlich auch viel besser zu dem Spielprinzip, weil man das Verhalten dann sauber und kontrollierbar halten kann.

Gerade der Punkt mit:

• Boden unter mir
• Hindernis vor mir
• Fallkante schräg unten
• Bereich über mir

wirkt auf mich wie eine sehr gute Grundlage für die Kernlogik.

Ich könnte mir gut vorstellen, das Level intern in logisch relevante Informationen aufzuteilen, also z. B. begehbar / blockierend / grabbar / tödlich, und die Figuren dann nur noch auf diese Daten schauen zu lassen.

Das würde wahrscheinlich auch spätere Eingriffe des Spielers sauberer machen, wenn sich das Level zur Laufzeit verändert.

Vielen Dank, das hilft mir gerade sehr bei der gedanklichen Strukturierung.

Viele Grüße

Hallo zusammen,

Aktuell habe ich von der Figur eine fertige **Seitenansicht als einzelnes PNG** und frage mich, wie man daraus am sinnvollsten eine **Gehanimation** ableitet.

Mein Ziel ist keine High-End-Animation, sondern ein sauberer, glaubwürdiger Walkcycle für ein Spiel.
Die Figur ist eher rund und simpel aufgebaut, also kein realistischer Charakter.

Meine Fragen an euch:

* Habt ihr Erfahrung damit, **aus einer einzelnen Seitenansicht** eine Gehanimation zu erstellen?
* Macht ihr so etwas eher **klassisch Frame für Frame**?
* Oder nutzt ihr dafür Tools wie **Spine, Moho, Live2D** oder etwas anderes?
* Lohnt sich Rigging bei so einer einfachen Figur überhaupt, oder ist ein kleines Sprite-Sheet mit z. B. 4–8 Frames in der Praxis sinnvoller?
* Gibt es Tools oder Workflows, die einem dabei wirklich helfen, ohne dass man erst ein komplettes Profi-Rig bauen muss?

Mir geht es vor allem um einen pragmatischen Workflow für ein kleines Spielprojekt.
Falls jemand so etwas schon gemacht hat, würde mich interessieren, wie ihr dabei konkret vorgeht.

Danke euch!

Eher modern, nicht Pixelart.

Die Figur ist zwar simpel und eher cartoonig aufgebaut, aber schon als normales PNG und nicht als klassischer Pixel-Sprite gedacht. Es geht also eher um einen kleinen sauberen 2D-Game-Character für Mobile als um einen Retro-Look.

Mein Ziel wäre im Moment ein pragmatischer Walkcycle, der glaubwürdig wirkt, ohne dass ich dafür direkt einen riesigen Animations-Workflow aufbauen muss.

Deshalb überlege ich gerade, was in so einem Fall sinnvoller ist:

• ein kleines klassisches Sprite-Sheet mit ein paar Frames
• oder ein eher einfaches Rigging-Verfahren mit einem passenden Tool

Viele Grüße

Danke, das ist eine gute Einordnung.

Genau so hatte ich es bislang auch verstanden: Spritesheets wirken für einen einfachen Einstieg oft direkter und unkomplizierter, während Rigging eher dann spannend wird, wenn man später mehr Flexibilität braucht.

Für meinen konkreten Fall klingt Spritesheet im Moment tatsächlich näherliegend, weil es erstmal nur um eine glaubwürdige, einfache Gehanimation für eine relativ simple Figur geht und nicht um ein großes Animationssystem mit vielen Varianten.

Der Speicherpunkt ist natürlich interessant, aber für den Anfang wäre mir ein unkomplizierter Workflow wahrscheinlich wichtiger als maximale Flexibilität.

Ich versuche gerade abzuschätzen, ab wann sich Rigging bei so einer Figur wirklich lohnt.
Würdest du sagen, dass man bei einer einfachen 2D-Figur für einen Walkcycle mit z. B. 4–8 Frames in der Praxis meist besser fährt als mit einem kleinen Skeleton-Setup?

Viele Grüße

Quote from grinseengel

Das kann ich dir leider nicht beantworten. Skeleton-bones-animationen habe ich selbst noch nicht erstellt. Aber bezogen auf dein Projekt würde ich das auch nicht in Erwägung ziehen.

Alles klar, trotzdem danke dir.

Das bestätigt mich aber schon in meinem Eindruck, dass für mein Projekt ein kleines klassisches Spritesheet wahrscheinlich der sinnvollere und pragmatischere Einstieg ist als direkt mit Skeleton-/Bone-Animationen zu starten.

Dann werde ich die Richtung erstmal weiterverfolgen.

Viele Grüße

Quote from Orange4

Ich habe mit Godot noch nie gearbeitet aber so rein aus dem Bauch raus würde ich schätzen, dass es vermutlich besser wäre, ein Rig zu erstellen. Das ist ja eine relativ einfach gehaltene Figur wodurch das nicht so eskalieren sollte wie bei einer Animefigur mit tausend Strähnen und absurder Kleidung xD

Ok Spaß bei Seite, kommt natürlich letztlich auch drauf an, mit was sich besser am Ende in Godot arbeiten lässt. Ich vermute aber, dass eine größere Grafik wie du sie hier gepostet hast mit nur 4-8 Frames für eine Laufanimation ruckelig aussehen könnte und ggf auffällt, dass die Schatten bei der Bewegung nicht passen (weil die sauber Frame per Frame nachzuzeichnen würde ich nur bei Pixelgrafik empfehlen). Wenn du es aber dennoch einfach mal probieren möchtest, würde ich die Grafik in verschiedene Ebenen aufteilen (Hände, Körper, Haarsträhnen falls die sich bewegen sollen, Füße) und dann die entsprechenden Parts, die sich bewegen sollen, ein Stück drehen / deformieren / neu zeichnen / ... und das Ergebnis dann als neuen Frame speichern.

Also ungefähr so zum Beispiel (bei mir ist jeder Ordner ein Frame, dann kann man den ganzen Ordner kopieren und hat seine Ebenen direkt wieder parat):

Danke dir, das ist ein interessanter Punkt.

Genau diese Frage mit der Größe der Figur und der möglichen Ruckeligkeit bei nur wenigen Frames beschäftigt mich auch gerade. Bei kleiner Pixelart kann man mit wenig Frames oft gut durchkommen, aber bei einer größeren, saubereren Grafik fällt es wahrscheinlich schneller auf.

Dein Vorschlag, die Figur in Ebenen aufzuteilen und daraus erst einmal manuell ein paar Frames zu bauen, klingt für mich sehr sinnvoll. Das wäre wahrscheinlich ein guter Mittelweg: noch kein richtiges Rig, aber auch nicht jede komplette Figur immer neu von Grund auf zeichnen.

Gerade für einen ersten Walkcycle könnte das ein pragmatischer Test sein, um zu sehen, ob 4–8 Frames schon reichen oder ob man später doch in Richtung Rigging denken muss.

Danke auch für den Hinweis mit den Schatten, das ist ein guter Punkt.

Viele Grüße

Kurzes Update von mir:

Ich habe inzwischen mit einem ersten Prototypen in **Godot** angefangen und wollte den aktuellen Stand einmal ergänzen.

Bisher ging es vor allem darum, das Grundprinzip technisch überhaupt einmal in Bewegung zu bringen:

* erster sehr einfacher Prototyp
* Umstellung auf eine **Seitenansicht**
* erster Versuch mit einer einfachen **Rigging-/Bone-Animation** für die Figur

Damit bin ich noch ganz am Anfang, aber es hilft gerade sehr, die grundsätzliche Richtung besser einzuschätzen – vor allem, was Figurendarstellung, Bewegungsgefühl und den möglichen Workflow in Godot angeht.

Ich hänge dazu drei kurze Videos an, die diese ersten Entwicklungsstufen zeigen:

1. erster technischer Prototyp
2. Seitenansicht der Figur
3. erster Rigging-Versuch

Als nächsten Schritt möchte ich nach diesem ersten Rigging-Versuch ausprobieren, die **Gehanimation durch den Einsatz von Polygonen** weiter zu verbessern, um die Bewegung organischer wirken zu lassen.

Mich interessiert dabei vor allem, wie ihr den bisherigen Weg einschätzt – insbesondere im Hinblick auf:

* Lesbarkeit der Figur in der Seitenansicht
* ob Rigging hier grundsätzlich sinnvoll wirkt
* oder ob ihr für so ein Projekt eher früh in Richtung klassischer Frame-Animation gehen würdet

Ich freue mich über Feedback.

Viele Grüße

Danke dir, das ist eine sehr hilfreiche Einschätzung.

Ja, das stimmt – aktuell ist es noch eher ein Wackeln als eine richtige Gehanimation. Im Moment konzentriere ich mich bewusst erst einmal auf den grundlegenden Bewegungsablauf, also vor allem auf die Gehbewegung selbst.

Die Figur ist bei mir allerdings auch etwas speziell aufgebaut: eher ein runder Körper mit sehr kurzen Beinen ohne Knie und kurzen Armen ohne Ellenbogen. Deshalb habe ich im ersten Schritt zusätzlich den Körper mitanimiert, damit das Ganze überhaupt etwas dynamischer wirkt und nicht komplett starr aussieht.

Die nächsten Ausbaustufen wären bei mir:

• die Beine klarer nach vorne/hinten zu führen
• die Arme mitzunehmen
• und später auch die Haare leicht mitfedern zu lassen

Also genau in die Richtung, die du beschreibst.

Der Hinweis mit den Keyframes passt auch gut zu dem, was ich gerade ausprobiere. Im Moment geht es für mich vor allem darum, erst einmal die Hauptposen sauber herauszuarbeiten und danach zu schauen, wie gut sich die Zwischenbewegungen in Godot lösen lassen.

Danke dir, das hilft mir beim Einordnen auf jeden Fall weiter.