Hallo!

Welcher Guru-Beitrag hat euch eigentlich am besten gefallen? Habt ihr auch alle Max vorne gesehen? Ich will Andreas Entscheidung nicht in Frage stellen, aber mich interessiert schon, ob es auch andere Meinungen gibt.

Ich selbst kann es nicht wirklich beurteilen, da mir Inform fremd ist. Wenn ich Max' Code lese, verstehe ich zwar ungefähr, worum es geht, aber nicht mehr. Zwei happige Bugs sind drin, und die Beschreibungen sind etwas lieblos - aber für Beschreibungen gab es ja höchstens Bonuspunkte.

Bei Martins Beitrag funktioniert wie bei Max "> nimm alles" nicht so, wie es sollte. Trotzdem ist er aber klar der beste TAG-Beitrag. Ich werde schon neidisch, wenn ich seinen Code lese. Alles, worum ich so lange gerungen habe, kurz und elegant, als würde es gar keine Mühe kosten. Schönes Anschauungsmaterial für jeden, der TAG lernen will. Dazu kommt die tolle Schlußpointe, die ich sehr, sehr traurig fand. seufz Hat mich richtig berührt. IF-Autoren sind eben ein einsames Volk.

Florians Beitrag ist ein richtiges Spiel geworden und zwar ein gutes. Hat mich richtig begeistert. Florian war fast beleidigt deswegen, weil er es wohl selbst nicht so gut findet, aber ich sehe das Spiel als ein kleines Meisterwerk. Gewinnen konnte er natürlich nicht, da er spezielle Lösungen statt allgemeine benutzt hat.

Tja, mein eigener Beitrag: Ich hab's versucht. Besser kann ich es nicht. Inspiration hatte ich keine. Aber man sieht wunderbar, wie ich programmiere: Denkt euch noch alle Tabulatoren weg und mischt die Blöcke lustig durcheinander, und ihr habt Original-Code von mir.

Eure Meinungen?

Inhaltlich lag für mich ganz klar Martin vorne. Den TAG-Code kann ich nicht beurteilen. Und Max' Inform-Lösung habe ich mir noch nicht ausführlich genug angesehen, um behaupten zu können, dass ich sie wirklich verstanden habe. Beim Spielen habe ich mich jedenfalls gefragt, was der zweite Raum im Spiel soll.

Tanan:

Bei Martins Beitrag funktioniert wie bei Max "> nimm alles" nicht so, wie es sollte.

Dass "nimm alles" nicht richtig klappt, habe ich bei Max natürlich sofort gemerkt, bei mir jedoch nicht. Hmmm.

Die Implementierung mit den Klassen 'Unsichtbar' und 'DunklerRaum' ist schon eines Guru würdig. Die Realisierung des Bodens als Klasse scheint mir aber etwas kompliziert. Wieso benutzt der Boden nicht 'found_in'? Und wieso ist das Vokabular doppelt definiert, einmal bei der Klasse und dann beim Kellerboden?

Der zweite, nicht halbdunkle Raum dient wohl nur zum Testen, ob die Lösung allgemein gültig ist. Der Schluss scheint mir etwas unrealistisch. Aber vielleicht schreibe ich ja nur die falschen Briefe?

Die drei T.A.G.-Beiträge sind unterschiedlich. Jens arbeitet mit einem Dummy-Raum, einer Kopie des halbdunklen Raums. Um mehrere halbdunkle Räume zu implementieren, müsstest Du gar nicht zu jedem Raum einen Dummy-Raum programmieren, Jens - einer würde genügen. Du müsstest nur sicherstellen, dass bei einem Raumwechsel alles vom Dummy-Raum in den alten halbdunklen Raum geräumt wird und dann alle kleinen Dinge in den Dummy-Raum verschieben. Und es bleiben noch 251 Räume übrig, die wollen erst einmal implementiert werden.

Florians Ansatz ist der unkomplizierteste, der genau auf die eine Situation zugeschneidert ist. Er macht Gebrauch vom Unterschied zwischen den beiden Räumen 'nirgendwo' und 'Nirwana', um zu überprüfen, ob der Schlüssel schon gefunden wurde - das ist gar nicht so unelegant. Guru kann Florian damit nicht werden, aber für Einsteiger ist diese Lösung bestimmt die geeingnetste.

Mein Code ist der, der am schlechtesten kommentiert ist. (Dafür bin ich derjenige, der seinen Code am schönsten einrückt...) Die Überprüfung, ob es Licht im halbunklen Raum gibt, macht den Raum dunkel, und wenn dann (Licht_In aRaum) ist, muss es eine Lichtquelle geben.

IF-Autor Jens:

IF-Autoren sind eben ein einsames Volk.

Für hoffnunglose Fälle gibt es ja jetzt das Forum.

seufz

Es war wirklich nicht einfach mit der Entscheidung, die Beiträge von Max und Martin lagen schon recht dicht beieinander, auch in meiner Bewertung. Die Lösung von Max war nur an einer Stelle etwas allgemeiner, was diesmal den Ausschlag gegeben hat. (Martin hat beim Boden die Abfrage "Wenn (aRaum = Keller) dann" benutzt). Der zweite Raum diente bei Max dazu, um zu demonstrieren, daß die Eigenschaft, daß ein Raum halbdunkel ist, sich einfach auf andere Räume übertragen läßt.

