Die Programmiersprache Ruby

Blog| Forum| Wiki  

Inhaltsverzeichnis

Projektseite

Allgemein

Der Open Ruby RPG Maker (der Name steht noch nicht fest ;-)) soll eine OpenSource Variante des bekannten RPG Makers sein und kostenlos für private, wie kommerzielle Zwecke zur Verfügung stehen. Angedacht ist eine (fast) reines Ruby Projekt (mit ggf C-Libs zur Performance-Steigerung). Geplant ist das Projekt(+Wiki) auf GitHub zu portieren.

Da wir nun bei den Engine's schon einige Vorschläge bekommen haben möchte ich darum bitten deren Vor- und Nachteile auszubauen und dass sich jeder mal bei seinem Favoriten als Befürworter einträgt, um am Ende zu schauen wie der allgemeine Tenor tendiert ;-).

"Ich habe mal begonnen und mich nach aktuellem Wissens-Stand für Gosu entschieden" by Kjar

Kernprojekt

Sprache und Libs

Fest steht, dass Ruby 1.9 verwendet werden soll. Für die Grafik wurden folgende Libs vorgeschlagen:

  • Rubygame (SDL) + openGL, eventuell nicht leicht zusammen nutzbar
  • Java + OpenGL, JRuby nicht komplett 1.9-fähig
  • Ruby-SFML
  • Gosu, hat unter Windows eine einschränkende Lizenz (was aber eventuell geändert werden kann)
  • Clanlib, besitzt keine Ruby-Bindings (stimmt das? Bitte korrigieren, wenn falsch!)

Einigung erfolgte auf Gosu.

Scripte

Der Scripteditor im RMK wurde stark bemängelt gerade hinsichtlich seiner Flexibilität und seiner Bedienfreundlichkeit. (Wer den Maker nicht kennt: Scripte werden da durch eine GUI zusammengeklickt, was nahezu keine Programmierkenntnisse erfordert) Es konnte sich noch nicht so recht für ein ScriptModell entschieden werden. (Es wurde auch die Option genannt, einen Expertenmodus einzuführen, der es den Profis ermöglicht normal zu Programmieren, wohingegen die Laien, eine einfachere Variante erhalten)

interne DSL

Eine Domain Specific Language (siehe auch in den Links) ist eine selbst definierte Sprache für eine spezielle Umgebung, in unserem Fall, das Scripten im Maker. Ruby kann per eval (und "Varianten") Code ausführen der in den Scripten hinterlegt ist. Dadurch hat steht dem User die volle Palette an Ruby zur Verfügung (abzüglich dem, was wir ihm wegnehmen damit er keinen Blödsinn macht). Dadurch sind kürzere flexiblere und komplexere Scripte möglich. Dem Profi steht die Option normal Ruby zu programmieren. Der Anfänger braucht "nur" die DSL erlernen und kann damit auch arbeiten.

Kommentare:

  • Es wurden ein paar Zweifel an einer DSL geäußert, da die Erstellung einer guten DSL einiges an Planung erfordert.
  • Ein schönes Ruby-Märchen findet man hier - Rotkäppchen und dient gleich als Vorbild für unseren Ansatz "Eine DSL muss sich lesen wie eine Geschichte"

Bereiche, die die DSL abdecken muss (unvollständig):

  • Manipulation des Spielers/der Party (Attribute, Items, Fähigkeiten, Bewegen)
  • Manipulation von NPC (Bewegen)
  • Textausgabe (Dialoge und ggf Texte an beliebigen Stellen)
  • Manipulation der Umgebung (Wetter, Hintergrund, Musik)
  • Kommunikation mit der Engine (Variablen setzen/lesen, andere Events triggern)

Befürworter:

  • Kjarrigan Da Quintus und ich für eine DSL sind und imo nicht mehr daran mit diskutieren wird das so gemacht :-D

endliche Automaten

Kann mal jmd noch ne schöne Beschreibung des Begriffs suchen.

Kommentare:

  • Endliche Automaten sind schick, da gibts wenig zu zu sagen
  • Verstehe mich nicht falsch, nichts gegen endliche Automaten, aber ich habe bislang nur ein Negativbeispiel da.
  • Etwas ausführlicher zu endlichen Automaten: Die Dinger sind gut, aber wie Quintus geschrieben hat, können sie zu einer ziemlichen Zustandsexplosion führen, wenn man viele mögliche Übergänge hat. Für einen Aktor ist das meistens nicht besonders haarig (Beispiel Tür: offen, zu, blockiert... easy), bei mehreren ist das relativ schlimm.

Petri-Netze

Kenn ich nicht, also mal recherchieren und hier verlinken und ne Kurzbeschreibung einführen

Kommentare:

  • Wenn ihr eine robuste Abstraktion für die Interaktion mehrerer Aktoren mit Bedingungen unter Beachtung der Zeit haben wollt, sind übrigens Petri-Netze sehr cool. Ohne Rückreferenzen können die sogar sehr gut automatisch auf Fehler und Unmöglichkeiten gecheckt werden.[1] Darüber hinaus bieten sie meiner Meinung nach die beste Visualisierung von Algorithmenabläufen, die für Nicht-Informatiker noch verständlich ist, solange man die ganzen Erweiterungen weg lässt.

