Ich habe jetzt mal Le jeu à énigmes en mode texte auf donjon.fi angeguckt und bin froh, dass wir auf deutsch stets so ein großes Angebot an Systemen haben. Aber gut, vielleicht macht's ja Sinn, für mich jedenfalls nicht.

Martin:

Diese niederschwelligen Systeme scheinen auf jeden Fall die Quantität der Spiele zu erhöhen ...

Ist halt wieder der gleiche Effekt wie seinerzeit mit ADRIFT und Quest oder noch viel früher mit AGT. Bei Systemen, die die Komplexität nicht verstecken (denn sie existiert ja immer, egal wie sehr man sie per Drag & Drop-Interface maskiert), ist die Einstiegshürde so hoch, dass man ziemlich sicher sein kann, meist Autoren mit der Geduld und dem Sinn für Details zu haben, dass nachher was Vernünftiges rauskommt. Aber was ist das richtige Maß an sog. Zugänglichkeit? Weiß keiner.

proc: Ich habe jetzt mal Le jeu à énigmes en mode texte auf donjon.fi angeguckt und bin froh, dass wir auf deutsch stets so ein großes Angebot an Systemen haben.

Hm. Hatten wir nicht festgestellt, dass man, wenn man Spiele auf Deutsch schreiben will, eine Auswahl von meist veralteten und schlecht gepflegten Systemen ist? Drehen wir uns hier im Kreis?

Hannes: Bei Systemen, die die Komplexität nicht verstecken (denn sie existiert ja immer, egal wie sehr man sie per Drag & Drop-Interface maskiert), ist die Einstiegshürde so hoch, dass man ziemlich sicher sein kann, meist Autoren mit der Geduld und dem Sinn für Details zu haben, dass nachher was Vernünftiges rauskommt. Aber was ist das richtige Maß an sog. Zugänglichkeit? Weiß keiner.

Das Programm sollte also eine steile Lernkurve haben, damit sichergestellt ist, dass nur geduldige Autoren überhaupt ein Spiel schreiben können?

Die Komplexität steckt ja schon darin, das Spiel selbst zu entwerfen. Das System selbst sollte da möglichst wenig im Weg stehen. Der Unterschied zwischen den "einfachen" und den "komplexen" Systemen zeigt sich ja oft nur, wenn ich etwas besonders Komplexes machen will, das sich mit den einfachen Systemen dann nicht umsetzen lässt.

Zugänglichkeit ist nichts Schlechtes. Die einfachen Sachen sollen einfach, die komplexen zumindest möglich sein. Wenn man sein Spiel aber so entwirft, dass die komplexen Dinge nicht nötig sind, kann man mit den so genannten einfachen Systemen auch ein gutes Spiel schreiben.

Dass eine gute Zugänglichkeit dazu führt, dass es auch mehr Schlechtes gibt, damit muss man sich wohl abfinden. Solange man die guten Sachen unter den schlechten noch findet, finde ich das nicht weiter schlimm.

Wo die Komplexität liegt, ändert sich auch. Im Designers' Manual von Inform 6 lag noch ein sehr starkes Augenmerk auf komplizierten Parser-Spielchen. Ein großer Teil der Übungen befasst sich mit sprachgesteuerten Bordcomputern, Bibeln, in denen man einzelne Bücer nachschlagen kann, riesigen begehbaren Schachbrettern, die mit mur einem Raum und einem Objekt umgesetzt wwerden und, und, und. Für Inform 7 hat Emily Short die Direktive ausgegeben, dass man nie wieder parse_name verwenden soll. Die Parser-Geschichten sind weitestgehend verschwunden, dafür gibt es jetzt umfangreiche Relations, mit denen man die Beziehungsgeflechte aus den Romanen von Jane Austen nachstellen kann.

Man kann mit den komplexen Systeme übrigens auch "einfache" Spiele schreiben. Das französiche I7-Tutorial beginnt man in einer Oase, die eigenartigerweise direkt neben einem Dschungel liegt:

Sie sehen hier eine Steintür, ein Dromedar und eine Palme.

Grrr. Diese lieblose und unsortierte Auflistung der Gegenstände ist leider typisch für Inform, egal ob 6 oder 7. Alles, was nicht ausdrücklich als scenery gekennzeichnet ist, wird gelistet. Ehrlich gesagt, ist das nicht viel besser als

I'm in an Oasis.

Obvious exits: N W E S

I can also see: stone door - dromedary - palm tree

