Backstage #3: Versionieren selbstgeschriebener Texte
Ich hatte bereits angemerkt, dass mir das Versionieren und die Nachvollziehbarkeit aller Änderungen beim Schreiben meiner Dokumente sehr wichtig sind. In diesem Backstage-Artikel, der wieder beim RSP-Karneval Selbstgeschriebene Rollenspiele mit macht, möchte ich meinen Ansatz dazu vorstellen.
Verwendung findet dazu bei mir das Tool Subversion (kurz SVN), das starke Verbreitung in der Softwareentwicklung genießt, wo es primär zur Verwaltung von Source Code dient. Ich möchte hier nicht darauf eingehen, warum ich gerade SVN und nicht Alternativen wie CVS oder Git verwende, so gut wie alles hier gesagte geht mit anderen Systemen auch. Mir geht es darum zu unterstreichen, dass ein Versionierungstool auch für Autoren sehr hilfreich sein kann.
Wie funktioniert das also grob:
- Man legt einmalig ein s.g. SVN-Repository an. Das ist nichts anderes als ein Verzeichnis, in dem sich SVN austoben kann, und in dem es alles merkt, was es zum Versionieren von Dateien benötigt. Da drinnen wird man niemals direkt was ändern können oder wollen. SVN macht diese Versionen halbwegs intelligent, und kopiert nicht einfach alles zig-fach, sondern erstellt Delta-Dateien, aus denen es bei Bedarf die einzelnen Versionen rekonstruieren kann.
- Mit dem SVN-Programm macht man dann ein “checkout”, um eine (meist die aktuelle) Version in ein Arbeitsverzeichnis zu übernehmen, editiert das dort nach Lust und Laune, und wenn man fertig ist, macht man mit dem SVN-Programm wieder ein “commit”, und alle Änderungen im Arbeitsverzeichnis werden zurück in das Repository übernommen.
- SVN selbst ist ein unsichtbares Kommandozeilenwerkzeug, das man selten direkt nutzt, sondern über das Tool seiner Wahl oder die Integration im Lieblingseditor nutzt. Wie bequem und übersichtlich das ist, hängt daher davon ab, wie gut das Tool/der Editor ist, nicht wie gut SVN ist. Mein Editor (Eclipse – stelle ich getrennt noch mal vor), ist für Programmierer gedacht die Source Code bearbeiten, und entsprechen tiefgehend ist dort die Integration der SVN-Funktionen. (Unter Windows gibt es z.B. aber auch ein Plugin für den Explorer, wo man versionierte Ordner wie ganz normale Ordner auch per Rechtsklick-Menüs bearbeiten kann.)
- Um zu Versionieren muss ich nicht viel tun, bloß 1x am Tag nach getaner Arbeit einen Commit-Button zu drücken, und darf für diese Tagesversion (“Sub-Version”), sogar noch einen Kommentar erfassen, damit ich nach einer Woche noch grob weiß, was die Montag-Änderung und was die Dienstag-Änderung war. Natürlich steht es mir frei, in längeren oder kürzeren Intervallen so eine Unterversion zu “commiten”, ich gehe für diesen Artikel mal von Tagesversionen aus. Jede dieser Tagesversionen bekommt automatisch eine eigene (fortlaufende) Nummer, und kann optional auch mit einem Namen versehen werden. Ich habe also viel mehr Tagesversionen, als ich z.B. ROBiN PDFs publiziere. Zwischen einer v0.3 und einer v0.4 könnten dann z.B. 42 Tagesversionen liegen.
Welche allgemeinen Vorteile habe ich nun, wenn ich Subversion benutze:
- Das Offensichtliche zuerst: SVN protokolliert im Hintergrund was ich schreibe in diesen Tagesversionen. Jedes neue Komma wird registriert, jede Leerzeile die ich wieder lösche, alle Änderungen am Layout (weil die in LaTeX ja in Textform passieren und nicht in Dialogfeldern).
- Mit diesen Tagesversionen kann man nun allerhand anstellen. Ich kann nachsehen, wie sich mein heutiger Stand vom dem von gestern unterscheidet. Ich kann genauso einfach nachsehen, wie sich mein heutiger Stand von dem vor zwei Monaten und drei Tagen unterscheidet, oder ich kann das SVN fragen, was eigentlich ROBiN v0.3 von v0.4 über diese 42 Tagesversionen unterschieden hat, obwohl ich gerade an v0.6 werke. In meinem Editor wird das auch hübsch dargestellt, mit den zwei Versionen nebeneinander und farblich markierten Änderungen in den zwei Dateien. Sehr praktisch, wenn man in einem LaTeX-Makro, das “eben noch funktioniert hat”, die fehlende Klammer sucht, die man unabsichtlich gelöscht hat.
- Ich kann die Änderungen nicht nur anzeigen lassen, sondern in der Zeit hin- und herspringen. SVN stellt mir auf Wunsch den Tagesstand vom 23.05.2010 wieder her, dann den vom Jahr davor, und dann wieder den aktuellen. Das kann ich auf Datei-, Ordner- oder Gesamtebene machen. Damit kann ich z.B. ein altes PDF nochmal generieren, und muss mir nicht alle PDFs aufheben.
- SVN versioniert über alle Ordner im Arbeitsverzeichnis hinweg und merkt sich, welche Dateien für so ein einzelnes Tageswerk zusammen gehören. Damit sehe und vergleiche ich Änderungen an allen Dateien der jeweiligen Version, was bei LaTeX sehr praktisch ist, wenn man aus Bequemlichkeit nicht in einem riesigen .tex-File arbeiten möchte. SVN merkt sich, wann welche Dateien dazu gekommen sind, und sogar wann Dateien oder Ordner gelöscht oder umbenannt wurden. Springe ich in der Zeit zurück, stellt es alle Dateien und Ordner wieder her, die es zu diesem Zeitpunkt noch gegeben hat.
- SVN ist mir unmittelbar nicht im Weg. Ich habe meinen normalen Ordner (das Arbeitsverzeichnis) auf der Platte, in dem sich meine LaTeX-Dateien befinden, und die ich mit dem Editor meiner Wahl ganz normal bearbeite. Mit dem SVN interagiere ich nur, wenn ich commite oder in den Versionen springe. SVN zwingt mir auch kein bestimmtes Tool auf.
Welche besonderen Vorteile habe ich, wenn ich SVN für LaTeX bzw. für Rollenspiele benutze:
- Die Verfolgung von Änderungen über alle Dokumente ist extrem hilfreich, wenn man Regeln ändert. Ich sehe nämlich, was ich am Tag, an dem ich damals eine Regel erfunden habe, noch alles geändert habe, z.B. sich auf die Regel beziehende Beispiele später im Text, oder darauf aufbauende Sonder-/Ausnahmeregeln. Die möchte ich dann ja ggf. auch mit ändern. (Wenn man klug ist, macht man ein commit nicht am Ende des Tages, sondern am Ende jeder zusammengehörigen Änderung, u.U. halt mehrfach pro Tag – dann fällt das Nachvollziehen noch leichter. SVN wird nicht langsamer, nur weil viele Versionen da sind. Ich habe beim Programmieren schon mit langjährigen Mega-Repositores gearbeitet mit Commits/Versionsnummern im 6-stelligen Bereich.)
- Ich brauche mir keine Sorgen zu machen, Texte oder Layoutelemente zu löschen. Wenn etwas gerade unwichtig ist – raus damit. Sollte ich das nochmal benötigen, kann ich im SVN den gelöschten Text wieder finden, und muss nicht in einem Notizfile das für den Fall des Falles aufheben.
- Im LaTeX-Umfeld ein praktischer Nebeneffekt: das Layout ist ja auch in Text definiert, also sehe ich genauso einfach wie ich Fließtext- und Regeländerungen verfolgen kann auch, wann ich welche Layoutänderungen wo gemacht hab, seit wann z.B. die Tabelle blau ist oder die Hervorhebungen fett statt kursiv. Oder welche Texte ich gekürzt habe, damit sie sich nach einem Layoutwechsel wieder auf eine Seite passen.
- Ich kann von unterschiedlichen PCs aus arbeiten. Gehe ich auf Reisen, mache ich das check-out eben auf den Notebook. Komme ich wieder zurück, commite ich vom Notebook in das SVN, und hole die Änderungen – mit der selben Protokollqualität wie sonst auch – auf den Stand-PC.
Dann gäbe es noch Vorteile, die ich gar nicht nutze, die aber für Autoren interessant sein könnten:
- SVN ist ja eigentlich für Teams gedacht, die gemeinsam an Projekten (Source-Code) arbeiten. Ich arbeite nur am Stand-PC ODER am Notebook, aber natürlich könnte ein Autorenteam, das gemeinsam an einem Setting arbeitet, gleichzeitig arbeiten und ihre Änderungen in ein gemeinsames SVN commiten. Das SVN kümmert sich dann darum, das alles in einen Stand zusammenzuführen, und nur wenn zwei Personen zeitgleich am selben Absatz gearbeitet haben, ist ein manuelles Abgleichen nötig. Und auch dann hilft SVN mit, indem es die fraglichen Passagen im Text mit Klammern markiert, damit man leicht weiß, zwischen welchen Sätzen man sich entscheiden muss.
- Es ist möglich, an zwei Versionen von einem Dokument getrennt weiter zu arbeiten, ohne dass die sich stören. Beispiel TRiAS: Sagen wir mal, ich bin mit v1.0 fertig. Dann kann ich so einen s.g. “Branch” auslösen, und habe nun zwei Versionsstränge im System: v1.0 und sagen wir mal “aktuell”. Zwischen denen kann ich nun hin und her schalten. Am v1.0-Strang mache ich Änderungen, wenn Errata auftauchen und ich ein v1.0.1 benötige. Am “aktuell” Strang beginne ich das Regelwerk komplett umzubauen, weil in einer v2.0 ja alles neu und besser werden soll. Jeder Strang hat nun eine eigene Historie, und ich kann innerhalb derer vor und zurück springen.
- SVN ist so weit verbreitet, da kann man bei vielen Anbietern im Internet hosten lassen, meist kostenlos wenn man an freien Projekten arbeitet, und für wenig Geld für abgesicherte Accounts. Man kann also auf das Repository daheim verzichten, wenn man die Administration scheut.
Zwei Nachteile möchte ich aber nicht unerwähnt lassen:
- SVN kann nur bedingt in Binärdateien wie z.B. Bilder hineinsehen. Es versioniert die zwar genauso wie alle anderen Dateien, tut das aber, indem es jedes mal eine neue Kopie davon macht wenn sich was ändert. D.h. wenn man ein Bild oft ändert, entsprechend viel Plattenplatz verbraucht wird.
- Wenn man ein SVN-Repository auf der eigenen Platte führt, belegt ein Projekt natürlich dann doppelt Platz: einmal das Arbeitsverzeichnis, in dem das LaTeX Projekt liegt, und dann noch einmal im SVN-Repository, dem Verzeichnisbaum, in dem sich das SVN seine internen Notizen ablegt, um alle Versionen wiederherstellen zu lassen. Mit heutigen Platten ist das aber zu vernachlässigen. Mein LaTeX-Arbeitsverzeichnis hat ca. 50MB an Daten, das Repository ist nach etwa 1,5 Jahren nun auf 300MB gewachsen – und geschätzte 90% davon wegen der Bilder.
Der Artikel kratzt natürlich nur an der Oberfläche, aber vieleicht hat er Lust gemacht, sich SVN mal näher anzusehen oder bei einem der kostenlosen SVN-Hostern mal ein Test-Repository anzulegen und ein kleines Dokument dort testweise abzulegen. So findet man IMHO am einfachsten heraus, ob diese Art der Versionierung einem bei eigenen Rollenspielprojekten weiter hilft.
Backstage #2: Warum (nicht) LaTeX?
Ich layoutiere und setze meine Rollenspielprojekte in LaTeX, einer Software, deren Wurzeln in den 1980ern liegt. Ähnlich dem P&P-Rollenspiel hat man LaTeX schon oft den Untergang prophezeit, geben tut’s das Ding aber immer noch. LaTeX wird vor allem auf Universitäten benutzt, weil es besonders stark im Umgang mit Formeln und anderen Besonderheiten wissenschaftlicher Dokumente ist. Ins Detail möchte ich dazu gar nicht gehen, auf der Wikipedia ist das ganz gut beschrieben. Für diesen Artikel wichtig zu wissen ist vor allem:
- LaTeX-Dokumente sind Textdateien, die man in einfachen Text-Editoren bearbeiten kann. Es gibt dazu zwar auch Editoren a la Word und OpenOffice, mit denen man Fett/Kursiv/etc. “erklicken” kann, aber die verwende ich nicht. LaTeX selbst ist kein Editor.
- Damit LaTeX weiß, was eine Überschrift ist, was Fett gehört usw., muss man um die betreffenden Wörter/Sätze im Text mit bestimmten Kommandos/Metabefehlen versehen, etwa so, wie man in HTML-Seiten das tut, nur mit einer anderen Syntax. Auf der genannten Wikipedia-Seite gibt es ein Beispieldokument zu sehen.
- In einem zweiten Schritt werden die Zieldokumente, z.B. ein PDF, aus diesen Text-Dateien mit dem LaTeX-Programm generiert (sowas dauert 2-3 Sekunden für ein 80-seitiges PDF wie das von ROBiN). Erst in diesem Schritt wird das Layout, Farben, Schriften, usw. auf den Text angewandt. Auch hier die grobe Analogie zu HTML: Gemeinsam mit einem CSS (Stylesheet) wird daraus das, was man im Browser sieht.
Daraus ergeben sich für Leute, die so etwas wie Word oder aber auch echte DTP-Software wie Scribus, QuarkXPress oder Indesign gewohnt sind, folgende Nachteile:
- Man sieht während dem Textschreiben nicht sofort, wie es am Ende aussehen wird. Nimmt man Änderungen am Layout vor, muss man das Zieldokument neu generieren.
- Alles, was nicht Text ist, ist umständlicher zu handhaben. Bilder z.B. werden nicht per Drag&Drop direkt im Text eingebunden – weil das in einer normalen Textdatei gar nicht geht – sondern man muss im Text Kommandos a la “Bitte später hier Bild.jpg hin, 5cm breit, 8cm hoch”.
- Layouts macht man ohne Maus, in dem man die Standard-Kommandos von LaTeX umdefiniert bzw. denen, die das können, mit Konfigurationskommandos sagt, wie sie sich verhalten sollen. Das fühlt sich teilweise nach Programmieren an.
- Man kann mit LaTeX nicht sofort loslegen, ohne sich gründlich einzuarbeiten.
Warum sollte man also 2012 noch mit so einem rückständigen Tool arbeiten wollen, das nicht mal ohne Hilfsmittel WYSIWYG kann? Für mich sind das:
- Die Qualität des entstehenden Text-Satzes ist für mich ungeschlagen. Zeichen/Wort/Satzabstände sind homogen und ästhetisch. Mittels Gewichtung kann man die noch bis ins Details selbst beeinflussen, z.B. wieviel Silbentrennung gemacht werden darf und wieviel Leerraum zwischen Worten oder Zeichen noch OK ist.
- Während man den Text schreibt, ist man nicht durch Layoutspielereien abgelenkt: Da wird nicht am Paragraphen mit der Maus gezupft. Da macht man keine Leerzeilen dazu oder weg. Da ärgert man sich nicht, dass in einer Aufzählung die Bullets auf einmal anders aussehen als noch im Paragraph davor, usw. Trotzdem verankert man beim Schreiben bereits die Layout-Information in Form der Kommandos im Text (Überschrift, Fett, …). In klassischer DTP-Software ist man sonst gezwungen, nur mehr im Layoutprogramm die Texte zu bearbeiten (und dann vermisst man Funktionen einer Textverarbeitung), oder man macht das in der Textverarbeitung und hat dann wieder einen Migrationsschritt in das DTP-Tool.
- Man kann aus einem LaTeX-Dokument verschiedene Zieldokumente generieren lassen, in meinem Fall z.B. eine Druckversion mit höherer Auflösung aber tintesparenden Bildern, und eine superbunte E-Book Version. Dazu muss man am LaTeX-Dokument nix ändern, sondern nur (einmalig) einen zweiten Layout-Stil definieren. Genauso gut könnte man einspaltiges A5 und zweispaltiges A4 Buch aus einer Quelldatei machen lassen. Zur Zeit experimentiere ich gerade damit, auch ePub Dokumente rauszuspielen.
- LaTeX macht nur, was man ausdrücklich per Kommandos verlangt. Es versucht nicht, klüger als der Anwender zu sein und automatisch Dinge zu formatieren.
- LaTeX-Dateien sind Text-Dateien. Damit kann man jegliche Tools benutzen, die auf Text-Dateien operieren können. Man verwendet dann jenen Editor, der einem am liebsten ist. Man kann auch z.B. Versionsverwaltungstools wie Subversion drüber laufen lassen, mit dem man Texte Vergleichen kann und Änderungen leicht sieht. Man kann externe und ggf. bessere Wörterbücher/Rechtschreibkorrekturen drüber laufen lassen. Man kann die Texte leicht in mehrere Dateien zerlegen (z.B. nach Kapitel) und sie per Import/Include Kommando zusammenführen. Usw.
- Die Layout-Kommandos stehen alle in der Textdatei. Man kann sie genauso einfach suchen & ersetzen oder kopieren & einfügen, wie Wörter im Fließtext.
- Inhaltsverzeichnis, Index, Glossar, Querverweise, Fußnoten, Zitate/Literaturangaben usw. funktionieren einfach. Beispiel Index: Man setzt um ein Wort einfach das Bitte-auch-in-den-Index Kommando, und das war’s. Bei jedem Generieren vom PDF wird nun die Seitenzahl korrekt neu generiert. Verschiebt man im Text jemals den Paragraph, muss man nix weiter bedenken – LaTeX generiert den Index sowieso jedesmal neu. Und das Wort fällt auch nicht unabsichtlich wieder aus dem Index raus – dazu müsste man schon absichtlich das Index-Kommando im Fließtext wieder wegnehmen. Und es versteht sich von selbst, dass das Index-Kommando alle Stückerln spielt, die man von wissenschaftlichen Büchern kennt. “X -> siehe A”, Gruppierungen gleicher Begriffe/Subbegriffe, mehrere Seiten pro Begriff und die wichtigste Seite davon fett, usw. Und da das Index-Kommando ja einfach so im Textfile steht, kann man mit der Suchen-Funktion des Editors bequem von einem Index-Kommando zum nächsten springen.
LaTeX hat aber auch Schattenseiten. Abschrecken kann vor allem:
- Die Lernkurve. Es gibt viel Dokumentation, aber die muss man eben lesenoder sich erarbeiten, wenn der Standard-Look nicht gut genug ist. Und sind wir uns mal ehrlich, wer liest gerne Rollenspiele, die wie eine Diplomarbeit aussehen.
- Verwendung eigener Schriften. Die müssen erst mühsam konvertiert werden, weil LaTeX eigene Metadateien benötigt, und nicht direkt mit Truetype, Postscript oder Opentype arbeiten kann.
- Vom Text umflossene Grafiken, die nicht rechteckig sind.
- Druck & CMYK. Wer in eine Druckerei gehen möchte, muss sich irgendwann mit dem Thema Farbkonvertierung befassen. LaTeX trägt da nichts dazu bei. Wenn man entsprechend vorsorgt, kann man auch mit LaTeX drucktaugliche PDFs machen, aber man muss selber drauf achten, nicht unabsichtlich doch irgendwo ein RGB-Bild o.ä. einzubetten. Oder man bemüht ein weiteres Tool, das aus dem LaTeX-PDF ein Druck-PDF macht.
Warum verwende ich also LaTeX für meine Rollenspiele? Neben dem Argument der Gewohnheit mag ich besonders:
- LaTeX ist keine eierlegende Wollmilchsau, sondern tut das, wofür es da ist, und das gut. Für alles Andere lässt es mir die Wahl, z.B. welchen Editor ich verwenden möchte.
- Index, Inhaltsverzeichnis, Querverweise: die halte ich in einem Rollenspielregelwerk für sehr wichtig, und da ist LaTeX einfach stark.
- 10 Seiten, 100 Seiten, 1000 Seiten – LaTeX geht da nicht die Luft aus und bleibt verlässlich.
- Ich sehe meine Texte beim Schreiben zwei mal: einmal als langweilige Textdatei, einmal im generierten Layout. Es ist ja schon schwer genug, selbst seine Tippfehler zu finden, da hilft es, den Text zwangsweise auf unterschiedliche Arten zu sehen und man findet Fehler eher.
- Da man Layouts eher “konfiguriert” als “gestaltet” fällt es mir leichter, Elemente aus einem Layout in ein anderes zu übernehmen, z.B. Monsterblöcke.
- In der Textdatei sieht man immer die ganze Wahrheit, es gibt keine unsichtbaren Marker oder Elemente, über deren Einfluss auf das Aussehen man sich später wundert.
Vielleicht noch ein Beispiel, was mit LaTeX möglich ist: das TRiAS Regelwerk und die Verwendung davon in ROBiN. TRiAS hat (semi)generische Regeln, die ROBiN verwendet. Die Regeltexte sind also gleich. Daher inkludiert der ROBiN-Band die Kapitel/Dateien von TRiAS und ersetzt (überschreibt) nur die Beispiele, damit die im Sherwood-Forest Fluff sind, und nicht im allgemein gehaltenen TRiAS-Fluff. Ändere ich etwas am Regelwerk, geht die Änderung automatisch in beide Dokumente. LaTeX macht dann einmal ein braunes TRiAS-PDF und ein grünes ROBiN-PDF.
Obwohl LaTeX sehr mächtig und flexibel ist, unterm Strich würde ich es aber trotzdem nicht für My-First-Rollenspiel Projekte empfehlen, weil damit keine schnellen Resultate zu erzielen sind, die gut aussehen. Beim Rollenspiel isst nun mal das Auge mit. Wer aber an mehr als einem Werk/Projekt arbeitet, oder sehr umfangreiche Heartbreaker schreibt, für den könnte sich der Aufwand aber auszahlen.
Ich sehe schon, der Artikel ist bereits jetzt sehr lang geworden, weshalb ich hier vorerst mal abbreche. Fortsetzung folgt.
Auch dieser Artikel ist Teil des RSP-Karneval zum Thema Selbstgeschriebene Rollenspiele auf rsp-blogs.de.
Backstage #1: Ein Blick in meine Werkzeugkiste
Dieser erste Backstage-Artikel soll den Auftakt zu einer kleinen Serie hier sein, in dem ich die diversen Hilfsmittel vorstelle, die ich so benutze, um meine Rollenspiele und Settings “auf Papier” zu bringen.
Mit der Zeit sammelt man ja diverse Tools an, meine Werkzeugkiste enthält gerade:
- LaTeX (zum Layoutieren und Generieren der PDF Dateien)
- Eclipse & TeXlipse-Plugin (eigentlich eine Entwicklungsumgebung zum Programmieren, damit kann man aber auch LaTeX-Projekte verwalten und bearbeiten)
- gEdit (ein simpler Text-Editor für schnelle Bearbeitungen)
- Gimp (zur manuellen Photo-/Bildbearbeitung)
- Inkscape (als Vektor-/Malprogramm für Karten und Icons)
- ImageMagick (zur automatisierten Bearbeitung von Bildern)
- FontForge (zum Gestalten eigener Icon-Schriftarten)
- Subversion (zur Versionierung aller Dokumente und Änderungen)
- GNU Make (Hilfstool, das die manuellen Schritte zum erzeugen des PDFs in LaTeX automatisiert)
- Evince und Acrobat Reader (als PDF-Viewer)
- Linux bzw. Ubuntu (als Betriebsystem)
Darüber hinaus gibt es noch einen Webauftritt zu verwalten. Dazu ist nötig:
- Apache httpd2 (als Webserver)
- WordPress (als Blog/Newsschleuder)
- MySQL (Datenbank, seit ich WordPress nutze)
- PmWiki (für Webseiten, die über WordPress hinaus gehen)
- FileZilla (um Dateien zu und vom Server manuell zu transferieren)
- rsync (um Dateien automatisiert zu transferieren und abzugleichen)
Das klingt jetzt vielleicht relativ technisch und ist es auch. Das liegt vor allem daran, dass ich im “echten Leben” Informatiker bin und mir Tätigkeiten, die ich 2x machen soll, missfallen. Und wenn ich sie ein drittes Mal machen soll, automatisiere ich sie. Wenn man diese Liste durchgeht, bemerkt man auch, dass all diese Software keinen Cent kostet: alles ist freie Software, die man ohne schlechtes Gewissen aus dem Internet ziehen kann. Naja, der Acrobat Reader ist nicht wirklich “frei”, wenn man das Wort gemäß der OpenSource-Gemeinde auslegt, aber immerhin kostenlos.
In künftigen Backstage-Artikeln möchte ich gerne das eine oder andere Tool näher vorstellen und etwas darauf eingehen, warum es mir aus Rollenspielautor-Sicht lieber als etwaige Alternativen ist. (Wenn euch ein Teil besonders interessiert, könnt ihr das ja gern in die Kommentare schreiben. Sonst wird wohl LaTeX zuerst zum Handkuss kommen.)
Dieser Artikel ist übrigens Teil des RSP-Karneval zum Thema Selbstgeschriebene Rollenspiele auf rsp-blogs.de.
QUO VADIS? #2
Mit etwas Verspätung hier ein Update, was sich bei LUDUS LEONIS so tut.
Was war:
Das Ende 2011 war bei mir geprägt durch zwei Dinge: dem Abschluss zahlreicher kleinerer Projekte im Job, die alle vor Neujahr fertig werden mussten, und die Vorbereitung auf einen Urlaub in Ecuador, wo es für Wanderungen jenseits der 4000er-Grenze galt, Kondition aufzubauen. Beides hat mich mal wieder von meinen Rollenspielprojekten fern gehalten. Im Dezember habe ich zwar schon am neuen Look der Homepage gewerkelt, doch der ist knapp nicht rechtzeitig vor dem Urlaub fertig geworden, der direkt an die Weihnachtsfeiertage angeschlossen hat. Damit ist das Thema zu meinem Leidwesen bei ca 80% erst recht in den Jänner gerutscht.
Der Urlaub hat dann gut getan. Vier Wochen ohne (naja, kaum) Internet, kein Stress und viel Bewegung. Mein persönliches Highlight war dann der neue Höhenrekord: 5040m hab ich geschafft.
Seit zwei Wochen bin ich wieder mit regenerierter Energie retour, und nachdem sich der Alltag jetzt wieder normalisiert hat und die aufgestauten Aktivitäten abgebaut sind, habe ich vorige Woche den Skin fertiggestellt und Live geschalten. Damit kann ich nun endlich wieder nach vorne blicken.
Was wird:
Der nächste Meilenstein am Horizont ist die RPC in Köln Anfang Mai. Dort werde ich gemeinsam mit jcgames und ein paar anderen, findigen freien Rollenspielautoren einen Stand in der Fanprojekt-Meile haben. (Herzlichen Dank an jc, dass er das alles organisiert!) Bis dahin soll das NIP’AJIN Manga-Szenario Kurai Jikan in Kleinauflage vorliegen, an dem ich die Arbeiten seit diesem Wochenende wieder aufgenommen habe. Hier ist in den nächsten Tagen/Wochen mit kleineren Zwischenreleases zu rechen. Ob das eigentlich fertige Horror-Szenario Geschlossene Gesellschaft auch gedruckt wird, weiß ich noch nicht so recht. Jedenfalls wird es davon noch ein PDF-Update geben mit dem eingearbeiteten Feedback von Gerrit Ansmann – hier knabbere ich noch an den Kommaregeln, da mein bescheidenes Schulwissen dazu durch die diversen Rechtschreibreformen wohl überholt ist. Und dann habe ich noch ein weiteres NIP’AJIN Szenario in der Pipeline, das aber noch Verschlusssache ist, und bei dem noch fraglich ist, ob das rechtzeitig fertig werden kann. Jedenfalls bin ich bemüht, diesmal die Heftchen optisch mit Illustrationen aufzulockern, wenn ich mir das leisten kann.
Jene von euch, die auf die nächsten ROBiN oder TRiAS Versionen warten, muss ich daher noch etwas vertrösten. Wenn alles gut läuft, könnte es bis zur RPC zumindest eine neue ROBiN Release mit etwas mehr Fluff, aber vermutlich wenig neuem Crunch geben – aber auch hier bin ich vorsichtig, weil die Erfahrung zeigt, dass immer alles langsamer geht als geplant, und ich auch noch auf der Suche nach einer neuen Testrunde bin (wer in/um Wien wohnt und Interesse hat, bitte melden!).
Fazit: Es tut sich wieder was, und LUDUS LEONIS nimmt langsam Fahrt auf!
Der Klassiker: “Was ist ein Rollenspiel?”
Für das TRiAS Regelwerk hatte ich mich bereits einmal an dem klassischen Einführungskapitel “Was ist ein Rollenspiel?” versucht. Ob man so etwas in einem Rollenspielbuch braucht oder nicht wurde sicherlich schon oft und viel diskutiert, auf dem Wiener Spielefest 2011 habe ich jedoch diese Frage immer wieder Brettspielern beantwortet, die sich in die Rollenspielzone “verirrt” hatten. Daher habe ich mich entschlossen, das Kapitel – minimal überarbeitet – auch hier auf die Webseite zu stellen. Siehe Was ist ein Rollenspiel in der Navigation.
Ein neuer Look
Der Webauftritt von LUDUS LEONIS hat soeben einen Tapetenwechsel erhalten. Ich hoffe, dass das neue Design übersichtlicher ist, und Neulinge wie alte Hasen besser zu den gewünschten Informationen leitet. Inhaltlich hat sich (noch) nicht viel geändert, aber ich möchte auch die Info-Seiten noch etwas überarbeiten.
Nachdem das alles Handarbeit ist, und sich wie mit jeder Änderung vermutlich auch Bugs einschleichen, wäre ich über Feedback zum neuen Skin dankbar… Im IE 6-8 dürfte es noch ein Problem mit der Farbe des gerade aktiven TAB geben, und ein paar Paddings oder Margins hier und da gehören noch nachadjustiert, sonst ist mir noch nicht viel aufgefallen.
(Wegen einem Urlaub hat diese Umstellung viel länger gedauert als geplant, aber dazu mehr im überfälligen Quo Vadis in den nächsten Tagen.)
QUO VADIS? #1
Ich hatte bereits angekündigt, dass ich in diesem Blog auch etwas über den aktuellen Stand meiner Aktivitäten schreiben möchte. Ich habe mir vorgenommen, das etwa monatlich zu tun, vorausgesetzt, es gibt auch etwas zu berichten.
Was war:
Diesen Sommer habe ich relativ wenig an meinen Rollenspielprojekten weitergebracht. Gründe gibt es dafür viele. Aber neben Job, regulären Rollenspielrunden und dem Wunsch, die schönen Sommertage lieber draußen zu verbringen, habe ich vor allem ein “Problem” identifiziert, das mich vom Schreiben abgehalten hat: selbst auferlegter Leistungsdruck, der zu einer Schreibblockade geführt hat. Da war einerseits mein Wunsch, heuer noch mit ROBiN fertig zu werden. Das Projektmanagement, das ich dafür aufgezogen hab, inklusive Roadmap mit Meilensteinen und Terminen, war kontraproduktiv, da sich das auf einmal wie Arbeit angefühlt hat. Und andererseits hatte (und habe) ich zuviele Baustellen: CONs besuchen, ROBiN schreiben, TRiAS schreiben, eine neue Testrunde/-gruppe aufbauen, und die noch nicht abgeschlossene NIP’AJIN Szenarien. Da LUDUS LEONIS für mich Hobby sein soll und nicht Arbeit, bin ich also lieber vor all dem in andere Freizeitbeschäftigungen geflüchtet. In Folge hab ich meine internen Deadlines verpasst, und mehr Frust hat sich aufgebaut. Sozusagen eine Todesspirale. Doch: Gefahr erkannt, Gefahr gebannt – zumindest schrittweise. Und das führt mich zu …
Was wird:
Das Spielefest kommendes Wochenende sollte vorläufig die letzte Veranstaltung sein, die ich besuche. Damit sind bis zur RPC 2012 keine Wochenenden mehr mit Events verplant (und die Tage davor mit Vorbereitungen). Nun gilt es, die Baustellen langsam abzuarbeiten und abzuschließen. Die länger werdenden Abende und das positive Feedback, dass ich auf der 8. VFGC bekommen habe, haben scheinbar die Schreibblockade überwunden.
Zuerst möchte ich mich auf NIP’AJIN konzentrieren, weil ich so leichter zu Ergebnissen komme, da die Baustellen kleiner sind. Das Szenario “Geschlossene Gesellschaft” habe ich vor wenigen Wochen finalisiert, als nächstes ist “Kurai Jikan” an der Reihe. Dann steht noch ein weiteres NIP’AJIN Szenario in den Startlöchern, mit dem ich vor 2 Monaten angefangen habe, und das halbfertig in der Schublade liegt – aber da ich nunmal damit schon angefangen habe, lässt mich das geistig nicht mehr los und zählt als Baustelle.
Erst wenn diese Themen hinter mir liegen, werde ich mich wieder ROBiN und TRiAS zuwenden können. Bei ROBiN ist soweit klar was ich tun möchte, die fehlenden Inhalte müssen einfach nur niedergeschrieben werden. Bei TRiAS ist das nicht ganz so einfach, weil ich erst eine neue Testrunde finden muss. Hier habe ich über die letzen Monate auch von interessierten Lesern Feedback zur v0.6 erhalten, das auch noch aufgearbeitet und eingearbeitet gehört (und es ist mir unangenehm, die guten Tipps noch nicht schon längst umgesetzt zu haben). Wenn ihr noch weiteres Feedback habt, wäre jetzt also ein guter Zeitpunkt, das los zu werden!
Um den selbst auferlegten Leistungsdruck zu minimieren, habe ich aus der ROBiN Roadmap die Termine entfernt. Es kommt halt, wenn es fertig ist, und nicht per Stichtag.
Und dieses Blog scheint mir als Ein-Mann-Selbsthilfegruppe auch gut geeignet, Dampf abzulassen ;)