Das Thema „Arbeitsweisen“ aus dem IFGP2024-Thread hätte mich dann doch noch stärker interessiert, weshalb ich es nun herauslöse und ihm einen eigenen Thread spendiere.

Mich interessiert nämlich, wie ihr üblicherweise an IF oder artverwandten Projekten arbeitet. Schreibt ihr direkt drauflos in Inform? Plant ihr alles minutiös, oder geht ihr einen Mittelweg? Spannend ist vielleicht auch gerade die Frage: Bis wohin lohnt sich eurer Erfahrung nach vorausschauendes Arbeiten, und ab wann wird es Zeitverschwendung?

Spannend wäre natürlich auch, ob eure Erfahrungen mit diesen Arbeitsweisen alle positiv waren oder ob sich ein Zuviel oder Zuwenig an Voraus-Design- und Planungsarbeit auch schon mal gerächt hat.

Was mich selbst angeht: Ich schreibe absolut immer ein Game Design Document, das beschreibt Räume, Personen, Gegenstände, Puzzles, Story. Ohne dass ich auf dem Papier sehe, dass das Ganze grundsätzlich funktioniert, schreibe ich keine Zeile Code. Irgendwann löse ich mich dann vom GDD, aber sicher nicht, bevor das Spiel nicht über den Hauptstrang lösbar ist. Ich behaupte nicht, dass das die geilste Arbeitsweise überhaupt ist. Aber ich kann halt nur so arbeiten, ich habe vielleicht – berufsbedingt – einen Planungsfimmel.

Ich kann mich auch an frühe Fälle erinnern, wo ich es übertrieben habe. Ein übergroßer Detailgrad rächt sich ja bei jeder Änderung, die man nachher noch einpflegen muss.

Bei mir ist es ein Mittelweg, würde ich sagen; aber mit Tendenz dazu, die Planung nicht allzu weit zu treiben, weil ich irgendwann mehr Lust darauf habe, endlich in die konkrete Programmierung einzusteigen.

Ich lege vorher Notizen in Text-Dokumenten an (zu Geschichte, Umgebung, NPCs, Puzzles - nicht unbedingt immer sauber getrennt); einfach unformatiertes ".txt", weil es am schnellsten geöffnet wird, am portabelsten ist, und man ohne Probleme auch mal Code-Schnipsel hin und her kopieren kann, ohne dass es Ärger mit Formatierungen gibt.

Ich habe allerdings überlegt, ob ich nicht evtl. auf Markdown oder ähnliches umsteigen sollte, oder ein Outliner-Format wie Emacs Org-Mode, oder Software wie Notion oder Obsidian. Da hat man dann ja einige zusätzliche Features und Möglichkeiten zur Organisation.

Außerdem zeichne ich mit Trizbort anfangs eine ungefähre Karte, die ich im Laufe des Projekts aktualisiere. Das motiviert immerhin ein bisschen, wenn man sieht, wie die ausgedachte Welt allmählich Gestalt annimmt und größer wird.

Ich hab auch mal so etwas wie ein Ablaufdiagramm oder ein "Puzzle Dependency Chart" mit dem Diagramm-Editor yEd erstellt. Das war nicht schlecht, um einen gewissen Überblick zu haben, aber ich habe es irgendwann nicht mehr aktuell gehalten, erstens aus Zeitnot (besser direkt am Spiel arbeiten), und zweitens, weil ich durch die Spielstruktur und durch Tests relativ sicher war, dass es keine unbeabsichtigten Sackgassen gab.

Emily Short beschreibt ihre Erfahrungen mit verschiedenen Herangehensweisen in diesem interessanten Artikel: https://emshort.blog/2009/08/23/idea-to-implementation/

Die Methode, die sie "write the through-line first" nennt, geht wahrscheinlich in eine ähnliche Richtung wie bei dir (den Hauptstrang zu implementieren), oder auch eine Art Minimum Viable Product zu erstellen und iterativ zu erweitern.

