Da ich mit Wishbringer von Infocom schöne Erinnerungen verbinde, hat es mich natürlich gefreut, bei "Wo ist Mr. Beaver?" wieder mal einen Briefträger spielen zu dürfen. Dieses Mal wird freilich kein Haustier vermisst, sondern das Herrchen, der titelgebende Mr. Beaver. Besonders gut gefallen hat mir der Weltenbau. So ein Kuriositätenladen mit einem ebenso kuriosen Inhaber ist natürlich der ideale Schauplatz für ein Adventure ideal, um in eine andere Welt einzutauchen. Mir hat es jedenfalls Spaß gemacht, den Laden, und alles darüber hinaus, zu erkunden.

Sehr gut gelöst ist auch die Motivation des Spielers: Ein Briefträger will ein Einschreiben zustellen und macht sich zunehmend Sorgen über den Verbleib des Empfängers. So ist vom ersten Moment an klar, was das Spielziel ist: "Wo ist Mr. Beaver?" Super fand ich, dass bereits am Anfang klar wird, mit welcher Art von Welt man es zu tun hat, nachdem man das Aquarium untersucht hat. Sehr gefallen hat mir auch das Eskalationssystem. Von Haus aus bin ich zwar kein Freund davon, wenn ich einen Behälter mehrmals durchsuchen muss, bis mit fortschreitendem Spiel eine Bedingung erfüllt ist, das doch etwas Nützliches zu finden sei. Runaway 1 von Pendulo ist mir da negativ in Erinnerung geblieben. Das Eskalationssystem passt freilich gut zur Geschichte und und die Stufen erklären sich weitgehend gut aus dem Spielfortschritt. Im Prinzip ist das eine sehr lange Rätselkette.

Obacht/Achtung: Spoiler voraus!

Bei den Rätseln merkte ich, wie in meinem Hirnkastl ein paar eingerostete Zahnrädchen wieder in Gang kamen. Den Schlüssel aus dem Jenga-Turm wollte ich am liebsten mit dem Holzpflock herausbefördern. Hier habe ich in die Lösung geschaut. Beim Ölfläschchen und dem Gartenschlauch war ich dann ausdauernder und kam ohne Hilfe auf die Lösung. Wobei ich mich immer noch frage, um welche Art von Ölfläschchen es sich handelt. Klar, es handelt sich nicht um ein Ölkännchen, aber auch von einem Fläschchen hätte ich spontan angenommen, es besäße eine Vorrichtung zum gezielten Dosieren der gewünschten Ölmenge. Aus der Beschreibung ergab sich kein Hinweis in die eine oder andere Richtung. Aber vielleicht liegt dieses Missverständnis auch an meiner sprachlichen Prägung in Süddeutschland und Österreich? Deshalb auch mein quasi zweisprachiger Hinweis "Obacht/Achtung". In jedem Fall war es ein schönes Gefühl, das Gartenrätsel geknackt zu haben.

Ein lustiges Detail war, dass sich der stinkende Fisch als nützlich erwiesen hat, und es sich dabei folglich um keinen roten Hering gehandelt hatte.

Etwas dünn gebohrt, also deutlich ausbaufähig, fand ich das abschließende Gespräch zwischen Briefträger und Mr. Beaver, und zwar sowohl die drei Gesprächsoptionen als auch Mr. Beavers Antworten. Dass er wie die Männer in Schwarz eine Möglichkeit zum Blitzdingsen hat, überrascht nicht, aber irgendwie habe ich mir da mehr Infos erwartet.

Richtig schön fand dann den abschließenden Hinweis auf den nächsten Brief, den der Protagonist zustellen sollte, sowie natürlich die Empfängerin. Das war echt ein humvorvoller Abschluss und Ausblick.

Besonderes Lob möchte ich für das System oder die Engine aussprechen. Ich habe mich beim Spielen so gut aufgehoben gefühlt wie seinerzeit bei den Legend-Adventures. Ich spiele an sich sehr gerne mit Texteingabe, schätze es aber auch, wenn ich eine Kompassrose und Wörter zum Anklicken habe. Absolut Spitzenklasse finde ich, dass man sich das Spiel so konfigurieren kann, dass es auf die eigenen Vorlieben abgestimmt ist. Manchmal tippe ich, manchmal klicke ich. Hier kann ich beides! Sehr komfortabel ist sie Speicherfunktion, sogar mit Auto-Save. Zwar gab es in der von mir gespielten Version 0.9.3 ein paar Fehler und Ungenauigkeiten, die ich jetzt aber nicht näher ansprechen möchte, weil ich annehme, dass bereits eine neuere Fassung existiert.