Dateisystem/Projektverzeichnis

  • bin Executable des Makers
  • doc Dokumentation des Makers
  • game Ein "Blanko"-Spiel, quasi ohne Inhalt, nur Gerüst
    • bin Executable des Spiels
    • doc Dokumentation des Spiels - wenn denn der Ersteller sich dahingehend bemüht...
    • data Spieldaten
      • audio Sounds, Musik...
        • music Hintergrundmusik
        • sounds Sounds
      • graphics Graphikdateien
        • character Charakter-Graphiken (und andere Objekte für die Map, z.B. Kisten)
        • map Map-Graphiken: Boden, Wasser, Bäume...
        • ... usw
    • ext C-Extensions - oder auch Java, wir werden sehen...
    • lib Code für das Spiel
    • maps Vom Spieler erstellte Karten - wie auch immer wir sie abspeichern werden...
    • saves Spielstände
  • lib Code für den Maker

Ideensammlung

Neben den Ideen die hier von Mitgliedern des Ruby-Forum festgehalten werden, sollte man sich vllt auch mal die Mühe machen die einschlägigen RPGMaker Fanseiten zu durchforsten und deren Wünsche erfragen und ihr "Normalverhalten" zu erforschen (zBsp: was wird am liebsten und häufigsten benutzt)

Übernehmen aus dem RMK

  • Ich persönlich fand das Szenen-basierte Modell des RPGXP nicht schlecht und hätte etwas in diese Richtung geschrieben, aber ich höre mir auch gern ganz andere Vorschläge an. Die Graphiken hatte ich vor als Einzel-PNG-Bilder in gezippten oder ge7zipten Dateien unterzubringen, über Audio-Dateien habe ich mir bislang keine Gedanken gemacht. Irgendwo im Hinterkopf schwirrte auch noch eine Multiplayer-Idee herum, aber "nebenbei" noch Netzwerk-Kommunikation einzubauen wäre wohl etwas zu viel.

Serialisierung

  • Marshal ist sehr empfindlich bei Versionssprüngen
  • Verwendung von YAML
  • widerspricht dem eigentlich Sinn von YAML, nämlich für Menschen lesbare und leicht editierbare Dateien bereitzustellen, wenn man Ruby-Objekte hineinserialisiert, die ein Mensch dann wohl nicht "einfach so" editieren könnte
  • Bilder gehören sowieso nicht serialisiert

Maps & Ebenen

Gedanken die mir zum Thema Maps kamen (einige davon auch extrem unwichtig ;-)):

  • Wie groß kann eine Map maximal werden
  • Wie viele Ebenen kann der User "übereinander" malen (der RM2k hatte Untergrund(Wiese,etc)-Deko(Häuser,Bäume,...)-Event)
  • Wie wird eine Map(-Instanz gespeichert)
  • Wie sieht eine Map-Instanz aus und was verwaltet die alles
  • Also ich würde eine Map als 2-dimensionales Array sehen, an der auf jeder Koordinate eine Feld-Instanz steht, die aus n-Ebenen besteht
    • eine (Grafik)Ebene ist einfach ein Struct mit einer relativen Id zur passenden Textur (und Zusatzinfos, wie begehbar?, ...)
  • Der Map ist ein Header beigefügt, der eine absolute(?) Id zum Tileset enthält. Anhand der beiden Id's kann dann das passende Bild gerendert werden
    • der Header enthält selbstverständlich auch weitere Infos wie Größe, Hintergrundbild/-musik...
  • Für die Events müsste überlegt werden, ob diese in einem 2ten Array "draufliegt" oder ob sie als Teil eines Feldes (wie würde da die Bewegung erfolgen?)
  • Eine Instanz könnte serialisert abgelegt werden und müsste dann immer nur geladen werden bei betreten
    • alternativ speichert man es in einem definierten Format ab und erstellt die Instanz dann erst wenn nötig
  • Für die Kartengröße ist denke ich mit entscheidend, ob im "Vollbildmodus" mehr Felder angezeigt werden oder immer gleich Viele und diese dann skaliert werden
  • Bei den aktuell gängigen Auflösungen würde ich schon 1000x1000 Maps erlauben ;-)

Kritiken am RMK

  • Der Maker hatte bei seinen Events einen ganz furchtbaren Editor, nach ein paar Schachtelungen sah man gar nichts mehr. Auch hat mich die ganze Klickerei für die "Code"-Blöcke genervt. Ruby eignet sich hervorragend für DSLs, es sollte leicht möglich sein, eine für Events angepasste DSL zu erlernen. Und wem die zu wenig ist, der kann dann ja direkt in "vollem" Ruby schreiben.
  • extremer Gebrauch von globalen Variablen (, die ich einfach als unschönen Code betrachte)
    • Idee anstatt $data_ Variablen wollte ich klassen methoden benutzen ... ich weis nicht ob das so besser ist
  • spieltechnische Dinge wie das auf die 32x32 Pixel-Felder begrenzte Gehen (, Feinjustierungen gingen dabei völlig verloren)
  • Eine andere von mir oft vermisste Sache war ein AKS, also ein (vernünftig geschriebenes und erweiterbares, z.B. mit der Möglichkeit das Verhalten für eigene Gegenstände einigermaßen anpassen zu können, ohne gleich das gesamte System des Makers verstehen zu müssen) Aktionskampfsystem á la Zelda auf der Map

Links