Oliver:

galickis:

Ich bin von der Idee wirklich begeistert. Java eröffnet absolut neue Möglichkeiten, z.B.:

Alle Attribute, die in Inform auf "-able" enden können in Java als (ggf. leere) Interfaces implementiert werden. Es ist wohl klar, dass "closeable" eine andere Art Attribut ist als "close". Ersteres ist nämlich eine Eigenschaft/Fähigkeit, letzteres dagegen ein Zustand.

Nein, das ist ganz einfach: Java-Objekte bestehen, wie eigentlich Objekte in allen OO-Sprache, aus Methoden und Eigenschafen. "close" wäre in diesem Fall eine Methode (d.h. eine Funktion) und "closeable" eine Eigenschaft (d.h. eine Klassenvariable). Das ist alles, wenn man das einmal kapiert hat, eigentlich ganz logisch.

Gruß,

Oliver

Ups, ich habe eigentlich "closed" und nicht "close" gemeint, was den Sinn der Aussage natürlich ändert.

tomjoad:

Hust, hust. Das ist eins der ganz großen Probleme von Java, nämlich daß alles in eine objektorientierte Zwangsjacke forciert wird, auch wenn's Unsinn ist - java.lang.Math ist ein wunderschönes Beispiel für OOP wie's nicht sein sollte oder besser, was passiert wenn man OOP in Reinkultur betreiben will.

[...]

Im Übrigen sehe ich darin keine Antwort auf das Problem - sollen Spielobjekte etwa nur aus statischen Methoden bestehen? Du mußt sie trotzdem instanzieren - oder wie willst Du Dir in Variablen die Objekte merken - die Klasse merken? Und damit kannst Du auch die Polymorphie optimal ausnutzen? Und wie klappen Deine "Attribute als Interfaces" wenn ein Spielobjekt eine Klasse mit nur statischen Methoden ist?

Du hast tausendmal Recht. Das ist nicht die Lösung des Problems. Das habe ich inzwischen auch verstanden. Man könnte das (hoffentlich) mithilfe der Reflection-API lösen.

Irrelevant aber wahr: In Python wäre das Problem einfacher zu lösen. In dict des Moduls nachschlagen, mit issubclass überprüfen und mit new.instance erzeugen. Wenn's in Java so einfach wäre...

galickis:

Oliver:

Als nächstes steht jetzt der wohl schwierigste Teil an, nämlich der Parser. Aber dafür gibt es bei Java auch Hilfsmittel wie antlr oder jlex, das ist ja gerade das Schöne an der Sache.

JLex & Co. für die erzeugung der Grammatik zu verwenden wäre, denke ich, nicht besonders sinnvoll. Schließlich muss die Grammatik on-the-fly erzeugt werden.

Na gut, ich habe mir nochmal das Designer's Manual durchgelesen. Informese hat seine eigene Grammatik. (Ich glaube sie ist sogar regulär, was hier irrelevant ist). In diesem Fall macht ein vorher generierter Parser Sinn. Soll die Grammatik eher aus Schablonen bestehen (ein bisschen wie in Floyd), dann wiederum nicht.

galickis:

Dass Java keine mehrzeiligen Strings zulässt, ist eigentlich schade. Ich hätte keine Lust, zusätzliche Anführungs- und Pluszeichen zu schreiben. Man könnte allerdings ein kleines Programm benutzen, das alle Strings java-konform macht und das veränderte Programm an den Compiler weitergibt.

Ohne mehrzeilige Strings wäre mir das auch nichts. Vielleicht ist ja eine Sprache wie 'Ruby' oder auch 'PHP' doch besser geeignet.

Ein zusätzliches Programm könnte dagegen vielleicht gleich mehr machen: Automatisch alle Texte in Textdateien auslagern. Dann hat man auch die Möglichkeit, Texte direkt im Code zu schreiben und trotzdem noch durch unabhängige Korrekturleser durchsehen zu lassen. Für Release-Versionen könnten die Texte gleich verschlüsselt werden. Dann fehlt nur noch ein Tool, mit dem die korrigierten Texte auch automatisch zurück in den ursprünglichen Code gelangen (möglichst an die alte Stelle!), sonst kann man ja nicht sinnvoll weiter "codieren". Das wäre mal ein Vorschlag für ein Feature, das es auch bei anderen Autorensystemen so noch nicht gibt - so viel ich weiß.