StJohn Limbo:

Emily Short beschreibt ihre Erfahrungen mit verschiedenen Herangehensweisen in diesem interessanten Artikel: https://emshort.blog/2009/08/23/idea-to-implementation/

Das ist I7-Promo von 2009 als es noch im Säuglingsalter war, das war damals schon alles Altwein-Neuschlauch. Innovativ wirkt historisch betrachtet lediglich der Rat "Transcript fully, then implement: You sit down with a text editor and you write the transcript of your player’s perfect experience. Then you implement that." Das klingt arg nach Twine, Emiliy war da ihrer Zeit mal wieder voraus;)

Von "write the through-line first" bin ich gar kein Freund. Da ist erstens die Verlockung zu groß, den Sack dann einfach zuzumachen, es also dabei zu belassen. Zweitens entgehen einem dann garantiert Abbiegungen oder Parallelstränge, die man sonst weiterentwickeln könnte.

Ein einziges Mal habe ich wirklich alles durchgeplant. Da hatte es aber auch einen Grund, nämlich die (etwas seltsamen) Regeln der damaligen Ectocomp, die beliebig viel Vorbereitungszeit, aber nur zwei Stunden Implementierungszeit erlaubten. Also haarklein alles aufgeschrieben, die Eieruhr angestellt und nur noch eingehackt. Fand ich eher interessant als schön, dieses Experiment.

Ansonsten eher: grobe Notizen zu Szenen, deren Abfolge, dem dramaturgischen Bogen. Grundlegende Designparadigmen eher im Kopf. Implementierung tendenziell nach Zeitlinie des Spiels, es sei denn, es gibt gute Gründe. Und das Spiel dabei leben lassen. Ohne Angst, geplante Dinge über den Haufen zu werfen, wenn sich etwas anders ergibt. Bei der schwarzen Lilie hatte ich im ersten Treatment bspw. eine Figur in einer komplett anderen Rolle. In der ersten Nacht ist eine breite Handlungswendung, die von vornherein als optional geplant war, ersatzlos gestrichen, weil es den Gesamtbogen meines Erachtens dann doch unrund gemacht hat. Wenn etwas nicht klappt, versuche ich es im Allgemeinen nicht zu retten. Das führt nach meiner Erfahrung nur zu halbgarem Krampf.

Die Methode, die sie "write the through-line first" nennt, geht wahrscheinlich in eine ähnliche Richtung wie bei dir (den Hauptstrang zu implementieren), oder auch eine Art Minimum Viable Product zu erstellen und iterativ zu erweitern.

Ein MVP ist das meines Erachtens noch nicht, dafür ist das Nebenhergedöns dann doch zu zentral (vermutlich hätte in den 80ern so ein Status genügt, um einen IF-Vertrag als erfüllt anzusehen und das Ding beim Publisher einzureichen. Ächz, und wir armen Schweine mussten den Mist dann spielen). Aber ansonsten hast du völlig recht, das unterscheidet sich vermutlich nur in Nuancen von meiner eigenen Arbeitsweise. Ich sehe es als pragmatischen Mittelweg an.

Von "write the through-line first" bin ich gar kein Freund. Da ist erstens die Verlockung zu groß, den Sack dann einfach zuzumachen, es also dabei zu belassen. Zweitens entgehen einem dann garantiert Abbiegungen oder Parallelstränge, die man sonst weiterentwickeln könnte.

Diese Verlockung verspürt allerdings wahrlich nicht jeder. Und nur, weil man eine einigermaßen gut durchstrukturierte Grundlage hat, ist das noch lange kein Grund, um den Griffel fallen zu lassen. Aber im Grunde genommen muss man hier sagen: Typfrage! Mich würde das in keiner Weise einschränken, noch weiter an meinem Spiel herum zu sägen, aber ich spreche hier auch nur für mich.

