Abenteuerpräsentation durch Wiki

Infernal Teddy

mag Caninchen
Registriert
2. August 2006
Beiträge
22.694
Ich denke seid gestern abend darüber nach ob nicht ein "portable Wiki" nicht für bestimmte Abenteuerarten (Runs zum Beispiel, oder Dungeons) eine bessere Art der Präsentation wären als PDFs. Durch interne Verlinkung könnte man zum Beispiel alle relevanten Spielwerte einbinden ohne das man ein PDF - das vielleicht auch zur Publikation gedacht ist - aufblähen müßte oder erst umständlich hin und her scrollen bzw. blättern müßte (Ja, ich weiß, für sowas gibt es auch Lesezeichen und so). Ein Wiki dürfte auch wesentlich einfacher zu gestalten sein als ein PDF, und es gibt mittlerweile genug Portable Wikis die man dafür nutzen könnte.

Was meint ihr dazu?
 
Wenn man das Abenteuer aber vorher in seiner Gänze lesen möchte, dann braucht es eine weitere Aufbereitung, sonst folge ich ja nur einem der möglichen Pfade.
 
Hm... vielleicht eine zusammenfassung der möglichen "Pfade" - anderseits ist das nur dann wirklich relevant bei linearen oder semilinearen Abenteuern, oder? Und für die braucht man diese Art von Präsentation nicht unbedingt. Außerdem hätte so ein Wiki den Vorteil das man seine Notizen direkt einpflegen kann
 
Bei vollkommen offenen Abenteuern bräuchte es auch noch protokollierte Abhängigkeiten. Waren die SC schon mal an diesem Ort? Kennen sie die auftretenen NSC schon? Gibt es diese überhaupt noch.

Wenn man das nicht aufwändig nebenher protokollieren will, bräuchte es schon ein vollelektronisch mitdenkendes Medium, würd ich sagen.

Dann fänd ich auch eine Ptolus-Umsetzung interessant. :)
 
Wie "offen" ein Abenteuer auch immer gestaltet sein mag, als Spielleiter möchte nicht nur, sondern MUSS ich vor dem Spielen wirklich ALLES gelesen haben.

Und das ist bei "Textschnippsel-Netzen" leider nicht wirklich komfortabel möglich. - Eventuell könnte man ein Abenteuer aber in ZWEI Formaten aufbereiten: Als normaler, sequentiell von A bis Z zu lesender Text zur Vorbereitung für den Spielleiter, und dann als vernetzter, während der eigentlichen Spielsitzung benutzter Text.

Aber dafür sind ja auch schon direkte Links in einem PDF einfachst zu machen, ohne daß man dafür ein Wiki aufsetzen müßte.

Übrigens ein Tipp für diejenigen, die direkt aus dem PDF heraus zu leiten gewohnt sind (ist bei mir nur bei Hangout-Runden der Fall, denn bei "leibhaftigen" Runden am Spieltisch haben bei mir Rechner nichts zu suchen):

Den Spielverlauf, Spielwerteänderungen, Interaktion der SCs, usw. direkt in das PDF - idealerweise eine "Arbeitskopie" - per Kommentarfunktion des jeweiligen Readers einfügen. Das ist komfortabel und mittels Zeitstempel kann man ja sogar den Verlauf der Änderungen über mehrere Sitzungen nachverfolgen.

Sehr bewährt, wenn man z.B. vorgefertigte, nicht-simpel-lineare Kampagnen leiten möchte, da hier wirklich im Arbeitsdokument ALLES notwendige an Information griffbereit vorgehalten werden kann.
 
Wenn ein Pdf gut designet wurde d.h. Kommentarfunktion, viele interne Verlinkungen,. Text aus dem Pdf kopieren können., Druckversion, Verlinkungen etc. braucht es kein Wiki. Ein Wiki ist für Verlage auch sehr unpraktisch. Aus einer Datei für den Buchdruck kann man relativ einfach ein einfaches Pdf erstellen. Es gibt mehrere Wikisoftwareanbieten, ob die Daten, die mit einer Wikisoftware erstellt worden auch auf einer anderen Wikisoftware funktionieren, weis ich nicht. Falls nicht, würde sich ein Verlag mit der Wahl einer Wikisoftware an diese binden.
Einer der Vorteile eines Wikis ist, dass die Einträge, wenn das Wiki im Netzt liegt, von vielen verändert werden können. Das liegt nicht in Interesse des Verlages. Ein Wiki zu lekorieren ist auch schwieriger als ein als ein lineares Pdf. Ein Wiki ist dann besonders gut, wenn mehrere Personen die Inhalte eingeben können sollen. Einige Gruppen verwenden ein Campaign Wiki, dass alle Spieler und der SL mit Informationen füllen. Wenn man kooperativ mit anderen an der Erstellung von Spielmaterial arbeitet kann ein Wiki auch nützlich sein.

