Nun da die große Aufbruchsstimmung um den Grand Prix verebbt und die übliche Ruhe wiedereingekehrt ist, möchte ich mal versuchen, eine Bestandsaufnahme der Schreibmöglichkeiten auf Deutsch anzufangen. Korrekturen und Ergänzungen sind herzlich willkommen!

• Inform 7: deutsche Bibliothek GerX existiert, ist aber nur mit einer sehr alten Compilerversion kompatibel
• Inform 6/Standardbibliothek: deform existiert, ist aber auf dem Stand von 6/11 (Englisch: 6.12.5) und hat darüber hinaus ein paar Bugs.
• Inform 6/PunyInform: nicht übersetzt
• TADS: G-TADS ist verfügbar und aktuell? Generell erscheint mir TADS allerdings tot.
• Dialog: deutsche Bibliothek von Mikawa, anscheinend eine Version hinter der englischen
• Floyd/T.A.G.: originär deutsch, aber beide tot
• Quest/HUGO/ADRIFT: meines Wissens nicht auf Deutsch nutzbar

Ein Muster, das sich herausbildet: Wir werden abgehängt und damit inkompatibel mit dem Rest der Welt. Klar kann man uralte Inform-7-Versionen noch installieren und verwenden. Aber die Spiele verhalten sich dann anders als man es von anderen Sprachen gewohnt ist, Erweiterungen und Codebeispiele funktionieren nicht usw.

Andererseits, wenn man die den letzten GP anschaut: Ist das überhaupt noch relevant? Sechs Spiele, sechs Entwicklungssysteme. Brauchen wir überhaupt noch das eine?

Hannes:

Brauchen wir überhaupt noch das eine?

Es muss ja nicht unbedingt ein bestimmtes dominierendes System geben; aber die Aspekte, die du nennst (Erweiterungen, Codebeispiele), und generell der angesammelte Erfahrungsschatz und die Qualität der bewährten Systeme sprechen m. M. n. schon dafür, sie zu aktualisieren bzw. am Laufen zu halten. (Wobei natürlich Neuentwicklungen trotzdem jederzeit willkommen sein sollten.)

Leider habe ich im Moment wenig Zeit, deswegen bin ich in der etwas unangenehmen Lage, zu sagen: "Wäre super, wenn es jemand (der berühmte jemand) machen würde; aber ob ich was beitragen könnte, weiß ich nicht."

Ich hab deswegen auch die neueste Inform-7-Version (v10) noch nicht kompiliert, sondern warte auf die fertigen IDE-Veröffentlichungen, um zumindest mal eine "offizielle" Endverbraucher-Version vorliegen zu haben, die wie intendiert funktioniert, und bei der die ersten neuen Bugs auch schon wieder behoben sind.

Bei der Version kann man (bzw. könnte ich ggf. auch) dann mal gucken, ob man sich rantasten kann, diese Sprach-Kits auszutauschen und die bisherige GerX-Extension irgendwie einzubinden.

Olaf hat ja im GerX-Thread schon den Intfiction-Thread mit entsprechenden Hinweisen verlinkt: https://intfiction.org/t/updating-translations-for-inform-10-1-0/55743

Ob ich persönlich damit weit kommen würde, weiß ich nicht, weil ich mich mit dem inkludierten I6 nicht auskenne und mich auch mit der neuen Architektur von I7-v10 noch nicht beschäftigt habe.

Insgesamt wage ich es allerdings einfach mal, vorsichtig optimistisch zu sein, was die Update-Möglichkeiten angeht. Die ersten Enthusiasten haben ja auch schon das System bei sich kompiliert und versuchen, durch die Struktur durchzusteigen. Graham Nelson fixt Bugs und hat sich in dem langen Thread auf intfiction.org geäußert; kann also sein, dass es jetzt leichter wird, ihn zu kontaktieren, falls etwas nicht klappt. Außerdem ist z.B. Nathanaël Marion aktiv bei der französischen Übersetzung. Das Know-How zu den Interna von Inform wird sich ansammeln, und es sollte im Laufe der Zeit machbar werden, auch GerX auf den neuesten Stand zu bringen.