...dagegen wäre es auch nicht uncool, ein solches Tool für Inform, TAG etc. zu schreiben. Gibt es hier Autoren, die sich prinzipiell für so etwas interessieren würden?

...falls es so etwas für das ein oder andere System schon gibt, wo ist es evtl. zu finden? Ich will ja nicht schon wieder ein Rad erfinden.

Thomas

Thomas:

Ohne mehrzeilige Strings wäre mir das auch nichts. Vielleicht ist ja eine Sprache wie 'Ruby' oder auch 'PHP' doch besser geeignet.

Oder Python. Wie wäre es eigentlich mit einer "hybriden" Lösung? Die Bibliothek kann z.B. in Java geschrieben sein, während das Spiel als Python-Programm mit Jython (oder Java-Programm mit BeanShell) ausgeführt wird.

Ich weiß schon, die Antwort wird lauten, warum man nicht gleich alles in Python schreibt. Darum: Für Java gibt es Implementierungen mehrerer Skript-Sprachen. Jython ist die beliebteste. Dann gibt es BeanShell. Diese Sprachen haben alle gemeinsam, dass man aus dem Skript heraus auf die Java-Klassen zugreifen kann (auch zum Subclassing). Im Endeffekt würde dies Bedeuten, dass der Entwickler die Wahl zwischen mehreren Programmiersprachen haben, die alle sehr bequem zu programmieren sind und z.B. bessere String-Funktionen bieten als Inform (und da ist noch die Begrenzung von 8 Zeichen für Dictionary-Einträge und andere Unannehmlichkeiten...)

So, und damit geht das Brainstorming weiter!

Der obige Beitrag über hybride Lösungen stammt von mir - hab vergessen mich anzumelden.

galickis:

Ups, ich habe eigentlich "closed" und nicht "close" gemeint, was den Sinn der Aussage natürlich ändert.

Na und, was soll daran so schwierig sein? Ein Zustand ist auch nur eine Variable. Wenn "Closed" nur wahr oder falsch sein kann, nimmt man halt eine Boolean-Variable (sofern dieser Datentyp in der jeweiligen Programmiersprache verfügbar ist), wenn man mehrere Werte braucht, nimmt man eben eine Integer-Variable.

Gruß,

Oliver

Oliver:

galickis:

Ups, ich habe eigentlich "closed" und nicht "close" gemeint, was den Sinn der Aussage natürlich ändert.

Na und, was soll daran so schwierig sein? Ein Zustand ist auch nur eine Variable. Wenn "Closed" nur wahr oder falsch sein kann, nimmt man halt eine Boolean-Variable (sofern dieser Datentyp in der jeweiligen Programmiersprache verfügbar ist), wenn man mehrere Werte braucht, nimmt man eben eine Integer-Variable.

Gruß,

Oliver

Nichts ist schwierig, aber der Unterschied zwischen einer Methode und einem Feld einer Klasse ist wohl eindeutig. Außerdem ist die Frage einer weiteren Diskussion nicht wert.

Puh. Dieser Thread passt ja genau zu meinem Thema!

Hallo erstmal. Ich bin neu in diesem Forum, und das Thema dieses Threads ist genau der Grund, warum ich mich hier angemeldet habe. Java programmiere ich sowohl beruflich als auch privat schon ziemlich lange (seit etwa 1992 oder 1993). Darum sind mir die Grenzen und Contras von Java wohlbekannt, und es ist klar, dass Java nicht ganz so toll ist wie alle behaupten.

Aber trotzdem ist es die Programmiersprache, die ich zur Zeit favorisiere. Die Gründe dafür will ich jetzt nicht lang und breit ausführen, aber wenn sich jemand dafür interessiert, kann ich sie gern nennen.

