Hat sich damit schonmal jemand auseinandergesetzt? Klingt vom Ansatz her sehr gut, gefällt mir besser als diese kompletten „Retro“-Entwicklungssysteme (DAAD und Konsorten). Wie ist es so zum Programmieren? Wie sieht es mit Übersetzbarkeit aus?

https://github.com/johanberntsson/PunyInform

Meine ersten Eindrücke:

• Programmiert sich sehr ähnlich wie mit der Standard-Inform-6-Bibliothek

• Sobald man komplexere Manipulationen machen möchte, gibt es grundlegende, aber nachvollziehbare Unterschiede

• Cheap Scenery: geiler Mechanismus für irrelevante Schmuckobjekte

• Absolut keine impliziten Aktionen werden standardmäßig ausgeführt. Will ein Spieler vom Wohnzimmer ins Schlafzimmer gehen, sitzt aber noch auf dem Sofa, wird ihm gnadenlos gesagt, er solle gefälligst erst vom Sofa aufstehen. Solche Komfortfunktionen muss man selbst programmieren.

• Die herausgenommenen Verben sind tatsächlich eher sinnlos, also kein großer Verlust. Bei wirklichem Bedarf kann man sie ja wieder einbauen.

• Einige Mechaniken hätte man meiner Meinung nach verlustlos auch noch streichen können. Wer braucht heute noch Dunkelheit oder ein Inventarlimit?

• Library-Messages können relativ einfach überschrieben werden, aber damit wäre eine Übersetzung ja nicht getan…

Das würde dann erfordern, sich mal ausführlich mit der Library auseinanderzusetzen und zu überlegen, was man weglassen kann.

Nur durch das Weglassen lässt sich eine deutliche Reduzierung der Speicherverwendung erreichen, was ja das Ziel von PunyInform ist, um die Spiele auch auf alter 8-Bit Hardware zum Laufen zu bekommen.

Hmm, aus meiner Sicht:

• ae / oe usw. Ersetzungen unabdingbar

• abschneiden von Wortenden (-en, -e, -es usw.) unabdingbar

wo man aber ansetzen könnte:

• Infinitvform ("den stein nehmen") - muss nicht sein

• Die vielen Verb-Synonyme - muss auch nicht sein, das kann der Autor, sofern sein Spiel entsprechend "klein" ist auch selbst ergänzen, genauso wie das automatische Aufstehen usw. was ja sowieso schon gekürzt wurde

Was ich bisher herausgefunden habe:

Wenn .z3 das Ziel ist, kann vermutlich die Statusanzeige nicht geändert werden. Jegliches Jonglieren mit dem Parser ist wegen der fehlenden @tokenize routine unmöglich, also kein Abschneiden von Endungen, keine Textersetzungen von ä und ö, keine Manipulation der Eingabe. Das macht es für den Autor sehr schwer, denn niemand möchte 4 verschiedene Adjektiv-Formen händisch anlegen.

Bei .z5 dürfte eigentlich alles, was Deform macht, auch für PunyInform umsetzbar sein. Wie dann allerdings die Dateigröße im Vergleich zur regulären Lib aussieht und ob dann tatsächlich soviel Speicher gespart werden kann, ist fraglich.

Ok, ist dann wohl doch eher ein Monolog :-)

Nur zur Info: die "cheap" scenery gibt's schon lange.

"scenic.t" heißt die Erweiterung für die Standard-Lib.

Mikawa:

Wenn .z3 das Ziel ist, kann vermutlich die Statusanzeige nicht geändert werden. Jegliches Jonglieren mit dem Parser ist wegen der fehlenden @tokenize routine unmöglich, also kein Abschneiden von Endungen, keine Textersetzungen von ä und ö, keine Manipulation der Eingabe. Das macht es für den Autor sehr schwer, denn niemand möchte 4 verschiedene Adjektiv-Formen händisch anlegen.

Bei .z5 dürfte eigentlich alles, was Deform macht, auch für PunyInform umsetzbar sein. Wie dann allerdings die Dateigröße im Vergleich zur regulären Lib aussieht und ob dann tatsächlich soviel Speicher gespart werden kann, ist fraglich.

Das deckt sich mit den Aussagen/Interpretationen unserer französischen Kollegen. Ich sehe es so: Selbst, wenn man ein Spiel auf Deutsch doch nur auf Z5 bringt, könnte man eine englische Version dann in Z3 herausbringen. Bei "kleineren" Plattformen würde ich ohnehin mit Zeichensatzproblemen usw. rechnen.