Meiner Auffassung nach gehören nur Objekte, die ich aufheben kann in die allgemeine Auflistung. Die Steintür gehört zum Ausgang im Süden und wird daher in der Raumbeschreibung erwähnt. Ebenso die Palme, mit der ich noch nicht einmal etwas Gescheites machen kann. Das Dromedar sollte zumindest einen eigeen Absatz bekommen und nicht zusammen mit anderen Objekten aufgelistet werden. Dabei bietet Inform ja mit initial und listing_together die Möglichkeit, das zu ändern.

proc: [Donjon FI] Aber gut, vielleicht macht's ja Sinn, für mich jedenfalls nicht.

Du hast ja recht: Donjon ist nicht doll und macht mit dem unterimplementierten Demo-Spiel Coincé des Autors auch nicht unbedingt Werbung.

Dass ich mit dem System nicht warm werde liegt auch daran, dass der Autor nicht dieselbe Vorstellung von einem Textadventure hat wie ich. Das Interface ist eher wie eine Linux-Shell gestaltet: Wenn ein Verb nicht verstanden wird, kommt direkt ein langer Hilfetext. Wenn ein Objekt zu einem Verb nicht verstanden wird, kann man manchmal mit "aide prendre" oder so eine gezielte (aber für mich nicht besonders nützliche) Hilfe anfordern.

Wenn ich etwas aufhebe, heißt es: "Sie haben die Murmel Ihrem Inventar zugefügt." Viel technischer kann man das ja nicht sagen.

Grrr. Diese lieblose und unsortierte Auflistung der Gegenstände ist leider typisch für Inform, egal ob 6 oder 7. Alles, was nicht ausdrücklich als scenery gekennzeichnet ist, wird gelistet.

Doofe Frage: Wie willst du es denn sonst machen als es an sowas wie dem scenery-Flag (oder weiteren Flags ähnlicher Beschaffenheit) festzumachen?

Martin:

Hannes: Bei Systemen, die die Komplexität nicht verstecken (denn sie existiert ja immer, egal wie sehr man sie per Drag & Drop-Interface maskiert), ist die Einstiegshürde so hoch, dass man ziemlich sicher sein kann, meist Autoren mit der Geduld und dem Sinn für Details zu haben, dass nachher was Vernünftiges rauskommt. Aber was ist das richtige Maß an sog. Zugänglichkeit? Weiß keiner.

Das Programm sollte also eine steile Lernkurve haben, damit sichergestellt ist, dass nur geduldige Autoren überhaupt ein Spiel schreiben können?

Eine steile Lernkurve erhöht die Wahrscheinlichkeit eines "geduldigen" Autoren ungemein. Das ist nur eine Feststellung. Sollte man deshalb den Einstieg schwierig machen? Nein, das habe ich nicht gesagt und ist auch nicht meine Meinung.

Wobei das, was heute als "steile Lernkurve" bezeichnet wird, ja ehrlich gesagt auch alles tatsächlich zugängliche Hochsprachen sind. Selbst I6 ist ja sehr, sehr nahe an kanonischem Englisch, man kann den Code von Objektdefinitionen und zugehörigen Aktionen auch als Nichtprogrammierer lesen und im Wesentlichen verstehen, was das soll. (Nein, ich spreche nicht von parse_name Verrenkungen.)

In diesem Sinne bin ich durchaus der Meinung, dass ein sanity check bzgl. Entwicklererwartungen auch immer mal wieder angebracht wäre.

StefanH: Doofe Frage: Wie willst du es denn sonst machen als es an sowas wie dem scenery-Flag (oder weiteren Flags ähnlicher Beschaffenheit) festzumachen?

Ja, natürlich muss so etwas auf Basis der Objekteigenschaften passieren. Für Inform sind scenery (das Objekt wird nicht aufgelistet) und static (Objekt kann nicht aufgehoben werden) aber zwei unabhängige Konzepte. (Und concealed gibt es auch noch, um das Objekt in der Liste zu unterdrücken. Das DM4 selbst zitiert Andrew Plotkin in einer Fußnote zur Beschreibung des Weltmodells: "I've always said that the definition of concealed was ad-hoc and not well understood by anybody.")

Außerdem fallen auch Personen unter "alles, was nicht 'scenery' ist", was sie zusammen mit allerlei Gerümpel in Listen erscheinen lässt, wenn man nicht explizit einen eigenen Absatz mit describe oder initial angibt.