Ich hoffe auch drauf, weil ich Inform 7 durchaus mag und eventuell wieder was mit der Vorple-Erweiterung machen wollen würde.

Ansonsten hätte ich prinzipiell auch kein Problem damit, auf TADS umzusteigen, nur dass da leider ja die Zukunft/Weiterentwicklung etwas unklar ist. Ich meine, okay, das System ist bewährt und läuft bereits sehr gut und ich bin keiner, der jeden Monat nur aus Prinzip ein Update braucht -- aber falls doch mal ein Bug auftaucht oder das Zusammenspiel mit neueren Betriebssystem-Versionen aus irgendwelchen Gründen schwierig würde, wäre es schon nett zu wissen, dass es Updates gäbe.

Dialog ist technisch beeindruckend, und man kann tolle Spiele damit entwickeln, wie Mikawa ja bereits auf Englisch gezeigt hat. Aber ich persönlich hätte da ebenfalls etwas Bedenken hinsichtlich der Weiterentwicklung. Linus hat noch viele andere Interessen und hat sich in den Foren schon länger ziemlich rar gemacht. Das ist natürlich auch absolut sein gutes Recht; aber aus meiner Sicht ist jedenfalls nicht klar, wieviel Zeit er in die weitere Entwicklung stecken wird. Der Quellcode ist zwar offen, aber ob sich da wirklich jemand anderes so einfach reinfuchsen wird?

-- Michael

Hannes:

eine Bestandsaufnahme der Schreibmöglichkeiten auf Deutsch

Danke für das lostreten dieses Themas!

StJohn Limbo:

Ansonsten hätte ich prinzipiell auch kein Problem damit, auf TADS umzusteigen, nur dass da leider ja die Zukunft/Weiterentwicklung etwas unklar ist. Ich meine, okay, das System ist bewährt und läuft bereits sehr gut und ich bin keiner, der jeden Monat nur aus Prinzip ein Update braucht -- aber falls doch mal ein Bug auftaucht oder das Zusammenspiel mit neueren Betriebssystem-Versionen aus irgendwelchen Gründen schwierig würde, wäre es schon nett zu wissen, dass es Updates gäbe.

Mein Hauptzweifel ist gar nicht mal so sehr auf der Autoren-, sondern auf der Spielerseite. Ich persönlich habe nicht einmal mehr einen TADS-Interpreter installiert, weil man's halt nie mehr braucht.

Erwähnenswert ist vermutlich auch noch:

• Adventuron: https://adventuron.io Das ist ziemlich neu (seit 2020?) und recht beliebt (mein Eindruck). Es ist einfach gestrickt, erlaubt Grafik und Sound und lässt sich auch für verschiedene alte Plattformen exportieren (Amstrad CPC, C64, ZX Spectrum). Es gibt wohl noch keine deutsche Variante, die wäre aber anscheinend auch nicht sehr schwer zu erstellen (https://adventuron.io/documentation/#LanguageSupport).

Hannes:

Andererseits, wenn man die den letzten GP anschaut: Ist das überhaupt noch relevant? Sechs Spiele, sechs Entwicklungssysteme. Brauchen wir überhaupt noch das eine?

Es zeigt sich ja schon, dass ein Großteil der Entwicklung dann für einen proprietären Parser draufgeht, der dann natürlich nicht allen Ansprüchen genügt. Kommt dem Autor dann auch noch die Idee, ein zweites Spiel zu entwickeln, liegt der Wunsch nach einem Framework natürlich auf der Hand. Das habe ich ja nun auch durchlebt... Ich werde auf jeden Fall Heretic.InteractiveFiction als eigenständiges Framework weiter entwickeln, einfach weil es mir Spaß macht. Mal schauen, wo es noch hinführt

Ich werde auf jeden Fall Heretic.InteractiveFiction als eigenständiges Framework weiter entwickeln, einfach weil es mir Spaß macht. Mal schauen, wo es noch hinführt

Ich nehme an, wir reden von einem Framework, bei dem die Spiellogik in C# Code geschrieben ist? Mir gehts ansonsten ähnlich: Ich pflege meinen selbstgestrickten Code, solange ich da Spaß dran habe. Es ist kein vollständiges Framework und beabsichtigt auch nicht, eins zu werden.

