[ZFX Action 25] [Projekt] Donkeys & Droids

[xTr1m]

Ich bin das erste mal hier dabei :) Auf Einladung von Schrompf habe ich mich motivieren lassen mitzumachen.

Vorstellung
Für diejenigen die mich nicht kennen: ich bin Entwickler in der Spieleindustrie, ich war bei EA Phenomic und bin jetzt bei Envision Entertainment. Meine Hauptsprache ist C#. Da wir seit über'n Jahrzeht unsere in-house Engine nutzen und weiterentwickeln, kam ich bisher nie dazu, mir Engines wie Unity, Unreal & co anzuschauen. Ich wollte mal zwischendurch Lua lernen und hatte mir privat Defold angeguckt gehabt, aber für die zfx action habe ich mich für Godot entschieden, um eine (für mich) neue Engine mit gutem Ruf und C# support kennenzulernen.

Ich finde die Themen super, die haben den nötigen kreativen Anreiz geliefert 🙂

Ich habe mich am Wochenende nach Lehrbuch drangesetzt... Ideen gesammelt, game-design Dokument formuliert, Datenstrukturen modelliert, und habe damit an einem Prototypen in C# gebastelt. Die Spiellogik darin ist unabhängig von einer jeglichen Engine, und wird aktuell mit einer WPF Anwendung isoliert getestet. Sobald ich zufrieden bin ziehe ich dann alles nach Godot um.

Ich lasse mich aktuell stark aus zwei meiner aktuellen Lieblingsspiele inspirieren: Opus Magnum (Planen, Knobeln, Optimieren) und Balatro (Zufall, Investieren, Opfern), ich versuche ein Blend von beiden Spielen mit meinen eigenen Twists zu basteln.

Design Zusammenfassung
Es wird ein taktisches Einzelspieler-Roguelite auf Hexfeldern: Man programmiert freischaltbare Roboter über ein begrenztes Command-Tape, um in acht vorgegebenen Aufgaben wachsende Lieferziele zu erreichen.

Die Aufgaben sind denkbar einfach: erfülle eine Mindestanzahl an Lieferungen von A nach B. Vorteilhaft für den Roboter ist es, sobald ein oder mehrere Packesel einsetzt werden um die Tragekapazität enorm zu erhöhen.

Ressourcen wie Energie, Vorschau und Tape-Länge werden verwaltet, Wetter und Zonenmodifikatoren beeinflussen die nächsten Anweisungen, und eine feste Effektreihenfolge sorgt für Planbarkeit.

Vor jedem Lauf werden Anweisungen aus dem Roboterspeicher gezogen, auf dem Tape angeordnet, vorab geprüft und anschließend ausgeführt. Zwischen der Ausführungszeiten kann man Patches einspielen, oder sich kosmischer Strahlung mit zufälliger Auswirkung aussetzen. Glitches treten als Sofortereignisse auf oder werden gegen steigende Energiekosten aufgeschoben.

Durch Metaprogression sollen später weitere Roboter und Optionen freigeschaltet werden. Effizienzmetriken wie benötigte Anweisungen, Pfadlänge, besuchte Felder, verschwendete Energie und Lieferungsüberschuss sollen den Spielstil bewerten und zu immer eleganteren Programmen motivieren.

Fortschritt
Hier eine Vorschau des Prototyps vom Wochenende: http://xtr1m.com/temp/zfx1.mp4

[xTr1m]

Ich habe Fortschritte beim Prototyp gemacht.
Die core loop ist nun ein deterministischer endlicher Automat. Beim erreichen eines Zustands kriegt eine GUI die Möglichkeit, mit einem Request, Zustandsübergänge über Commands auszulösen. Requests und Commands sind beide stark typisiert.
Im Spiel wird durch einen Command eine menge von Absichten (Intent) generiert. Sämtliche Effekte im Spiel kriegen die Gelegenheit, die generierten Intents zu modifizieren (als Modifier) modelliert. Danach werden die modifizierten Intents ausgeführt, und eine Menge von Results werden generiert, und als Ergebnis des Commands an die GUI zurückgegeben. Somit kann das Spiel der GUI gezielt alle Änderungen mitteilen, und die GUI kann mit diesem kontext die nächste Stufe im Spiel auslösen.
Die Spiellogik kommt komplett ohne einer jeglichen Zeitkomponente aus, Animationen usw kann die GUI wie sie will machen.
Ich habe meine Core Loop (Glitch, Improve, Execute) modelliert und mein WPF Prototyp erweitert, um auf Zustandsänderungen im Spiel zu reagieren, und die nächsten Schritte auszulösen. Ich habe mir auch hilfsweise ein PropertyGrid eingebaut um jederzeit in den Spielzustand reingucken zu können.
Als nächstes will ich mich um die eigentliche Ausführung der Programme und dessen Anweisungen kümmern.

