Eigenes Textadventure-Projekt

[Albaster]

Seit ein paar Wochen habe ich die Seiten gewechselt und versuche mich an einem eigenen Spiel. Mit dem freien Autorensystem "Quest" schreibe ich an einem Textadventure. Damit erfüllt sich (so ganz langsam) ein Wunsch, welcher seit gut 30 Jahren auf dem C16 seinen Anfang nahm. Darin besucht man Als Autor/ Schriftsteller einen Ort im Hunsrück (Rheinland-Pfalz) mit der Aufgabe für ein Sachbuch über lokale Mythen und Sagen zu recherchieren, dabei geschehen merkwürdige Dinge und Menschen verschwinden.

Das Spiel findet also in Deutschland unserer heutigen Zeit 2017 statt. Das Projekt ist auch kein reines Textadventure, es wird Grafiken und Sounds besitzen. Orientiert habe ich mich eher an Adventures wie Personal Nightmare
http://1stpersonblog.blogspot.de/2013/0 ... tmare.html
welches man mit Texteingabe spielt, aber auch eine Menüstruktur hat. Quest besitzt standardmäßig diverse Menüs z.B. für das Inventar, Orte und Objekte mit Hyperlinks oder die Fortbewegung durch einfachen Mausklick auf dem Kompass auf der rechten Seite des Bildschirms, wie dieser Screen vom Spielanfang zeigt:



Dazu ein paar Anmerkungen, Erfahrungen und Beobachtungen:

- Quest habe ich gewählt, weil die Grundkenntnisse "relativ" einfach und schnell zu erlernen sind, die Benutzerführung zwar in englisch ist, dafür gibt es aber eine integrierte deutsche Verbenliste mitsamt Vokalen und was noch so dazu gehört. Außerdem ist wohl sehr vieles möglich, im Forum jedenfalls gibt es offenbar immer eine Lösung für irgendwelche Probleme und Fragestellungen. "Marktführer" in diesem Bereich wäre aber wohl das viel zitierte Inform.

- Es ist ein Haufen Arbeit, Objekte, NPCs und Texte zu kreieren sowie nötige Scripte und Dialoge zu erstellen, vor allem wenn man sich erst in einem Autorensystem einarbeiten muss.

- Und natürlich will man viel zu viele Features ins Projekt einbauen, statt erstmal ein kleines Spiel zu erstellen... dazu gibt es hier auch einen schönen Artikel:
https://medium.com/@leetcore/wie-progra ... f2439a73ba

- Man kann schnell ordentliche Fortschritte erzielen und etwas auf die Beine stellen, um jedoch etwas Qualität mit Anspruch zu liefern, braucht es viel Zeit und Übung, halt der Lernprozess. In der Szene schreiben Entwickler teilweise über mehrere Jahre an ihren Spielen, wir reden hier natürlich von nicht kommerziellen Hobby-Projekten.

- Schnell wird klar: Ein Open World-Adventure von fähigen Entwicklern wie ich mir es wünschen/ vorstellen würde und ich hier schon mehrmals diskutiert habe, wäre sehr zeitintensiv und damit teuer.

- Ich habe keine sinnvollen Ideen für wirkliche Rätsel, wie sie sich einige Puristen in Adventures wünschen, sie würden bislang aufgesetzt und unpassend wirken, wobei ich noch ganz am Anfang bin. Wie nicht anders zu erwarten lege ich wert auf Story, Charaktere und Atmosphäre, wobei passende Texte und entsprechendes Verhalten von NPCs viel Aufwand bedeuten.

- Mein Nahziel ist erstmal den ersten Tag als Prolog (Demo) fertig zu bekommen, der recht kurz ist. Das Spiel wird also in Tagen und Zeitabschnitten ähnlich wie bei Gabriel Knight 3 eingeteilt sein.

- Ich würde als Entwickler niemals Versprechungen machen, WANN mein Spiel fertig wird. Man hat so viele Ideen, probiert aus, verwirft sie wieder ect. ich habe jetzt z.B. zum dritten mal neu angefangen.

- Der "harte" Kern in der Interactive Fiction-Szene hat wohl einen gehobenen Anspruch, es wird erwartet zu jedem möglichen aufgeführten Gegenstand eine Beschreibung zu bekommen. Das macht es bei Grafiken natürlich noch schwerer, da man einen Haufen Objekte sehen kann und diese auch ansehen/ untersuchen will. Das ist bei Texteingaben natürlich auch der Reiz, die Orte so zu explorern, bei heutigen Grafikadventures stört es aber kaum noch jemanden, wenn der Mauszeiger sich bei Objekten nicht in eine Lupe ändert und eine kurze Beschreibung abgibt. Spannend wird das bei meinem Auto, welches auch als Fortbewegungsmittel zu den einzelnen Orten dienen wird, denn wahrscheinlich werden Spieler dieses Auto komplett untersuchen wollen und nach Dingen (Kofferraum, Reifen, Tankdeckel, Lenkrad, Klimaanlage, Handschuhfach ect.) sondieren, die nicht alle im Text erwähnt werden. Da könnte man aber eine Einheitsbeschreibung machen oder auf eine Objekt-Bibliothek zurückgreifen, die man dann aber auch erst noch anpassen müsste.