Andererseits, wenn man die den letzten GP anschaut: Ist das überhaupt noch relevant? Sechs Spiele, sechs Entwicklungssysteme. Brauchen wir überhaupt noch das eine?

Aus meiner Sicht macht eine derartig unübersichtliche Lage es ja nicht gerade erfolgversprechender, wenn man sich auch noch verzettelt. Insofern macht es glaube ich sehr viel Sinn, sich möglichst auf ein System zu fokussieren. Inform 7 finde ich ja schon faszinierend, muss ich sagen.

StefanH:

Insofern macht es glaube ich sehr viel Sinn, sich möglichst auf ein System zu fokussieren. Inform 7 finde ich ja schon faszinierend, muss ich sagen.

Hallo,

um auch zu dem spannenden Thema zu schreiben: Ich bewundere ja schon Leute, die nicht nur ein Spiel programmieren, sondern gleich noch das ganze System darum, was mir einfach zu viel Aufwand wäre.

Mir ging es aber in der Corona-Zeit genau so: Ich wollte mal wieder eine neue Programmiersprache lernen und da ich schon immer gerne Textadventures gespielt habe, dachte ich, dass eine solche Sprache ganz witzig wäre. Und gerade Inform 7 mit seinem "natürlichsprachlichen" Ansatz fand ich super-faszinierend, auch wenn ich TADS3 als Sprache und mit der Erweiterung G-TADS auch interessant fand (Dialog kannte ich damals nicht). Und so hatte ich damals auch ein Spiel programmiert, da man am Besten eine Sprache beim Schreiben lernt.

Und es macht eine Menge Spaß in Inform7 zu schreiben, allerdings würde ich mir heute kleine Makros schreiben, die sehr repetative Anweisungsketten abkürzen würden, in etwa wie:

The Tapestry is scenery in the anteroom. The printed name of tapestry is "Wandteppich[m]". Understand "Wandteppich", "teppich", "unscheinbar" as tapestry. The description of tapestry is "Ein uscheinbarer Wandteppich, nichts weiter.".

abgekürzt würde durch z.B.:

Tapestry/Wandteppich[m] scenery in Anteroom (Teppich, unscheinbar). "Ein unscheinbarer Wandteppich, nichts weiter."

(klar ginge das in Inform7 auch kompakter, aber ich hatte mich für eine Programmierung in Englisch mit deutschen Übersetzungen der Wörter entschieden.)

Insgesamt hat man halt das Gefühl, dass sich zu Z-Code immer ein Interpreter finden wird (und wenn es ein Stift ist, der in Laufschrift Zork I-Antworten gibt). Alles andere wird etwas schwieriger: So gibt es, um nur mal ein Beispiel zu nennen, auf dem Android gleich mehrere Interpreter für Z-Code (u.a. "Text Fiction", den ich großartig finde), aber zu TADS3, Adrift, Hugo, etc. (und Glulx) wird es sofort sehr wenig (meines Wissens nur "Fabularium"). Das ist natürlich auch ein Punkt, den man als Autor eines Textadventures im Kopf haben sollte.

Heiko:

Insgesamt hat man halt das Gefühl, dass sich zu Z-Code immer ein Interpreter finden wird

Sehr guter, und wichtiger Punkt. Ich fand es beispielsweise vor ein paar Monaten witzig, als hier ein Betatester mit den Worten "keine besonderen Systemanforderungen, nur Windows" gesucht wurde.

Sehr guter, und wichtiger Punkt. Ich fand es beispielsweise vor ein paar Monaten witzig, als hier ein Betatester mit den Worten "keine besonderen Systemanforderungen, nur Windows" gesucht wurde.

Klingt so, als bezögest du das auf ein Posting von mir. Dazu das kleine Addendum, dass ich da gerade angefangen habe, meine Software so umzustricken, dass sie auch auf anderen Systemen läuft (iOS, Android, MacOs und in einiger Zeit hoffentlich auch auf Linux). Das ist noch ein Abenteuer mit ungewissem Ausgang, einfach basierend darauf, dass das .NET Framework zunehmend plattformübergreifend eingesetzt werden kann. Eine relativ große Plattform-Unabhängigkeit kriegt man also mittlerweile auch mit selbstgebastelten Lösungen hin.