Ein Wiki und Pdf können jeweils Verlinkungen. Bei einer Pdf-Datei kommt es beim Ersteller darauf an, dass er an die richtigen und wichtigen Verlinkungen bei der Erstellung denkt.

Die Idee bei einem Wiki alle relevaten Infos mit einem Klick geliefert zu ist nur theoretisch möglich, aber nicht im Sinne des Wikis. Beispiel: Dungeon Raum 13 beherbergt eine Anzahl an Goblins. Im Wiki gibt es eine Karte auf der im Raum 13 ein Link ist. Die Infos auf der Seite, zu der der Link führt, ist je nach Wikinutzungsauffassung unterschiedlich. Theoretisch könnte auf der Seite die Beschreibung und die Stats der Goblins sein, aber i.d.R. ist auf der Seite nur eine Beschreibung von Raum 13 und in dieser Beschreibung ist ein Link zu den Stats der Goblins. D.d. um an beide Informationen zu kommen braucht es mehrere Klicks. Die Stats der Goblins sind auf einer anderen Seite, weil sie so auch an dereren Stellen des Abenteuers oder auch von anderen Abenteuern genutzt werden können.
Um alle Informationen mit einem Klick zu bekommen braucht es alle Informationen in einer Datenbank und der Link zur Information löscht eine Datenbankabfrage aus. Auf der neuen Seite werden die Ergebnisse der Datenbankabfrage als eine Seite dynamisch angezeigt.

Auch in einem Pdf kann man eine interaktive Karte eines Dungeons oder Realtionship Maps einbauen. In dem Kartenbild werden einfach für jeden Raum zwei (oder mehrere) Links (einen zur Raumbeschreibung und einen bis X zu den Stats der Gegner) eingefügt. In den Zielen der Links werden Links "zurück zur Karte" eingebaut. An solche Möglichkeiten für elektronische Publikationen könnten oder sollten Verlage bei der Erstellung denken.
 
PDF dient dazu Druckseiten zu beschreiben. Struktur und Inhalt eines Dokuments sind dabei zweitrangig. Ziel von PDF ist, eine exakte Repräsentation der Seiten zu reproduzieren.

HTML dient dazu, die Struktur eines Dokuments zu beschreiben und Dokumente miteinander zu verknüpfen. Da (in einer idealen Welt) keine Aussagen darüber getroffen werden, wie diese Struktur präsentiert wird, steht hier der Inhalt im Vordergrund. Ziel von HTML ist es, ein "Netz" verknüpfter Informationen zu weben.

Das WikiWikiWeb war Cunninghams Idee, das Weben besagter verknüpfter Informationen zu vereinfachen, indem man erstens Texte nicht in HTML formulieren musste, sondern wie man es aus Email und dem Usenet gewohnt war, und daraus einfache Auszeichnungen automatisch abgeleitet wurden, zweites Verknüpfungen automatisch durch eine Konvention geknüpft wurden und drittens, dass man keinen besonderen Texteditor und eigenen Server zum Ausliefern der Dokumente brauchte, sondern alles im Browser machen konnte.

Das als Vorrede. Begreift man ein Rollenspiel-Abenteuer als ein Netz verknüpfter Informationen, welches flexibel präsentiert werden soll, ist HTML einem PDF-Dokument überlegen und ein einfaches Wiki-Textformat wiederum HTML. Begreift man das Erstellen eines Rollenspiel-Abenteuers zusätzlich noch als eine explorative, nicht-lineare Tätigkeit, die von den Ideen vielen Autoren profitieren könnte, kann auch ein Wiki gegenüber der Idee, ein einzelner Autor benutzt eine Textverarbeitung, die dann PDF erzeugt, punkten.

Meine Präferenz, ein Abenteuer zu konsumieren (im Sinne von einfach zur Erbauung zu lesen) und zu leiten (es also während eines Rollenspiels als Nachschlagewerk zu benutzen) ist ein E-Book. Ein PDF könnte man als E-Book bezeichnen. Doch ich hätte gerne eine Präsentation, die erst von einem Anzeigeprogramm (E-Book-Reader) passend umgebrochen wird. Nur dafür möchte ich den Term E-Book benutzen.