- Kann gut sein das die Grafiken auch wieder rausfliegen. Passende freie Bilder im Internet zu finden ist sehr schwer, normal braucht man das Einverständnis des Erstellers, um sie nutzen zu können. Und eigene "Grafiken" zu programmieren ist für mich utopisch, allein vom Zeitaufwand.

- Wer sich etwas mehr mit der Thematik beschäftigen möchte, findet folgend interessante Lektüre über die (deutschsprachige) Szene mit vielen Informationen:
http://ifwizz.de/if-textadventures-online-spielen.html
http://ifiction.pageturner.de/
https://textlastig.com/ (Podcast)
http://textfire.de/

[Mikej]

Klingt sehr gut, bin gespannt auf das Resultat !!

[advfreak]

Toll, alles Gute für dein Projekt, drücke dir die Daumen das du gut voran kommst und das es vor allem fertig wird!

[Albaster]

Danke für euren Zuspruch!

Werde hier immer mal wieder kleine Updates einbringen, je nach Zeit und Lust. Aktuell beschäftigen mich zwei Fragestellungen: Wie sehr sollte ich ins Detail gehen (Beschreibungen, Aktivitäten mit der Spielumgebung) und wie sinnvoll ist es, diverse Features einzufügen? Auf dem Screen kann man es erkennen: Punkte, Geld, Gesundheit, Tagebuch, Kleidung, Auto als Teleport.

Dazu möchte ich hier demnächst ein paar Beispiele zu mit meiner Herangehensweise vorstellen.

Bis dahin werde ich mir natürlich auch ein paar Textadventures aus der IA-Szene anschauen, wie andere Autoren da vorgehen.

[Albaster]

Wie angekündigt ein erstes kleines Update mit drei Fragestellungen bzw. Einblicken:

Wie detailreich und komplex soll die Kommunikation mit der Spielumgebung sein?

Ein Beispiel wäre das schon genannte Auto. Der Spieler wird es wohl ganz genau anschauen wollen und erwarten entsprechende Beschreibungen. "Untersuche Auto" gibt eine kleine Beschreibung des Autos. Der Spieler möchte in ein Gasthaus, wo er für ein paar Tage eingemietet hat, um in der Gegend für seinen Auftrag (Buch über Mythen und Sagen) zu recherchieren. Er musste auf dem Parkplatz halt machen, da der Weg zum Gasthaus gesperrt ist, es regnet und gewittert. Das Auto muss erstmal zurückgelassen werden, später dient es dann als Teleport zu den einzelnen Orten. Über das Navigationsgerät werden diese Orte ausgewählt.

Zurück zum Auto, es besitzt einen Kofferraum, der als Behälter fungiert. Alle anderen möglichen äußeren Autoteile (Räder, Motorklappe, Tankdeckel ect.) die der Spieler anschauen möchte, bekommen eine Einheitsbeschreibung, der Text der dann angezeigt wird ist also immer gleich. Der Kofferraum kann geöffnet werden, z.B. um Items abzulegen. Nun sind Spieler faul, der Kofferraum wird also nicht wieder geschlossen, soll ich das jetzt ignorieren? Bleibt der Kofferraum einfach auf oder schließt er automatisch? Ich bevorzuge hier das Detail und der Spieler bekommt eine Meldung, wenn er losfahren möchte, das der Kofferraum noch offen ist. Ursprünglich musste man den Kofferraum zumachen, damit man überhaupt mit dem Auto losfahren konnte. Aber ich glaube das würde mit der Zeit nur nerven, nun erscheint zwar die Meldung, wenn der Spieler es aber wünscht kann er dennoch losfahren - mit entsprechender Konsequenz. Denn es regnet, der Kofferraum wird also nass. Mit "Untersuche Kofferraum" bekommt man nun eine ergänzende Beschreibung "Der Kofferraum ist nass". Nun kann man das immer komplexer machen, denn auch alle Inhalte (Items) des Kofferraums müssten dann geflaggt werden und diesen zusätzlichen Kommentar bekommen.



Schwierigkeit und Wiederspielwert