Das Ziel, eine Java-Plattform für Textadventures zu schaffen, hält sich bei mir schon seit sicherlich gut zehn Jahren. Aber Ihr wisst ja wie das so ist: Es kommt einem immer was dazwischen, andere Dinge sind einem wichtiger. Und eigentlich ist es sogar gut, dass ich z.B. vor 5 Jahren noch nicht viel Zeit darin investiert habe - denn heute entwickle ich ganz, ganz anders als früher und müsste wohl alles neu schreiben. (Ist es nicht immer so? )

Kurzum: Vor etwa einem halben Jahr habe ich wieder damit angefangen. Eine ausführliche Suche im Internet hat schon gezeigt, dass es interessante Projekte gibt, vor allem im MUD-Bereich. Aber ehrlich gesagt - wenn ich mir den Programmcode dieser Projekte anschaue, wird mir schon nach kurzer Zeit übel. Außerdem verwenden die mir für meinen Geschmack zu viel Schnickschnack. Wozu brauche ich eine JavaScript-Engine in einer Textadventure-Engine, die sowieso schon in Java implementiert ist? Das schafft nur unnötige Verwirrung und komische Fehlermeldungen.

Naja, das ist meine Meinung. Ich sehe durchaus ein, dass man auch anderer Meinung sein kann. Aber mein Projekt führe ich ja nur für mich allein durch, und da ich in solchen Dingen Perfektionist bin, will ich natürlich alles, dass alles exakt so ist, wie ich es gern mag.

Hier eine kurze Übersicht über "meine" Engine und Stellungnahmen zu einigen Punkten, die ich hier schon gelesen habe:

"Meine Engine"

Der Arbeitstitel ist "Ether Storm", in Anlehnung an ein Adventure, das ich mal vor langer Zeit schreiben wollte. Der Name tut eigentlich nichts zur Sache, aber "ES" schreibt sich einfach besser als "meine Engine".

Zielbereich

ES soll sowohl für MUDs als auch für herkömmliche Singleplayer-Textadventures geeignet sein. Das hat zwei wesentliche Konsequenzen:

1. Die gesamte Engine muss threadsafe programmiert sein.

2. Der Timer-Dienst muss sowohl synchronen als auch asynchronen Zeitverlauf unterstützen.

Erweiterungen sind natürlich beliebige denkbar, wie etwa eine "Automap" im separaten Fenster oder formatierter Text. Aber zunächst mal will ich das reine Textadventure unter Dach und Fach bringen.

Sprachunterstützung/Parser

Die Sprachunterstützung soll hervorragend sein. Das System zur Sprachanalyse soll gleichzeitig genutzt werden, um in begrenztem Umfang auch natürlichsprachliche Sätze zu generieren.

Das heisst, dass die Spiel-Engine eine gewisse Kenntnis von Worten und Grammatik besitzen muss. Anders als bei anderen Engines verwendet der Parser kein Pattern-Matching, sondern baut sich tatsächlich einen Syntaxbaum zusammen. Umgekehrt kann man natürlich einen Syntaxbaum als Objekt erstellen und diesen dann als natürlichsprachlichen Satz ausgeben lassen. (So könnte man z.B. die grammatische Struktur von "nimm schwert" herausparsen und relativ leicht automatisch eine Antwort wie "Du nimmst das Schwert" daraus machen.)

Eine Konsequenz daraus ist beispielsweise, dass alle natürlichsprachlichen Worte zentral in einem globalen Objekt ("Dictionary") gehalten werden. Während einige Engines beispielsweise den Namen eines Objekts etwa so zuweisen:

ObjectClass object = ...;

object.addName("Schwert");

object.addName("Schwerts");

object.addName("Schwertes");

object.addName("Schwerte");

Wird es in ES in etwa so durchgeführt:

ObjectClass object = ...;

Dictionary dictionary = ...;

Word sword = dictionary.getNounByID("nl.noun.sword");

object.addName(sword);