Das kann man so machen, aber meine (subjektive) Empfindung ist, dass viele Autoren diese Attribute nicht verstehen. Vielen Autoren und Spielern sind die ungeordneten Listen auch egal, aber mich stören sie.

Das kann man so machen, aber meine (subjektive) Empfindung ist, dass viele Autoren diese Attribute nicht verstehen.

Ok, das klingt jetzt so, dass das eigentliche Problem ist, wie die Autoren mit diesen Attributen umgehen. Die Attribute selbst kann ich allesamt nachvollziehen und die sind im Phoney Island Objektmodell auf erstaunlich gleiche Weise auch so enthalten, ohne dass ich das von irgendwo übernommen hätte. Inklusive dieses etwas brachialen concealed Attribut. Offensichtlich ergeben sich diese Attribute fast von selbst.

StefanH: Ok, das klingt jetzt so, dass das eigentliche Problem ist, wie die Autoren mit diesen Attributen umgehen.

Stimmt schon, man könnte auch sagen, dass die leblosen Listen ein Benutzerfehler sind. Und ja, das Attribut concealed bedeutet genau das, was draufsteht.

Ich finde aber trotzdem, dass das System, in diesem Fall das Modell der I6-Library, es dem Autoren so leicht wie möglich machen sollte. Wieso werdrn die Konzepte "wird aufgelistet" und "kann man mitnehmen" getrennt betrachtet? Für mich sind diese beiden Konzepte miteinander verknüpft: In der generischen Liste der Dinge im Raum ("Außerdem siehst du hier ...") tauchen nur Dinge auf, die ich mitnehmen kann. Alles andere wird entweder in der Raumbeschreibung erwähnt oder bekommt einen eigenen Absatz. Die genersche Liste am Ende der Raumbeschreibung existiert ja nur, weil man diese Sachen mitnehmen und woanders wieder ablegen kann.

A propos "kann man mitnehmen": In I6 werden Dinge, die man nicht mitmehmen kann, als 'static' gekennzeichnet, in I7 als 'fixed in place'. Meiner Meinung nach ist das genau falsch herum: Alles sollte fest sein, nur Gegenstände, die man aufheben kann, sollten zum Beispiel als 'portable' gekennzeichnet werden.

Im Abschnitt über Türen des Designers' Manual heißt es:

Note that the door is static - otherwise the player could pick it up and walk away with it. (Experienced play-testers of Inform games try this every time, and usually come away with a door or two.)

oder Fußnote 2 im Abschnitt Finishing:

It wasn't until the fifth proofs of §12 of this manual that any of us noticed that the "great stone slab" altar of 'Ruins' had never been made static.

Ein anderer Default würde so etwas verhindern: Dass man Dinge, die man aufheben können sollte, nicht aufheben kann, bemerkt jeder Tester. Wahrscheinlich bemerkt es der Autor selbst schon schnell und ein automatischer Start-Ziel-Durchlauf findet es auch.

Ach ja, ich hacke wieder auf Inform herum, dabei finde ich vieles dort nicht so schlecht. Und Inform 6 wurde in den Neunzigern entworfen, als Spiele halt noch viel mehr mitnehmbare Objekte hatten. Trotzdem finde ich es schade, dass diese Sachen in I7 nicht überarbeitet wurden.

StefanH: Die Attribute selbst kann ich allesamt nachvollziehen und die sind im Phoney Island Objektmodell auf erstaunlich gleiche Weise auch so enthalten, ohne dass ich das von irgendwo übernommen hätte. Inklusive dieses etwas brachialen concealed Attribut. Offensichtlich ergeben sich diese Attribute fast von selbst.

Na klar. Als Graham Nelson Curses geschrieben hat, stand er natürlich vor den gleichen oder zumindest sehr ähnlichen Fragestellungen wie Du bei Phoney Island.

Hannes: Eine steile Lernkurve erhöht die Wahrscheinlichkeit eines "geduldigen" Autoren ungemein. Das ist nur eine Feststellung.

Mag sein. Ich glaube, ich verstehe jetzt, was Du sagen willst: Es gibt allgemein geduldige und weniger geduldige Menschen. Die Geduldigen können sich in ein System einarbeitet und haben auch die Geduld, ein rundes Spiel zu schreiben.

Ich glaube aber, dass die Geduld nicht gleich verteilt ist: Wer geduldig ein Spiel entwirft lernt nicht unbedingt geduldig ein neues System.

Hannes. Wobei das, was heute als "steile Lernkurve" bezeichnet wird, ja ehrlich gesagt auch alles tatsächlich zugängliche Hochsprachen sind. Selbst I6 ist ja sehr, sehr nahe an kanonischem Englisch, ...