Den Kofferraum für Gegenstände könnte man regelmäßig nutzen, denn das eigentliche Inventar ist begrenzt. Übrigens eine Restriktion die bei vielen alten Adventures üblich gewesen sind, bei mir aber auch so ziemlich die Einzige. Früher war scheitern bzw. mehrmaliges durchspielen eines Spiels um die Lösung zu finden bzw. alle Zusammenhänge zu verstehen durchaus Content. Allerdings kann das auch sehr nervig sein, wenn das Spiel plötzlich zuende ist, das Spielziel aber nicht erreicht wurde. Ich werde das vielleicht ähnlich machen und je mehr Punkte man sammelt, umso mehr zur Story wird zum Spielende erklärt. Trotzdem soll das Spiel ein befriedigendes Ende bekommen, das Mysterium soll also beim erstmaligen spielen mehr oder weniger aufschlussreich gelöst werden können. Ich bevorzuge es aber, allerlei "optionale" Szenen, Dialoge und auch Orte einzubauen, da ich diese Dinge selber sehr spannend finde, welche dann natürlich auch verpasst werden können. Positivbeispiel wäre ja Gabriel Knight 3, wie da teile ich mein Spiel in Zeitabschnitten ein, in denen man aber endlos Zeit haben wird, alles zu schaffen. Nur wenn alles nötige gemacht wurde um die Story voranzutreiben, kann in den nächsten Zeitabschnitt/ Tag gewechselt werden. Der Faktor Zeit war ja auch immer ein Thema in Adventures (Deadline von Infocom, Maupiti Island, Personal Nightmare ect.)

Wie in Thaumistry (neues Textadventure von Bob Bates) habe ich eine kleine Hintfunktion eingebunden. Damit bekommt der Spieler eine kleine Hilfestellung, was als nächstes sinnvoll zu tun wäre. Ob ich diese Hilfe wieder rausnehme, abschaltbar mache oder das Benutzen Punkte kosten wird, muss ich mir noch genau überlegen.

Der Anspruch an einem Tagebuch

Erstes Konzept: Wie auch das Navigationssystem ist das Tagebuch eigentlich aus einer Conversations-Bibliothek (ConvLib) entnommen, welche für Dialoge/ Gespräche mit NPCs gemacht wurde. Eine Bibliothek ist praktisch ein Code/ Script, welches man im Editor einfügt um es sich nicht selber mühsam zusammen schreiben/ klicken zu müssen. Die ConvLib bietet dann Dialogoptionen für Gespräche an in Verbindung mit allerlei Optionen. Diese Bibliothek habe ich meinen Bedürfnissen einfach angepasst, praktisch aber sind Navi und Tagebuch eigentlich NPCs. Immer wenn man im Spiel etwas wichtiges gemacht/ erlebt hat bekommt das Tagebuch einen neuen Eintrag. Außerdem dient es dazu, die nächsten Schritte aufzuzeigen, was der Spieler als nächstes machen kann/ muss. Im Tutorial vom Autorensystem Quest aber wird ein Journal beschrieben, indem man selber Texte eingeben und diese speichern konnte. Das wollte ich natürlich auch haben und so habe ich beide Möglichkeiten verbunden: Zusätzlich zu den automatischen Einträgen kann der Spieler jetzt eigene Notizen hinzufügen und abrufen.

[Joey]

Bezüglich des Kofferraums...
Kannst du nicht beim ersten Mal sowas schreiben wie "Du bemerkst, daß der Kofferraum noch offen ist und schließt ihn. Ooops, das sollte hoffentlich nicht noch einmal passieren."
Und wenn es nochmal vorkommt, bekommt man nasse Items oder Punktabzug oder ähnliches?
Sorry, ich hab null Ahnung, wie man ein Adventure macht und was da einfach oder kompliziert ist. War nur so ein Gedanke gerade.

[Mikej]

Beim Kofferraum würde ich mir auch zumindest zu Beginn den Hinweis wünschen, dass der Kofferraum noch offen ist (oder ihn die Spielfigur selbst schließen lassen).

Gerade in den ersten Minuten ist es mMn wichtig, ein Gefühl dafür zu vermitteln, wie das Spiel tickt. Der Komplexitätsgrad bei Spielen ist ja doch oft sehr sehr unterschiedlich. Und teilweise wird so viel vereinfacht, dass ein Detail wie eine offene Tür nicht zwangsläufig eine Rolle spielen muss...

Aber wenn das Spiel von Anfang an auf solche Details hinweist, achte ich nach einer Weile selbstständig darauf.

[Albaster]

Beim Kofferraum würde ich mir auch zumindest zu Beginn den Hinweis wünschen, dass der Kofferraum noch offen ist (oder ihn die Spielfigur selbst schließen lassen).

Ich könnte die Einführung einfach so anpassen, das der Kofferraum zu Spielbeginn geöffnet ist, denn eigentlich ist er ja erstmal zu. Ich könnte meinen Text von