Ich lege vorher Notizen in Text-Dokumenten an (zu Geschichte, Umgebung, NPCs, Puzzles - nicht unbedingt immer sauber getrennt); einfach unformatiertes ".txt", weil es am schnellsten geöffnet wird, am portabelsten ist, und man ohne Probleme auch mal Code-Schnipsel hin und her kopieren kann, ohne dass es Ärger mit Formatierungen gibt.

Um mich mal richtig unbeliebt zu machen: ich verwende für sowas tatsächlich hauptsächlich Word. Eigentlich habe ich die Arbeitsweise von Open Office/ Libre Office übernommen, aber Word, räusper, bedient sich einfach besser. Ich strukturiere die Dokumente grundsätzlich mit Formatvorlagen und benutze die Navigationsleiste exzessiv, um im Dokument zu navigieren. Funktioniert für mich wunderbar. Für den Fall, dass ein Text von nervigen Steuerzeichen bereinigt werden muss, ist im Hintergrund immer ein Notepad++ offen. Der nächstlogische Schritt für mich ist dann eigentlich die Arbeit in einem Wiki. Im Beruf benötigen wir das ständig. Zum Glück kam selbst Phoney Island ohne solche Design Dokument Monströsitäten aus. Richtig unverzichtbar wirds ja auch eigentlich nur bei kollaborativem Arbeiten.

Wenn etwas nicht klappt, versuche ich es im Allgemeinen nicht zu retten. Das führt nach meiner Erfahrung nur zu halbgarem Krampf.

Ha, und das ist schon fast wieder ein neues Thema. Hm, was heißt hier "fast"?

proc:

Das ist I7-Promo von 2009 als es noch im Säuglingsalter war, das war damals schon alles Altwein-Neuschlauch. Innovativ wirkt historisch betrachtet lediglich der Rat "Transcript fully, then implement: You sit down with a text editor and you write the transcript of your player’s perfect experience. Then you implement that." Das klingt arg nach Twine, Emiliy war da ihrer Zeit mal wieder voraus;)

Kläre mich Twine-Unkundigen mal auf. Inwiefern ist das Twine?

Ansonsten klingt das nach einer Arbeitsweise direkt aus dem tiefsten Abgrund der Hölle. Aber was weiß ich schon?

Hannes:

Von "write the through-line first" bin ich gar kein Freund.

Das habe ich bei "Wildcard Nucleus" gemacht und ohne wäre ich nicht fertig geworden, insofern war das schon eine große Hilfe. Da es mein erstes IF-Spiel war, ist das Ergebnis ziemlich spröde. Emily gibt in ihrem Artikel einige nicht von der Hand zu weisende Gründe für so einen Ansatz, u.a., dass sich so am Ende alle Teile gleich gut ausgearbeitet anfühlen.

Da ist erstens die Verlockung zu groß, den Sack dann einfach zuzumachen, es also dabei zu belassen. Zweitens entgehen einem dann garantiert Abbiegungen oder Parallelstränge, die man sonst weiterentwickeln könnte.

Das stimmt.

Ein einziges Mal habe ich wirklich alles durchgeplant. Da hatte es aber auch einen Grund, nämlich die (etwas seltsamen) Regeln der damaligen Ectocomp, die beliebig viel Vorbereitungszeit, aber nur zwei Stunden Implementierungszeit erlaubten. Also haarklein alles aufgeschrieben, die Eieruhr angestellt und nur noch eingehackt. Fand ich eher interessant als schön, dieses Experiment.

Hehe, habe ich auch genau einmal im gleichen Kontext gemacht (bei "Vampire Gold"). Mir hat es tatsächlich gefallen, weil ich sonst immer so planlos arbeite und ich so gezwungen war, deutlich effektiver zu sein. Heute hat man 4 Stunden Zeit, das ist aber auch noch deutlich zu wenig, um ein halbwegs poliertes Spiel zu machen.