Da stimme ich dir zu: Vieles bei den als komplex empfundenen Systemen ist auch nur "Formulare ausfüllen", wie bei den einfachen Systemen. Und man muss die Komplexität der Systeme nicht unbedingt ausreizen.

(Über die Zugänglichkeit von I6 sage ich aber mal lieber nichts.)

Hannes: In diesem Sinne bin ich durchaus der Meinung, dass ein sanity check bzgl. Entwicklererwartungen auch immer mal wieder angebracht wäre.

Das verstehe ich, glaube ich, nicht ganz. Wer soll denn seine Erwartungen überprüfen ‒ Autoren ihre Erwartungen an vermeintlich einfache oder komplexe Systeme oder die Entwickler die Erwartungen an die Akzeptanz ihrer Systeme?

Martin:

Wieso werdrn die Konzepte "wird aufgelistet" und "kann man mitnehmen" getrennt betrachtet?

Weil vielleicht nicht die gesamte Welt deine Präferenz zur logischen Verknüpfung der beiden teilt? Deine Argumentation ist in sich stimmig, aber eben nur im spielmechanischen Sinn. Erzählerisch mag es diverse Gegenbeispiele geben, wo anderes Verhalten zu bevorzugen ist.

Hannes. Wobei das, was heute als "steile Lernkurve" bezeichnet wird, ja ehrlich gesagt auch alles tatsächlich zugängliche Hochsprachen sind. Selbst I6 ist ja sehr, sehr nahe an kanonischem Englisch, ...

Da stimme ich dir zu: Vieles bei den als komplex empfundenen Systemen ist auch nur "Formulare ausfüllen", wie bei den einfachen Systemen. Und man muss die Komplexität der Systeme nicht unbedingt ausreizen.

(Über die Zugänglichkeit von I6 sage ich aber mal lieber nichts.)

Du hast es gerade getan. Die Objektdefinitionen von I6 finde ich schon ziemlich intuitiv. Attribute, Aktionsoverrides – ergibt Sinn. Blöd ist die Aufteilung in Tokens ('') und Strings (""). Außerdem halte ich life für absoluten Unsinn, mag aber auch daran liegen, dass ich nie richtig verstanden habe, wann nun life und wann normales before greift.

Richtig schlimm finde ich I6, wenn es an die Umdefinition von tieferem Libraryverhalten geht. Also bspw. den Listenschreiber umzuschreiben.

Hannes: In diesem Sinne bin ich durchaus der Meinung, dass ein sanity check bzgl. Entwicklererwartungen auch immer mal wieder angebracht wäre.

Das verstehe ich, glaube ich, nicht ganz. Wer soll denn seine Erwartungen überprüfen ‒ Autoren ihre Erwartungen an vermeintlich einfache oder komplexe Systeme oder die Entwickler die Erwartungen an die Akzeptanz ihrer Systeme?

Gerne beide. Aber meine Aussage bezog sich schon auf die Spielautoren. Zu denken, man könne jemals einen Baukasten komplett vorgefertigter Bausteine haben, die man nur noch mit Prosa füllen muss, ist schlicht und einfach naiv. Von den typischen Softwareentwicklungsaufgaben wie dem Denken in variablen Zuständen, logischen Aktionsabfolgen, dem Vorsehen von vielen, vielen Alternativen und dem Abfangen/Implementieren „unerwünschten“ Verhalten wird man niemals wegkommen. Das kann kein Entwicklungssystem leisten, es ist rein logisch unmöglich.

Von den typischen Softwareentwicklungsaufgaben wie dem Denken in variablen Zuständen, logischen Aktionsabfolgen, dem Vorsehen von vielen, vielen Alternativen und dem Abfangen/Implementieren „unerwünschten“ Verhalten wird man niemals wegkommen.

Es ist ja - zumindest in manchen Fällen - noch viel schlimmer. Gerade grafische Programmiersysteme haben die recht unangenehme Angewohnheit, einen nach einem simplen und hoffnungsfrohen Start gnadenlos zu strangulieren, weil man plötzlich an Grenzen stößt. Technische Grenzen des verwendeten Systems, die Grenzen dessen, bis zu welcher Komplexität sich logische Zusammenhänge grafisch anschaulich darstellen lassen, etc.

