[WIP] TermQuickRPG Worklog

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • [WIP] TermQuickRPG Worklog

      Hi,

      ich hab neulich am Wochenende als Fingerübung mit ein paar Tools herumgespielt.

      • dem Terminal/der Shell
      • Ruby, meiner liebsten Programmiersprache
      • ncurses, eine Bibliothek, mit der man (1) ASCII-Art Fensterrahmen zeichnen, (2) Fenster als Koordinatensysteme mit eigenem Nullpunkt, und (3) Tastatureingaben behandeln kann


      Da dachte ich mir glatt: ey, so kannst du doch auch eine RPG Engine schreiben! Ohne Grafik (weniger Aufwand), und cross-platform!

      Ich veröffentliche Änderungen hier:
      github.com/DivineDominion/TermQuickRPG

      Ich baue das Ding "bottom-up": das heißt unter anderem, manche Teile vom Code sind in ihrer Form jetzt noch viel zu zu konkret, um wiederverwendet zu werden, sodass ich mit der Zeit immer mehr Bausteine herausbreche und umschreibe. Mit anderen Worten: selbst das bisschen, das schon da ist, bleibt wahrscheinlich nicht in dieser Form bestehen. Ich mache das so, damit ich schnelles Feedback für neue Features habe, die ich einbaue, und weil ich in der Vergangenheit mit zu viel Architekturüberlegungen am Anfang ausschließlich schlechte Erfahrungen gemacht habe. (Meine letzte spielbare Demo habe ich 2001 geschrieben -- die war nicht erweiterbar, aber immerhin spielbar, wohingegen alle Versuche danach an der Überstrukturierung ohne Funktionalität krankten.)

      Ich poste hier dann mal Fortschritt. In naher Zukunft sollte das Bearbeiten von Karten und Basteln von Dialogen auch gehen. Ab dann wird es irgendwann auch interessant für andere Spielebauer, Szenarien zu entwerfen.
    • Hier mal der Stand bisher in 2 Updates, die ich gepostet hätte, wenn ich den Thread früher erstellt hätte :)


      Stand 2018-08-10



      Damit ihr einen ersten Eindruck bekommt, so sieht ein hässliches ncurses-Fenster im Vollbild aus, mit Text oben und einem beweglichen ASCII-Zeichen auf der Karte.

      ncurses kann das Hauptfenster (die "main map") an die ursprüngliche Größe des Terminals anpassen. Das heißt, je nachdem, wie groß das Programmfenster ist, wird auch der Textrahmen nach Start des Spiels sein.

      Auf Änderungen des Programmfensters zu reagieren wird schwieriger. (Da gibt es für Windows keine Standardlösung, hab ich den Eindruck.) So ein "responsive game window", analog zu modernen Websites, ist aber auch nicht so superwichtig im Moment.

      WASD Steuerung ist natürlich auch schon drin, mit E als alternativer Aktionsknopf :)


      Stand 2018-08-26



      Hier sieht man schon, wie Gegenstände auf der Karte für Kollision herhalten und aufgenommen werden kônnen. Es gibt momentan noch keine Objekte, mit denen man kollidieren kann, ohne sie mitnehmen zu dürfen ... :)

      Außerdem hat das Fenster vom "pick up" Dialog einen anderen Rahmen als das Hauptfenster, und die Optionen sind interaktiv, wie man sieht. Die Tastatursteuerung wird also vom Dialog-Fenster übernommen; man bewegt währenddessen nicht versehentlich die Spielfigur weiter. Dafür musste ich nix besonderes machen, das folgte einfach so glücklicher Weise aus der Tastaturbehandlung.

      Nachteil: keine parallele Verarbeitung möglich. Zumindest nicht im Moment, denn jedes Fenster übernimmt in der Tastaturabfrage die game loop. Weil alles auf Text basiert, muss ich nicht darauf achten, dass ich regelmäßig den Bildschirminhalt neu zeichne, sodass es in der Praxis gar kein Problem ist, wenn jedes Fenster gierig die Kontrolle übernimmt. Für Multiplayer taugt das freilich nicht, wo die Computer regelmäßig Daten aneinander verschicken müssten :)
    • Stand 2018-08-30

      Um das Fenster variabel groß zu machen und die Karte bei fixer Größe zu halten, habe ich eine Differenz zwischen "map" und "viewport" eingezogen. Man kann jetzt eine beliebig große Ansicht auf eine map erzeugen. Wenn man die Ränder der Ansicht erreicht, wird gescrollt.




      Ich habe auch eingebaut, dass die viewports sich auf dem Bildschirm verschieben, wenn man die Größe vom Terminal-Fenster verändert, damit immer der gesamte viewport sichtbar ist. Auf der Basis kann ich gut aufbauen, um Übergänge zwischen Karten zu gestalten, z.B. um Häuser zu betreten.

      Wenn man auf einen Gegenstand läuft, dann wird die Spielfigur jetzt auch zuerst bewegt und dann der Abfragedialog gestartet. Vorher wurde die Bewegung blockiert, sodass alles, was man nicht mitgenommen hat, zu einem unüberwindbaren Hindernis wurde :)

      Würde gerne Emoji einbauen, aber die werden leider mit 2 Zeichen Breite gezeigt. Das ist mir zu nervig. Stattdessen führe ich lieber Farben ein, sobald interessantere Sachen zum Zeichnen zur Verfügung stehen.
    • Ich finds bei solchen Spielen eh schöner, wenn nur das ganz "normale" Zeichenset genutzt wird. Da wirkt der Abstraktionsgrad einheitlicher/harmonischer.

      Beinhaltet cross-platform in diesem Fall eigentlich auch eine Möglichkeit, es im Browser zu spielen? Ich komme drauf, weil ich etwas Ähnliches mal in Javascript (nach Tutorial allerdings) gebastelt hatte. Da war das möglich - aber ich habe von Ruby keine Ahnung (bzw noch weniger).
      nobody.
    • @aeyol: Ich kenne interaktive Tutorials, die Ruby Code ausführen. In diesem Fall geht es aber nicht nur im STDIN/STDOUT Textverarbeitung, sondern um ein Terminal-Fenster, das "grafisch" benutzt wird. Da hab ich auch noch keinen Plan. Theoretisch müsste es in jeder Umgebung laufen können, die auch die Ausführung von Terminal-Apps wie vim oder emacs in einem Browser-Fenster zulässt. Es gibt JavaScript Tools die aus ausführbaren Dateien JS & HTML machen, das man dann im Browser laufen lassen kann. Irgendwie. Vielleicht wäre das ein möglicher Pfad.
    • Stand 2018-09-03

      Am Wochenende war reichlich Zeit im Zug, um ein paar Sachen auszuprobieren. Jetzt sind Übergänge zwischen verschiedenen Karten möglich, und Karten liegen als Dateien außerhalb des Codes vor. (Vorher waren die Positionen von den 2 Items und dem Spieler testweise fest eingebunden.)

      Um Karten zu laden und die Türen ins Haus hinein und aus dem Haus heraus interaktiv zu machen, werden Skripte geladen und ausgeführt. Hier zahlt sich aus, dass ich das Projekt in Ruby schreibe, denn in Ruby ist es irrwitzig einfach, eine externe Textdatei auszulesen und den Inhalt als Ruby Code auszuführen. Auf diese Weise kann man mit einfachsten Mitteln eigene Skript-Sprachen umsetze, ohne all das, was Skript-Sprachen schwer macht, einbauen zu müssen (nämlich Tokenizer, Parser und Interpreter). open_map "house.map.rb" und leave_map sind die einzigen Befehle, die bisher gehen.





      Als nächstes sollte man mit der Person im Haus auch reden können :) Und ich habe schon eine Idee, um ein einfaches Puzzel einzubauen.
    • Aaaah ich hätte auch gern Zeit und Energie, mein Projekt voranzutreiben. :D
      Cool, dass man auf Github auch ein bisschen spicken kann, wie der Quellcode zur Map aussieht.

      Hast du eigentlich vor, die Engine auch noch deutsch zu lokalisieren? (als Option)
      Nicht, dass Englisch ein Problem wäre - es interessiert mich bloß.
      nobody.
    • @aeyol Natürlich hab ich aus meinen Überlegungen dazu absolut keine Konsequenzen gezogen und schreibe weiterhin allen "user-facing content" in den Quellcode, aber an Lokalisierung hab ich gedacht ... :) Im Moment ist mir das natürlich zu viel Aufwand, statt "END" im Code irgendein LocalizedString("END") oder so zu schreiben, und am Ende werde ich mich ärgern, aber das ist der Preis, den man für Blödheit zu zahlen bereit sein muss.

      Stand 2018-09-07

      War krank diese Woche und habe an dem Tag ein ganzes kleines Szenario entworfen, um eine erste "Quest" umzusetzen.

      weltenbastler.net/BB4/upload/i…14560cc0a3d1252173e9e8ccb
      Habe das Inventar so weit überarbeitet, dass es ein eigenes Fenster hat, und nicht bloß ein 0815 Textdialog ist.



      Dialoge haben ein eigenes Interface. Dialogzeilen tauchen Zeile für Zeile auf und lange Dialoge "scrollen" sogar (d.h. alles rutscht ne Zeile nach oben und nur die letzten 3 werden angezeigt).



      Die Stadtkarte ist jetzt auch ein bisschen umfänglicher, mit 3 locations, die man besuchen kann,



      Die Startlocation ("zu Hause") mit hungrigen Freunden und einem Waffenständer in der Ecke.

      Karten können Zustände speichern ("flags"), sodass man geöffnete/geschlossene Türen in den Kartendaten unterschiedlich behandeln kann. Oder man zeigt andere Dialoge, z.B. nachdem der Held einen Gegenstand bekommen hat, damit er nicht unendlich viele davon bekommt.

      Es gibt ein paar special effects und aufregende Animationen.

      Eine optische veraltete Zwischenversion des Abenteuers (ohne Dialogboxen oder das neue Interface) gibt es als zweiminütige GIF (Achtung, Spoiler!): weltenbastler.net/BB4/upload/index.php/Attachment/5794/

      (Edit 2018-09-09: Bilder gefixt)
      Bilder
      • 2018-09-04 TermQuickRPG girlfriend scenario.gif

        869,96 kB, 1.052×732, 8 mal angesehen

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ctietze ()

    • Stand 2018-09-13

      Das Inventar und alle Dialogboxen sind jetzt "echte" Fenster die alle von einer zentralen Stelle aus verwaltet und gezeichnet werden, sodass keine Fehler beim Zeichnen mehr kommen, wenn man eine Dialogbox schließt und direkt danach eine Unterhaltung am unteren Bildschirmrand aufpoppt. Animationen in Skripten sind dadurch jetzt auch zuverlässiger.


      Inventar


      Außerdem hab ich die Interaktion mit der Umwelt überarbeitet: wenn man "E" drückt (oder Leertaste oder Enter), dann kommt eine kleine Box um den Spieler herum, in der man das Ziel der Interaktion auswählen kann, das durch ein X markiert ist. Damit kompensiere ich, dass man im Terminal keine Blickrichtung sieht: wenn man den Aktionsknopf drückt, weiß man sonst nicht, wohin man interagiert, was zwischen zwei NPCs oder mehreren Items schwierig werden würde.


      Zielvorrichtung

      Diese Zielvorrichtung will ich auch einsetzen, wenn es mal Kämpfe gibt. Theoretisch kann man einen Radius >1 einstellen, um zum Beispiel mit Fernkampfwaffen zu arbeiten, oder mit Ketten, oder langen Speeren, oder sonstwas mit irgendeiner Reichweite.


      Hier eine Animation mit den aktuellen Änderungen:

    • Hm, das mit der Interaktionsbox habe ich noch nie irgendwo gesehen. War das so eine spontane Lösungsidee oder gibt es da Referenzen?

      Ich würde sowas wohl umgehen, indem ich das Level entsprechend gestalte und Items und NPCs nicht zu dicht nebeneinander platziere. Aber vielleicht würde das auch unnötig einschränken.
      Bei einer Auswahl "Waffenständer" bietet sich natürlich an, dass man irgendeine Möglichkeit gibt, zu selektieren. Da fällt mir ein - aus neueren Spielen kenn ich das natürlich dann schon, dass sich dann ein Lootfenster öffnet mit Icons oder Text(Liste), wo ich auswählen kann, was ich mitnehmen möchte. Ich denke ich würde da eher letzteres präferieren - also ein Fenster mit einer Liste der Itemnamen (was zugleich auch das Problem löst, dass man anhand der Icons nicht so gut erkennt, was man da sammelt bzw womit man interagiert).
      Und vielleicht auch ein Texttitel für dieses kleine Fensterchen, was sich da öffnet? Also zB "Rede mit:" oder "Nimm:" ;)

      Oder vielleicht auch eine Abfrage, dass dieses Interaktionsfenster nur erscheint, wenn sich mehr als 1 Interaktionsobjekt direkt am Charakter befindet? (oben, links, unten, rechts)

      Oder bei auf dem Boden herumliegenden Items die Möglichkeit, das selbe Feld zu betreten und dann direkt mit dem zu interagieren wo man draufsteht.
      Bei NPCs bietet sich das wiederum leider auch nicht an. :D

      Bloß ein paar spontane Gedanken dazu.
      nobody.

      Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von aeyol ()

    • Auf Items zu stehen und sie direkt aufzuheben war ganz gut. Bei NPCs hatte ich dann manuell in den Karten die Stellen markiert, von denen aus man mit ihnen reden konnte, weil man gerade _nicht_ auf sie drauflaufen soll :) Bei Spielen wie Dwarf Fortress ist das allerdings so gedacht, da sind Räume und Gänge aber auch in einem kleineren Maßstab gestaltet. Bei Nethack und anderen Roguelikes von damals auch. Bei mir ist das ja alles ziemlich verschwenderisch und high fidelety im Vergleich :)

      Ich werd die Interaktionsbox noch mal in Angriff nehmen, wenn das Kampfsystem steht und ich geschafft habe, dass man das Spiel auch auf Linux und Windows richtig spielen kann. Dann kann ich mir Feedback von Testern für verschiedene Interaktionssysteme holen.

      Die cross-platform Spielbarkeit gestaltet sich jedoch überraschend schwierig, weil die ganzen Sonderzeichen auf Linux z.B. mit doppelter Zeichenbreite angezeigt werden.