The Tapestry is scenery in the anteroom. The printed name of tapestry is "Wandteppich[m]". Understand "Wandteppich", "teppich", "unscheinbar" as tapestry. The description of tapestry is "Ein unscheinbarer Wandteppich, nichts weiter.".

Und da geht sie dahin, die Natürlichsprachlichkeit. Ok, sie wurde eindeutig ein Opfer des Deutsch/Englisch-Mischmasches, insofern vielleicht kein ganz fairer "Vorwurf" für ein englischsprachiges System, dem man immerhin die Möglichkeit angeflanscht hat, es auch (mit sichtbaren Verrenkungen) auf Deutsch zu nutzen.

Was mich tatsächlich brennend interessiert: Bleibt das Ganze dann bei steigender Komplexität immer noch übersichtlich? Blickt man in diesem Fließtext noch durch, wenn man erst mal ganz viel davon hat? Bewährt sich diese Methodik der Logik-Beschreibung? Oder wünscht man sich dann doch manchmal Inform 6 zurück?

StefanH:

Und da geht sie dahin, die Natürlichsprachlichkeit.

;) . Stimmt, guter Punkt. Ich denke, wenn man ein englischsprachiges Spiel schreibt, wirkt das dann doch eleganter.

StefanH:

Was mich tatsächlich brennend interessiert: Bleibt das Ganze dann bei steigender Komplexität immer noch übersichtlich? Blickt man in diesem Fließtext noch durch, wenn man erst mal ganz viel davon hat? Bewährt sich diese Methodik der Logik-Beschreibung? Oder wünscht man sich dann doch manchmal Inform 6 zurück?

Ich fand das ganze erstaunlich übersichtlich. Das liegt aber vor allem daran, dass Inform7 einem gute Möglichkeiten gibt, den Code zu gliedern und man ist dank der "Natürlichsprachlichkeit" auch sofort wieder in dem drin, was man geschrieben hatte. Im Grunde ist am Ende doch nur alles Deklaration, ein paar Variablen, If-then-else und Schleifen (und halt Text).

Man muss ein System für sich finden, alles gut zu ordnen und zu gliedern. So gab es bei mir Abschnitte, die sich auf das ganze Spiel bezogen (neue Verben, Mechaniken, "globale" Variablen) und dann Kapitel, in denen dann die einzelnen Orte beschrieben wurden, wiederum mit "lokalen" Mechaniken, etc., wobei die Teilbereiche wiederum alle gleich gegliedert wurden. Ob ich in den Code allerdings in 1-2 Jahren nochmal reinkomme, wäre dann die nächste Frage.

Zu Inform6 kann ich nicht viel sagen, da ich mich damit nicht wirklich beschäftigt habe (außer mal ein paar Code-Schnipsel eingebaut, wenn es gar nicht anders ging). Aber klar: Inform7 ist sehr tippaufwendig, dafür hatte ich aber das Gefühl besser im Fluß zu bleiben, statt ständig diverse Klammerzeichen, etc. eintippen zu müssen (aber ich denke, das ist jetzt ganz subjektiv und hängt von den jeweiligen Gewohnheiten ab. Ich hatte es als gute Auffrischungsübung im sauberen 10-Finger-Tippen gesehen).

Heiko: [...] allerdings würde ich mir heute kleine Makros schreiben, die sehr repetative Anweisungsketten abkürzen würden

Da werfe ich doch mal den Link zum Informisator in die Runde. Leider ist der I7-Code, der dort erzeugt wird, auf einem sehr alten Stand und in der Denglisch-Variante, die ich eigentlich nicht empfehle.

