if-de :: Forum Foren-Übersicht
Autor Nachricht
<  Java-Package für IF-Authoring
Thomas
BeitragVerfasst am: Do, 28 Apr 2005 - 9:54  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 21.12.2004
Beiträge: 8
Wohnort: Sommerfeld

ChrisW hat folgendes geschrieben:
...eine derartige Erweiterung ist letztendlich nur für Leute interessant, die die Sprache (ob nun Java oder Ruby) bereits kennen.


Natürlich will ich nicht verhehlen, dass ich mit C++, Java und anderen Sprachen sehr vertraut bin und genau deshalb ein Konzept cool finde, das Code in solch einer Sprache erlaubt und trotzdem im Komfort einem TAG-Parser gleichkommt.

ChrisW hat folgendes geschrieben:
Ob Java-Runtimes wirklich so weit verbreitet sind, ist die Frage... ich habe auf meinen Rechner keine und kenne auch einige Leute, die hervorragend ohne auskommen.


Mhm, ok, das ist ein Argument, das einem Java-basierten Interpreter das Genick brechen könnte, zumindest in der MS-PC Gemeinde. Es gibt aber auch Plattformen, wo Java immer integriert ist. In Zukunft werden wahrscheinlich sogar Geräte (wie PDA ...) mit Hardware-Java stärkere Verbreitung finden.

Vielleicht ist ja doch eine Interpretersprache wie Ruby eher geeignet. Vielleicht kann man auch über VB-Script nachdenken, welches aber nich plattformübergreifend ist.

Die Kommandozeilenversion von PHP ist ein Programm mit schlappen 25 kB, läuft auch hervorragend ohne Webserver und mit einem einfachen Tool kann man für PCs komfortabel EXE-Dateien erzeugen, die nicht ab 1,5 MB groß sind (Bezug auf Ruby), sondern ab 15 kB entsprechend ihrer Funktionen. Grafische Oberfläche wäre möglich, aber frisst natürlich Ressourcen. Daneben könnte dann jeder, der will, solch ein Spiel über das WWW spielen, da Server mit PHP extrem verbreitet sind.
- Ja, wenn ich es mir recht überlege, würde ich als Sprache für eine IF-Interpreter-Bibliothek PHP empfehlen.

Viele Grüße von
Thomas
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Thomas
BeitragVerfasst am: Do, 28 Apr 2005 - 10:31  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 21.12.2004
Beiträge: 8
Wohnort: Sommerfeld

Thomas hat folgendes geschrieben:
Die Kommandozeilenversion von PHP ist ein Programm mit schlappen 25 kB, läuft auch hervorragend ohne Webserver und mit einem einfachen Tool kann man für PCs komfortabel EXE-Dateien erzeugen, die nicht ab 1,5 MB groß sind (Bezug auf Ruby), sondern ab 15 kB entsprechend ihrer Funktionen.


Da habe ich mal wieder Quatsch geschrieben. Inklusive der von PHP.EXE verwendeten DLLs sind es min. 5 MB (wieviel die minimale Installation braucht, wäre auszutesten). Aber man braucht PHP ja nur einmal installieren.

Und eine erzeugte EXE eines PHP-Programms braucht auch eine DLL von 1 MB, welche jedoch ebenfalls nur einmalig besorgt werden müsste, bzw. in der PHP-Installation enthalten ist, so dass die Aussage mit der EXE ab 15 kB prinzipiell noch stimmt.

Es wären also die Details abzuklären, aber nach wie vor halte ich PHP für so handlich, dass ich es als Sprache für eine IF-Bibliothek empfehlen würde.

Thomas
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
galickis
BeitragVerfasst am: Sa, 14 Mai 2005 - 10:31  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 25.03.2003
Beiträge: 6

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.

tomjoad hat folgendes geschrieben:

Nun ist aber Java eine klassenbasierte Sprache. Da sich beim TA alle Objekte anders verhalten (wäre andernfalls langweilig) würde ich einmal denken, man müßte für jedes Objekt extra eine Klasse erstellen und die dann genau einmal instanzieren.

Das Problem, dass man jede Klasse zuerst instantiieren muss, besteht nicht, es gibt ja auch statische Klassen, wie z.B. java.lang.Math.

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.

Oliver hat folgendes geschrieben:

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. Der Lexer ist dabei trivial (s. java.util.StringTokenizer), hinter dem Parser steht (natürlich) ein endlicher Automat. In diesem Zusammenhang möchte ich auf das Buch Jurafsky, Martin "Speech and Language Processing" verweisen, das genau dieses Problem behandelt.