Aber dieses Beispiel ist sowieso nur hypothetisch, denn Objekte werden sowieso anders instantiiert:

Persistierung

Objekte speichern ist ein echtes Problem - nicht nur in Java, sondern allgemein. Java liefert dafür eine ziemlich einfach API. Nur leider werden die Objekte dann alle zusammen in eine Binärdatei geschrieben, die nicht einfach so editierbar ist.

Um "die Welt zu erschaffen", müsste man sich also ein eigenes Java-Programm schreiben, welches per Java-Kommandos alle Objekte aus der Spielwelt anlegt und am Ende alles in eine solche Binärdatei schreibt. Dies wäre dann das Savefile, welches bei Spielbeginn geladen würde. Ganz schön unpraktisch, diese Vorgehensweise.

Einige gehen darum den Weg, ihre Klassen mit irgendwelchen "load" und "save"-Methoden auszustatten, welche die Daten des Objekts in irgend eine hübsche Struktur speichern, damit sie z.B. bequem mit dem Texteditor die Savefiles erstellen und verändern können. Schon besser, aber es hat leider den entscheidenden Nachteil, dass die Persistierung nicht mehr transparent ist: In jeder Klasse hat man den Overhead, die "load" und "save"-Methoden zu erweitern. Vergisst man es, werden die Daten nicht korrekt gespeichert.

Darum habe ich mich entschieden, einen dritten Weg zu gehen: Ich benutze die [url=xstream.codehaus.org]XStream-Bibliothek[/url], die eine transparente Persistierung von Objekten in XML-Dateien ermöglicht. Klappt prima - ich musste XStream nur leicht erweitern, um die Welt in mehrere Savefiles aufzuteilen und das XML-Format geringfügig übersichtlicher zu gestalten. Die Welt wird also mit dem XML-Editor erschaffen. Das obige Beispiel würde also eher so aussehen:

<object class="es.world.Physical">

<id>world.demoObject</id>

<name ref="nl.noun.sword"/>

...

</object>

Und damit bin ich dann ganz zufrieden. Natürlich kann man am Ende auch einfach alles in ein Binärfile schreiben. Aber zumindest für MUDs und für die Entwicklungsdauer eines Adventures ist es mir wichtig, die Spieldaten "ordentlich", übersichtlich und leicht editierbar abzulegen. Außerdem kann ich so natürlich ziemlich einfach das Dictionary zusammenschreiben.

Kommando-Modellierung

Wie schon beschrieben, gibt es Klassen für natürlichsprachliche Ausdrücke. Die Eingabe des Benutzers wird zunächst in ein grammatisches Objekt umgewandelt. Anschließend wird ein "Aktions-Verzeichnis" durchsucht, um herauszufinden, welche "Aktionen" man aus diesem grammatischen Konstrukt ableiten könnte. Hier ist ein Unterschied zu anderen Adventure-Engines: Typischerweise hängen alle Aktionen, die man mit einem Objekt durchführen kann, an dem Objekt selbst. Aber ich ziehe es vor, Aktionen abstrakt und global zu modellieren. Hat den Vorteil, dass Änderungen an den Aktionen (z.B. ein neues, alternativ benutzbares Verb) sich auch auf alle Aktionen dieser Art auswirken. Sprich: Nicht das Objekt entscheided, was mit ihm getan werden darf, sondern das Kommando entscheided, ob es auf seine Objekte anwendbar ist.

Nichtspielercharaktere

Es soll besonderes Augenmerk auf Nichtspielercharaktere gerichtet werden. Ein "Tagesablauf" wäre ein Standard-Feature, aber die NSCs sollen darüber hinaus auch in der Lage sein, Ziele zu verfolgen und zu priorisieren. Auch im Singleplayer-Spiel soll der Eindruck entstehen, in einer lebendingen Spielwelt zu spielen.

Dynamischer Handlungsrahmen

