84 lines
3.8 KiB
Markdown
84 lines
3.8 KiB
Markdown
# Ruin Adventurer
|
|
|
|
Ruin Adventurer ist ein Automatisierungs- und Ressourcenmanagement-Spiel, das im Rahmen einer Diplomarbeit entwickelt wird. Der Spieler ist in einer unterirdischen Ruinenanlage gefangen und nutzt Roboter, um die Umgebung zu erkunden, Ressourcen abzubauen, Gegenstände herzustellen und neue Ebenen freizuschalten.
|
|
|
|
Das Spiel wird mit **Godot 4.6** und **C#** entwickelt und ist auf eine spielbare Early-Access-Version für Linux und Windows ausgelegt.
|
|
|
|
## Spielidee
|
|
|
|
Der Spieler steuert keinen direkten Charakter, sondern verwaltet die Ruine aus einer Management-Perspektive. Die eigentliche Arbeit wird durch Roboter erledigt, welche über eine visuelle DSL programmiert werden. Fortschritt entsteht durch das Zusammenspiel von Erkundung, Automatisierung, Crafting, Forschung und Survival-Mechaniken.
|
|
|
|
Das langfristige Ziel ist es, tiefere Ebenen der Ruine freizuschalten und schliesslich aus der Anlage zu entkommen.
|
|
|
|
## Kernsysteme
|
|
|
|
- **Prozedurale Weltgenerierung** mit Wave Function Collapse
|
|
- **Mehrere Ebenen** mit Gates und freischaltbarem Fortschritt
|
|
- **Roboterautomatisierung** über visuelle Programmblöcke
|
|
- **DSL-System** mit Nodes wie Move, Explore, Harvest, Craft, If, For, While, Maintain und Sacrifice
|
|
- **Ressourcen, Inventar und Crafting** auf Basis von JSON-Daten
|
|
- **Forschungssystem** mit freischaltbaren Rezepten, Robotereffekten und Fortschritt
|
|
- **Survival-Aspekte** wie Hunger, Durst, Energie, Hitze und Wartung
|
|
- **Speichern und Laden** des Spielstands in mehreren Dateien
|
|
- **Tutorial und UI-Systeme** für Einstieg, Optionen, Karte, Inventar, Forschung und Roboterübersicht
|
|
|
|
## Technische Grundprinzipien
|
|
|
|
Das Projekt ist bewusst in getrennte Verantwortlichkeiten gegliedert:
|
|
|
|
- `Scripts/World` enthält Weltgenerierung, Layer, Tiles, Pathfinding und Kartendarstellung.
|
|
- `Scripts/Gameplay` enthält Roboter, Crafting, Forschung und Survival.
|
|
- `Scripts/DSL` enthält die ausführbare Logik der Programmierblöcke.
|
|
- `Scripts/UI` enthält die sichtbaren Fenster, Node-Editoren und Anzeigen.
|
|
- `Scripts/Core` enthält zentrale Daten, Laden/Speichern, Ressourcen und Systemintegration.
|
|
|
|
Die sichtbaren DSL-Nodes im Editor sind von den zur Laufzeit ausgeführten ProgramNodes getrennt. Beim Kompilieren werden Runtime-Kopien erstellt, damit mehrere Roboter unabhängig voneinander Programme ausführen können, ohne sich gegenseitig zu beeinflussen.
|
|
|
|
## Voraussetzungen
|
|
|
|
- Godot 4.6 mit .NET/C# Unterstützung
|
|
- .NET SDK passend zur verwendeten Godot-Version
|
|
- Linux oder Windows als Zielplattform
|
|
|
|
Für lokale Steam-Tests wird eine `steam_appid.txt` verwendet. Steamworks ist im Projekt vorbereitet, aber die Kernlogik des Spiels ist nicht davon abhängig.
|
|
|
|
## Starten
|
|
|
|
Das Projekt kann direkt über Godot geöffnet werden:
|
|
|
|
```text
|
|
project.godot
|
|
```
|
|
|
|
Die Hauptszene wird über die Godot-Projekteinstellungen gestartet. Für Tests existiert eine eigene Testszene:
|
|
|
|
```text
|
|
Scenes/TestRunner.tscn
|
|
```
|
|
|
|
## Tests
|
|
|
|
Das Projekt enthält einen einfachen eigenen TestRunner für Unit- und Integrationstests. Getestet werden unter anderem:
|
|
|
|
- Inventar und Crafting
|
|
- Forschung und Forschungseffekte
|
|
- Survival-Logik
|
|
- Roboterzustände
|
|
- DSL-Nodes und Verbindungen
|
|
- Save/Load
|
|
- Layergenerierung
|
|
|
|
Headless-Ausführung mit Godot:
|
|
|
|
```bash
|
|
Godot_v4.6.1-stable_mono_linux.x86_64 --headless --path . Scenes/TestRunner.tscn
|
|
```
|
|
|
|
## Projektstatus
|
|
|
|
Das Projekt befindet sich in einer fortgeschrittenen Prototyp- bzw. Early-Access-Phase. Die wichtigsten Kernmechaniken sind umgesetzt und miteinander verbunden. Weitere Inhalte, Balancing, UI-Polish, Story-Elemente und zusätzliche Roboter-/Gebäudesysteme sind für spätere Versionen vorgesehen.
|
|
|
|
## Hinweis
|
|
|
|
Dieses Repository ist Teil einer Diplomarbeit. Einige Systeme sind daher bewusst auf den Projektumfang zugeschnitten und priorisieren Nachvollziehbarkeit, Testbarkeit und eine funktionierende Spielschleife gegenüber vollständigem Feature-Umfang.
|