Hallo zusammen,

ich bin gerade dabei, ein Java-Package (d.h. eine Sammlung von Java-Klassen) für die Programmierung von Adventure-Spielen zu erstellen. Das Projekt läuft unter dem Namen JAGD (Java Adventure Game Development). Der Vorteil ist, daß das JAGD-Package ganz einfach wie andere Java-Bibliothen zu verwenden ist und man sich als Programmierer nicht erst umgewöhnen muß. Mit Eclipse steht zudem eine leistungsfähige IDE zur Verfügung, außerdem ist man mit Java nicht auf eine Plattform beschränkt.

Gruß,

Oliver

Oliver:

ich bin gerade dabei, ein Java-Package (d.h. eine Sammlung von Java-Klassen) für die Programmierung von Adventure-Spielen zu erstellen.

Schön. Aber wie sollen die mit JAGD erstellten Spiele aussehen? Um welche Art von Adventures handelt es sich? Textadventures mit Parser? Textadventures auf Basis von Multiple-Choice? 2D-Grafik-Adventures mit Point-n-Click? Das wird nicht ganz klar.

Vielleicht erklärst du noch etwas mehr zu deinem Projekt, denn die Ankündigung, dass du gerade dabei bist, etwas zu machen, von dem ich nicht weiß, was es ist - das begeistert mich nicht so...

Oliver:

Der Vorteil ist, daß das JAGD-Package ganz einfach wie andere Java-Bibliothen zu verwenden ist und man sich als Programmierer nicht erst umgewöhnen muß.

Außerdem hört es sich so an, als ob alle Autoren von Textadventures Programmierer wären und als ob alle Programmierer in Java programmierten. Java, schön und gut. Klar, es ist plattformunabhängig, aber die Plattformunabhängigkeit hast du mit Inform zum Beispiel auch. Außerdem ist Java so universell gar nicht - als ich das neulich hier angekündigte Jzuul ausprobieren wollte, habe ich es auf keiner der drei Plattformen in unserem Büro (Windows XP, Linux und IRIX) als Applet zum Laufen gekriegt. Schade. Denn ich lade mir nicht die neuesten Java-Packages herunter, wie es im readme steht*. (Von zu Hause aus habe ich es erst gar nicht probiert, der Download war doch recht umfangreich. Und allzu lange habe ich im Büro auch nicht herumprobiert.)

Oliver:

Mit Eclipse steht zudem eine leistungsfähige IDE zur Verfügung ...

Und was ist Eclipse? Eine IDE, also eine grafische Entwicklungsumgebung, für Java, nehme ich an. Aber das weiß hier niemand. (Behaupte ich mal, vielleicht hält sich der ein oder andere auch besser auf dem Laufenden als ich, was nicht besonders schwer sein dürfte.)

*) Eventuelle Aufrufe meinerseits zum Benutzen der neusten T.A.M. bleiben hiervon unberührt :-)

Martin:

Schön. Aber wie sollen die mit JAGD erstellten Spiele aussehen? Um welche Art von Adventures handelt es sich? Textadventures mit Parser? Textadventures auf Basis von Multiple-Choice? 2D-Grafik-Adventures mit Point-n-Click? Das wird nicht ganz klar.

Zunächst einmal soll es um Textadventures gehen (mit Tastatureingabe). Zur Generierung von Parsern gibt es für Java eine ganze Reihe von Werkzeugen (wie z.B. "antlr" oder "jlex"), so daß das keine allzu große Hürde darstellt. Die Textadventures können als einfache Konsolen-Anwendungen oder auch u.U. als Web-Anwendungen (via Servlet-Schnittstelle oder JSP) programmiert werden.

Martin:

Außerdem hört es sich so an, als ob alle Autoren von Textadventures Programmierer wären und als ob alle Programmierer in Java programmierten. Java, schön und gut. Klar, es ist plattformunabhängig, aber die Plattformunabhängigkeit hast du mit Inform zum Beispiel auch. Außerdem ist Java so universell gar nicht - als ich das neulich hier angekündigte Jzuul ausprobieren wollte, habe ich es auf keiner der drei Plattformen in unserem Büro (Windows XP, Linux und IRIX) als Applet zum Laufen gekriegt. Schade. Denn ich lade mir nicht die neuesten Java-Packages herunter, wie es im readme steht*. (Von zu Hause aus habe ich es erst gar nicht probiert, der Download war doch recht umfangreich. Und allzu lange habe ich im Büro auch nicht herumprobiert.)

Java-Applets werden heutzutage auch kaum noch programmiert, ebenso wie Applikationen auf der Basis von AWT oder gar SWING, ist alles viel zu langsam. Java wird heutzutage mehr für Server-Anwendungen oder im Embedded-Bereich verwendet. Inform habe ich mir mal angeschaut. Das ist im Grunde auch nur eine Programmiersprache (allerdings eine für einen speziellen Zweck). Ich will ja niemanden Inform vermiesen. Allerdings gibt es etliche Leute die bereits in Java programmieren können und sich nicht umgewöhnen müssen, zudem stehen für Java eine ganze Reihe von Packages und Tools zur Verfügung die in JAGD-basierten Projekten ganz einfach mitgenutzt werden können.