Die Handlung der Abenteuer soll maßgeblich von den NSCs abhängen. So ergeben sich sehr dynamische Abenteuer, und der Spieler muss sich schon etwas mit der Spielwelt beschäftigen, um voranzukommen. Es soll ein ähnliches "Gefühl" aufkommen wie damals bei den Spielen der Ultima-Reihe, in denen der Spieler das Gefühl hatte, völlig frei in einer realistisch simulierten Welt agieren zu können.

Status

So, soviel erstmal dazu. Es funktioniert erst recht wenig. Der Parser funktioniert fragmentarisch, das Aktionssystem existiert noch nicht. (Ich habe es wieder gelöscht, weil es mir nicht gefiehl.) Bei den Containment-Relationen bin ich einen etwas ungewöhnlichen Weg gegangen, um keinen Multithreading-Deadlocks und auch keinen Fehlern durch Veränderungen während Iterationen ausgeliefert zu sein: Der Containment-Baum ist ein eigenständiges Objekt, und die Kinder bzw. das Environment wird nicht in den Objekten der Spielwelt selbst gespeichert. Das Dictionary und alles was damit zu tun hat existiert, und das zusammensetzen von sprachlichen Sätzen funktioniert recht gut.

So arbeite ich mich langsam da durch. Ich halte Euch über Neuigkeiten auf dem Laufenden, aber da ich auf der Arbeit immer sehr eingespannt bin, wird das ziemlich lange dauern!

Crowley:

Aber trotzdem ist es die Programmiersprache, die ich zur Zeit favorisiere. Die Gründe dafür will ich jetzt nicht lang und breit ausführen, aber wenn sich jemand dafür interessiert, kann ich sie gern nennen.

Würden mich zumindest interessieren (muß nicht lang und breit sein). Wie Du vielleicht aus meinen Beiträgen in diesem Thema lesen kannst, bin ich nicht gerade ein glühender Befürwörter von Java als Sprache für Textadventures. Wäre auch interessant, welche anderen Sprachen Du kennst und warum Java geeigneter erscheint.

tomjoad:

Würden mich zumindest interessieren (muß nicht lang und breit sein). Wie Du vielleicht aus meinen Beiträgen in diesem Thema lesen kannst, bin ich nicht gerade ein glühender Befürwörter von Java als Sprache für Textadventures. Wäre auch interessant, welche anderen Sprachen Du kennst und warum Java geeigneter erscheint.

Ich würde noch nicht mal meinen, dass Java für Textadventures speziell geeigneter wäre als andere Programmiersprachen. Inform beispielsweise ist perfekt geeignet, wenn man eins der üblichen Textadventures schreiben will, und genau das würde ich auch jedem empfehlen, der mich danach fragt!

Aber als beruflicher Programmierer fühle ich mich mit Inform ziemlich unterfordert. Nachdem ich die Grundbegriffe der Sprache verstanden hatte, suchte ich zunächst einmal nach dem Befehl für das Anlegen eines neuen Objekts - und zwar dynamisch, also zur Laufzeit. Als ich herausfand, dass es einen solchen Befehl nicht gibt, sondern alle Objekte in einem Inform-Adventure lediglich statisch existieren, musste ich das System, das ich mir für die dynamisch handelnden NSCs ausgedacht hatte, komplett kippen.

Auch musste ich schnell einsehen, dass meine Ideen recht schnell den Skopus der Inform-Maschine sprengen würden. Das ist ja auch "in Ordnung", denn Inform-Adventures sind miniklein und laufen sogar auf mobilen Geräten. Leider kann man Inform nicht als Basis für ein MUD benutzen, und es wird auch schwierig, wenn man allein schon ein "Echtzeit-Adventure" schreiben will (bei dem also die Engine nicht wartet, bis der Benutzer Return drückt, sondern die Welt in Echtzeit weitersimuliert). Außerdem mag ich die Mode, seine Konfiguration in XML-Dateien abzulegen und derlei Schnickschnack. Bei Inform hat man mit sowas natürlich verloren. Mir fehlen auch die Möglichkeiten der objektorientierten Entwicklung im größeren Stil, also mit Interfaces, abstrakten Klassen, anonymen Implementierungen und derlei mehr. Ein Stück weit ist das einfach eine Vorliebe von mir, ohne tiefere rationale Begründung.