Zitat:

Ok, ist dann wohl doch eher ein Monolog :-)

Na ja, deine erste Antwort ließ beinahe ein volles Jahr auf sich warten – insofern ist Kritik jetzt glaube ich nicht angebracht

Ich will jetzt nicht nörgeln, aber mir entgehen die Vorteile, soweit es jetzt nur um cheap scenery oder einige irrelevante Verben geht. Auf Github wird dargestellt, dass die directions anders behandelt werden oder die library messages anders angepasst werden können, öffentliche Beiträge darüber betonen die "smaller, faster library", was heute keine Rolle mehr spielt. Das Coding scheint weitgehend identisch zu I6 zu sein. Daher eine simple Verständnisfrage: Warum sollte man sich mit PunyInform auseinandersetzen?

Zitat:

öffentliche Beiträge darüber betonen die "smaller, faster library", was heute keine Rolle mehr spielt.

Aus deiner Sicht, ja. Aber es gibt seltsamerweise mittlerweile gefühlt mehr Spieler, die gerne Textadventures auf einem C64-Emulator spielen, als mit einem Z-Code-Interpreter.

Puny geht da genauso wie Inform-Z5 über Ozmoo Online

http://microheaven.com/ozmooonline/

Wenn es um das Retrofeeling geht, könnte Puny seine Stärken haben, ich kenne das so nicht. Aber why not.

Da machst du es dir zu einfach. Wenn ich Die schwarze Lilie (Z5) entsprechend zu verpacken versuche, geht das erstmal nicht mit dem normalen Diskettenformat - das Spiel ist bereits zu groß. Verwende ich ein Spezialimage, dann läuft es. Dann verschluckt er alle Umlaute. Also nochmal bauen mit deutschem Font. Juhu, einen Schritt weiter! Allerdings bleiben die Ladezeiten inakzeptabel. Bis sich nach dem Introtext die erste Raumbeschreibung aufbaut, sind mal locker 30 Sekunden vergangen. Testbefehl SCHAU MICH AN: 1,5 Minuten bis zur Antwort!

Wow, ein geradezu kulturhistorischer Thread. Gibt es für Retro-Diskimages überhaupt ein nennenswertes Publikum oder Apps? Ich tickere ja auch ab und zu alte Diskimages durch, stamme aber aus den 80ern und habe das Sitzfleisch, die technischen Probleme bis zum Start der Spiele zu lösen. Das macht doch heute keiner mehr...

Einen C64/Spectrum/...-Emulator haben um mehrere Größenordnungen mehr Leute installiert als einen Z/Glulx/TADS-Interpreter.

Ich wollte mir eigentlich einen ZX Spectrum next besorgen, aber die sind derzeit ausverkauft :-(

Nachdem in einem anderen Thread diskutiert wurde, ob eine deutsche Übersetzung von PunyInform wünschenswert ist, habe ich mir die Argumente hier noch einmal durchgelesen.

Mikawa: Jegliches Jonglieren mit dem Parser ist wegen der fehlenden @tokenize routine unmöglich, also kein Abschneiden von Endungen, keine Textersetzungen von ä und ö, keine Manipulation der Eingabe. Das macht es für den Autor sehr schwer, denn niemand möchte 4 verschiedene Adjektiv-Formen händisch anlegen.

Das ist ein guter Punkt, den ich nicht bedacht hatte, als ich mich in der anderen Diskussion optimistisch gezeigt hatte, was eine Übersetzung angeht.

Unmöglich ist das aber natürlich nicht. ;)

Ich habe einmal ein kleines Testprogramm für die Version 3 der Z-Maschine geschrieben, das nichts anderes macht, als die Eingabe zu zerlegen und zu analysieren. Mit etwas Nacharbeit kann man die Version 3 schon dazu bringen, Umlaute zu verstehen und Adjektivendungen zu ignorieren.

Weil man natürlich das, was eigentlich der Interpreter machen soll, nachprgrammieren muss, wird es auf dem C64 aber immer noch langsam sein. Der Code dafür plus Hilfsfelder ist in der Spieldatei weniger als ein Kilobyte.

Quelltext für Inform 6.

Martin:

Mikawa: Jegliches Jonglieren mit dem Parser ist wegen der fehlenden @tokenize routine unmöglich, also kein Abschneiden von Endungen, keine Textersetzungen von ä und ö, keine Manipulation der Eingabe. Das macht es für den Autor sehr schwer, denn niemand möchte 4 verschiedene Adjektiv-Formen händisch anlegen.

Das ist ein guter Punkt, den ich nicht bedacht hatte, als ich mich in der anderen Diskussion optimistisch gezeigt hatte, was eine Übersetzung angeht.

Meinem Gefühl nach ist bei PunyInform gerade mehr Bewegung als bei jedem anderen IF Framework. Vllt kann man bei den Verantwortlichen ja mal Fragen, ob die nötigen Routinen da irgendwann mit reinkommen (könnten)? (Ich könnte das auch übernehmen, würde damit aber vermutlich nur ein Stille-Post-Spiel anfangen.) Wenn ich das richtig sehe sind die aus Schweden, die haben da doch selbst jede Menge Sonderzeichen...

Ach, ich weiß nicht. Der Code ist mehr so ein proof of concept, um zu zeigen, dass eine Nachbehandlung der Eingabe auch ohne @tokenise schon irgendwie ginge. PunyInform ist aber für Anwendungen auf 8-Bit-Computern gedacht und ich kann mir vorstellen, dass der Code auf einen C64 oder Spektrum langsam ist.

(Ich habe mittlerweile eine durchgängige Intervallschachtelung umgesetzt. Beide Varianten laufen auf dem PC mit einem Wortschatz von etwa 500 Wörtern so schnell, dass man es nicht merkt. Erst wenn ich den Satz hunderttausendmal untersuche, vergeht eine Sekunde. Ich weiß aber nicht, wie man die Zeit, die eine Anweisung braucht, auf der Z-Maschine am besten misst, damit man Code optimieren kann. Vielleicht muss ich doch Ozmoo auf dem C64-Emulator verwenden, wo man dann langsame Operationen mit der Uhr stoppen kann.)

Aber selbst, wenn man Umlaute und Endungen erkennen kann, hat z3 immer noch viele Einschränkungen: Wörter können nur sechs Zeichen lang sein und man kann nur bis zu vier Wörter angeben, wenn man keinen parse_name verwendet.

Mit PunyInform selbst habe ich mich noch nicht weiter befasst.

Moin, sorry wenn ich erst spät zum Thread hinzustoße aber ich wusste bis heute noch nicht mal dass es dieses Forum gibt

Hannes:

Hat sich damit schonmal jemand auseinandergesetzt?

Ja, Puny ist aus meiner Sicht das derzeit (Stand 2023) beste und innovativste System, wenn man beabsichtigt anspruchsvolle Adventures für klassische 8-bit und 16-bit Systeme zu schreiben. Ich war quasi User Nummer 1 des Systems und habe mitgewirkt es zu dem zu machen was es heute ist. Ich bin so ziemlich im täglichen Austausch mit Fredrik, einem der Hauptautoren von PunyInform. Grundsätzlich sei hier aber zu berücksichtigen: wer ist meine Zielgruppe? Beabsichtige ich auch die Retro-Fanbase zu beglücken, sollte man zu Puny greifen. Was dafür spricht, dazu komme ich später. Ist mir die Retroszene egal, dann bin ich auch mit der Standard Library gut aufgehoben, weil ich mir um Performance keine Gedanken machen muss. Auf einem modernen Computer läuft selbst so ein Ungetüm wie Inform 7.

Wie ist es so zum Programmieren?

Puny verhält sich fast genau wie die Inform Standard Library, bis auf wenige Ausnahmen. System Messages werden anders modifiziert, auf Dinge wie ParserError oder Tokenization muss man verzichten, ansonsten gibt es nicht viel was man nicht auch mit PunyInform erreichen kann. Dafür ist der Memory Footprint aber viel kleiner als beim Inform Standard Library. Die Performance von einem Puny Spiel ist equivalent zu einem Spiel was in ZIL geschrieben wurde.

Wie sieht es mit Übersetzbarkeit aus?