(Ich dachte ja, dass sich keine Sau für den Informisator interessiert und wollte schon damit kokettieren, dass es nur zwei Google-Treffer für "Informisator" gibt, nämlich den Informisator selbst und den Forums-Post, in dem er angekündigt wurde. Mittlerweile gibt es aber mindestens einen weiteren Treffer, einen intfiction.org-Post zu I6-Ressourcen für Spiele, die nicht auf Englisch sind. Danke also an StJohn Limbo, der, das möchte ich betonen, keine Sau ist.)

Auf einem Nebensektor meiner Festplatte liegen auch noch die Anfänge eines Projekts namens J6. (J6 ist eine Weiterentwicklung von I6, aber in eine andere Richtung als I7.)

Es ist eigentlich nur ein Präprozessor, der nach dem Muster des Informisators Daten für einen eigenen Parser erzeugt. Der Wandteppich könnte dann zum Beispiel so aussehen:

Prop tapestry in Anteroom
    !> der Wand=teppich
    !> der unscheinbare Wand=behang
    !> das grüne Paisley-Muster
    with description "Der unscheinbare grüne Wandteppich
        hat ein Paisley-Muster."
    with before
        looking_behind "Da ist nichts."
    ;

Sehr gut finde ich an I7 den regelbasierten Ansatz. Dass man dadurch sehr generische Mechaniken formen kann, ohne in jedes Objekt reinzugehen und immer und immer wieder Ähnliches reinzupasten.

Die „Natürlichsprachigkeit“ (schon dieses Label ist ja Unsinn; als wäre nicht jede Hochsprache, ja sogar jeder Assembler „natürlichsprachig“) ist dagegen ganz, ganz schlimm. Nicht nur wegen des Tippaufwandes, sondern vor Allem hatte ich niemals das Gefühl wirklich eindeutig sicher sein zu können, was ein gerade geschriebener „Satz“ wirklich bewirken wird. Die Syntax (etwas anderes ist es ja letztlich auch nicht) ist zu uneindeutig, nicht gut genug dokumentiert und, und, und…

Letzteres, sowie die faktische Unmöglichkeit, mit I7 noch ein Spiel im Z-Code-Format zu machen (siehe Portabilität oben), haben mich nach zwei Spielen davon wieder wegziehen lassen.

Martin:

Da werfe ich doch mal den Link zum Informisator in die Runde.

Danke für den Link. So etwas hätte schon geholfen (wobei ich auch nicht die Denglish-Variante benutzt habe in meinem Spiel damals).

Martin:

Prop tapestry in Anteroom
    !> der Wand=teppich
    !> der unscheinbare Wand=behang
    !> das grüne Paisley-Muster
    with description "Der unscheinbare grüne Wandteppich
        hat ein Paisley-Muster."
    with before
        looking_behind "Da ist nichts."
    ;

Ja, so etwas hat schon etwas, zumal man die einzelnen Eigenschaften und Dinge, die man standardmäßig mit so einem Gegenstand machen würde, gleich schön übersichtlich geschachtelt hat. Bei Inform7 können diese, wenn man sich nicht an eigene Konventionen hält, ja schnell munter über den ganzen Quelltext verteilt sein.

Olaf: Erwähnenswert ist vermutlich auch noch: Adventuron Das ist ziemlich neu (seit 2020?) und recht beliebt (mein Eindruck). Es ist einfach gestrickt, erlaubt Grafik und Sound und lässt sich auch für verschiedene alte Plattformen exportieren (Amstrad CPC, C64, ZX Spectrum).

Ah, das kannte ich noch gar nicht, danke. Das setzt ja schon sehr auf die Retro-Karte. Es ist aber klar, weshalb es beliebt ist: Grafik ud Sound ziehen halt und man kann die Spiele auf itch.io hochladen, wo man sie direkt im Browser spielen kann und so ein breites Publikum hat. (Es ist allerdings nicht leicht, aus der Menge der Spiele die Handvoll guter herauszulesen.)

Es gibt wohl noch keine deutsche Variante, die wäre aber anscheinend auch nicht sehr schwer zu erstellen

Hm, da bin ich skeptisch. Man kann zwischen einem reinen Zwei-Wort-Parser und einem "komplexen" Parser auswählen. Der komplexe Parser zieht sich aber nur die wichtigen Wörter heraus und schweigt über das, was er nicht versteht. Es können zwar zwei Objekte und auch eine Präposition verstanden werden, aber die Hauptmethode "match" prüft nur Verb und ein Objekt.