Fazit: Chapeau! Ich habe die Suche nach Mr. Beaver von Anfang bis zum Schluss sehr genossen und hoffe auf weitere Spiele mit diesem Autorensystem oder dieser Engine, oder wie das bei IF auch heißen mag. Gerne auch Geschichten aus demselben Universum. Wer ist Mr. Beaver? Woher kommt Mr. Beaver? Was weiß Frau Badger?

Hallo mik,

freut mich wirklich sehr, dass dir "Wo ist Mr. Beaver?" so gut gefallen hat. Die Kritik im Detail kann man glaube ich so stehen lassen, daran habe ich für die neuere Version auch noch etliches geschraubt gehabt (Martin war aber noch immer nicht zufrieden. ).

Schön auch, dass du meine Design-Philosophie zu würdigen weißt. Ich möchte, dass jeder das Ganze so spielen kann wie er/sie es will, dass Story und Rätseldesign möglichst völlig separat von den Eingaben sind. Das funktioniert aktuell nicht nur mit Texteingabe und Multiple Choice, sondern auch mit Voice Input. Das funktioniert noch nicht perfekt, aber auf den meisten Geräten schon erstaunlich gut (wobei mein Beitrag da erstaunlich gering ist. Das ist halt ein Browser-Feature). Gerade auf mobilen Geräten würde ich es der Tipperei vorziehen.

(Was ich ja auch ein spannendes Experiment fände: Mittels KI-Einsatz völlig natürlichsprachige Sätze in IF-Befehle umzuwandeln. Gemini und Co. kriegen das erstaunlich gut hin)

Es gibt ansonsten noch "The Master's Lair" mit dem gleichen System, das ist aber gerade broken. Ich sollte es wohl mal wieder online stellen.

Fazit: Chapeau!

Eine schöne Besprechung des Spiels!

Ich finde auch, dass das Gespräch mit Mr. Beaver am Schluss etwas drangeklatscht wirkt. Da wird versucht, etwas zu erklären, wo es nichts zu erklären gibt. Die gelungene Pointe im eigentlichen Schlusstext hätte mir als Abschluss gereicht.

Aber vielleicht liegt dieses Missverständnis auch an meiner sprachlichen Prägung in Süddeutschland und Österreich?

Das glaube ich nicht. Das Spiel macht es einem schon nicht leicht. So wie im Spiel habe ich noch nie ein Ölkännchen benutzt. Und die Gegenstände, die das Spiel für den Jenga-Turm und den Sturmhaken vorgesehen hat, wären auch nicht meine erste Wahl gewesen. (Ich halte beide für zu groß.)

Viele Aufgaben im Spiel beruhen auf der richtigen Kombination von Gegenständen, also quasi "benutze X mit Y". Die exakten Verben sind aber unklar und weil das Spiel es nicht schafft, konsistent zwischen Ein- und Ausgabe zu sein, ist guess the verb vorprogrammiert.

Und das ist schade, denn die Aufgaben sind nicht sehr exotisch und es ist klar, was genau die Kombination bedeutet. Da fällt man dann wieder zurück auf "benutze", das in meiner Erinnerung vom Spiel verstanden wird, oder auf die Aktionsmenüs bei den Objekten.

Besonderes Lob möchte ich für das System oder die Engine aussprechen.

Dazu vielleicht noch eines. Erst mal: Danke! Und: Ich habe ja nun ein Weilchen an meinem Homebrew-Kram rumgedoktort. Da hatten sich doch recht viele Altlasten angesammelt, also habe ich das Framework nochmal neu aufgesetzt und dabei tüchtig aufgeräumt. Es ist jetzt noch längst nicht fertig, aber das bisherige Resultat ist doch eine klare Weiterentwicklung. Das UI sieht ähnlich aus, ist aber an entscheidenden Stellen deutlich leistungsfähiger (Martin kriegt endlich seine Multiple Choice Menüs dort, wo er nicht ewig mit dem Mauszeiger reisen muss). Ich habe auch erstaunlich viele Limits des alten Parsers geknackt. Und das Coding ist doch deutlich smoother als vorher.