Dann gibt es Vorteile von Java, die aber genauso auch in Inform und/oder .net vorhanden sind: Java ist mittlerweile ausgesprochen stabil, gibt einen hervorragenden Support für Multithread-Entwicklung mit, kommt mit einer großartigen Standardbibliothek, ist (mittlerweile) ziemlich fix in der Ausführung.

Die Gegenargumente, von denen ich hier gelesen habe, sind mit Vorsicht zu genießen: So ist es natürlich klar, dass man sich mit einer differenzierten Klassenhierarchie auch was verbaut. Das Wesen einer effektiven Programmiersprache besteht nunmal grade in der Beschränkung des Programmierers; dadurch wird sie nicht komplizierter, sondern einfacher. Zum Tragen kommen die Nachteile der Klassenhierarchie allerdings nur, wenn man nach dem falschen Paradigma programmiert. Generell ist es eine gute Idee, größtenteils Interfaces zu schreiben und so weit wie möglich auf Implementierungsvererbung zu verzichten. Stattdessen sollte man simple Integration verwenden, was mindestens genauso gut funktioniert und transparenter und wartbarer ist. Diese Erkenntnis hatte sich leider noch nicht durchgesetzt, als Java damals entworfen wurde, aber trotzdem kann man in Java ganz wunderbar nach diesem Paradigma programmieren. (Prima Artikel dazu: http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html )

Dann wurde angedeutet, dass Java zur Behandlung von Text nicht gut geeignet ist. Wieder kann ich antworten: Das stimmt, solange man voraussetzt, dass schlecht programmiert wird. Wenn Du ausschließlich auf der String-Klasse arbeitest, hast Du bei komplexeren Anwendungsfällen (wie z.B. Textadventures) verloren. Aber wer objektorientiert denkt, der macht sich seine Wrapper-Klassen für alles, getreu dem Motto "divide & conquer", und dann sieht die Sache ganz anders aus. Ein Grund, warum viele Leute davor zurückschrecken, ist die Angst davor, zu viele Objekte zu instantiieren und somit zu viel Speicherplatz zu verschwenden. Diese Angst ist (weitgehend) unbegründet: Grade heute macht es keinen Unterschied mehr, ob Dein Programm ein paar Dutzend Kilobytes mehr verbraucht oder nicht, und erst wenn man mit wirklich vielen Objekten arbeitet, kommen die Vorteile der Objektorientierung wirklich zum Tragen (sowohl in der Güte des Programmcodes als auch in der Performance). Die modernen VMs sind darauf ausgelegt, dass viele kurzlebige Objekte existieren, sie stellen sich dynamisch auf den "Objektdurchsatz" ein, so dass man es sich wirklich nicht mehr so vorstellen kann, dass für jeden "new"-Aufruf auf Maschinenebene ein "malloc" aufgerufen würde.

Naja, aber am Ende des Tages ist es dann wohl doch eine Geschmacksfrage. Für das, was ich vorhabe, ist Inform gar nicht oder bestenfalls eingeschränkt geeignet. Für "herkömmliche" Textadventures hingegen ist Inform ganz klar das Mittel der Wahl. Stünde allerdings die Wahl zwischen Java und C(++), würde ich ganz klar für Java plädieren. Denn in C(++) fehlt die Garbage Collection sowie die Introspektion, die man direkt oder indirekt für die Persistierung des Weltzustands benötigt. Hey, und ich weiß wovon ich rede, denn ich habe früher mal eine kleine Textadventure-Foundation in ObjectiveC geschrieben!

Crowley:

Nachdem ich die Grundbegriffe der Sprache verstanden hatte, suchte ich zunächst einmal nach dem Befehl für das Anlegen eines neuen Objekts - und zwar dynamisch, also zur Laufzeit. Als ich herausfand, dass es einen solchen Befehl nicht gibt, sondern alle Objekte in einem Inform-Adventure lediglich statisch existieren, musste ich das System, das ich mir für die dynamisch handelnden NSCs ausgedacht hatte, komplett kippen.