Durchwachsen würde ich sagen. Der Sprachanteil in Puny ist nicht so modular aufgebaut wie bei dem Inform Standard Library. Eine Übersetzung ist aber möglich. Ich arbeite gerade an einer Übersetzung, jedoch anders als Du ggf. denken würdest. Ich programmiere ein Python Utility, welches gezielt nach den definierten Strings, Grammars und Logiken sucht und diese dann entsprechend eindeutscht. Das hat den Vorteil, dass ich mit jedem neuen Puny Relese relativ schnell das ganze Library wieder auf Deutsch bekomme und Backporting entsprechend wegfällt. Das Python Utility wird Bestandteil des offiziellen Puny Repository wenn es fertig ist. Kann aber noch eine Weile dauern weil ich gerade noch an zwei Spielprojekten arbeite, welche leider ein wenig Aufmerksamkeit fordern.

Absolut keine impliziten Aktionen werden standardmäßig ausgeführt. Will ein Spieler vom Wohnzimmer ins Schlafzimmer gehen, sitzt aber noch auf dem Sofa, wird ihm gnadenlos gesagt, er solle gefälligst erst vom Sofa aufstehen. Solche Komfortfunktionen muss man selbst programmieren.

Das ist mittlerweile nicht mehr der Fall. Ein Mindestmaß an Inference wird durchgeführt, zum Beispiel: (taking the object first). Für komplexe Inference muss man selbst Hand anlegen, finde ich aber nicht weiter schlimm, denn so hat Infocom das auch damals gemacht, zudem ist das im Inform Standard Parser nicht immer ganz stimmig.

Einige Mechaniken hätte man meiner Meinung nach verlustlos auch noch streichen können. Wer braucht heute noch Dunkelheit oder ein Inventarlimit?

Jemand der Spiele nahe an den Vorbildern von Infocom schreiben möchte und dem anachronistische Spielmechaniken wichtig sind, was so ziemlich auf die komplette Entwicklerzielgruppe von Puny zutrifft.

Mikawa:

ae / oe usw. Ersetzungen unabdingbar

Kommt darauf an aus welchem Blickwinkel man dies betrachtet. Puny ist primär zur Ausführung auf Retrohardware gedacht. Nehmen wir mal den C64 als Beispiel. Der wurde auch auf dem deutschen Markt mit einer englischen Tastatur herausgebracht. Umlaute sucht man dort vergebens, kann diese also gar nicht eingeben. Den Bildschirmtext miit einer angepassten C64 Font und entsprechendem ZSCII Charmapping auch mit Umlauten darzustellen, ist kein Problem, aber um die Eingabe von ae, ue etc. kommt man nicht herum.

Wenn .z3 das Ziel ist, kann vermutlich die Statusanzeige nicht geändert werden. Jegliches Jonglieren mit dem Parser ist wegen der fehlenden @tokenize routine unmöglich, also kein Abschneiden von Endungen, keine Textersetzungen von ä und ö, keine Manipulation der Eingabe. Das macht es für den Autor sehr schwer, denn niemand möchte 4 verschiedene Adjektiv-Formen händisch anlegen.

Das ist leider so. Die Z-Machine in der Version 3 ist stark limitiert. Ein z3 Spiel wird immer mit einer Statusleiste angezeigt, welche zuerst die Location dann die Score und die Turns darstellt. Es muss aber nicht z3 sein. Puny's Performance ist genauso herausragend wenn man das Ganze als z5 kompiliert. Mittlerweile gibt es für alle wichtigen Retrosysteme auch einen z5-fähigen Interpreter. Den z3 Weg muss man also nicht gehen. Mit meinen Puny BuildTools kann ich zudem den Prozess automatisieren und innerhalb weniger Sekunden jede Menge Retro-Diskettenimages heraushauen.

Bei .z5 dürfte eigentlich alles, was Deform macht, auch für PunyInform umsetzbar sein. Wie dann allerdings die Dateigröße im Vergleich zur regulären Lib aussieht und ob dann tatsächlich soviel Speicher gespart werden kann, ist fraglich

Nein, ist eigentlich nicht fraglich. Mit PunyInform erstelle ich ein z3 Spiel mit einem Raum und einem Objekt mit ca. 23kb, ein z5 Spiel mit Puny hat ca. 26kb, also 3kb mehr. Mit dem Standard Library geht der Spaß bei 100kb los und durch den komplexen Parser ist selbst das kleinste Spiel nicht Spielbar (Reaktionszeiten von über einer Minute etc.)

Nur zur Info: die "cheap" scenery gibt's schon lange. "scenic.t" heißt die Erweiterung für die Standard-Lib.