Martin:

Und was ist Eclipse? Eine IDE, also eine grafische Entwicklungsumgebung, für Java, nehme ich an. Aber das weiß hier niemand. (Behaupte ich mal, vielleicht hält sich der ein oder andere auch besser auf dem Laufenden als ich, was nicht besonders schwer sein dürfte.)

Eclipse ist in der Tat eine IDE, die von IBM als Open Source für jedermann frei verfügbar ist. Dadurch hat Eclipse bereits eine gewisse Verbreitung, und es gibt jede Menge Erweitungern (Plugins) für Eclipse, möglicherweise sogar vielleicht auch für Inform.

Gruß,

Oliver

Ich teile Martins Meinung. Für simple Textadventures ist die notwendige Einrichtung von Java und eventuellen zusätzlichen Bibliotheken einfach zu aufwendig und erfordert ein zu hohes Maß an Fachwissen. Ebenso haben im DSL-Zeitalter nicht alle die Möglichkeit es zu nutzen und sind auf ein 56K-Modem beschränkt (ich zitiere die Tlkom: "DEUTSCHLAND WEIT ERHÄLTLICH!" !!!).

Ich bin selbst Java-Entwickler und habe eine positive Meinung darüber, aber für Textadventures oder gar Spiele in 2D oder 3D ist es leider noch ungeeignet...

@Oliver: Sorry, aber die neuesten Erkenntnisse zeigen, dass Java-Anwendungen zum Teil sogar schon performanter sind als C/C++ oder .NET-Anwendungen. Ich weiß auch aus Erfahrung, dass Java-Anwendungen und Applets immer noch entwickelt werden. Somit ist die Aussage, dass Java nur noch für Embedded-Systems und Server-Systeme geeignet ist für meinen Teil einfach falsch. Sieh dir doch mal SWT an, mit dieser nativen GUI-Lösung sind alle Performance-Probleme bei grafischen Anwendungen behoben.

Aber gut, selbst die Entwicklung von MS-DOS hat in der Garage stattgefunden. Ich bin mir sicher, dass wenn du genug Engagement in dieses Projekt reinsteckst und alle Möglichkeiten ausreizt es ein Erfolg werden kann. Halt uns einfach auf dem Laufenden und berichte, falls es was Neues gibt.

Ich wünsch dir auf jeden Fall viel Erfolg bei deinem Vorhaben

shadow:

Ich bin selbst Java-Entwickler und habe eine positive Meinung darüber, aber für Textadventures oder gar Spiele in 2D oder 3D ist es leider noch ungeeignet...

;)

Daß Java nicht für Textadventures geeignet sein soll, halte ich für eine ziemlich gewagte Aussage. Mit reinen Textanwendungen dürfte es eigentlicht keine Probleme geben. Was mein Projekt betrifft: Ich hatte in der letzten Zeit ein paar Probleme mit Eclipse, die dazu führten daß Eclipse öfter mal einen Hänger hatte und dabei gleich den ganzen X-Server mit zum Stehen brachte, so daß nur noch Druck auf den Resetschalter half. Aber das ist jetzt hoffentlich nach Installation der neuesten Eclipse-Version und einer neuen Version des Blackdown-JDK erledigt. 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. In meinem vorherigen Beitrag habe ich vielleicht ein wenig herumgesponnen, aber ich wollte nur aufzeigen, was im Prinzip theoretisch alles möglich wäre, vielleicht könnte man mit dem Teil sogar irgendwelche Handy-Spiele programmieren, wer weiß das schon... Und wenn ich dann irgendwann mal ganz viel Zeit und Langeweile habe, wird es vielleicht in andere OO-Sprachen portiert wie z.B.. Python oder Objective C oder was auch immer (ist auch wieder nur Spinnerei, ich weiß)...

Gruß,

Oliver

Hallo,

also ich finde JAVA-IFs nicht abwegig und will damit unterstreichen, dass die Geschmäcker von (potenziellen) Autoren verschieden sind.

Wie ich gerade im Beitrag zu dem geplanten RUBY-Interpreter geantwortet habe, ist für mich persönlich die Idee verlockend, dass man eine Anzeige-Engine, einen Parser und vorbereitete Objektstrukturen hat, aber gleichzeitig in einer Allzweck-Programmiersprache schreibt, die in bestimmter Hinsicht flexibler und effizienter ist.

Wie auch bei RUBY, ist hier die Umsetzung natürlich entscheidend. Es darf nicht zu schwerfällig und kompliziert zu handhaben sein. Das fertige Spiel muss komfortabel zusammen mit einem Interpreter weitergegeben werden können. Außerdem (auch das habe ich schon bei RUBY gesagt) sind die Ansprüche - auch meine - an den Parser hoch. Er sollte sich mit Inform und T. A. G. messen können.