Viel Spaß beim Zusehen: http://xTr1m.com/temp/zfx2.mp4

[Schrompf]

Ich versteh zwar nicht viel von Deinen internen Vorgängen und Schlüsselwörtern, aber klingt als hättest Du Fortschritt auf dem Weg zur Spielbarkeit. Das ist doch toll!

[scheichs]

Hey xTr1m, willkommen hier bei ZFX!
Schön einen Vollblut-Spieleentwickler hier zu haben.

Deine Posts lesen sich sehr interessant (auch wenn ich ein paar Dinge auch nicht ganz kapiere :)) und dein Prototyp sieht auch schon krass aufwendig aus. Freue mich auf weitere Fortschritte!

[xTr1m]

Ich bin seit dem letzten Update gut vorangekommen. Es wird ein Tatktikspiel mit 14 "glitch" Karten und 20 "patch" Karten, dem Namen entsprechend verhalten sie sich vorteilhaft oder nachteilhaft für unseren Avatar, eine Blechbüchse!

Ich stelle gerne ein Auszug aus meinem game design Dokument vor, und die paar Sprites die ich mir mit ChatGPT erstellen lassen habe ;)

Modifiers
Meine Entitäten im Spiel sind ein Feld auf dem Spielbrett, eine Karte/Instruktion die man ausspielt, oder der Avatar. Entitäten können sogenannte Modifier kriegen, die das Verhalten verändern:

• Corrupt: does the opposite
• Unreliable: 1 in 4 chance of doing nothing
• Race condition: 1 in 4 chance of switching places with next instruction
• Throttled: Energy cost +1
• Effective: 1 in 4 chance of working twice
• Optimized: Energy cost -1 (min 0)
• Efficient: Consumes no tape space
• Persistent: Not discarded after execution

Glitches
Am Anfang einer Runde zieht man aus dem Glitch-Deck eine Karte... will man sie nicht haben, kostet das was. Und zwar zunehmend je öfter man ein Glitch vertagt. Also doch lieber in den sauren Apfel beißen?

• Rain: 1 in X grass cells become mud, dry grass becomes grass, #Temporary
• Drought: fertile becomes grass, 1 in X grass cells become dry, #Temporary
• Pest: All deliveries reduced, #Temporary
• Gravity: Carry capacity and move energy reduced, #Temporary
• HeatWave: Energy reduced, #Temporary
• Sand storm: Preview malus, #Temporary
• Misconception: One random instruction receives corrupt (permanent)
• Short circuit: One random instruction receives unreliable (permanent)
• Desynchronization: One random instruction receives race condition (permanent)
• Latency: One random instruction receives throttled (permanent)
• Solar flare: All instruction slots receive corrupt, #Temporary
• Lightning storm: All instruction slots receive unreliable, #Temporary
• Meteor storm: All instruction slots receive race condition, #Temporary
• Wind storm: All instruction slots receive throttled, #Temporary

Patches
Das sind die guten Karten, die man durch diverse Mechaniken erhalten kann um sie später auszuspielen:

• Common
  • Instruction: Move #Forward 1 cell
  • Instruction: Turn #Right
  • Instruction: Turn #left
  • Instruction: #Interact
• Uncommon
  • Potentiate, adds effective
  • Optimize, adds optimized
  • Streamline, adds efficient
  • Persist, adds persistent
  • Remember, adds memory
  • Reason, adds preview
• Rare
  • Instruction: Detoxium Prime: Converts #Forward mud into grass or grass into fertile
  • Instruction: Flying disk: Move #Forward into 1 blocked cell
  • Instruction: Aluminum hat: instructions are #Immune to the effects of unreliable #ShortTerm
  • Instruction: Electromagnetic field: instructions are #Immune to the effects of corrupt #ShortTerm
  • Instruction: Atomic clock: instructions are #Immune to the effects of race condition #ShortTerm
• Legendary
  • Instruction: Jump: move #Forward 2 cells, ignoring blocking
  • Instruction: Repeat: copy #Next
  • Instruction: #Rest (restores Energy instead of consuming)
  • Instruction: Stabilize: nullifies the effect of any modifiers of #Next

[xTr1m]

Ich habe auch bereits die Logik von all den Karten und Modifiers implementiert, und konnte schon die gesamte core loop durchtesten: der Roboter kriegt Lieferungen von A nach B hin.
http://xtr1m.com/temp/zfx3.mp4

[Schrompf]

Oh wow, ein quasi vollwertiges Spiel!