Ein sinnvolles Einsatzgebiet für solche "Ich klicke mir mein Spiel zusammen"-Tools ist aber natürlich beim Rapid Prototyping. Da machts dann auch nicht mehr so viel, wenn ein Projekt an seine Grenzen stößt.

StefanH:

Was ist eigentlich aus Biegomirs System geworden? Ich fand jetzt den Konsolen-Ansatz nicht so attraktiv, aber da das Ganze .NET-based und in C# ist, hat mans ja nicht so weit zum Windows Desktop, zur App oder zum Browser.

Oh sorry, erst jetzt wahrgenommen...

Ja, die Entwicklung geht weiter und den neuen Beitrag zum Wettbewerb werde ich auch wieder mit Heretic umsetzen. Wie Martin geschrieben hat, ist das Repo frei verfügbar. Die aktuelle Entwicklung liegt aber in einem separaten Branch und der Plan ist, im Weihnachtsurlaub wieder eine neue Version zu veröffentlichen. Ich habe mich hier im Thread zurückgehalten, weil Heretic als One-Man-Privatvergnügen natürlich nicht mit den bestehenden Systemen konkurrieren kann. Natürlich ist in die Weiterentwicklung viel der geäußerten Kritik eingeflossen und ich schaue mal, wie es wird

Wen es interessiert: https://github.com/biegomar/Heretic.InteractiveFiction

[Nur tragbare Objekte auflisten] Erzählerisch mag es diverse Gegenbeispiele geben, wo anderes Verhalten zu bevorzugen ist.

Das mag sein und man sollte es auch umsetzen können, aber ich denke die Voreinstellung, die man ohne Weiteres erzielt, sollte sein, wie ich es beschrieben habe.

Und auf die Gefahr hin, dass schon wieder nicht die gesamte Welt meine Vorlieben teilt: Ich sehe auch erzählerisch wenig Anlass, kunterbunte Listen wie "Du siehst hier eine leere Sardinenbüchse, Prinz William und ein Beistelltischchen" zu erzeugen.

Apropos Vorlieben: Ich habe natürlich so meine Vorstellungen, wie ein Textadventure aussehen sollte, aber diese Vorstellungen kommen ja nicht aus dem Nichts, sondern daher, dass ich mir schon das ein oder andere Spiel angeschaut habe und weiß, was (für mich) funktioniert hat und was mir gefallen hat.

[Inform 6] Blöd ist die Aufteilung in Tokens ('') und Strings ("").

Die Aufteilung hat schon ihren Sinn, weil die Z-Maschine (und auch die I6-Umsetzung in Glulx) diese beiden Arten von Strings unterscheidet: Einträge ins Wörterbuch ('schluessel') kommen ins Wörterbuch und werden auf neun Zeichen beschnitten. Ausgabetexte ("Kuckuck!") werden ans Ende der Spieldatei gepackt und im Z-Code intern als packed address abgelegt.

Inform 7 trifft diese Unterscheidung aus dem Kontext: Understand-Phrasen erzeugen Wörterbucheinträge, alles andere Ausgabetext. (Frühe Versionen von I6 haben das auch gemacht, und so kann man bei name und allem, was bei Verb definiert wird, beide Varianten benutzen, um Wörterbucheinträge zu erzeugen.)

Außerdem halte ich life für absoluten Unsinn, mag aber auch daran liegen, dass ich nie richtig verstanden habe, wann nun life und wann normales before greift.

Ja, life ist irgendwie Quatsch. Man kann aber alles, was man in life machen kann auch in before abfangen. Und man kann immerhin selbst Aktionen erzeugen, die life aufrufen, indem man in der Aktions-Routine RunLife aufruft.

(Ich schreibe "immerhin", weil es oft keinen allgemein gültigen Mechanismus gibt und viele Dinge fest im Parser verdrahtet sind. Das betrifft zum Beispiel einige fake actions, etwa ##LetGo und die vorgegebenen Verben mit topic, bei denen im Parser das jeweilige Objekt als Sonderfall mit einem Wörterbucheintrag belegt wird.

Dieses Klein-Klein, mit dem historisch bedingte Sonderfälle umgesetzt werden, macht Inform aus meiner Sicht nicht gerade sehr zugänglich. Hier fehlen übergeordnete, allgemein gültige Mechanismen. Ein Autor oder eine Autorin können in ihren Spielen ruhig Ad-hoc-Definitionen verwenden, aber in einer Bibliothek sind sie fehl am Platz.)