So, das wären alle Punkte, die mir bis jetzt eingefallen sind. Es wäre nicht schlecht, wenn Oliver sein JAGD-Package als Open-Source veröffentlicht. Am besten jetzt gleich. Dann können wir alle, die diese Idee interessant finden, daran arbeiten. Das wäre doch ein interessantes Projekt, oder?
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
tomjoad
BeitragVerfasst am: So, 15 Mai 2005 - 11:47  Antworten mit Zitat
Wasserträger
Wasserträger


Anmeldungsdatum: 26.08.2002
Beiträge: 53
Wohnort: Münster

galickis hat folgendes geschrieben:

tomjoad hat folgendes geschrieben:

Nun ist aber Java eine klassenbasierte Sprache. Da sich beim TA alle Objekte anders verhalten (wäre andernfalls langweilig) würde ich einmal denken, man müßte für jedes Objekt extra eine Klasse erstellen und die dann genau einmal instanzieren.

Das Problem, dass man jede Klasse zuerst instantiieren muss, besteht nicht, es gibt ja auch statische Klassen, wie z.B. java.lang.Math.


*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. Inzwischen haben manche gemerkt, daß das nicht alle Anwendungsfälle erschlagen kann und sind bei multiparadigm programming angekommen, wovon Java meilenweit entfernt ist.

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?

Eine kurze Erklärung, ein kurzer Beispielcode wäre also weiterhin nicht schlecht, um sich ein Bild machen zu können wie das laufen soll.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Oliver
BeitragVerfasst am: So, 15 Mai 2005 - 12:57  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 06.08.2004
Beiträge: 9

galickis hat folgendes geschrieben:
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
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
galickis
BeitragVerfasst am: Mo, 16 Mai 2005 - 13:54  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 25.03.2003
Beiträge: 6

Oliver hat folgendes geschrieben:
galickis hat folgendes geschrieben:
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 hat folgendes geschrieben:
*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...
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
galickis
BeitragVerfasst am: Mo, 16 Mai 2005 - 13:58  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 25.03.2003
Beiträge: 6

galickis hat folgendes geschrieben:

Oliver hat folgendes geschrieben:

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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
Thomas
BeitragVerfasst am: Di, 17 Mai 2005 - 16:13  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 21.12.2004
Beiträge: 8
Wohnort: Sommerfeld

galickis hat folgendes geschrieben:

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
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Gast
BeitragVerfasst am: Mi, 18 Mai 2005 - 18:34  Antworten mit Zitat






Thomas hat folgendes geschrieben:
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!
Nach oben
galickis
BeitragVerfasst am: Mi, 18 Mai 2005 - 18:36  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 25.03.2003
Beiträge: 6

Der obige Beitrag über hybride Lösungen stammt von mir - hab vergessen mich anzumelden.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden MSN Messenger
Oliver
BeitragVerfasst am: Fr, 20 Mai 2005 - 18:48  Antworten mit Zitat
Neuling
Neuling


Anmeldungsdatum: 06.08.2004
Beiträge: 9

galickis hat folgendes geschrieben:

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
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Gast
BeitragVerfasst am: So, 22 Mai 2005 - 14:19  Antworten mit Zitat






Oliver hat folgendes geschrieben:
galickis hat folgendes geschrieben:

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.
Nach oben
Crowley
BeitragVerfasst am: Di, 3 Jan 2006 - 15:34  Antworten mit Zitat
Wasserträger
Wasserträger


Anmeldungsdatum: 15.12.2005
Beiträge: 32
Wohnort: Düsseldorf

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!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
tomjoad
BeitragVerfasst am: Di, 3 Jan 2006 - 20:48  Antworten mit Zitat
Wasserträger
Wasserträger


Anmeldungsdatum: 26.08.2002
Beiträge: 53
Wohnort: Münster

Crowley hat folgendes geschrieben:
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.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Crowley
BeitragVerfasst am: Mi, 4 Jan 2006 - 20:08  Antworten mit Zitat
Wasserträger
Wasserträger


Anmeldungsdatum: 15.12.2005
Beiträge: 32
Wohnort: Düsseldorf

tomjoad hat folgendes geschrieben:
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! ;)
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Alle Zeiten sind GMT + 1 Stunde (MEZ)

Nächstes Thema anzeigen
Vorheriges Thema anzeigen
Seite 2 von 3
Gehe zu Seite Zurück  1, 2, 3  Weiter
if-de :: Forum Foren-Übersicht  >  Dies & Das

Neues Thema eröffnen   Neue Antwort erstellen


 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.



Kontakt: Administrator

Powered by phpBB and NoseBleed v1.05