Sofern Interesse besteht, würde ich das Ganze auch frei zugänglich machen. Es ist halt ein Framework, wo man direkt in C# arbeiten kann und alle Vorzüge eines Compilers und Debuggers genießt. Es gibt zwar aktuell nur die Web-Version, aber es ist auch technisch machbar, das Ganze als App für Windows, Android und iOS zu realisieren. Ja, auch die Trennung von Player und Gamecode ist technisch machbar. Wie weit ich den Aufwand noch treiben möchte, weiß ich gerade auch nicht. Ich habe mir ja nicht zum Ziel gesetzt, einen Inform-Killer zu entwickeln. Aber bis jetzt ist das ein außerordentlich unterhaltsames Gebastel in Blazor und C#.

Ich denke, so bis Ende des Jahres dürfte es das eine oder andere zum Anschauen geben. Vielleicht auch früher schon. Wer Lust hat, mal reinzuschauen, kann sich gerne melden. Gerade fürs UI würde ich gerne auch ein paar Ideen ausprobieren...

(Martin kriegt endlich seine Multiple Choice Menüs dort, wo er nicht ewig mit dem Mauszeiger reisen muss)

Haha, steter Tropfen ...

Aber was mache ich dann mit der schönen ergonomischen Handgelenkmanschette aus dem Sanitätshaus?

Aber was mache ich dann mit der schönen ergonomischen Handgelenkmanschette aus dem Sanitätshaus?

Wusste gar nicht, dass du dich so in Unkosten gestürzt hast. Das ist natürlich ein super Geschäftsmodell, die Bedienung extra so vermurksen, dass die Umsätze der Apotheken und Sanitätshäuser hochgehen, und sich dann an den Umsätzen beteiligen lassen...

Wusste gar nicht, dass du dich so in Unkosten gestürzt hast.

Ich weiß mittlerweile auch, wo das Sanitätshaus steht, aber das mit dem orthopädischen Ausgleich für schlechte Mauswege war nur ein flauer Gag.

Ich spiele die Hoffmann'schen Werke natürlich im Parser-Modus - wenn ich schon einmal am Anfang so nett gefragt werde, wie ich spielen will. In den Menü-Modus wechsle ich nur, wenn ich nicht weiter weiß und mir erhoffe, aus der Menüstruktur Tipps ableiten zu können.

Das mit der Fragerei am Anfang ist allerdings passé, glaub ich.

Mittlerweile gibts was neues in den Optionen, siehe angehängter Shot. Dazu muss ich allerdings sagen, dass ich da gedanklich schon wieder ein Stück weiter bin.

StefanH:

Aber bis jetzt ist das ein außerordentlich unterhaltsames Gebastel in Blazor und C#.

Ich denke, so bis Ende des Jahres dürfte es das eine oder andere zum Anschauen geben. Vielleicht auch früher schon. Wer Lust hat, mal reinzuschauen, kann sich gerne melden. Gerade fürs UI würde ich gerne auch ein paar Ideen ausprobieren...

Das freut mich sehr, dass du weiterhin mit Freude an deinem Framework schraubst und weitere Ideen verwirklichst. Ich fand ja schon das Spielen sehr unterhaltsam, von daher habe ich große Lust, mal in das Framework reinzuschauen. Mit Blazor habe ich noch nichts gemacht und mein C# ist auch eingerostet, aber ich helfe gerne beim Testen, Auspropieren, Philosophieren. Ich mache gerne mit und melde hiermit.

Mit Blazor habe ich noch nichts gemacht und mein C# ist auch eingerostet, aber ich helfe gerne beim Testen, Auspropieren, Philosophieren. Ich mache gerne mit und melde hiermit.

Super! Dauert wie gesagt ein bisschen noch, bis ich was zum Diskutieren habe. Aber es füllt sich langsam.

Blazor ist nur die Verknüpfungs-Technologie zwischen HTML/CSS/JS und C#, da muss man sich nicht mit rumschlagen, um es zu benutzen. Das tut das Framework. Wenn man da unbedingt etwas ändern will, siehts natürlich anders aus.