Und leider ist mir der eine Fehler bei Max nicht gleich aufgefallen, ich muß beine Betatests wohl nächstes mal noch verbessern ops:

Mir hat die Lösung von Martin ja auch gut gefallen, so gesehen kann sie ebenfalls als eine Musterlösung angesehen werden.

Es gibt ja hoffentlich noch viele Gurus, so daß jeder eine Chance hat!

viele Grüße,

Andrea

Du hast Dir da keine leichte Aufgabe aufgehalst, Andrea. Einer muss aber Guru werden, Du sollst Dich nicht rechtfertigen müssen. Mit dem Fazit und dem Veröffentlichen aller Sources können sich Interessierte ja schnell einen Überblick schaffen.

Die Wahl wird natürlich durch den Vergleich von Äpfeln (Golden Inform) mit Birnen (Williams TAG) nicht eben einfacher.

Andrea:

(Martin hat beim Boden die Abfrage "Wenn (aRaum = Keller) dann" benutzt)

Aaaargh! Ich war so nah! Und dann das... War es Überheblichkeit, die mich beim Griff nach der goldenen IF-Kutte unachtsam werden ließ?

Die Gurumacherin:

Und leider ist mir der eine Fehler bei Max nicht gleich aufgefallen, ich muß beine Betatests wohl nächstes mal noch verbessern

Mir sind meine eigenen Fehler auch nicht aufgefallen. Aufgefallen ist mir aber, dass Florian der einzige war, der seinen Beitrag testen lassen hat. Das war professionell.

Benutzt Du eigentlich beim Testen der Beiträge einen vorgegebenen Walkthrough?

Zitat:

Um mehrere halbdunkle Räume zu implementieren, müsstest Du gar nicht zu jedem Raum einen Dummy-Raum programmieren, Jens - einer würde genügen

Wow, stimmt. Darauf hätte ich kommen können.

Zitat:

Die Überprüfung, ob es Licht im halbunklen Raum gibt, macht den Raum dunkel, und wenn dann (Licht_In aRaum) ist, muss es eine Lichtquelle geben.

Ja, das hab ich auch so gemacht. stolz Nur viel umständlicher.

Ach so, für diejenigen, die sich fragen, was der 2. Bug bei Max' Beitrag ist: Gebt bei Spielbeginn "> lies brief" ein. Nichts für ungut.

Hallo Martin,

ja, ich hab schon eine Art Walkthrough gehabt, allerdings hätte ich doch noch ein paar Seitenwege mehr berücksichtigen sollen.

Bei Inform hab ich die Sourcen im Debug-Modus kompiliert und konnte dann die Befehle aufzeichnen und hab daran gedacht, diese in den anderen Spielen wiederzugeben.

Soweit ich rausgefunden habe, ging das bei den TAG-Spielen nicht, und so hab ich mich nach dem Testen der wichtigsten Sachen auf meine Intuition verlassen.

Grüße,

Andrea

Andrea:

Soweit ich rausgefunden habe, ging das bei den TAG-Spielen nicht, und so hab ich mich nach dem Testen der wichtigsten Sachen auf meine Intuition verlassen.

Man kann keine Liste der eingegebenen Befehle (Record) herausschreiben, wie es mit der Z-Maschine möglich ist. Man könnte sich aber die Befehle aus einem Transkript extrahieren. (Was aber mühsam ist, da unter MS-DOS so schöne Tools wie grep und awk fehlen.)

Einen solchen Record abspielen kann man, in dem man die Abfolge der Eingaben aus einem Texteditor kopiert und sie mit Copy&Paste ins MS-DOS-Fenster vom T.A.M. einfügt.

Ahh, danke Martin.

Das mit dem Copy&Paste wußte ich nicht. Die Befehle hab ich ja durch das Inform-Spiel schon in einer ASCII-Textdatei!

Ich hab's gerade ausprobiert, das funktioniert ja wunderbar, zumindest wenn man die Umlaute mit ae, oe, ue umschreibt.

D

viele Grüße,

Andrea

Hallo Andrea, nimm doch WindowsFrotz 2000 als Interpreter, er kann wunderbar mit Umlauten umgehen und ae ue oe gehört bei Inform Spielen der Vergangenheit an... 8)

Das Problem bestand nicht darin, Umlaute beim Inform-Spiel einzugeben, ich verwende WinFrotz2000.

Beim Abspeichern der Befehle (recording on) werden die Umlaute in der Textdatei aber in folgender Form gespeichert:

nimm h[155]ssliche Murmel

(WinFrotz mit dem Patch zeigt übrigends das gleiche Verhalten)

Das kann TAM dann natürlich nicht interpretieren. Zudem verwendet TAM bei der Eingabe den DOS-Zeichensatz, so daß da auch noch eine Umwandlung nötig wäre, wobei das kein Problem wäre, das geht z.B. in Ultraedit recht schnell.

Aber wie gesagt, so wichtig ist das nun auch nicht, solange Inform beide Versionen versteht, ist mir das zumindest bei den Testskripten egal.

Wenn ich ein Spiel richtig spiele, finde ich es aber auch angenehm, die Umlaute verwenden zu können.

viele Grüße,

Andrea