Von den typischen Softwareentwicklungsaufgaben wie dem Denken in variablen Zuständen, logischen Aktionsabfolgen, dem Vorsehen von vielen, vielen Alternativen und dem Abfangen/Implementieren "unerwünschten" Verhalten wird man niemals wegkommen. Das kann kein Entwicklungssystem leisten, es ist rein logisch unmöglich.

Vieles von dem, was Du aufzählst, ist ja nur im engeren Sinne Programmierung, also das womit einem ein Autorensystem helfen kann. Im weiteren Sinne ist es Spieldesign und damit sollte man sich natürlich schon befassen, wenn man ein Spiel schreibt.

Das Spieldesign, also das Planen der Erzählung und das Gestalten der Texte, sollte sogar im Vordergrund stehen. Deshalb ist es ideal, wenn man die einfachen Dinge in einem System leicht umsetzen kann.

Manchmal ist es aber sogar gut, wenn das System den Ideen des Autors im Wege steht, nämlich dann, wenn dieser etwas implementeren will, das den gängigen Konventionen entgegenläuft.

(Ich sehe übrigens hier Parallelen zu grafischen Benutzeroberflächen. Die Raumbeschreibung ist der Teil des Interfaces, der mir die Handlungsmöglichkeiten im Raum aufzeigt. Wenn da steht "Du siehst hier einen Stein", ist das eine Einladung, den Stein aufzuheben oder ihn zumindest zu untersuchen, genau wie ein breiter Fensterrahmen mich dazu einlädt, die Größe des Fensters zu ändern† oder ein Schieberegler dazu, ihn zu bewegen.

Und irgendwann fragt ein Newbie: Wie mache ich es, dass ich immer nur eine meiner Checkboxen anklicken kann? Und die Antwort, die vermutlich leicht mit jedem Toolkit umzusetzen ist, ist: Nimm keine Checkbox, sondern einen Radiobutton, denn das kennen die Benutzer. Die eckigen Dinger kann ich individuell ankreuzen. Von den runden Dingern kann immer nur eins in der Gruppe aktiv sein.

† Ich rede hier offensichtlich nicht von Windows 10.)

Hallo zusammen,

eine Beta von GerX 4 für Inform 10 steht unter https://sourceforge.net/projects/gerx/ bereit.

Liebe Grüße, Frank

YES!!!!! (oder besser JAAA!!!)

frage:

eine Beta von GerX 4 für Inform 10

Großartig!

Toll! Dann kann ich mein portables altes Reserve-Inform bald verabschieden.

Die neue (?) Syntax "The printed name of the box is "Kiste[-s][f]" gefällt mir besser als mein altes "The box is a female container." Ich weiß nicht, ob das schon immer so war; habe mich lange nicht mehr damit beschäftigt. Aber jetzt werde ich vielleicht doch mal an einem alten Projekt weiterarbeiten.

Hannes:

Nur mal als Beispiel: Ich habe Hibernated gespielt, und fand es grenzwertig blöd. Schlecht erzählt durch große Textdumps und dann ewig nichts, spielerisch schwankend zwischen frustrierend und einfallslos. Abseits der Lösung nichts implementiert. Anscheinend haben dafür sogar Leute Geld ausgegeben! [Achtung: Ich beziehe mich auf die ursprüngliche Version. Die überarbeitete habe ich nicht gespielt.]

Tja, dann solltest lieber mal den Director's Cut spielen. Insbesondere wenn Du für neue Spiele auf alter Hardware empfänglich bist. Als ich das ursprüngliche Hibernated geschrieben hatte, habe ich dafür eine extrem limitierte Engine verwendet (The Quill). Dem kompletten Spiel standen ca. 30kb zur Verfügung, was, nach heutigen Maßstäben bemessen, gar nichts ist. In diese 30kb musste die komplette Spiellogik (wenn X passiert führe Y aus) und der komplette Text (unkomprimiert) passen. Sowas wie eine Standard-Library? Fehlanzeige. Ein Parser der mehr als zwei Worte versteht? Ebenfalls Fehlanzeige. Speicher von der Disk nachladen? Natürlich nicht. Quill ist so konzipiert dass man ohne Programmieraufwand relativ kleine Maschinencode-Spiele schreiben kann. Das fertige Spiel kann dann auf Tape oder Disk gespeichert werden. Durch die Tape-Kompatibilität ergibt sich entsprechend dass weiterer Content von Disk laden nicht möglich ist. Und ja, Leute haben Geld dafür ausgegeben. Ziemlich viele sogar. Und es gab auch einige Awards, beispielsweise von der ZZAP!64. Anders als in der IF Szene, ist die Retro-Szene nämlich damit zufrieden, wenn ein Spiel sich mit den selben Limitierungen präsentiert, die auch ein anderes beliebiges europäisches Tape Adventure aus dem Jahre 1984 gehabt hätte.