Es sind auch nur wenige Standard-Aktionen (gehen, nehmen und ablegen, öffnen und schließen sowie auf- und abschließen) umgesetzt, alles andere muss man selbst implementieren und dabei jedesmal die Gültigkeit prüfen, weil es nur Suchmuster, kein verallgemeinertes Konzept einer Aktion gibt. Also wenn der Befehl "grabe im Sand" ist, muss der Autor selbst prüfen, ob der Sand da ist und ob der Spieler eine Schaufel hat. Das wird meistens in der Form "wenn Sand hier und Spieler hat Schaufel: Bingo!" gemacht, so dass alle Versuche, die daneben gehen mit dem etwas generischen "Das geht nicht" beschieden werden, auch wenn sie nur knapp gescheitert sind.

Es reicht nicht, die angegebenen Texte zu übersetzen. Es gibt auch viele Stolpersteine: Umlaute und Eszett werden erkannt. Manchmal. In der Liste der Ausgänge steht zum Beispiel "SüDen". Ich nehme an, das D wird groß geschrieben, weil das ü für die Routine, die Wörter am Anfang groß schreibt, kein Buchstabe ist und deshalb bei D ein neues Wort beginnt.

Soweit ich das sehe, hat man auch keine Möglichkeit, die Eingabe zu bearbeiten, so dass man immer alle Adjektiv- und Verbformen angeben müsste. Präpositionen müssen explizit überprüft werden. Man kann schnell match("mache X") prüfen, muss dan aber genau schauen, ob es "auf", "zu", "an", "aus" oder "kaputt" heißt. Das alles passiert in einem monolithischen Block. Es ist auch mühsam, generische Texte ("[Der obj] [ist] zu weit weg.") zu schreiben. Nach jeder print-Anweisung beginnt ein neuer Absatz, so dass man sich variable Ausgaben kleinteilig zusammenstückeln muss.

Hannes: Quest/HUGO/ADRIFT: meines Wissens nicht auf Deutsch nutzbar

Für Quest gibt es eine Vorlage auf Deutsch. The Shard (Alpha) wurde mit Quest geschrieben.

Quest und Adventuron sind sich in einigen Dingen sehr ähnlich. Mit Adventuron schreibt man Adventures in einem Browser-Editor mit automatischer Textvervollständigung in einer JSON-artigen Syntax. In Quest klickt man sich in einem Windows-GUI ein Spiel in einer XML-Syntax plus Scriptsprache zusammen. Adventuron-Spiele werden auf itch.io veröffentlicht, Quest-Spiele auf textadventures.co.uk.

Beide Systeme setzen das Augenmerk auf das Erscheinungsbild, auf Grafiken, auf Sound und auf Musik. Beide Systeme vermitteln das Flair der Spiele aus den frühen 80ern. Beide Systeme haben ein zweistufiges Konzept: Wenige Kernbefehle sind detailliert umgesetzt, weniger oft benutzre Befehle werden mit einem einfachen Abgleich umgesetzt. (In Quest werden dazu oft reguläre Ausrücke hergenommen.)

Man kann gewiss ordentliche Spiele in beiden Systemen schreiben, vielleicht sogar auf Deutsch, aber man müsste schon einige Verrenkungen machen, um die Unzulänglichkeiten zu umgehen.

Da ja in der Diskussion Systeme gesammelt werden, die lokalisiert werden können, möchte ich der Vollständigkeit halber noch Cruescript zu der Liste hinzufügen.

Der Ansatz, Text-Adventures zu schreiben, die nur über Buttons bedient werden und damit für jedes Smartphone bestens geeignet sind, finde ich zumindest spannend (klar geht da viel von dem Charme und der Unberechenbarkeit eines echten Parser-Spiels verloren) und eine Lokalisation ist in dem Zusammenhang wesentlich einfacher (man gibt ja keine Sätze ein). Zusätzlich wird wohl eine Lokalisation von Cruescript selbst unterstützt (Lokalisations-Tabelle, bzw. hier als Forums-Thema auf IntFiction.org).