Jaein. Cheap_Scenery ist eine Erweiterung die speziell für Puny geschrieben wurde. "scenic.t" hat nichts mit cheap_scenery zu tun. Die Erweiterung ist im Vergleich zu Cheap_Scenery doch recht resourcenhungrig und zudem nicht auf z3 Targets lauffähig. Zudem ist der cheap_scenery Syntax deutlich angenehmer. Jüngst haben wir Cheap_Scenery erweitert, so dass das Modul nun 9 Adjektive und 9 Nomen pro Scenery Eintrag unterstützt, außerdem kann ich jedem Scenery Object eine beliebige Anzahl an Aktionsroutinen inline zuweisen, da ist jede andere Scenery Erweiterung für Inform draussen.

proc:

Wow, ein geradezu kulturhistorischer Thread. Gibt es für Retro-Diskimages überhaupt ein nennenswertes Publikum oder Apps? Ich tickere ja auch ab und zu alte Diskimages durch, stamme aber aus den 80ern und habe das Sitzfleisch, die technischen Probleme bis zum Start der Spiele zu lösen. Das macht doch heute keiner mehr...

Ähm... wow! Wenn ich einen Vergleich ziehen muss zwischen den Zielgruppen: Adventurespieler in der Retroszene sowie in der modernen IF Szene dann muss ich leider sagen: im Verhältnis zur Retroszene ist die moderne IF Szene absolut irrelevant. Nicht falsch verstehen, ich spreche hier wirklich von Quantität in der jeweiligen Zielgruppe. Man könnte auch sagen: wenn ich heute mit einem Adventure möglichst viele Spieler erreichen möchte, dann ist die Retroszene der Ort, wo die Party abgeht. Mein Spiel Hibernated 1 Director's Cut wurde bis heute über 20.000 mal via itch.io heruntergeladen und hat sich mehr als 1000 mal physikalisch verkauft. Es hat zudem zahllose Awards gewonnen, z.B. von der ZZAP!64, der Crash, der Amtix und der Reset64, außerdem haben sogar Marc Blank und Amy Briggs (ehemals Infocom) das Spiel gespielt. Mehr geht eigentlich nicht. Da kann man in noch so vielen IFComps teilnehmen. Ohne Fokus und Vermarktung über die Retro Community wären solche Zahlen niemals möglich gewesen. Auch das Fünf-Sterne-Review von MathBrush hatte abseits von Anerkennung keinen nennenswerten Impact im Verhältnis zu der Reichweite über die Liebhaber klassischer Systeme.

Martin:

Weil man natürlich das, was eigentlich der Interpreter machen soll, nachprgrammieren muss, wird es auf dem C64 aber immer noch langsam sein. Der Code dafür plus Hilfsfelder ist in der Spieldatei weniger als ein Kilobyte.

Müsste man mal testen. Wenn Du mir ein Beispieladventure schicken kannst, schau ich mir das mal gerne an. Das C64 Diskimage kann ich natürlich selbst erstellen. Es muss aber nicht zwangsläufig langsam sein. Weniger als ein Kilobyte an Z-Code Instruktionen klingt aus meiner Sicht schon mal vielversprechend. Wie schon Eingangs erwähnt ist die Anpassung der Spielereingabe über Puny allerdings zu vernachlässigen, weil viele 8-bit Computer keine Umlauttasten haben.

Olaf:

Meinem Gefühl nach ist bei PunyInform gerade mehr Bewegung als bei jedem anderen IF Framework. Vllt kann man bei den Verantwortlichen ja mal Fragen, ob die nötigen Routinen da irgendwann mit reinkommen (könnten)? (Ich könnte das auch übernehmen, würde damit aber vermutlich nur ein Stille-Post-Spiel anfangen.) Wenn ich das richtig sehe sind die aus Schweden, die haben da doch selbst jede Menge Sonderzeichen...

Das ist korrekt. Die Puny Community ist sicherlich die stärkste aktive Inform 6 Community. Für das Implementieren der Routinen würde ich mir leider nicht viel Hoffnung machen. Es hätte keinen nennenswerten Mehrwert für englischsprachige Puny User und würde den Parser nur unnötig verkomplizeren und verlangsamen. Fredrik und Johan legen größten Wert auf Performance. Auch ein schwedischer C64 hat nicht viele Sonderzeichen Wer für Retrosysteme schreiben möchte, jedoch nicht auf die Kernfunktionen des Inform-Standard Parser verzichten möchte, für den ist Puny wahrscheinlich nicht die beste Wahl. Stattdessen lohnt es sich einen Blick auf Metrocenter '84 zu werfen. Dieses Projekt hatte ich realisiert als es Puny nur auf dem Reißbrett gab. Es kommt mit dem Inform Standard Parser und ist daher weitaus kompatibler mit gewohnten Techniken wie beispielsweise ParserError. Die Cheap_Scenery Erweiterung gab es übrigens zuerst in Metrocenter '84 (heißt dort metro_scenery) bevor Fredrik den Code dann auch in PunyInform implementiert hat.