Kleine Anmerkung meinerseits, wobei ich als Nichtprogrammierer deine Ausführungen sonst sehr plausibel finde: Auf sehr eingeschränkte Weise beherrscht Inform das schon. Beispiel:

                                             ! dynamisch erschaffene

                                             !Liquid-Objekte

    with Menge,                     !in 100ml-Schritten

         short_name, name, dekl, description,

         before [; Take, PutOn, Lift: print_ret "Das gestaltet sich

                          bei Flüssigkeiten schwierig...";

                   Empty: print "Du verschüttest ",(der)self, ".^";

                          Liquid.destroy(self);return;];```

Das hab ich mal benutzt, um Flüssigkeiten in Inform zu programmieren, die ja teilbar sein sollten. Nachteil ist, dass du exakt angeben musst, wieviele Objekte du von dieser Klasse höchstens dynamisch anlegen kannst (die Zahl in Klammern).

Dann könnte ich mit

```Wasser = Liquid.create()```

einen Wasserhahn Wasser erzeugen lassen. Das Objekt wird dann durch Verschütten wieder gelöscht.

Wie gesagt, von den Möglichkeiten her sehr beschränkt. Aber vollständig unmöglich ist es nicht.

So, ich melde mich mal wieder (Entschuldigung dafür, daß ich so lange "untergetaucht" bin, aber ich hatte tlw. noch andere Dinge zu tun, tlw. war ich schlicht und einfach zu müde und lustlos). Mit Eclipse unter Linux hatte ich immer Probleme, so daß dies dem Fortschritt des Projekts nicht gerade nützlich war. Jetzt bin ich aber auf NetBeans umgestiegen (da ist gerade die neue Version 5.0 herausgekommen, die enthält auch einen der besten GUI-Builder in der Branche). Eine erste Version von JAGD ist jetzt auf meiner Homepage verfügbar, und zwar sowohl als JAR-Archiv wie auch als Quelltext. Die URL ist:

http://www.mydarc.de/dl1yov/java.html

Das ist nur eine erste "Rohversion", die sicher in der nächsten Zeit noch erweitert wird.

Gruß,

Oliver

Hiho,

Oliver:

Eine erste Version von JAGD ist jetzt auf meiner Homepage verfügbar, und zwar sowohl als JAR-Archiv wie auch als Quelltext. [...]

Das ist nur eine erste "Rohversion", die sicher in der nächsten Zeit noch erweitert wird.

Jo, der war gut ;-) Wenn ich mir die bislang publizierte API dieses Projekts so anschaue, steht Dir noch eine Menge Arbeit bevor. Evtl. würde ich auch ein Redesign der schon exisiterenden Klassen empfehlen.

Entschuldige, nicht in den falschen Hals bekommen, aber bist Du Dir sicher, dass Du das schaffst? Hast Du Dir mal den Sourcecode von anderen Textadventure Libraries angeschaut? Ist Dein Ansatz da nicht etwas zu "einfach"?

Ich will wirklich nicht nur "runtermachen", aber sowas (4 Klassen, 20 Zeilen Sourcecode) selbst als "Rohversion", zu veröffentlichen ist etwas gewagt.

Meine Vorschläge: Entwickle Deine Konzepte erstmal etwas detaillierter auf dem Zeichenbrett. Ein strukturierteres Klassenkonzept muss dringend her.

Nichts für ungut,

Olav

So, ich hab ja lang nichts mehr geschrieben. Mein Java Textadventure-Projekt lebt noch. Genauer gesagt: Ich bin in die zweite Runde gegangen. Ich habe das Projekt nochmal auf einer solideren Basis begonnen und auf mehrere Programmcode-Projekte aufgeteilt: eins für die Modellierung der Spielwelt, eins für generelle Basisklassen und eins für die Modellierung natürlicher Sprache.

Dabei lege ich nach wie vor Wert auf ein erweiterbares, modernes OOP-Modell, sowie auf Thread-Sicherheit. (-> Die Basis soll potentiell multiplayerfähig sein.)

Ich möchte möglichst viele Informationen über die Objekte der Spielwelt in die Engine einbauen, damit die Engine den Spieler auf "intelligente" Weise unterstützen kann und besser als bei Inform-Adventures "versteht", was grade vor sich geht. Außerdem will ich ganz genau das in Objekten modellieren, was in meinem Kopf vor sich geht, wenn ich mir über die Korrellate in der Wirklichkeit Gedanken mache.

Ein Beispiel: Den normalerweise üblichen Weltbaum mit den Containment-Relationen lehne ich ab. Das ist nicht die Art, wie man normalerweise über Objekte in der wirklichen Welt nachdenkt. Stellen wir uns eine Kerze vor, die auf einem Tisch steht. Wie modellieren wir dies in Gedanken.

Also einmal haben wir die Kerze, die ist ein physischer Gegenstand. Das entspricht meinem Basis-Interface

interface IPhysical

Ferner hat die Kerze eine Position:

   /**

    * Get the current position of the physical object.

    * @return the object's current position, which is

    * <code>null</code> if the object is not whithin the

    * game world.

    */

   IPosition position();

}```