Aber ich nehme an, dass die meisten Leute eine JAVA-Runtime installiert haben und behaupte mal, dass eine IF-Engine keine neuen "Hightech"-Packages braucht, sondern nur die garantiert vorhandenen Basics. Aber das meinte ich mit Umsetzung. Es liegt in der Hand des Programmierers der Bibliothek.

Also von meiner Seite: Ich freue mich auf die JAVA-IF-Engine,

aber denk daran, es möglichst einfach zu halten, vielleicht braucht man gar keine IDE.

Viele Grrüße vom

Thomas

Passt zwar nicht direkt zum Thema, aber: Ruby ist keine Abkürzung (Java auch nicht) und wird desshalb auch nicht RUBY sondern Ruby bzw. ruby geschrieben.

ich denke in diesem fall geht es nicht darum, dass java oder ruby eine abkürzung sind, sondern ein eigener name ohne (ich sag mal) linquistischen hintergrund. so ist es durchaus gebräuchlich die namen von programmiersprachen in reinen großbuchstaben zu schreiben.

schau dir mal z. b. die titel der ganzen programmierbücher an...

... dann schau vielleicht mal in die Bücher. Es ist nicht üblich.

Sorry, wollte die Namen nur hervorheben, also in Zukunft Ruby und Java oder Ruby und Java? ;-)

Eine inhaltliche Kritik zu meinem Kommentar wäre daneben jedoch interessanter.

Viele Grüße

Thomas

@ChrisW: was möchtest du mir denn mit deinem kommentar sagen?

man muss nicht unbedingt die deutsche grammatik studiert haben, um diese zu beherrschen.

Ernstgemeinte Frage:

Ich kann mir nicht so ganz vorstellen, wie ein Textadventure in Java aussehen soll?

Java ist OO. Für ein Textadventure bietet sich das an - ich würde von einem OO-basierten TA-System erwarten, daß ein Spielobjekt als ein (z. B. Java-)Objekt repräsentiert wird.

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 fände ich extrem unschön, so eine Idee ist zwar nicht verkehrt, aber man sollte vielleicht besser eine prototypbasierte, klassenlose OO-Sprache nehmen ...

Thomas:

Eine inhaltliche Kritik zu meinem Kommentar wäre daneben jedoch interessanter.

Okay. Ich kann die Idee einer Textadventure-Bibliothek für eine allgemeine, verbreitete Programmiersprache durchaus nachvollziehen, speziell wenn ich an die Klimmzüge denke, zu denen Inform einen bei der Stringverarbeitung zwingt. Trotzdem würde die Verfügbarkeit einer solchen Bibliothek mich nicht dazu bringen, von Inform wegzuwechseln, eine derartige Erweiterung ist letztendlich nur für Leute interessant, die die Sprache (ob nun Java oder Ruby) bereits kennen. Für alle anderen willigen Autoren ist die Einarbeitung in ein auf den Zweck abgestimmtes System wie Inform oder TAG sicher lohnenswerter und auch einfacher.

Ob Java oder Ruby als Sprachen für ein derartiges Unterfangen wirklich in Frage kommen, können letztendlich nur Leute beurteilen, die sowohl die entsprechende Sprache als auch eine der bestehenden Lösungen wie z.B. die Inform-Library gut kennen. Da zähle ich mich nicht dazu.

Als Spieler wäre ich jedenfalls nicht bereit, mehr Zeit und Mühe aufzuwenden, um das Spiel zum Laufen zu kriegen, als ich momentan bei WinFrotz, der TAM oder Glulxe aufwende, da gebe ich dir vollkommen Recht. 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. Als durchschnittlicher Websurfer, E-Mail-Leser und Computerspielezocker braucht man Java extrem selten.

shadow:

was möchtest du mir denn mit deinem kommentar sagen?

Genau das, was drin steht. Aber ich schreibs gerne nochmal: Es ist nicht üblich, die Namen von Programmiersprachen prinzipiell groß zu schreiben (wenn es sich nicht wie bei BASIC um eine Abkürzung handelt). Auch nicht in den von dir angeführten Büchern, auf die ich mich bezog.

wenn du meinst...

ich sagte nicht, dass es richtig sei, nur dass es durchaus des öfteren vorkommt.

Das ist mir klar, ich hab deine Beiträge durchaus gelesen. Ich meinte das ebenso, deshalb sprach ich auch nicht von "falsch" sondern von "nicht üblich". Ich denke, damit, bezüglich des Ausmaßes der Verbreitung von reiner Großschreibung von Programmiersprachennamen nicht einer Meinung zu sein, können wir beide problemlos leben, lass uns das jetzt beenden.

ChrisW:

...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:

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

Thomas:

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

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:

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:

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?

galickis:

tomjoad:

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.

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