Da der diesjährige IFGP abgeschlossen ist, der ja scheinbar unter dem Motto "Reise Richtung Norden" stand (selbst die Tataki schippert anfangs gen Nordosten), wollte ich auch kurz meine Gedanken zu Gruescript schreiben (im Folgenden alles nur sehr subjektiv):

Allgemein zu Gruescript:

Eher Vorteile:

• Man kommt recht schnell in die Sprache rein. Es gibt neben Beispielprogrammen ein sehr ausführliches Manual, das eigentlich keine Fragen offen lässt.
• Man kann, im Gegensatz zu klassischen Parser-Text-Adventures, sehr schnell sein Spiel umsetzen, da einem nächtelanges Abarbeiten von Beschreibungen und Verb-Reaktionen auf Scenery-Objekte wegfallen (wenn man das nicht so mag).
• Da die Eingabe der Spieler deterministisch ist, ist das Beta-Testen und allgemein die Fehlersuche wesentlich leichter (auch wenn dafür der Wahnsinn und die Unberechenbarkeit eines Parser-Spiels natürlich etwas verloren geht). Die Spiele lehnen sich etwas mehr an CYOA-Spiele an.
• Die Spiele sind auf dem Smartphone vernünftig spielbar, z.B. auf dem Weg zur Arbeit im Zug, also imho gerade für Casual Gaming geeignet, wenn man nicht mit Karopapier, Cola und Pizza sich einen Abend frei nehmen will, um ein klassisches Infocom-Spiel zu spielen (und dann im drehenden Raum kein weiteres Rätsel lösen kann und mit Cola und Pizza nach 5 Minuten wieder vor den Fernseher umzieht).
• "Guess-the-right-word"-Rätsel entfallen.

Eher Neutral:

• Die Rätsel sind in der Tendenz eher einfacher als in klassischen IF.
• Beta-Testing bleibt aber unabdingbar um Ungeschliffenheiten und Bugs zu finden (hier nochmal tausend Dank an meine Tester).
• Der Source-Code des Spiels ist aus der Spiel-Datei mit einem Texteditor direkt lesbar.
• Kombinationsrätsel, wie die richtige Reihenfolge für etwas finden oder den richtigen Code in einen Safe eintippen, funktionieren sehr gut.

Eher Negativ:

• Objekt-Rätsel funktionieren etwas schlechter, gerade wenn ein neuens Verb "aufploppt" um die Aktion zu beschreiben (z.B. "verbinde Schrubber mit Haken"). Wenn aber eine Aktion immer möglich ist (wie z.B. "blase in Vuvuzela") und nur an einer Stelle dann das erwünschte Ergebnis bringt, ein Rätsel löst oder die Geschichte voranbringt, dann funtkionieren sie aber imho durchaus.
• Gruescript funktioniert "Out of the Box". Wenn man das Spiel aber etwas schöner haben will, muss man sich dann doch mit CSS und Javascript auseinandersetzen.
• Es gibt keine hilfreichen Abkürzungen wie in Inform mit "[first time]...[only]", "[only one]...[or]...[at random]" oder überhaupt "if-then-else"-Verzweigungen für Texte. Man muss (zumindest hatte ich keine bessere Methode dafür gefunden) erst vor der Ausgabe des Textes eine Prozedur aufrufen, die diese Abfragen macht, dann den entsprechenden Text in eine globale Variable schreiben und darauf diese im Text daselbst ausgeben.
• Die ganzen versteckten Gags, wie in Parserspielen, lassen sich schwer umsetzen. Der Protagonist in meinem Spiel wird an mehreren Stellen als "Zerstörer von Welten" betitelt. Normalerweise würde man eine launige Reaktion auf die Eingabe "zerstöre welt" schreiben (zusammen mit einem Hinweis auf die Undo-Funktion). In Gruescript müsste man im Interface einen Button anlegen, was für so einen simplen Gag einfach zuviel wäre und ihn auch gleichzeitig killen würde.
• Die eigentlich nie eingehaltene Metapher von "ich unterhalte mich mit dem Computer wie mit einem Menschen in einem anderen Raum: Ich tippe etwas, er antwortet im selben Medium, ich tippe etwas,..." geht verloren (man denke an "Eliza" in der frühen ChatBot-Geschichte).