Noch in Gedanken versunken schlenderst du um dein Auto herum, als dich die ersten zaghaften Regentropfen erreichen.

z.B. in
Noch in Gedanken versunken öffnest du den Kofferaum deines Autos, als dich die ersten zaghaften Regentropfen erreichen.

ändern. Schaut man sich das Auto dann an, käme auch noch mal die Info, das der Kofferraum auf ist und der Inhalt durch den Regen nass werden könnte. Immerhin muss man ja eigentlich den Weg zum Gasthaus zu Fuß fortsetzen und sein Gepäck/ Rucksack befindet sich im Kofferraum. Wer dann immer noch losfahren möchte, braucht auch keinen extra Hinweis mehr beim Ziel auswählen, immerhin hat man ja genügend (wenn auch nicht explizit direkte) Warnungen bekommen?

Gerade in den ersten Minuten ist es mMn wichtig, ein Gefühl dafür zu vermitteln, wie das Spiel tickt.
...
Aber wenn das Spiel von Anfang an auf solche Details hinweist, achte ich nach einer Weile selbstständig darauf.

Im Textlastig-Podcast, also der Cast der sich intensiv mit Textadventures der Hobbyszene beschäftigt, wurde ein TA explizit gelobt (ein "Qualitätsspiel"), das man nach einem Telefonat erst den Hörer wieder auflegt, nachdem man einen neuen Befehl eingibt. Das Auflegen des Hörers passierte allerdings automatisch, ähnlich würde ich vorgehen. Dinge die man eigentlich blind und unterbewusst ausführt, wie z.B. einen Hörer auflegen oder die Autotür zumachen, solche Handlungen würde ich nicht extra aktiv gestalten, vielleicht aber mit einem Text unterstreichen.

Ich mag jedoch Entscheidungen und Konsequenzen, ein offener Kofferraum und nasse Items wäre z.B. ein Detail, den ich ins Spiel bringe. Oder dieses Beispiel:



Die Beschreibung im Auto ändert sich also, abhängig wie man darin agiert. Als Script in Quest sieht das dann so aus:

Kannst du nicht beim ersten Mal sowas schreiben wie "Du bemerkst, daß der Kofferraum noch offen ist und schließt ihn. Ooops, das sollte hoffentlich nicht noch einmal passieren."

Mhh, meinst du vor oder nachdem man schon mit offenen Kofferraum losgefahren ist?

Und wenn es nochmal vorkommt, bekommt man nasse Items oder Punktabzug oder ähnliches?

Eigentlich möchte ich den Frust ersparen das Punkte abgezogen werden, so wird wohl das Anwenden der Hintfunktion auch keine kosten. Ich habe vor Punkte nur zu verteilen wenn sie im Zusammenhang mit dem Mysterium der Story stehen, da sie ja am Spielende zusätzliche Informationen geben sollen.

Hier wäre die Konsequenz das man eben einen nassen Kofferraum + Inhalt hat, wobei ja dann eigentlich auch der Spieler bzw. dessen angezogene Kleidung nass werden müsste...? Im Handschuhfach des Autos befindet sich ein Brief der ehemaligen Freundin des Protagonisten, die in der Gegend wohnt. Sie könnte man im Laufe des Spiels besuchen wollen, was aber wenn der Brief einfach in der Umgebung abgelegt wird und nass und unleserlich wird? Er könnte dann nicht mehr gelesen werden. Also man merkt schon das man es beliebig komplex machen kann...

Sorry, ich hab null Ahnung, wie man ein Adventure macht und was da einfach oder kompliziert ist. War nur so ein Gedanke gerade.

Immer sehr gerne her mit euren Ideen und Gedanken, dafür ist ein Forum ja da und ich nehme sie gerne an. Kurz mal zur Einarbeitung ins Autorensystem Quest, ein paar Dinge/ Inhalte, die ich innerhalb einer "relativen" kurzen Zeit gelernt/ erstellt habe, einiges ist wirklich recht intuitiv zu bedienen:

- Räume (ein Ort wird als Raum bezeichnet) erstellen und verbinden
- Ausgänge öffnen oder verschließen
- Bilder und Sounds einbinden
- einfache Timer erstellen, die z.B. Sounds starten oder wieder deaktivieren können
- mit einem Timer kann ich also zu einem bestimmten Zeitpunkt einen Blitz (Sound und Text) einschlagen lassen
- Aktivitäten wie hupen oder Zeitung aufschlagen mit passenden Sounds erstellen
- Beschreibungen erstellen und diese bei Bedarf anpassen/ verändern
- zufällige Ereignisse und Beschreibungen anzeigen lassen
- Dialoge mit NPC erstellen
- Tagebuch integriert
- Auto als Fortbewegung (Teleport)
- Funktionen wie Punkte, Geld und Gesundheit zu - oder abziehen
- "Flaggen" setzen, Flag ist eine Kennzeichnung die ausgelöst wird wenn etwas entsprechend geflaggt ist (ähhh ja), wenn es z.B. regnet wird etwas auch nass, wenn es entsprechend markiert wurde und dann wird ein Text oder etwas anderes "ausgelöst", ein für mich eher komplizierter Vorgang.