Heiko: [...] möchte ich der Vollständigkeit halber noch Cruescript zu der Liste hinzufügen.

Ah, Gruescript. Auch das kannte ich noch nicht. (Crüescript ist ein Programm, mit dem man über Markow-Ketten Texte für Heavy-Metal-Songs erstellen kann ;).)

Bei den ganzen Referenzen zu Zork und Colossal Cave ist es kein Wunder, dass das Genre so fest in den Achtzigern verhaftet ist. Das scheint ja auch hier wieder so zu sein: Das Beispiel The Party Line hat hellgrauen Text auf mittelblauem Grund, der in einer Vektorvariante der C64-Schrift dargestellt wird.

Aber ja, da es ja keinen Parser im eigentlichen Sinne gibt, müsste man so etwas leicht lokalisieren können.

Hannes: Ein Muster, das sich herausbildet: Wir werden abgehängt und damit inkompatibel mit dem Rest der Welt.

Hm. Waren wir überhaupt schon einmal kompatibel mit der Welt? Ich habe ja den Eindruck, dass "wir" immer schon unser eigenes Süppchen gekocht haben.

Eine Kompatibilität ist ja nur dann nötig, wenn man sie auch nutzt, indem man zum Beispiel Spiele aus anderen Sprachen übersetzt. Das passiert aber selten.

(Bei den Textadventures gab es wohl immer schon zwei Welten: Die deutschsprachige, in der dann nicht Zork, sondern Das Dachental und die Spiele der Weltenschmiede zum Kanon gehören und die englischsprachige, in der es viel mehr Klassiker gibt und die natürlich viel größer ist, weil Englisch so verbreitet ist.)

Eine Kompatibilität ist ja nur dann nötig, wenn man sie auch nutzt, indem man zum Beispiel Spiele aus anderen Sprachen übersetzt. Das passiert aber selten.

Die Henne-und-Ei-Diskussion brauchen wir jetzt aber nicht zu führen, oder?

(Bei den Textadventures gab es wohl immer schon zwei Welten: Die deutschsprachige, in der dann nicht Zork, sondern Das Dachental und die Spiele der Weltenschmiede zum Kanon gehören und die englischsprachige, in der es viel mehr Klassiker gibt und die natürlich viel größer ist, weil Englisch so verbreitet ist.)

Das halte ich für sehr kurzgegriffen. Weltenschmiede war doch eine deutliche Antwort auf / Imitation von Magnetic Scrolls. Das erste deutsche Adventure, das ich gespielt habe, war Der Stein der Weisen. Das würde ich heute als Adventureland-Kopie bezeichnen.

Die Henne-und-Ei-Diskussion brauchen wir jetzt aber nicht zu führen, oder?

Nein, brauchen wir nicht. Aber als die I6- und I7-Übersetzungen auf Deutsch noch aktueller waren, sind ja auch wenige Übersetzungen erschienen. Mir fällt eigentlich nur Marius Müller ein, der das ein paarmal gemacht hat.

Das [meine Behuptung, dass deutsche und englische Textadventures getrennte Welten sind] halte ich für sehr kurzgegriffen.

Natürlich haben die deutschen Textadventures versucht, die damals erfolgreichen Originale zu kopieren, aber das betrifft ja nur das Konzept. Die Spiele selbst waren ja keine Übersetzungen, sondern eigene Geschichten.

Das war ja bei den Grafikadventures ganz anders: Da wurden sehr viele Sachen für den deutschen Markt übersetzt und von deutschen Entwicklungen wurden auch anderssprachige, mindestens englische Versionen erstellt.

(Weil die Steuerung der Spiele nicht mehr Texteingabe war und daher nicht mehr der Sprache angepasst werden musste, ließen sich diese Spiele aber auch einfacher übersetzen. Seit Sprachausgabe die Norm ist, geht die Anzahl der Sprachen, in die ein Adventure übersetzt wird, nach meiner Einschätzung wieder zurück, weil der Aufwand einer Übersetzung wieder gestiegen ist.)