Gruescript für deutschsprachige Spiele:

Dem Programm liegt eine beispielhafte Übersetzung des "Mantel der Dunkelheit" ins Spanische bei, was sehr hilft. In der aktuellen Beta ist man aber gezwungen, da einige Default-Texte nicht mit Variablen ersetzbar sind, doch einiges im Quellcode von Gruescript zu ändern. Das dürfte aber eigentlich für keinen ein Problem darstellen, der rudimentäre Erfahrung hat, wie typische Programmiersprachen aufgebaut sind. So wird z.B. auch fest ein Komma gesetzt vor dem "und" in Aufzählungen. Ich hatte dem Entwickler eine Mail mit einer Aufzählung dieser Probleme geschickt, in der Hoffnung, dass er die Punkte in eine spätere Version von Gruescript mit einfließen lässt. Ansonsten muss man sich etwas behelfen und weitere "Default"-Variablen in seinem Spiel definieren (z.B. für Akkusativ-Formen von Objekten, damit es heißt "Du siehst einen Tisch und ein Haus." und nicht "Du siehst ein Tisch und ein Haus.". Evtl. können bessere Programmierer hier eine bessere/automatischere Lösung wie in Inform schreiben. Genauso hatte ich auf Dauer zu allen eigenen Verben die Prompt-Ausgabe direkt angegeben: Klickt man auf "lesen" hinter dem Objekt "Buch", so habe ich die Promptangabe "lies das Buch" direkt angegeben und das nicht über Variablen gelöst. Schön ist aber, dass das alles überhaupt möglich ist und Spiele umsetzbar sind, denen man nicht anmerkt, dass sie in einem System, das zuvorderst für englischsprachige Spiele entwickelt wurde, programmiert wurden.

Meines Erachtens eignet sich das Programm gut, um kleine Puzzler zu bauen (im Handbuch zu Gruescript wird explizit Bezug auf Scott-Adams-Spiele genommen), oder aber umfangreiche, erzählende Spiele, wenn der Autor keine Lust hat, sich mit zuvielen Scenery-Objekten, etc. rumzuschlagen. Michael Baltes "Geheimnis von Beagle's Rock" weist da imho stark in diese erzählende Richtung. Auch hat Michael gleich Grafik mit umgesetzt, was vielleicht auch zur Darstellung einer Kompassrose genutzt werden könnte (wie z.B. in den Legend-Entertainment-Titeln).

In dem Forum fiel, mangels u.a. echten Objekträtseln in Gruescript-Spielen, der Vergleich zu Render-Adventures (zumindest in der Art der Rätsel und Erzählstruktur) und er ist nicht ganz von der Hand zu weisen. Allerdings gibt es hier neben all den "Türme von Hanoi / Schiebepuzzle"-Spielen auch durchaus Perlen wie Riven, die imho absolut überzeugend funktionieren. Oder man nimmt die Künstlichkeit der Rätsel als Erzählprämisse, wie es z.B. aktuell bei den "The Room"-Spielen von Firework Games der Fall ist. Es gibt bestimmt Autoren, die auch in diesem System ganz großartige, fordernde Rätsel schaffen können (wie ich ja auch immer mal wieder in CYOA-Spielen gelingt). Ich persönlich würde hoffen, dass weitere Spiele in dem Längen-Format "30-60 Minuten" geschrieben werden.

Edit (02.05.23 / 12:54): Ich vergaß noch den Punkt, dass man in Gruescript dank der Button-Struktur leicht neue Funktionalitäten ("schau in die Zukunft", "verteidige Torso") einführen kann, ohne sie durch eine Anleitung am Anfang des Spiels erklären zu müssen oder didaktisch vorbereiten zu müssen. So müsste man in einem Parser-Spiel zu dem Beispiel "verteidige Torso" frühzeitig in dem Spiel eine Situation schaffen, bei der man angegriffen wird und darauf hingewiesen wird, dass man sich ja verteidigen könnte (z.B. durch einen betrunkenen Partygast, der einem immer wieder etwas zu fest auf die Schulter haut und sich darüber lustig macht, dass man ja gar nicht die Flanke verteidigt (solange bis man zum richtigen Zeitpunkt "verteidige Flanke" eingibt)), so dass am Ende des Spiels, wenn man diese Funktion als Teil des End-Rätsels braucht, der Spieler gesichert weiß, dass er diese Option ja überhaupt hat.

Edit (08.05.23 / 10:16): Ein Punkt, der aus einer Diskussion auf https://intfiction.org/t/german-language-if-grand-prix-2023/ hervorging und vielleicht irgendwann mal zum Tragen kommen kann, wenn Maschinenübersetzungen noch etwas stärker werden: Man kann Gruescript-Spiele in einem entsprechenden Browser aus einer anderen Sprache automatisch übersetzen lassen und ohne echte Kenntnisse der Ausgangssprache spielen. Das Spiel erscheint dann komplett in der eigenen Sprache. Dasselbe gilt zwar auch für Parser-Spiele, die man in einem Browser startet, allerdings müssen die Befehlseingaben hier in der Ursprungssprache gemacht werden. Da allerdings unklar bleibt, wie einzelne Objekte im Ursprung hießen (z.B. "a box" für entweder "eine Kiste" oder "ein Kästchen", ...) muss man doch das Originalspiel wenigstens parallel spielen und rudimentäre Kenntnisse in der Ursprungsspache haben).

Der Vollständigkeit halber gerade noch, mehr als Archivar, die Links zu den Reviews, die sich auch detailliert mit dem System auseinandergesetzt haben:

• https://if-forum.org/topic.php?id=1295 (Thread zu "Das Geheimnis von Beagle's Rock")
• https://if-forum.org/topic.php?id=1297 (Thread zu "Ich, Shub-Jagaroth")
• http://martin-oehm.de/adv/gruescript.html (allgemein zu Gruescript von Martin Oehm)

Vielen Dank, Heiko, für diese umfangreiche Bewertung von Gruescript aus der Autorenperspektive.

... Reviews, die sich auch detailliert mit dem System auseinandergesetzt haben: ...

Oh, jetzt muss ich meinen vollmundig angekündigten Artikel über Gruescript ja doch zügig zu Ende schreiben. Ich habe mich natürlich nicht so intensiv mit der Sprache selbst beschäftigt und werde das Ganze aus Spielersicht betrachten.

Du hast ja schon geschrieben, dass sich nicht alle Arten von Rätseln, die man aus Parserspielen kennt, gleich gut in Gruescript umsetzen lassen, und ich schließe mich Deiner Meinung an, dass man mit umsichtigem Rätseldesign gewiss gute Gruescript-Spiele schreiben kann.

Und ich denke, dass vor allem beim Layout noch viel Luft nach oben ist. Ich bin jedenfalls mal gespannt, was da noch auf uns zukommt. Vielleicht die von Dir gewünschten kurzen Puzzler?

Sehr interessant! Ich schließe mich Martins Aussage auf seiner Webseite vorbehaltlos an, es ist gut, dass wir diese zwei Spiele bekommen haben.

Ich habe den Vergleich mit den Renderadventures habe ich verbrochen. Also kurz dazu. Heiko hat recht, in jeder Darstellungsform gibt es gute Spiele. ziemlich wörtlich habe ich das vor ein paar Tagen über die allseits gescholtenen FMV-Adventures der 90er Jahre gesagt. Leider ist die erste Assoziation aber eine andere. Nämlich irgendwelche dummen Springerprobleme, das Öffnen von Kisten oder Türen mit farbigen, verschieden geformten Bauklötzen usw.

Es bedarf einem anderen Medium eben neuer Gedanken, wie man ein gutes Spiel macht. Diese Findungsphase befindet sich für Gruescript ganz sicher noch am Anfang. Experimente, was funktioniert und was nicht, werden noch viele stattfinden müssen.

Generell scheint, was Interaktion angeht, das Denken bislang in Richtung Wissensrätsel zu gehen. Das ergibt Sinn, weil dies ja im Spiel nicht durch das Interface verraten wird, wie es bei mechanischen Rätseln der Fall ist. Doch auch hier gibt es Abstufungen. Michaels Rätsel mit den Statuen empfinde ich spontan als positives Beispiel. Seine Süteßterlinnotiz dagegen als negativ, da dann praktisch überhaupt kein Anteil der Lösung mehr im Spiel selbst stattfindet.

Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren. Was ja in Krimiadventures immer wieder ein ungelöstes Problem ist.

Auch bewusst erwähnt hatte ich ja in dem Kontext auch Ren'Py. Dem stand ich anfangs sehr negativ gegenüber. Doch mittlerweile habe ich auch darin Spiele entdeckt, die mir insgesamt gefallen haben. Man muss halt den passenden Spielinhalt für die Darreichungsform finden. Nur, in Ren'Py wie in Twine usw. ist der Löwenanteil der Spiele eben leider unerträglich. Was die ganzen Medien herunterzieht. Wie früher Render- oder FMV-Adventures.

Auch von mir danke für den detaillierten Einblick mit Pro- und Contra-Aspekten, Heiko!

Ich habe mich in den Rezensionen relativ kritisch zu Gruescript als System geäußert, freue mich aber darauf, was ggf. an weiteren Spielen und Experimenten/Entwicklungen kommen wird. Hab auch schon überlegt, mal ein eigenes Projekt damit zu starten.

Hannes:

Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren. Was ja in Krimiadventures immer wieder ein ungelöstes Problem ist.

Finde ich auch sehr interessant, weil ich selbst mit einem Krimiadventure liebäugele. Hast Du schon eine bestimmte Mechanik vor Augen, z.B. in Richtung "Verbinde Spur A mit Zeugenaussage B"? (Oder vllt. auch gerade das nicht?)

Das System aus "Detective Grimoire" (Graphikadventure) fand ich vor einiger Zeit ganz witzig. Da musste man die Zusammenhänge herstellen, indem man quasi einen Satz aus vier Variablen bildete; zwei Leerstellen waren für eine Reihe vorgegebener Textbausteine vorgesehen, zwei weitere für Bezüge auf Tatsachen, NPCs, Gegenstände (siehe Screenshot im Anhang).

StJohn Limbo:

Hannes:

Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren. Was ja in Krimiadventures immer wieder ein ungelöstes Problem ist.

Finde ich auch sehr interessant, weil ich selbst mit einem Krimiadventure liebäugele. Hast Du schon eine bestimmte Mechanik vor Augen, z.B. in Richtung "Verbinde Spur A mit Zeugenaussage B"? (Oder vllt. auch gerade das nicht?)

Das ist so das beste, was ich bislang gesehen habe in ein paar Spielen, denn damit wird der Wissenserwerb immerhin überhaupt im Spiel modelliert. Gar nicht mag ich es, wenn Protagonisten plötzlich einfach irgendwelche Schlüsse ziehen oder Wissen haben, den ich mir als Spieler überhaupt noch nicht erschlossen habe. Weil die Autoren davon ausgehen, ich müsse das jetzt ja bereits "offline" verstanden haben. Aber auch ein solches System ist aber immer noch weit von einem Idealzustand, finde ich. Es geschieht dabei immer noch häufig, dass durch das mechanische Verknüpfen von Informationen innerhalb des Spiels es zu Schlüssen kommt, die gar nicht dem entsprechen, was ich im Kopf hatte. Ich also sozusagen durch Zufall etwas "löse", obwohl mein Denken in ganz andere Richtungen ging. Zugegeben, das gleiche kann bei mechanischen Objekträtseln auch passieren. Durch "Benutze Nagel mit Brett" will ich vielleicht ausdrücken, ersteres solle eingeschlagen werden, aber dann macht der Protagonist vielleicht doch einfach ein Loch darein, um hindurchzusehen.

Leider haben aufwändigere Systeme in Detektivspielen anscheinend die Angewohnheit, dann sehr, sehr komplex zu werden. Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948. Sehr ausdrucksstark und erlaubt sehr feine Abstufungen, aber man verliert praktisch sofort den Überblick. Das Zusammenklicken der Aussagen und Fragen dauert außerdem viel zu lange, so dass man schnell die Motivation verliert.

Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948.

Dass das noch jemand kennt, wow.

Hannes:

auch ein solches System ist aber immer noch weit von einem Idealzustand

Ja, schwieriges Problem, sehe ich auch so. Teils werden durchs Kombinieren ganz andere oder weitreichendere Schlüsse gezogen, als man erwarten würde, und das nimmt einem dann den Spaß an der Lösung. Und teils ist es so, dass man vorm Bildschirm schon selbst die richtigen Überlegungen angestellt hat, aber man nicht weiß, welche obskure Aktion man jetzt im Spiel noch auslösen muss, damit die Spielfigur auch auf den Stand kommt.

StefanH:

Hannes: Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948.

Dass das noch jemand kennt, wow.

Ich nicht, muss ich zugeben.

Ich hab mir ein paar Screenshots angeguckt; sieht interessant aus, aber auch tatsächlich etwas umständlich.

Hannes: Was ich tatsächlich mal interessant fände wäre der Versuch, in diesem System wirklich Protagonistenwissen quasi als Objekte oder Knoten zu modellieren.

Der berühnte "Gedankenpalast". Oder natürlich das Whiteboard im Kommissariat, auf dem Fotos von Verdächtigen und Beweisstücke in Verbindung gebracht werden.

Wie man das aber in einem Interface mit expliziten Optionen umsetzt, ohne dass dem Spieler Logiksprünge in den Kopf gesetzt werden und ohne dass man alles ausprobieren kann, bis es passt, weiß ich nicht, aber ich denke nicht, dass sich Gruescript besonders gut dazu eignet. Vermutlich müsste man ein eigenes Interface entwickeln.

StJohn Limbo: Hast Du schon eine bestimmte Mechanik vor Augen, z.B. in Richtung "Verbinde Spur A mit Zeugenaussage B"? (Oder vllt. auch gerade das nicht?)

Oder man müsste drei Dinge miteinander verknüpfen: Zwischen A und B besteht eine (mögliche) Verbindung über Indiz X.

Vielleicht modelliert das Spiel auch nicht, was der Spieler über die Tat weiß, sondern was er meint zu wissen, so dass er sich in seinem Gedakenpalast quasi verlaufen kann: A und B werden verknüpft, weil es ein Indiz X gibt und das ist dann wiederum ein Indiz Y, mit dem man C und D verknüpfen kann, nur dass die Annahme, dass A und B verknüpft sind, bereits falsch ist.

(Das zu programmieren ist aber eine Herausforderung: Wenn man eine früh im Spiel getroffene Annahme widerruft, ribbelt sich das ganze danach gesponnene Gedankennetz wieder auf.)

Und teils ist es so, dass man vorm Bildschirm schon selbst die richtigen Überlegungen angestellt hat, aber man nicht weiß, welche obskure Aktion man jetzt im Spiel noch auslösen muss, damit die Spielfigur auch auf den Stand kommt.

Wenn die Aktion nicht obskur wäre, sondern sich eindeutig aus den gesammelten Indizien ergäbe, wäre das tatsächich eine fast ideale Lösung. Vielleicht müsste man dazu noch nicht einmal den Wissensstand im Spiel ausdrücklich modellieren. Aber natürlich ist die Gefahr, dass so etwas für viele Spieler dann doch wieder obskur ist, zu groß.

[Detective Grimoire] Da musste man die Zusammenhänge herstellen, indem man quasi einen Satz aus vier Variablen bildete; zwei Leerstellen waren für eine Reihe vorgegebener Textbausteine vorgesehen, zwei weitere für Bezüge auf Tatsachen, NPCs, Gegenstände

Etwas Ähnliches scheint The Case of the Golden Idol zu machen, wo man Lücken im Text füllen muss. (Hab's aber nicht gespielt, nur davon gehört.)

Martin:

Oder man müsste drei Dinge miteinander verknüpfen: Zwischen A und B besteht eine (mögliche) Verbindung über Indiz X.

Gute Idee, das würde es etwas komplexer machen.

Vielleicht modelliert das Spiel auch nicht, was der Spieler über die Tat weiß, sondern was er meint zu wissen

Interessant! Also den Spieler erstmal machen lassen und nicht gleich "falsch!" ausgeben... dadurch würde man wohl auch das stumpfe "alles mit allem Ausprobieren" verhindern, da es nicht sofort Rückmeldung gibt. Und man kriegt wirklich das Gefühl, frei kombinieren zu können.

(Das zu programmieren ist aber eine Herausforderung: Wenn man eine früh im Spiel getroffene Annahme widerruft, ribbelt sich das ganze danach gesponnene Gedankennetz wieder auf.)

Das könnte ich mir ziemlich cool in Form einer im doppelten Sinne graphischen Repräsentation vorstellen: Das Gedankennetz als gerichteter Graph, auch visuell auf dem Bildschirm. Wenn der Spieler eine Annahme widerruft, leuchten die Folgerungen auf und werden aufgeribbelt, abgetrennt oder als "unbegründet" dargestellt. Sie müssen ja nicht per se falsch sein; könnten evtl. noch auf andere Weise begründet werden. Wenn der Spieler dagegen auf Beweise stößt, die ihn zwingen, eine der Folgerungen aufzugeben, könnte vielleicht ähnlich wie beim modus tollens die Kette entgegen der Implikationsrichtung aufgerollt werden und die Annahmen als "widerlegt" gekennzeichnet werden.

(Ich schreibe "ähnlich wie", weil ja nicht ganz klar ist, ob man Annahmen und Folgerungen hier in so einem Spielkontext als streng deduktiv betrachten kann; je nachdem, wie genau man alles repräsentiert. Das Vorhandensein von Zigarrenasche plus das Wissen, dass Onkel Eduard Zigarre raucht, legen den "Schluss" nahe, dass Onkel Eduard hier war. Aber man kann, falls man erfährt, dass Eduard definitiv nicht hier war, also dass die Folgerung falsch ist, in diesem Fall nicht plausibel den Rückschluss ziehen, dass eine dieser Annahmen falsch gewesen sein muss, also dass doch keine Asche vorlag oder dass Eduard doch kein Zigarrenraucher ist. Stattdessen wird man eher den Rückschluss ziehen können, dass eine versteckte Annahme vorhanden war, sowas wie "niemand sonst raucht Zigarre", und dass diese Annahme falsch gewesen sein muss. Daher schwierig zu modellieren. Aber wäre interessant, mal zu gucken, wie weit man so ein Interface umsetzen könnte. Wobei wir uns damit zugegebenermaßen schon deutlich aus Gruescript rausbewegen.)

Etwas Ähnliches scheint The Case of the Golden Idol zu machen, wo man Lücken im Text füllen muss.

Ah, das sieht auch cool aus, kannte ich bisher nicht; ist vorgemerkt.

StefanH:

Ich erinnere mich da beispielsweise mit Schrecken an das Befragungssystem aus Berlin 1948.

Dass das noch jemand kennt, wow.

Habe ich vorletztes Jahr zuletzt gespielt. Völlig abgesehen von anderen Schwächen ist dabei halt das Versäumnis, dass es zwar die detaillierte Befragung modelliert, nicht aber das daraus resultierende Wissen. Was man erfährt, bleibt nur im Kopf des Spielers (oder auch nicht).

StJohn Limbo:

Stattdessen wird man eher den Rückschluss ziehen können, dass eine versteckte Annahme vorhanden war, sowas wie "niemand sonst raucht Zigarre", und dass diese Annahme falsch gewesen sein muss. Daher schwierig zu modellieren

Oder, noch komplizierter: Vielleicht raucht wirklich niemand sonst Zigarre, aber jemand hat die Asche dort platziert, um Onkel Eduard zu belasten.

Die Variante, Schlussfolgerungen auf Basis einer unbekannten oder unbewiesenen Behauptung stehenzulassen, und eben nicht gleich wieder "aufzuribbeln", erscheint mir recht attraktiv. So würde man praktisch "Ahnungen" modellieren. Vielleicht sogar mehrere Theorien parallen, die sich widersprechen dürfen.

Warum bin ich überhaupt auf dieses Thema gekommen? Auf Basis dieser beiden Spiele erschien mir das Spieldesign in Gruescript in Richtung Wissensrätsel zu gehen. Ist es allerdings für solch komplexe Modellierungen geeignet? Meinerseits keine Ahnung, vielleicht traue ich dem System ja zu viel zu. Aber die Hoffnung stirbt bekanntlich zuletzt