Martin:

Ach, ich weiß nicht. Der Code ist mehr so ein proof of concept, um zu zeigen, dass eine Nachbehandlung der Eingabe auch ohne @tokenise schon irgendwie ginge. PunyInform ist aber für Anwendungen auf 8-Bit-Computern gedacht und ich kann mir vorstellen, dass der Code auf einen C64 oder Spektrum langsam ist.

(Ich habe mittlerweile eine durchgängige Intervallschachtelung umgesetzt. Beide Varianten laufen auf dem PC mit einem Wortschatz von etwa 500 Wörtern so schnell, dass man es nicht merkt. Erst wenn ich den Satz hunderttausendmal untersuche, vergeht eine Sekunde. Ich weiß aber nicht, wie man die Zeit, die eine Anweisung braucht, auf der Z-Maschine am besten misst, damit man Code optimieren kann. Vielleicht muss ich doch Ozmoo auf dem C64-Emulator verwenden, wo man dann langsame Operationen mit der Uhr stoppen kann.)

100.000 mal in einer Sekunde werden wohl nicht machbar sein. Aber wie schon oben erwähnt, müssten wir mal ausprobieren.

Aber selbst, wenn man Umlaute und Endungen erkennen kann, hat z3 immer noch viele Einschränkungen: Wörter können nur sechs Zeichen lang sein und man kann nur bis zu vier Wörter angeben, wenn man keinen parse_name verwendet.

Ozmoo und viele andere Retrointerpreter können ganz prima mit z5 umgehen. Die z3 Limitierung muss also nicht sein, es sei denn ich möchte mein Spiel auf einem Exoten wie einem Kaypro zum laufen bringen. Ozmoo auf dem C64 kommt ganz hervorragend mit z5 zurecht. Der Unterschied zwischen einem Puny z3 und einem z5 game sind 3kb, das ist also absolut vertretbar. Eine maximale Z-file Größe für den C64 (wenn man ein einziges Diskettenlaufwerk verwenden möchte) ist ein Story file mit 170kb. Mit 170kb kann ich mit Puny ein sehr großes Spiel schreiben, ähnlich dem Umfang von Hitchhiker's Guide to the Galaxy, Planetfall, Lurking Horror oder einem anderen x-beliebigen Infocom Spiel. Trinity eher nicht, das ist in ZIL schon 256kb groß

Dass die Retro-Szene wesentlich größer ist als die Interactive-Fiction-Community glaube ich sofort.

Es ist nur die Frage, ob wir hier zusammenkommen. Die Retro-Leute möchten die Spiele auf alter Hardware laufen lassen und nehmen in Kauf, dass die Spiele dann auch die Einschränkungen aus der Zeit dieser Hardware haben.

Wir hier in unserem kleinen Elfenbeinturm-Forum versuchen schon, modernere Spiele zu schreiben. Nicht, dass wir damit sehr weit gekommen wären oder viel Erfolg hätten, aber das ist schon das, was uns prinzipiell umtreibt.

Eine andere Frage ist, ob man nicht versuchen könnte, die Beliebtheit der Retro-Szene für unsere Zwecke zu nutzen. Neuere Spiele sind oft nicht sehr umfangreich, vielleicht weil die meisten für Wettbewerbe geschrieben werden. Außerdem sind die Zeiten der komplexen Parser, die roboter, gehe nach norden und ziehe den bauern d2 auf d4 verstehen müssen, auch passé.

Vielleicht könnte man versuchen, ein Spiel mit modernen Standards, so wie wir es uns vorstellen, mit den Einschränkungen der Retro-Hardware zu schreiben und hoffen, dass die Retor-Szene offen ist gegenüber Spielen ohne Labyrinthe und ohne Lichtquellen, die nur 10 Züge lang brennen können.