Ansonsten eher: grobe Notizen zu Szenen, deren Abfolge, dem dramaturgischen Bogen. Grundlegende Designparadigmen eher im Kopf. Implementierung tendenziell nach Zeitlinie des Spiels, es sei denn, es gibt gute Gründe. Und das Spiel dabei leben lassen. Ohne Angst, geplante Dinge über den Haufen zu werfen, wenn sich etwas anders ergibt. Bei der schwarzen Lilie hatte ich im ersten Treatment bspw. eine Figur in einer komplett anderen Rolle. In der ersten Nacht ist eine breite Handlungswendung, die von vornherein als optional geplant war, ersatzlos gestrichen, weil es den Gesamtbogen meines Erachtens dann doch unrund gemacht hat. Wenn etwas nicht klappt, versuche ich es im Allgemeinen nicht zu retten. Das führt nach meiner Erfahrung nur zu halbgarem Krampf.

Das klingt alles sehr vertaut für mich. Ich tu mich immer etwas schwer, Sachen wieder wegzuwerfen und daher brauche ich meistens etwas zeitlichen Abstand, um zu erkennen, wo ich mich verrannt habe. Dinge zu ändern ist oft auch mit viel Aufwand verbunden und dann muss der Druck gross genug sein, das auch zu tun. Ich hab für mich festgestellt, dass die allereinfachsten Ideen am besten funktionieren, weil kompliziert wird das dann alles schon von alleine – "Fischstäbchen" z.B. sollte am Anfang nur 3 Räume haben, und für die englische Version habe ich die Karte da noch mal ziemlich umgekrempelt. Ansonsten ist jedes Spiel immer ein Experiment. Die großen Pläne zu Beginn weichen schnell der Ernüchterung. Oft entsehen aber interessante Sachen aus kleinen Tests, wo ich nur etwas ausprobiere.

Und das Spiel dabei leben lassen.

Das bringt es für mich auf den Punkt. Jedes Spiel entwickelt ein Eigenleben, einen eigenen Willen und eine Richtung, in die es drängt. Dem sollte man folgen und nicht dagegen arbeiten, weil man sich vorab was anderes vorgestellt hatte.

Ich tu mich immer etwas schwer, Sachen wieder wegzuwerfen und daher brauche ich meistens etwas zeitlichen Abstand, um zu erkennen, wo ich mich verrannt habe.

Das geht mir ziemlich ähnlich. Dabei ist es eigentlich egal, ob und wie weit etwas vorgeplant ist - sobald es in Code gegossen ist, setzt die Neigung ein, das Gebilde erst mal so hinzunehmen, wie es da steht. Da hilft dann tatsächlich nur der Zeitfaktor - oder, noch besser, externes Feedback!

Jedes Spiel entwickelt ein Eigenleben, einen eigenen Willen und eine Richtung, in die es drängt. Dem sollte man folgen und nicht dagegen arbeiten, weil man sich vorab was anderes vorgestellt hatte.

Das ist ja insgesamt schon ein gutes Zeichen, wenn ein Spiel eine klare Richtung hat, in die es drängt. So einer Dynamik würde ich auch in jedem Fall folgen. (Zuletzt ging mir das so beim "Versteck des Meisters", wo sich die Story beim Schreiben imnmer mehr selbständig gemacht hat. So bekam dann der anfangs etwas verschroben wirkende Meister seine zunehmend schlimmere Midlife Crisis) Das spricht aber nicht wirklich dagegen, so einer Dynamik planvoll zu folgen, finde ich.

StefanH:

Kläre mich Twine-Unkundigen mal auf. Inwiefern ist das Twine?

Na wie der berühmte Roman "Der Ritt nach Santa Fe": "Galoppi, Galoppi, Galoppi, Galoppi, Galoppi, Galoppi, ... Stop! Santa Fe!". Argh, schon wieder rutscht's mir raus: Siehe https://ifwizz.de/gen-sueden-(2003-de).html wo das Script mindestens eine Klorolle benötigt. Spielerseits ist auch mit einer zu rechnen, je nach Tippgeschwindigkeit. Na gut, werd's nie wieder erwähnen, ich schwöre versuchshalber!