Die Idee wäre jetzt schon, dass recht einfaches C# ausreicht, um damit ein Spiel zu schreiben.

StefanH: Das mit der Fragerei am Anfang ist allerdings passé, glaub ich.

Ja, glaub auch. Flexible Konfiguration während des Spiels finde ich besser. (Gab's ja schon, aber die Frage am Anfang hat einem ja suggeriert, dass die Entscheidung für einen Spielmosud unwiderruflich ist.)

Das neue kompakte Konfigurationsmenü aus dem Screenshot sieht jedenfalls schick aus und ist eine riesige Verbesserung des alten Menüs, das zu große Schaltflächen als Radiobuttons oder Auswahllisten missbraucht hat und bei dem man zu viel scrollen musste.

Man kann offenbar das Inventar (oder jede andere Liste) in alle vier Ecken gleichzeitig packen. Ich hoffe nicht, dass das der einzige Beitrag zur Minimierung der Mauswege ist ...

mik: ... aber ich helfe gerne beim Testen, Auspropieren, Philosophieren.

Das finde ich gut.

StefanH: Sofern Interesse besteht, würde ich das Ganze auch frei zugänglich machen. Es ist halt ein Framework, wo man direkt in C# arbeiten kann ...

Und ich finde es gut, dass Du Dein Framework veröffentlichen willst. Ich werde wohl einen kurzen Blick auf den Code werfen, weil es mich interessiert, wie das alles organisiert ist, aber testen oder gar benutzen möchte ich das Framework eher nicht.

Es ist gewiss nicht verkehrt, eine allgemeine Programmiersprache zu verwenden, aber wenn ich mir anschaue, was David Cornelson - übrigens auch so ein KI- und Spracheingaben-Apologet - mit seinem Typescript-Framework oder auch Biegomar mit Heretic da so machen, winke ich ab. Mich erinnert das immer an FizzBuzz - Enterprise Edition.

(Jaja, weiß schon. Eine geeignete Entwicklungsumgebung sucht sich schon die über alle Dateien verstreuten Definitionen zusammen und bietet mir automatische Vervollständigung des Codes an, so dass alles beherrschbar bleibt. Trotzdem.)

Ich hoffe nicht, dass das der einzige Beitrag zur Minimierung der Mauswege ist ...

Nene, da ist jetzt ein Mechanismus drin, der immer jenen Button direkt unter dem Mauszeiger platziert, von dem ich möchte, dass du ihn anklickst.

Ok, anders: Multiple Choice ist jetzt flexibel platzierbar. Im Input-Bereich, als Tab in den Multiple Choice Panels oder als bewegliches Popup. Erste Erfahrungen damit zeigen, dass man das noch ein wenig smarter machen kann. Und mal schauen: Konkrete Vorschläge zum Ausprobieren sind willkommen.

... aber testen oder gar benutzen möchte ich das Framework eher nicht.

Ja, vermutlich wird das am Ende auch bestenfalls für wenige Leute überhaupt interessant sein. Ich stehe halt auf stark typisierte Sprachen wie C#, mächtige Compiler und leistungsfähige Debugger. (wahrscheinlich geht das auf ein lebenslanges Trauma zurück, weil ich zu lange in C unter DOS gecodet habe. Dummer Compiler, kein Debugger, und weniger eine Programmiersprache als eine universelle Todesfalle, so war das Arbeiten mit C früher... )

Was sind denn deine Kriterien, welche Frameworks für dich interessant welchen und welche nicht?

Nene, da ist jetzt ein Mechanismus drin, der immer jenen Button direkt unter dem Mauszeiger platziert, von dem ich möchte, dass du ihn anklickst.

Hehe. So als One-Button-Game sind Textadventures auch leichter zu schreiben. Und zu testen. Und zu spielen. Win, win, win.

Ja, vermutlich wird das am Ende auch bestenfalls für wenige Leute überhaupt interessant sein.

Na, weiß nicht. Wenn viele andere in eine ähnliche Richtung gehen, ist gewiss Interesse da. Und zu gucken, wie Du es gemacht hast, hat ja auch einen Wert, wenn man das System nicht produktiv nutzt.

Was sind denn deine Kriterien, welche Frameworks für dich interessant welchen und welche nicht?

Hm. Ich glaube, ich finde vor allem "Frameworks" nicht so interessant. Textadventures sind doch kleine, kompakte Programme.

Eine spezielle Sprache für Textadventures kann für die Produktivität beim Schreiben schon helfen. Prinzipiell finde ich das System von Inform 6 nicht schlecht, aber die Syntax ist schon sehr speziell und dass Library und Sprache so eng verwoben sind, hindert auch oft.

Zwischen:

printingSubsystem.Resource(Descriptions.CANDLE_PICKUP);
this.universe.Score += this.universe.ScoreBoard[nameof(this.TakeCandle)];

und

After taking the candle if the candle was not handled:
    increase the score by 5;
    say "Vorsichtig löst du die Kerze aus dem Kandelaber."

gibt es noch genug Terrain zu beackern.

Und zu gucken, wie Du es gemacht hast, hat ja auch einen Wert, wenn man das System nicht produktiv nutzt.

Ja, schon. Wobei ich ja durchaus gewillt bin, mir Feedback anzuhören und das Ganze einfacher und zugänglicher zu machen (falls es gute Ansätze dafür geben sollte).

Hm. Ich glaube, ich finde vor allem "Frameworks" nicht so interessant. Textadventures sind doch kleine, kompakte Programme.

Das ist jetzt vielleicht ein Begrifflichkeitsding. Woran ich hier rumschraube, ist eine Komponente mit Parser und Objektmodell (also allem, was man braucht, um ein Textadventure zu coden), und eine web-basierte Darstellungskomponente.

Eine spezielle Sprache für Textadventures kann für die Produktivität beim Schreiben schon helfen.

Genau an dem Punkt bin ich mir tatsächlich nicht so sicher. Das kommt so ein bisschen drauf an, was diese Sprache alles mitbringt. Aktuelle stark typisierte Compiler-Sprachen haben sicherlich erst mal eine etwas höhere Einstiegshürde, aber sie lohnen es einem später im Projekt, weil sie helfen, es beherrschbar zu halten. Ein richtiger Debugger ist bei IF definitiv nicht lebenswichtig, aber nützlich ist es natürlich schon, den Code einfach anzuhalten und sich Werte ausgeben zu lassen.

Zu den Codebeispielen später noch was.

["Framework"] Das ist jetzt vielleicht ein Begrifflichkeitsding.

Ob Du Deinen Parser plus Weltmodell jetzt als "Framework" oder als "Komponente" bezeichnest, ist egal. Du benutzt aber C# und baust damit auf dem .NET-Framework und in der Web-Version auf dem Blazor-Framework auf. Und ohne die geht es ja wohl nicht, oder doch?

Aktuelle stark typisierte Compiler-Sprachen haben sicherlich erst mal eine etwas höhere Einstiegshürde, aber sie lohnen es einem später im Projekt, weil sie helfen, es beherrschbar zu halten.

Hm, weiß nicht. Ist wahrscheinlich auch eine Typ-Sache.

Ich vermute, dass diese aktuellen, stark typisierten Sprachen tendenziell von denen benutzt werden die sie sowieso schon beherrschen.

Und wo sind in einem Spiel wie Mr. Beaver die Dinge, die sich nicht beherrschen lassen? Das ist ja kein riesiges Spiel. Es hat zehn Räume, die allerdings viele Objekte enthalten, und einen NPC oder vielleicht vier, wenn ich die eher objekt-artigen Tiere Barky, Crusty und Bruno dazuzähle.

Wenn ich mir das Beispiel "The Log Cabin" von Biegomars Heretic-Framework anschaue, aus dem der erste Code-Schnipsel oben stammt, dann macht die Aufteilung auf verschiedene Dateien und auf lauter kleine Methodenaufrufe das wirklich kleine Spiel für mich eher schlechter beherrschbar. Das wäre in Inform wesentlich kompakter. (Bin allerdings kein C#-Experte und habe mir das Beispiel auch nur kursorisch auf der git-Seite angeschaut. Vermutlich schreibt man so etwas in einer umfangreichen grafischen Entwicklungsumgebung mit automatischen Querverweisen.)

Und die Komplexität in Mr. Beaver kommt dadurch, dass Du es mit drei verschiedenen Interfaces und auf Deutsch und Englisch gleichzeitig anbieten willst. Wenn Du sagen würdest, ich schreibe ein Parser-Spiel auf Deutsch, dann wäre alles auch besser beherrschbar. (Aber dann wärst Du nicht Stefan Hoffmann, schon klar.)

Du benutzt aber C# und baust damit auf dem .NET-Framework und in der Web-Version auf dem Blazor-Framework auf. Und ohne die geht es ja wohl nicht, oder doch?

Ah ok, jetzt hab ich's. Ja, stimmt, das verwende ich natürlich. Das Ding belegt natürlich einiges an Speicher, nervt ansonsten aber auch nicht groß rum. Da geht natürlich etwas die Kompaktheit flöten, aber das stört ja eigentlich keinen großen Geist, oder doch?

BTW: Wenn man IF-Code und Player gescheit trennt (was ich jetzt konzeptionell schon mal gemacht habe), dann erhält man eine sehr kompakte Assembly-Datei für die Distribution. Da ist dann der ganze mopsige .Net-Kram nur noch im Player enthalten.

Wenn Du sagen würdest, ich schreibe ein Parser-Spiel auf Deutsch, dann wäre alles auch besser beherrschbar. (Aber dann wärst Du nicht Stefan Hoffmann, schon klar.)

Ok, da hast du mich natürlich erwischt. Allerdings erhöhen verschiedene Sprachen zumindest nicht die Komplexität des Logik-Codes. BTW: Ich habe auch nicht behauptet, dass IF-Code wahnsinnig komplex ist und man ohne brutal leistungsfähigen Debugger gar nicht erst anfangen sollte, sowas zu schreiben. Die Aussage war eher: Sprachen wie C# in Kombination mit IDEs á la Visual Studio spielen ihren Entwicklungskomfort umso mehr aus, je komplexer der Code ist.

Eine spannende Info für mich wäre tatsächlich: Wie zufriedenstellend sind die Debug-Möglichkeiten von Inform? Kommt man damit in der Praxis tatsächlich super durch, oder verflucht man das System irgendwann?

Die Code-Aufteilung auf verschiedene Dateien ist nicht unbedingt zwingend bei C#, aber nicht unüblich. Wie du schon ganz richtig vermutet hast: Wegen der umfassenden Möglichkeiten, den Verknüpfungen zu folgen, spielt das nicht ganz so eine große Rolle, wo genau etwas definiert ist.

Mal ein sehr vorläufiges Beispiel:

    bool Handle_Candle(IFOrderSummary order)
    {
        bool handled = false;

        if( order.Id == O_Take.Id )
        {
            StoryOutput("Vorsichtig löst du die Kerze aus dem Kandelaber.");
            SetScoreActive( Candle_Taken);
        }
        return handled;
    }

• Die Methode ist dafür gedacht, alle Logik für die Kerze aufzunehmen. Deshalb wird erst mal die festgestellte Aktion identifiziert und diese dann ausgeführt.
• Die handled-Flags steuern die Gesamtlogik dieser Aktion: Wenn hier ein False zurückgegeben wird, dann triggert dies das Standard-Verhalten für eine Take-Aktion
• Auch keine feste Vorgabe, aber imho sehr empfehlenswert ist das Score-System, was einem einerseits auferlegt, alle Scores erst mal zu definieren. Danach muss man sie nur noch aktiv setzen. Das kann man natürlich dann beliebig oft und von verschiedenen Stellen aus machen. Eindeutig weniger fehleranfällig, als direkt Punkte irgendwohin zu addieren.

Gerade über Codestruktur und Vereinfachungsmöglichkeiten denke ich übrigens gerade sowieso nach. Das geht noch kompakter, ich weiß.

Da ist dann der ganze mopsige .Net-Kram nur noch im Player enthalten.

[You have gained 2 points for re-inventing the interpreter concept.]

Die Aussage war eher: Sprachen wie C# in Kombination mit IDEs á la Visual Studio spielen ihren Entwicklungskomfort umso mehr aus, je komplexer der Code ist.

Soll ja auch jeder das verwenden, mit dem er am besten zurechtkommt. Ich bin jedenfalls eher der Texteditor- und Befehlszeilen-Mensch. (Wahrscheinlich komme ich deswegen auch zu nichts.)

Mein Code steht natürlich auch in mehreren Dateien, aber längst nicht so kleinteilig.

Wie zufriedenstellend sind die Debug-Möglichkeiten von Inform? Kommt man damit in der Praxis tatsächlich super durch, oder verflucht man das System irgendwann?

Man verflucht das System nicht irgendwann, sondern ab Tag 1.

Viele Interpreter bieten Möglichkeiten zum Debuggen. Bocfel hat spezielle Befehle zum Debuggen, die mit einem Schrägstrich anfangen. Im etwas älteren Frotz kann man verschiedene Sachen, etwa das Prüfen und Setzen von Attributen oder das Verschieben von Objekten tracken, allerdings nur global, was zu sehr viel Rauschen führt. Glulxe hat wohl auch einen Debugger, aber ich weiß nicht, wie der aussieht.

Dann gibt es noch Infix, eine Suite von Debug-Befehlen, die in die Spieldatei geschrieben werden.

Ich weiß allerdings nicht, wie sehr diese Möglichkeiten genutzt werden. Ich nutze die ja nie und debugge mit der altbekannten printf-Methode. (Ich schreibe aber auch keine Spiele mit Inform, bin also kein guter Messpunkt.)

Mein Code steht natürlich auch in mehreren Dateien, aber längst nicht so kleinteilig.

Naja, was dir Visual Studio dann generiert, sieht man dann am angehängten Shot. (Das ist eine Liste aller Methoden, die Objekten zugeordnet sind. Im Beispiel sind das ein paar Quatsch-Objekte) Zeile anklicken, dann bist du in der Methode.

Man verflucht das System nicht irgendwann, sondern ab Tag 1.

Ja, das hatte ich mir irgendwie gedacht. Klingt alles nach den typischen Homebrew-Debug-Möglichkeiten, die man halt vergleichsweise billig implementieren kann. Vermutlich für eine IF durchaus ausreichend, aber halt auch kein Overkill an Entwicklungs-Komfort.

Klingt alles nach den typischen Homebrew-Debug-Möglichkeiten, die man halt vergleichsweise billig implementieren kann.

Vielleicht habe ich das nur in den falschen Hals gekriegt, aber das klingt jetzt etwas unnötig herablassend. Ich stelle mal kurz fest, dass in den letzten Grands Prix die Systeme mit den vorsintflutlichen Debug-Möglichkeiten die Nase vorn hatten. Kommt es den Spielern am Ende gar nicht auf den Overkill an Entwicklungs-Komfort an?

(Ja, das war jetzt auch nicht fein. Ich schlage vor, wir lassen's mal gut sein. Ich werde Dich nicht überzeugen können, in die Niederungen des 90er-Jahre-Programmierens hinabzusteigen und Du mich nicht, eine USS-Essex-artige IDE zu installieren. Und für Dritte ist unser Geplänkel gewiss auch nicht sehr interessant.

Ich harre mal der angekündigten Veröffentlichung Deines Frameworks, das ich mir dann interessiert anschauen werde. Ansonsten gibt es im Frühjahr ja wieder einen Grand Prix, bei dem wir die Klingen kreuzen können. En garde!)

Vielleicht habe ich das nur in den falschen Hals gekriegt, aber das klingt jetzt etwas unnötig herablassend.

Woah, bitte nicht sowas in meine Postings reinlesen! Ich meinte doch eigentlich nur, dass ich es logisch finde, bei IF-Frameworks auf eher einfache Debug-Lösungen zu stoßen, denn a) man sollte einigermaßen weit damit kommen, und b) umfassende Lösungen wie ein richtiger Debugger á la Visual Studio einen völlig unverhältnismäßigen Aufwand bedeuten würden.

Und dass ich am Ende zuviel Zeit ins Coden und zu wenig Zeit ins Storytelling/ Game Design stecke, ist nebenbei bemerkt durchaus richtig beobachtet.

Und für Dritte ist unser Geplänkel gewiss auch nicht sehr interessant.

Was ich ja sehr schade finde.

Ich harre mal der angekündigten Veröffentlichung Deines Frameworks, das ich mir dann interessiert anschauen werde.

Gerne. Ich bin wirklich sehr gespannt drauf, ob da irgendwer außer mir was mit anfangen kann.