Nur so'n Gedanke. Warscheinlich denken die Leute bei Textadventures aber eh: retro, retro, retro. Und der Trend geht auch irgendwie wieder dahin: Man programmiert wieder in ZIL. Die Adventuron-Leute rufen ein "Adventure Literacy Project" ins Leben, wo sie dann erklären, wie man alte ZX-81-Adventures spielt. Und mit Gruescript bringt man das Look-and-Feel von Scott Adams auf mobile Geräte.

[Umlaute ersetzen und Endungen abschneiden] Wenn Du mir ein Beispieladventure schicken kannst, schau ich mir das mal gerne an.

Naja, es gibt kein Beispieladventure, nur den Code, der die Ersetzungen durchführt in dem verlinkten Standalone-Storyfile, das nur eine Eingabe liest und den bearbeiteten Satz ausgibt.

Ich habe mich nicht mit PunyInform beschäftigt und plane nicht, es auf Deutsch zu übersetzen. Ich habe das gemacht, was ich immer mache: Ich habe mir ein interessantes Problem gesucht und eine Prototyp-Lösung geschrieben, damit sie jemand anderes verwenden kann. Bis jetzt hat das aber keinen so richtig interessiert.

Dass man bei vielen alten Computern gar keine Umlaute eingeben kann, stimmt zwar, aber sollte eine z3- oder z5-Datei nicht trotzdem auf modernen Rechnern spielbar sein? (Wahrscheinlich müsste man nur eine Sonderversion ohne die Umlauterkennung erzeugen und diese dann auf das Diskimage ziehen.)

Martin:

Es ist nur die Frage, ob wir hier zusammenkommen. Die Retro-Leute möchten die Spiele auf alter Hardware laufen lassen und nehmen in Kauf, dass die Spiele dann auch die Einschränkungen aus der Zeit dieser Hardware haben.

Wir hier in unserem kleinen Elfenbeinturm-Forum versuchen schon, modernere Spiele zu schreiben. Nicht, dass wir damit sehr weit gekommen wären oder viel Erfolg hätten, aber das ist schon das, was uns prinzipiell umtreibt.

Naja, Storytelling und Puzzledesign z.B. sind schon recht universell. In dieser Hinsicht könnte ein Spiel theoretisch modern sein und gleichzeitig auf Retro-Hardware laufen, da sehe ich wirklich keinen Gegensatz.

Ich persönlich bewundere das ja immer sehr, wenn Leute mit den krassen Limitierungen von alten System arbeiten und dabei teilweise wirklich beeindruckende Ergebnisse abliefern, aber für mich selbst hat das nicht sehr viel Reiz.

@Martin: Ich bin da ganz Deiner Meinung. Genau das meinte ich mit: "man muss sich seiner Zielgruppe bewusst sein".

Die Einschränkungen sind dank Libraries wie Puny deutlich geringer als man meinen würde. Ein Inform 7 Spiel auf der anderen Seite würde man durch die Komplexität des erstellten Code niemals auf einem Retro-System zum Laufen bekommen. Es gibt sicherlich eine harte Grenze bei Story Dateien größer 170kb, was erst einmal wenig klingt, in Wirkllichkeit aufgrund der geringen Library Größe von Puny schon einen gewissen Freiraum lässt. Auch Linus' A-Machine eignet sich sehr gut wenn man ein Freund von Dialog ist, eine aus meiner Sicht sehr innovative Sprache.

Eine andere Frage ist, ob man nicht versuchen könnte, die Beliebtheit der Retro-Szene für unsere Zwecke zu nutzen. Neuere Spiele sind oft nicht sehr umfangreich, vielleicht weil die meisten für Wettbewerbe geschrieben werden. Außerdem sind die Zeiten der komplexen Parser, die roboter, gehe nach norden und ziehe den bauern d2 auf d4 verstehen müssen, auch passé.