EPUB3 scheint mir daher das beste Format zu sein. Es basiert auf HTML, beschreibt also die Struktur des Textes und überlässt es (im Normalfall) dem Anzeigeprogramm, die Darstellung zu entscheiden. Es erlaubt es einen linearen Weg durch alle Abschnitte zu definieren, sodass man es wie ein Buch lesen kann, erlaubt aber gleichzeitig beliebige Querverweise (das könnte ein modernes PDF übrigens auch) und interaktive Abschnitte, die man ein- und ausblenden kann. EPUB3 ist ein Containerformat, das quasi eine gesamte Website (also eine Sammlung beliebig vieler HTML-Dokumente und weiteren Ressourcen) offline zur Verfügung stellen kann. Schließlich ist es ein Standard (was auch PDF wäre).

Es wäre theoretisch problemlos möglich, aus einem Wiki ein EPUB abzuleiten.

Alternativ wäre es möglich, einem Wiki die Funktion zu geben, seine Seiten halbautomatisch zu linearisieren. Ich stimme durchaus Zornhau zu, dass man nicht nur in einem Netz von Einzelseiten navigieren möchte, sondern gerne auch alles einmal am Stück lesen können will.

Schließlich könnte man einem speziellen Wiki die Funktion geben, Seiten (bei anderen Ressourcen ist es aufwendiger) auch offline anzubieten und bei der nächsten Gelegenheit, wo eine Netzverbindung existiert, nachzugucken, ob es Änderungen gibt. Offline geschriebene oder geänderte Seiten auch dann wieder zurückschreiben zu wollen würde ich prinzipiell verhindern, um da nicht in eine Welt der Schmerzen (jemand Lust auf einen git-artigen 3-Wege-Merge?) zu geraten. Man landet dann vielleicht dort, wo sich Space Pirates mit seiner HTML-App bewegt.

Ich finde ein klassisches PDF jedenfalls beim Leiten ungenügend. Ich möchte nicht umständlich zwischen Abenteuer-PDF und Regel-PDF hin- und herspringen müssen (Neulich hatten wir 3 iPads und 2 Smartphones am Spieltisch, um die verschiedenen Regelstellen schnell im Zugriff zu haben), ich möchte nicht innerhalb eines Abenteuers blättern, weil die NSCs nicht im Kontext sondern im Anhang beschrieben sind und ich möchte z.B. die Möglichkeit haben, bei den NSCs direkt eine besondere Fähigkeit nachschlagen zu können oder ihre Lebenpunkte direkt abzustreichen. Schließlich möchte ich Anmerkungen und allgemeine Notizen hinzufügen können. Idealerweise ist ein Abenteuer für mehrere Spielsysteme auch so gestaltet, dass ich alle Regeln bis auf die, die mich interessieren, ausblenden kann.

All das ließe sich in Theorie in einem PDF programmieren, ist aber IMHO viel einfacher auf der Basis von HTML. Und den Aspekt, dass ich eigentlich zentral und gemeinschaftlich Abenteuer schreiben und teilen möchte, aber ich jetzt noch gar nicht angedacht, weil ich schon wieder 21 Zeilen a.k.a. Absätze geschrieben habe und es schon wieder viel zu lang geworden ist...

Stefan
 
Aber wie hältst du da fest, ob der namenlose Schrecken aus der Burgruine schon an Tag 2 ausgetrieben ist, oder ob er an Tag 12 noch die Dörfler terrorisiert?
 
Wer, ich? Entweder so wie zu der Zeit, wo ich ein papierenes Abenteuer hatte und das Heft nicht beschreiben wollte und daher einen Extrazettel benutzt oder es mir einfach gemerkt habe. Oder aber, ich postuliere, dass das perfekte elektronische Abenteuer (nicht als einfaches EPUB, sondern als webbasierte App) mindestens eine Notizfunktion eingebaut hat oder sogar eine Möglichkeit, per einfacher Geste die Szenen im Inhaltsverzeichnis umsortieren zu können - für den Fall, dass ich zwischendrin Pause machen will und der Community signalisieren möchte, dass ich nun für Tag 3-11 noch weitere Begegnungen mit dem namenlosen Schrecken brauche.

Stefan
 
Aber wie hältst du da fest, ob der namenlose Schrecken aus der Burgruine schon an Tag 2 ausgetrieben ist, oder ob er an Tag 12 noch die Dörfler terrorisiert?
In einem PDF-Abenteuer mache ich mir einen Kommentar bzw. eine Notiz ins PDF. Das geht leicht und man kann mit diesen Notizen jede Menge Dinge festhalten.
 
Zurück
Oben Unten