Man darf nicht vergessen, dass es zu der Zeit als ich Hibernated konzipiert hatte (2016), keine Engine gab, welche es mir ermöglicht hätte das Spiel anspruchsvoller für ein Retro-Target zu gestalten. Sowohl PunyInform als auch Metrocenter'84 gab es zu dieser Zeit höchstens als feuchte Träume und DAAD habe ich erst drei Jahre später in Zusammenarbeit mit Tim Gilberts (dem originalen Autor von DAAD) der Öffentlichkeit zugänglich gemacht. Davor war das System unter Verschluß. Es musste auch rechtlich einiges geklärt werden, bis wir DAAD auf die Welt loslassen konnten. Rabenstein war dann das erste englische Spiel was jemals mit DAAD entwickelt wurde (das Sytstem wurde in den späten 80ern bis frühen 90ern primär in Spanien mit spanischen Interpretern genutzt). Wir waren also 2016 Lichtjahre entfernt von einer Lösung, die es mir ermöglicht hätte, ein wirklich anspruchsvolles Spiel für ein Retrosystem zu schreiben. Vielleicht in Assember, ja, aber das Rad neu erfinden wollte ich dann auch nicht. Und hier muss explizit betont werden, dass mein Haupttarget der C64 war. Sowas wie die Inform 6 Standard Library hätte mir also nichts gebracht weil diese jede Menge Ballast mit sich bringt der ein Spielen auf einer 8-bit Maschine faktisch unmöglich macht. Den Ozmoo Interpreter gab es zu dieser Zeit sowieso noch nicht.

Blablablah, die Jahre ziehen ins Land und so weiter und ich wurde immer unzufriedener mit Hibernated. Also hab ich 2019, nachdem wir das DAAD Projekt abgeschlossen hatten, dann mit Inform geliebäugelt. Zwischenzeitlich war Ozmoo erschienen und ich hatte mit Metrocenter '84 eine auf der Inform Standard Library basierte custom Library entwickelt, die von der Performance auch auf 8-bit Systemen annehmbare Ergebnisse erzielt. Gleichzeit haben meine Freunde Fredrik und Johan angefangen, PunyInform zu entwickeln und ich wurde quasi Puny User Nummer 1. Viel von meinem Feedback ist in Puny eingeflossen und hat dazu beigetragen, das System zu dem zu machen was es heute ist. Nun hatte ich die Tools, die es mir ermöglichten, Hibernated neu zu schreiben.

Zu dem Hibernated 1 Director's Cut: Es handelt sich nicht um eine "nachgebesserte" Version, sondern es wurde komplett neu geschrieben. Man muss sich das so vorstellen als wenn man Infocom den Auftrag gegeben hätte, den Klassiker neu zu konzipieren. So ist das neue Hibernated endlich deckungsgleich mit meiner ursprünglichen Vision für diese Story und nicht mehr an Limitierungen gebunden. Es wurden außerdem neue Rätsel hinzugefügt, bestehende Rätsel angepasst und es gibt Tonnen von narrativem Content. Und das wurde anerkannt. Mehrere der alten Infocom Mitarbeiter haben die neue Version gespielt, Linus Åkesson sagt über eines der Rätsel im Spiel, es sei eines der besten, das er je gesehen habe, es gibt ein Five-Star-Review von MathBrush und zahllose Awards von Retro Magazinen (ZZAP!64, Crash, AMTIX usw). Ich bin also recht zuversichtlich, dass der Director's Cut Dir ein wenig Freude bringen wird

PS: Sorry für den langen Text, aber fand es wichtig bezugnehmend auf das o.a. Zitat ein paar Dinge zu erläutern. Man sieht Dinge ja oft in einem anderen Licht wenn man den Kontext versteht.

Schön, dass du dir die Zeit genommen hast. Dieser mir bereits vorher bekannte Kontext ändert an meiner Einschätzung jedoch nichts, denn er geht am Kern der Kritik vorbei. Vier lange Textdumps und ansonsten eine komplett stillstehende Spielwelt, in der man per USE OBJECT triviale Hindernisse beseitigt, sind keine gute interaktive Erzähltechnik. Und war es auch nicht 1982. Völlig unabhängig von Technik. Denn, nein, mehr Text macht ebenfalls nicht direkt eine bessere Erzählung. "Gut" heißt für mich, man erspielt sich die Geschichte Häppchenweise, durch Interaktion, und idealerweise so implizit wie möglich. Nicht, dass sich Spiel und Geschichte abwechseln.