Da bin ich fest davon überzeugt, dass das möglich ist. Die Tage von Labyrinthen und Lichtquellen die nur 10 Züge brennen sind auch in der Retro-Szene vorbei. Ebenso > GEHE NORDEN Du bist in eine Falle getreten und tot. Auch hier findet ein Wandel statt. Und es muss dann nicht immer gleich "Die-Hard Infocom Style" sein. Ein tolles Beispiel ist das jüngst von meinem Buddy Marco Innocenti im Rahmen des letzten PunyJam veröffentlichte "A1RL0CK". Das Spiel spielt sich in der Tat wie ein moderneres Werk, ist durch die Verwendung von Puny aber auf jeder Menge Heimcomputern lauffähig. Ich hatte Marco mit der Portierung auf +25 Retrosysteme geholfen. Marco war bis dato ein rein "moderner" IF Autor, der in der Szene dank seiner Andromeda Serie sehr bekannt ist. Ein anderes Beispiel ist Hugo, der mit Tristam Island auch zurück zu seinen Wurzeln gegangen ist. Er arbeitet gerade an einem neuen Spiel was lose ein Tribut an Collosal Cave Adventure ist. Es zeichnet sich also sowas wie eine "Back to the Roots" Bewegung ab, allerdings nimmt man das Verständnis für ein zeitgemäßes Spieldesign mit auf seiner Reise in die Vergangenheit.

Über die ZIL Leute möchte ich nicht urteilen, aber die sind tatsächlich sehr speziell. Am Syntax kann es ja nicht liegen, der ist aus heutiger Sicht ein Desaster

Ich schaue mal ob ich Deinen Code zu gegebener Zeit in ein Beispieladventure einfliessen lassen kann. Ich bin da sehr interessiert um ehrlich zu sein. Auch weil ich Puny gerade selbst am übersetzen bin. Vielmehr schreibe ich eine Software die es automatisiert übersetzt, so dass man neue Versionen gleich bereitstellen kann.

Eine Sonderversion für moderne Interpreter ist durchaus machbar. Man könnte ganz normal mit Umlauten im Quelltext arbeiten und diese dann mit einem kleinen Utility für Retrosysteme in die klassischen ue, ae usw. umwandeln. Von den Retrointerpretern ist mir eigentlich nur Ozmoo bekannt, der auch tatsächlich Umlaute auf dem Screen abdrucken kann. Ich muss mir das mal durch den Kopf gehen lassen. In der Retro Community ist sowas wie Bruecke aber kein Problem, weil man es noch so gewohnt ist.

8bit_era: Da bin ich fest davon überzeugt, dass das möglich ist. Die Tage von Labyrinthen und Lichtquellen die nur 10 Züge brennen sind auch in der Retro-Szene vorbei.

Gut zu wissen. Ich dachte halt nur, weil Du weiter oben geschrieben hattest, dass dem meisten 8-Bit-Entwicklern "anachronistische Spielmechaniken" wichtig seien.

(Ja, ja, ich weiß schon, dass es da keine scharfe Trennlinie gibt. Manche Leute gehen halt komplett retro und wollen dann auch Spiele wie aus den Achtzigern schreiben und spielen. Andere schreiben solche Spiele, weil sie sich halt gut mit auf der Retro-Hardware umsetzen lassen. Wahrscheinlich sind aber viele auch "moderneren" Spielen - ich setze das jetzt mal vorsichtig in Anführungszeichen - gegenüber aufgeschlossen.)

Es zeichnet sich also sowas wie eine "Back to the Roots" Bewegung ab, allerdings nimmt man das Verständnis für ein zeitgemäßes Spieldesign mit auf seiner Reise in die Vergangenheit.

Wenn man es genau nimmt, basiert der Erfolg von Inform auch darauf, dass man die Form des Textadventures voranbringen wollte, aber gleichzeitig zurück zu den Wurzeln von Infocom gegangen ist.

In den Neunzigern gab es viele simple Entwicklungssysteme plus TADS und Inform, die "richtige" Programmiersprachen waren und daher sehr flexibel waren. Nach meinem Empfinden war TADS das ausgereiftere System, vor allem was die Behandlung von Aktionen angeht. Es hat Bytecode für eine eigene virtuelle Maschine kompiliert.

Am Ende hat sich Inform durchgesetzt, und das liegt meiner Meinung nach auch daran, dass es als Zielformat den Z-Code hatte, der gerade erst rekonstruiert wurde und der wegen der Infocom-Vergangenheit natürlich sehr cool war und für den es für viele Plattformen schon Interpreter gab.

(Ich habe nie ernsthaft etwas mit TADS gemacht, kenne aber natürlich einige TADS-Spiele und habe auch ein paar veröffentlichte Quelltexte studiert.)

Über die ZIL Leute möchte ich nicht urteilen, aber die sind tatsächlich sehr speziell.

Naja, da geht es gewiss darum, auf den Pfaden der Implementors zu wandeln und etwas mit den alten Methoden zu entwickeln aus Spaß an der Sache selbst. Wieso auch nicht?