Mein Port mit dem Auto funktioniert, das ist ein einfaches "move player to Gasthaus"-Script. Allerdings müssen bei einem Ortswechsel noch allerhand andere Objekte verschoben werden, die Tür damit man aus dem Auto wieder aussteigen kann. Auch der Kofferraum muss als Objekt den move-Befehl bekommen, die Items darin werden dann automatisch verschoben, da der Kofferraum als Behälter definiert wurde. Das Auto ist also folgendes: Erstmal eins von mehreren Objekten, die man für ein Auto braucht (Kofferraum z.B.), benutzt man das Auto wird man in einen anderen Raum "In deinem Auto" bewegt und hat dort wieder neue Objekte wie Navi und Hupe, und auch die Tür muss immer mitbewegt werden. Das müsste zwar auch wesentlich einfacher und eleganter gehen, aber ich bin ja noch Anfänger. Es ist also schon ein gewisser Aufwand nötig, wenn man z.B. neue Texte und Zustände zufügen möchte, wenn bestimmte Situationen eintreffen sollten, wie Regen und ein nasser Kofferraum.

Auch bei den Gesprächen mit NPCs bin ich noch ganz am Anfang, grundsätzlich habe ich auswählbare Dialogoptionen. Es ist kein Problem, neue Dialoge hinzuzufügen, wenn z.B. der Spieler eine Person trifft, wird wieder der move-Befehl ausgelöst und ein neuer Dialog wird zu einen anderen NPC geschoben, womit man diesen über den getroffenen NPC ausfragen kann. Eine Dialogoption ist praktisch genau so ein Objekt wie ein Baum, ein Schild oder ein NPC. So ist es auch ganz einfach, neue Orte für das Navigationssystem anzeigen zu lassen.

[Joey]

Kannst du nicht beim ersten Mal sowas schreiben wie "Du bemerkst, daß der Kofferraum noch offen ist und schließt ihn. Ooops, das sollte hoffentlich nicht noch einmal passieren."

Mhh, meinst du vor oder nachdem man schon mit offenen Kofferraum losgefahren ist?

Und wenn es nochmal vorkommt, bekommt man nasse Items oder Punktabzug oder ähnliches?

Eigentlich möchte ich den Frust ersparen das Punkte abgezogen werden, so wird wohl das Anwenden der Hintfunktion auch keine kosten. Ich habe vor Punkte nur zu verteilen wenn sie im Zusammenhang mit dem Mysterium der Story stehen, da sie ja am Spielende zusätzliche Informationen geben sollen.

Das mit den Punkten sollte nur ein Beispiel sein, weil du ja Punkte erwähnt hattest.
Ich meinte eigentlich nur, ob das nicht eine Idee wäre, solche Dinge, die man leicht übersieht, wie das Schließen des Kofferraumes, beim ersten mal nicht zu "bestrafen", also keine Konsequenzen dafür zu setzen, sondern es sozusagen "automatisch" zu korrigieren. Mit einer entsprechenden Meldung, so daß der Spieler beim nächsten mal halt daran denkt, daß man die Klappe zuhauen muß, wenn die Sachen nicht z.B. naß werden oder während der "Fahrt" rausfliegen sollen. *Du bemerkst, daß der Kofferraum noch offen ist. Was da alles hätte passieren können? Du schließt den Kofferraum und steigst wieder ein. Noch einmal sollte dir dieser Fehler besser nicht passieren.* Wäre ja auch eine Möglichkeit, daß der Inhalt nicht nur naßwerden könnte, sondern daß man z.B. bei offenem Kofferraum auch etwas verlieren könnte, das man dann neu besorgen oder wieder einsammeln muß.

[lilbeeper]

Hört sich erstmal spannend an.

Ich habe aber das Gefühl, dass du dich viel zu früh in Details verlierst. Wenn man das tut wird ein Projekt selten fertig. Man entwickelt ein Spiel, einen Film oder einen Roman auch nicht vom Anfang hin zum Ende, so wie das dann später konsumiert wird, sondern Top-Down.