Die Position ist eine bestimmte Relation zu einem anderen Objekt:

```interface IPosition {

   /**

    * Get the relation of the position, which is something like

    * <i>on top of</i>, <i>inside</i>, <i>besides</i>, <i>below</i>,

    * etc.

    * @return the position relation.

    */

   IPositionRelation relation();

   /**

    * Get the object that provides the position. That is, any object

    * that occupies the position is on top of, inside, below, besides

    * or in some other relation to the object returned by this

    * method.

    * @return the position provider, which is never

    * <code>null</code>.

    */

   IPhysical provider();

}```

Tja, und so pedantisch gehe ich in allen Dingen vor. Die Engine könnte auf diese Weise bereits gewisse Default-Beschreibungen generieren, wie etwa:

**Zitat:**
> *In der Mitte des Raums steht ein Tisch.*

> schau den tisch an

Ein gewöhnlicher Holztisch. *Auf dem Tisch steht eine Kerze.*

> nimm die kerze *vom tisch*

Du nimmst die Kerze.

> schau den Tisch an

Ein gewöhnlicher Holztisch.

> *stell die kerze auf den tisch*

*Du stellst die Kerze auf den Tisch.*

> schau den tisch an

Ein gewöhnlicher Holztisch. *Auf dem Tisch steht eine Kerze.*

(Anmerkung: *Die Teile, welche die Engine per Default generieren und erkennen sollte, habe ich kursiv markiert.*)

Und das wäre eine Standard-Funktion der Engine, der Tisch müsste nicht mit den speziellen Kommandos ausgestattet werden - weil die Engine ja "weiß", was auf, unter, in und so weiter bedeutet.

So, das Beispiel für IPosition ist übrigens nicht ganz korrekt. Es müsste beispielsweise auch die Positions-Relation "zwischen" geben, für die mehrere Objekte als Provider angegeben können. Und, ganz wichtiger Punkt: Die Provider-Objekte müssen nicht zwangsläufig physikalische Gegenstände sein! Es können auch sozusagen "virtuelle" Objekte sein, die nur in der Raumbeschreibung erwähnt werden, aber nicht als physikalische Gegenstände vorhanden sind. Für solche "virtuellen" Objekte werde ich vielleicht noch einen entsprechenden Typen ausarbeiten, so eine Art Referenz auf physikalische Objekte, die zwar beschreibbar ist, aber nur optional tatsächliche IPhysical-Instanzen enthält.

Das war nur ein kleiner Einblick, um mal exemplarisch zu zeigen, wie ich da rangehe. Ich halte Euch natürlich weiter auf dem Laufenden, aber wie ich schon schrieb: Erwartet keine schnelle Entwicklung, ich mache das a) nur nebenher und b) extrem pedantisch.