Hannes:

Schön, dass du dir die Zeit genommen hast. Dieser mir bereits vorher bekannte Kontext ändert an meiner Einschätzung jedoch nichts, denn er geht am Kern der Kritik vorbei. Vier lange Textdumps und ansonsten eine komplett stillstehende Spielwelt, in der man per USE OBJECT triviale Hindernisse beseitigt, sind keine gute interaktive Erzähltechnik. Und war es auch nicht 1982. Völlig unabhängig von Technik. Denn, nein, mehr Text macht ebenfalls nicht direkt eine bessere Erzählung. "Gut" heißt für mich, man erspielt sich die Geschichte Häppchenweise, durch Interaktion, und idealerweise so implizit wie möglich. Nicht, dass sich Spiel und Geschichte abwechseln.

Wie man eine Geschichte erzählt weiß ich selbst. Wie oben schon erwähnt war ich unzufrieden mit dem Original. Dieser Kontext kann Dir nicht bekannt gewesen sein, denn ich habe bisher nicht darüber gesprochen. Man kann von dem Original halten was man will, prinzipiell ist es mir auch egal wie Du dazu stehst, ich wollte nur ein wenig Licht auf den Werdegang der Entwicklung von Hibernated von klassischer Variante zur Neufassung leuchten, insbesondere warum es sich lohnt die Neufassung zu spielen. Du kannst natürlich auch gerne weiter daran festhalten während der Rest der Welt die Neufassung spielt.

Insgesamt war aber auch das klassische Hibernated ein großer Erfolg und gewann unter anderem den ZZAP!64 Sizzler und den Crash Award. Was man retrospektiv sagen kann: es wurde von unheimlich vielen Menschen gespielt, die normalerweise keine Adventures spielen, USE anstelle von expliziten Verben hat das Spiel zugänglicher gemacht und das war auch der Sinn dahinter. Mein intiales Ziel war es immer gewesen, all jene Spieler mit an den Tisch zu bitten die in den 80ern frustriert das Spielen von Adventures aufgegeben hatten, weil diese insgesamt zu schwer für sie waren. Versteh mich nicht falsch, ich möchte mich keineswegs rechtfertigen, ich finde sogar dass Deine Kritik durchaus berechtigt ist, nur stehst Du mit ihr ziemlich alleine da weil einer sehr breiten Masse an Spielern auch das Original gut gefallen hat. Ich sehe es aber in der Tat genau wie Du, was mich wieder zu meinen Beweggründen bringt, die mich ermutigten, das Spiel komplett neu zu schreiben.

Vielleicht noch ein kurzer Kommentar zu dem kommerziellen Aspekt hinter dem Spiel (Zitat: Es gibt anscheinend sogar Leute die dafür Geld ausgegeben haben): Ja, es haben Leute dafür Geld ausgegeben. Allerdings freiwillig. Hibernated war von Tag 1 kostenfrei erhältlich. Auch der Director's Cut, in den viele, viele Stunden Arbeit geflossen sind, ist kostenfrei erhältlich. Auf itch kann man optional eine Donation bereitstellen, muss man aber nicht. Ich agiere komplett non-Profit und mach das was ich mache für die Community. Der physikalische Release über meinen Publisher Poly.Play ist für Liebhaber, die gerne eine Box mit einem Retrodatenträger in den Händen halten wollen. Sämtliche Einnahmen über Poly.Play nach Abzug der Unkosten gehen nicht auf mein Konto sondern werden von meinem Publisher in meinem Namen an wohltätige Zwecke gespendet.

8bit_era:

Dieser Kontext kann Dir nicht bekannt gewesen sein, denn ich habe bisher nicht darüber gesprochen.

Klar doch. Ich bin bekanntermaßen ein fieser Lügner. Kann ja jeder nachprüfen, ob man die gleiche Geschichte bereits anderswo nachlesen kann.

prinzipiell ist es mir auch egal wie Du dazu stehst [...] Versteh mich nicht falsch, ich möchte mich keineswegs rechtfertigen

Ja, das ist deutlich. Insbesondere versuchst du dich nicht zu rechtfertigen für Dinge, die überhaupt niemand gesagt, geschweige denn kritisiert oder in Frage gestellt hat.