Steht denn überhaupt die Story schon? Also nicht nur das Setting, sondern der Handlungsbogen samt Ende. Fang mit einem Elevator-Pitch in drei Sätzen an. Schreib dir dann die Geschichte mal auf ein oder zwei A4-Seiten auf. Dann charakterisiere die Persönlichkeiten und Hintergründe der Figuren mit Stichpunkten. Bestimme, welche Schauplätze es geben soll und zeichne eine Karte, wie diese zusammenhängen. Dann mach dir Gedanken zu den Rätseln und erstelle ein Rätsel Abhängigkeitsdiagramm. Packe das Ganze in einem Design-Dokument für das Spiel zusammen. Gehe da noch ein paar mal drüber, bis es sich für dich gut anfühlt.

Bevor du das nicht hast brauchst du gar nicht erst mit der Implementierung anfangen. Das heißt nicht, dass das alles schon vor der Implementierung perfekt sein muss oder in Stein gemeißelt ist. Wenn du dann mit der Implementierung anfängst, solltest du die Räume und Rätsel möglichst schnell verdrahten, also überhaupt keine Details, sondern super einfache Platzhaltertexte. Aber so, dass das Spiel von Anfang bis Ende "durchspielbar" ist. Dann kannst du damit anfangen, die Texte auszuformulieren, und dich dann um die Details kümmern. Vielleicht merkst du sogar, dass viele Details, wie beispielsweise ob der Kofferraum offen oder zu ist, möglicherweise gar nicht so wichtig sind, um ein spannendes Spiel zu bieten.

Und auch wenn du beschließt, du möchtest erstmal nur ein Kapitel umsetzen, dann solltest du trotzdem die gesamte Handlung aufgeschrieben haben, und dann für dieses eine Kapitel wie oben beschrieben vorgehen.

[Albaster]

lilbeeper, danke für deine Anregungen.

Ich habe aber das Gefühl, dass du dich viel zu früh in Details verlierst. Wenn man das tut wird ein Projekt selten fertig.

Tatsächlich plane ich mein Spiel in der Tat zu "groß", diesen "Fehler" machen viele Anfänger gerne, sie überschätzen den Aufwand, die Einarbeitung in ein Autorensystem und letztlich wohl auch sich selbst. Bei mir merke ich, wie ich scheinbar komplexe Features doch recht zügig eingebaut habe, bei eigentlich einfachen Dingen aber den Durchblick nicht habe. Im Moment stöbere ich mehr durch das (englische) Forum, als am Projekt selber zu arbeiten, die offenen Punkte notiere ich mir, bislang konnte ich mir vieles aber aneignen, was sicher auch einfacher zu integrieren geht, als ich es getan habe.

Die Größe des Spiels ist eine Sache, die Motivation eine andere. Kann natürlich der Zeitpunkt kommen das mich die Lust verliert, letztlich möchte ich das Spiel aber nicht heute oder morgen fertig bekommen, ich orientiere mich da schon in Jahren, wie es in der Hobby-Szene durchaus üblich ist.

Steht denn überhaupt die Story schon?

Im Groben, viele Ideen müssen (aus)sortiert werden. Das Setting steht, wie oben beschrieben. Persönlichkeiten habe ich jetzt vier NPCs, jedoch ungleichmäßig entwickelt. Neben meinen Einblicken hier gibt es wohl eine kleine Vorstellung der ersten Location, dem "Gehöft Wolfenstieg" mit Bewohnern. In diesem Komplex befindet sich auch das Gasthaus, indem der Spieler sein Quartier bezogen hat, der Hof ist praktisch Ausgangsort der Geschichte und auch ein Handlungshauptort.

In zwei weiteren "Updates" möchte ich je zwei bis drei Features vorstellen bzw. auch Bedienelemente, die Quest von Haus aus bietet. Klar, ich habe geschrieben Zeitangaben mache ich nicht, deshalb plane ich Meilensteine: Der erste ist Tag 1 der recht spät beginnt und sich Demo oder Prolog nennen darf, Meilenstein 2 wird dann Tag 2 sein mit dem kompletten Gutshof. Wenn das mal geschafft ist kann ich entscheiden, wie groß das Spiel letztlich werden kann oder ob ich Kürzungen mache, aber da habe ich kaum Gedanken dran verloren.

...und zeichne eine Karte, wie diese zusammenhängen. Dann mach dir Gedanken zu den Rätseln und erstelle ein Rätsel Abhängigkeitsdiagramm. Packe das Ganze in einem Design-Dokument für das Spiel zusammen.
...
Platzhaltertexte

Da musste ich denn doch grinsen, denn so ist meine Vorgehensweise aktuell. Die NPCs bekommen zusätzlich eine Relationship-Map, bei den Rätseln habe ich aber bislang nur wenig nennenswerte Ideen, so weit bin ich aber auch noch nicht, denn der Prolog soll eher die Bedienung, die Atmosphäre und die Story vermitteln. Wer mich hier schon öfter gelesen hat, weiß das ich eher contra gegen Rätsel eingestellt bin, ich weiß das sie "dazugehören", aber Gamebreaker brauch ich keine, Content kann auch anders sein, z.B. Wiederspielwert. Aber natürlich wird es Rätsel geben, nur keine aufgesetzten.

Wenn der Prolog/ die Demo fertig ist, bräuchte ich freiwillige Testspieler, die mir ein Gefühl vermitteln, wie stimmig sich so ein Textadventure spielt, damit meine ich vor allem Textlänge, Grammatik und dergleichen mehr. Das wird ein wichtiger Orientierungspunkt für mich werden, wenn ich denn mal so weit bin.

Bevor du das nicht hast brauchst du gar nicht erst mit der Implementierung anfangen.

In einigen Punkten teste ich natürlich noch und übe mich in den Möglichkeiten, die Quest bietet. Ich habe schon recht viel von meinen geplanten Spielelementen eingebunden und es funktioniert, vieles wird dann wieder entfernt und für später aufgehoben, da ich nicht alles in der ersten Spielstunde verballern bzw. die Spieler erschlagen möchte. Richtig schwer werden dann wohl die Dialoge mit den NPCs, weil diese eben sehr stimmig und nicht zu mechanisch ablaufen sollen, aber du weißt bestimmt selber, wie schwer Konversation in der IF umzusetzen ist...

Persönliche Frage an dich lilbeeper, bist du selber Autor oder intensiver Spieler von Textadventures, kannst gern auch per PM antworten. Ansonsten bin ich immer dankbar für Tipps und Ideen, dafür ist so ein Forum auch da, ich freue mich wenn ihr auf meine Gedanken und auch geplanten Inhalten eingeht.

[Albaster]

Ein paar weitere Gedanken zum Spieldesign:

Regen und Nässe

Es wird nur am ersten Tag - den Ankunftstag - regnen. Die Auswirkungen des Wetters bzw. des Regens sollen aber durchaus spielerische Bedeutung haben. Der offen gelassene Kofferraum ist vielleicht nur ein kleines Detail in der Beschreibung, massiv durchnässte Kleidung (sofern man sich nicht irgendwie vor Regen schützt) kann da schon etwas mehr anrichten, z.B. eine Dialogoption verändern oder eine Erkältung hervorrufen (körperlicher Zustand wird gesenkt). Auch die landschaftliche Umgebung wird entsprechend beeinflusst: Erst ist die Zufahrtsstraße zum Gehöft Wolfenstieg wegen dem Dauerregen gesperrt und einige Tage später wird er wieder für den Vekehr freigegeben, nachdem Bauarbeiter ihn wieder befestigt haben. Dann kann der Spieler mit dem Auto auch direkt am Gasthaus parken, wie auch immer wird es (witziges) Feedback geben, wenn der Kofferraum offen gelassen wird.

Platzhalterbeschreibungen & Implementierungen

Der Tipp mit dem "Skelett", also die Räume erstmal erschaffen und verbinden - also die Spielumgebung ohne implementierte Inhalte erschaffen - verfolge ist erstmal dahingehend, die Räumlichkeiten der Tage 1 (Prolog) und 2 (erster Zeitabschnitt) zu erstellen und damit voll begehbar zu machen, aber auch parallel schon mit Objekten, Texten ect. zu füllen. Gerade von all zu vielen Platzhaltern (beschreibende Texte) wird z.B. hier
http://inform-fiction.org/manual/html/s49.html
abgeraten, wenn man nicht am Ende 50 Raumbeschreibungen anfertigen muss, was sehr frustierend sein kann. Ich füge lieber erstmal kurze Texte und Ideen ein und formuliere später nach. Interessant auch die "empfohlene" Anzahl von drei Objekten je Raum, kommt mir doch sehr wenig vor? Klar, je nach Detailgrad ist das schon ein gewisser Aufwand, hier werde ich noch ausführlicher "testen" müssen.

Mit für mich grundlegenden Features habe ich schon viel getestet und bin zufrieden mit dem Ergebnis, neben den schon erwähnten Tagebuch und Navigationsgerät (bzw. Auto als Teleport) sind das vor allem Kleidung und ein Smartphone mit diversen Funktionen, dazu später mal mehr. Nächste Schritte sind z.B. dunkle Räume mit einer Taschenlampe zu erkunden oder Türen mit Schlüsseln zu öffnen und abzuschließen.

Rätsel

Rätsel gehören nun mal zu einem Adventure... sagt man zumindest. Doch es sollten "unauffällige", sich ins Spiel homogen eingefügte Rätsel sein. Tatsächlich bin ich da noch recht hilflos, wie ich passend Rätsel ins Spiel bringen könnte. Interessante Ideen habe ich schon ein paar, doch sehe ich die eher als optionalen Weg, mehr über das Mysterium bzw. den Orten und NPCs zu erzählen, nicht um den Spieler zu behindern, im Spiel überhaupt weiter zu kommen. Dieser
http://textfire.de/werkst/raetsel.htm
Artikel bestätigt meine Überlegungen, nicht zwingend Rätsel zu entwickeln:

Aus den genannten Gründen wüde ich empfehlen, nicht bewusst nach Rätseln zu suchen, wenn man sich an ein Spiel macht. Besser ist es, mit der Überlegung zu starten, wie man den Spieler überraschen könnte. Die Schwierigkeit, der Rätselcharakter, ergibt sich dann oft von selbst.

Ein Spiel durch Rätsel zu gliedern ist ein Fehler, den viele Spieler nicht verzeihen. Wer nur wegen eines Rätsels über die Karte flitzen muss, etwa weil ein wichtiger Gegenstand nicht ins Inventar gepasst hat, flucht - oder steigt aus.

Außerdem rate ich, gerade bei vielen Rätseln eine möglichst spannende Geschichte zu entwickeln, damit der Spieler überhaupt Lust bekommt, die Aufgaben des Autors zu lösen.

Rätsel sollten sich also von selbst entwickeln. Ich bleib da mal dran, diese Vorgehensweise zu prüfen, auch wenn es am Ende bedeuten könnte: Spiel gelöst - Mysterium nicht erforscht...? Wie viel Rätselkost und in welcher Komplexität kann ich den Spielern zutrauen? Da hilft wohl nur ausprobieren oder eben entsprechend Textadventures spielen.

Standards

Es gibt mit "Undo" ein Standardbefehl in der TA-Szene, welcher die letzten Züge zurück nimmt, da spielt es auch keine Rolle ob man ein Tür verschlossen hat oder sogar gestorben ist. Diesen Befehl habe ich deaktiviert, auch wenn ich mich damit wahrscheinlich gegen diverse Empfehlungen richte. Es ist für mich sehr befremdlich, so wichtige oder interessante Spielinhalte und Mechaniken auzuhebeln und letztlich viel Spannung aus dem Spiel zu nehmen.

Ein weiterer Befehl den ich entfernt habe ist "Nimm alles", mit einen solchen Verb wird ein bestimmtes Vorgehen seitens ungeduldiger Spieler gefördert, die scheinbar wenig wert auf Exploration und Spielatmosphäre legen, sondern einfach nur schnell und effektiv durch bzw. sich mit dem Spiel "messen" wollen.

Das Verb "benutze" ist in der Szene verpönt, aber warum eigentlich? Ich dachte so, ja klar mit "benutze" kann man viele Befehle wie öffne, schließe auf, schreibe mit Stift ect. einfach aushebeln. Schaut man sich alte Screens z.B. von den Lucas-Adventures an, wurden auswählbare Verben (von 15 auf 9) reduziert, auch weil "benutze" andere Befehle mit abgedeckt und gleichzeitig zur besseren Übersicht beigetragen hat.

Unelegant also, musste "benutze" sein und tatsächlich ist das wohl der Grund warum es von den erfahrenen Spielern und Autoren abgelehnt wird.

Aber Spieler lieben Abkürzungen, so dürfen ein U oder X (für engl. examine) für "untersuche", W für "warte" oder ein S für "schaue" natürlich nicht fehlen. Auch eine Erkennung des Parsers von Schreibfehlern wird stets hoch gelobt, dafür werde ich entsprechende falsch geschriebene Wörter als Synonym für das Objekt eintragen. So habe ich bei Kofferraum öfter das R vergessen und Kofferaum in den Testdurchgängen eingetippt, grad längere Wörter sind da von betroffen.

Das Autorensystem Quest hat ein integriertes Mapsystem, welches ingame eine Karte automatisch mitzeichnet. Für mich macht das Kartografieren aber auch einen besonderen Reiz in Textadventures aus. Also verzichte ich auf eine Map.

Hier erkenne ich jetzt auch die Denkweise eines Entwicklers und was er bei einem Spiel empfindet, ohne zu wissen was Spieler eigentlich wollen und gut finden, ich gehe strikt nach meinen Vorlieben vor, nur Tests werden zeigen, ob dieser Weg richtig bzw. sinnvoll ist... auch wenn ich das Spiel in erster Linie ja für mich machen möchte.

[Albaster]

Das aktuelle Cover-/Titelbild zum Textadventure:



Dieses Bild und alle die ins Spiel bislang eingeflossen sind, stammen von dieser Website
https://pixabay.com/
die dortigen Bilder kann man (fast) ohne Einschränkungen benutzen und bearbeiten. Evtl. konvertiere ich die noch entsprechend um damit sie eher wie Grafiken aussehen. Gut geht das, wenn man sie in einen Comicartigen Stil umwandelt. Aber ob das dann gut zu dem Spiel passt, mal schauen....