@binzl: Oder wie wärs mit einem AmigaTAM

Ne, mal ernsthaft: So kompliziert muss man das ja nicht machen. Es reicht wenn man vorerst nur für die Windows-User was grafisches macht, da diese Gruppe es eher gewöhnt ist als die Linux Freaks.

Außerdem könnte man es mit Java realisieren, wobei der Spruch "Write once, run everywhere..." auch nicht so ganz stimmt :cry:

So, wegen Kylix und "free": Das stimmt nicht ganz! Du kannst Kylix in der Community Edition zwar frei nutzen, jedoch nur für Lernzwecke. Ich glaube nicht, dass man damit was entwickeln darf, was später "vertrieben" wird auch wenn es Freeware ist.

Also in der Community Edition des C++ und J-Builders ist das jedenfalls so...

Falls ich mich irre, bitte um Korrektur 8)

Hey Leute,

so groß die Begeisterung für eine moderne Oberfläche für TAG/TAM auch ist, erstmal denke ich, daß Martin als Entwickler schon irgendwie das letzte Wort hat, in welche Richtung er TAM entwickeln will. Zweitens mach ich das als Hobby, sprich neben dem Beruf und kann nicht unendlich viel Zeit investieren, sprich wenn es fertig ist, ist es fertig.

Zunächst ist der erste Schritt, die vorhandenen Sourcen auf Linux zu portieren, danach wird man weiter sehen, und das wird auch nicht mehr so lange dauern, hoffe ich.

Aber wie gesagt, die Entscheidung sollte schon Martin treffen dürfen.

viele Grüße,

Andrea

shadow:

So, wegen Kylix und "free": Das stimmt nicht ganz! Du kannst Kylix in der Community Edition zwar frei nutzen, jedoch nur für Lernzwecke. Ich glaube nicht, dass man damit was entwickeln darf, was später "vertrieben" wird auch wenn es Freeware ist.

Also in der Community Edition des C++ und J-Builders ist das jedenfalls so...

Falls ich mich irre, bitte um Korrektur 8)

Auszüge aus license.txt (41KB!), Kylix 2 Open Edition:

(...)

2.1 Lizenzgewährung. (...) Das Produkt darf ausschließlich zum Erstellen, Compilieren (einschließlich Bytecode-Compilierung), Testen und Weitergeben Ihrer Anwendungsprogramme und anderen Arbeiten ("Arbeiten") in Quelltext- oder Objektcodeform nach Maßgabe der GNU General Public License (Sie finden diese unter www.borland.com/kylix/gpl.html)) sowie unter Beachtung von Abschnitt 4.1 und der anderen Bedingungen dieser Lizenz verwendet werden. Nach Maßgabe der anderen Bedingungen dieser Vereinbarung und unter Berücksichtigung der GNU General Public License dürfen Sie Ihre Arbeiten an Dritte weitergeben. (...)

2.3 Einschränkungen zu Wettbewerbsprodukten. (...) Außerdem darf dieses Produkt nicht verwendet werden, um ein Produkt zu erstellen oder einen Dienst zu betreiben, der grundsätzlich ein Wettbewerbsprodukt zu diesem Produkt darstellt. Dies gilt auch für universelle Software-Entwicklungswerkzeuge. Die vorstehende Einschränkung gilt jedoch nicht für den Einsatz des Produkts zur Entwicklung sogenannter "Plug-ins" (integrative Komponenten, die mit der Open-Tools-API dieses Produkts entwickelt wurden), sofern diese Plug-ins entwickelt werden, um die Funktionalität dieses Produkts zu erweitern.

(........)

4.1 SPEZIELLE BEDINGUNGEN FÜR KYLIX ENTERPRISE EDITION, KYLIX PROFESSIONAL EDITION UND KYLIX OPEN EDITION - GPL-DISTRIBUTIONSOPTIONEN

(...)

Wenn Sie Kylix Open Edition besitzen und Ihre Arbeiten unter anderen Bedingungen als den in der GNU General Public License beschriebenen weitergeben wollen, müssen Sie die entsprechende kommerzielle Lizenz von Borland erwerben.

Andrea:

Aber wie gesagt, die Entscheidung sollte schon Martin treffen dürfen.

Natürlich, wir unterbreiten nur Vorschläge!

@Ally: Hät ich ehrlich nicht gedacht, dass Borland der OpenSource-Gemeinde entgegenkommt. Aber das hätte man sich ja denken können unter Linux

Jedenfalls danke für die Aufklärung :!:

Aber dann wäre ja die Sache, dass LTAG dann doch OpenSource sein müsste. Denn die GPL besagt, dass die Software zwar verkauft werden kann aber der Quellcode frei zur Verfügung stehen muss.

Oder liege ich da auch falsch :?:

@Andrea: Wir haben Martin bis her noch in keiner Weise befohlen, dass er es machen muss und dass es so sein soll wie wir es haben wollen!

Wie ChrW bereits erwähnte sind dies alles nur Anregungen/Vorschläge, welche aber auch zum Teil von jedem anderen realisiert werden könnten...

Ich würde nie versuchen Martin etwas aufdrängen zu wollen. Auf jeden Fall hat er im Endeffekt das letzte Wort

ChrW:

Andrea:

Aber wie gesagt, die Entscheidung sollte schon Martin treffen dürfen.

Natürlich, wir unterbreiten nur Vorschläge!

Eben! Und diese Vorschläge werden auch von mir gelesen und in Betracht gezogen. Deshalb danke für die vielen Anregungen.

Hmmm. Ein Java-Buch habe ich mir einmal gekauft, mit dem Hintergedanken, eine jTAM zu schreiben. Aber im Moment steht es nur neben meinem Rechner und sorgt dafür, dass die Delphi-Bücher nicht umfallen...

Ich habe einmal (zaghaft) versucht, das Format der T.A.G.-Datei schriftlich festzuhalten. das Problem ist, dass der jetzige DOS-Interpreter schon genug Schwachstellen hat, da wichtige Teile der T.A.M. nicht in der Spieldatei stehen, sondern, wie man so schön sagt, fest verdrahtet sind. Jeder neue Interpreter müsste z.B. den Parser genauso handhaben wie die Ur-T.A.M. Und jede Korrektur müsste in jedem Interpreter nachgezogen werden.

Und ein neues T.A.G.-Format? Könnte man überlegen, aber da stellt sich die Frage: Warum nicht gleich z-Code oder Glulx?

Ich bin da etwas ratlos.

Martin:

Und ein neues T.A.G.-Format? Könnte man überlegen, aber da stellt sich die Frage: Warum nicht gleich z-Code oder Glulx?

Naja, die Frage kann ich beantworten: Weil TAG gerade für Leute wie mich, die sonst nix mit Programmieren am Hut haben, viel besser geeignet ist. Ich hab's damals auch kurz mit Inform versucht. OK, mit genug Energie hätte ich es vielleicht gepackt, aber wahrscheinlicher ist, daß ich ohne TAG nie ein Textadventure geschrieben hätte.

Außerdem ist der TAG-Parser meiner Meinung nach einen Ticken stärker als der deutsche Inform-Parser. Ich finde nicht, daß es sinnlos wäre, so ein tolles System auf eine neue Stufe zu hieven. Mich würd's freuen.

http://www.textadventures.de/

Hä? Ich raff's mal wieder nicht. Kann mir das jemand genauer erklären? Man programmiert in TAG und spielt's mit Frotz, oder was?

Ja, genau so wäre es. Wäre zwar mit Aufwand verbunden, man würde aber mit einem Schlag sehr viele Plattformen erschlagen,

auf denen TAG Spiele dann möglich wären.

Ist also durchaus eine Überlegung wert, wobei dann ein ähnlicher Schritt wie bei TADS (TADS2->TADS3) nötig wäre.

Aber wie gesagt, der erste Schritt wird eine Linux-Consolen TAM sein, danach wird man mal sehen.

-- Andrea

Ich sehe, ich habe hier einen Stein ins Rollen gebracht der langsam zur Lawine wird! Zur Klarstellung: Ich wollte und will Martin nicht dazu drängen eine neue Engine zu schreiben, sondern habe lediglich in Erwägung gezogen, ob eine modernere EntwicklerOBERFLÄCHE für Windows nicht reizvoll wäre, ebenso eine WinTAM wäre nicht übel, wodurch man nicht gezwungenermaßen ein neues System schreiben müßte(?) Ich habe bei der Entwicklungsumgebung eher an so eine Art GUI gedacht, die den vorhandenen Compiler nutzt um den Quellcode direkt per Mausklick zu kompilieren. Ob eine WinTAM aus dem vorhandenen Quellcode entstehen könnte ohne einen zu hohen Aufwand zu haben entzieht sich meiner Kenntnis. Nun, ich denke das für und wider könnte man im Thema VisualTAG weiterdiskutieren, da hier die Diskussion wohl eher an Linux/Unix User gerichtet ist. Ich weiß auch nicht ob Martin bereit wäre einem Programmierer der bereit wäre so etwas umzusetzen, dwen Quellcode zu überlassen, oder ob er vielleicht selbst in Erwägung zieht so etwas zu versuchen... vielleicht entsteht ja eine Arbeitsgruppe daraus?? @Martin: Ich würde mich freuen wenn das ganze weiterverfolgt würde, jetzt wo der Stein eh schon rollt

Tanan:

Hä? Ich raff's mal wieder nicht. Kann mir das jemand genauer erklären? Man programmiert in TAG und spielt's mit Frotz, oder was?

Genau, so wäre es.

T.A.G. wandelt im Moment den Quelltext in eine Spieldatei im tag-Format um. Mit dieser Datei kann nur die T.A.M. etwas anfangen, die es ja im Moment nur für DOS gibt. Inform wandelt einen Quelltext, der eine komplett andere Syntax hat, in z-Dateien um. Diese Dateien können von allen z-Maschinen-Interpretern gelesen werden, und die gibt es ja für fast alle Plattformen.

Man müsste nur einen neuen Compiler schreiben, der einen T.A.G.-Quelltext in eine z-Code-Datei umwandelt. (Was allerdings nicht ganz einfach ist: Der Parser und vieles mehr sind Bestandteil der T.A.M., nicht der Spieldatei. Eine z-Maschine hat nur eine sehr primitive Textanalyse, der gesamte Inform-Parser steckt in der z-Datei.)

Es ist übrigens gar nicht so selten, dass (fast) gleiche Quellcodes verschiedene Spieldateien oder auch Executables erzeugen. Der Biplattform-Compiler von Inform kann z-Dateien in verschiedenen Formaten und Glulx-Dateien erzeugen. Dasselbe C-Programm erzeugt, auf verschiedenen Plattformen kompiliert, verschiedene Executables.

Andererseits können aber auch verschiedene Quelltexte ähnliche Programme erzeugen: Wenn ich ein kleines Programm in C und in Pascal schreibe, dann sehen die Quelltexte verschieden aus, und die Executables sind zwar wahrscheinlich nicht identisch, bewirken aber dasselbe und gehorchen demselben Format.

In welcher Sprache du programmierst, ist vom Standpunkt des Interpreters her egal, wenn es den geegneten Compiler gibt. So, jetzt habe ich dich noch mehr verwirrt...

http://www.textadventures.de/

Eine jTAM wäre wohl die effektivste plattformübergreifende Lösung, solange es auf Konsolenebene läuft. Nur leider ist das aktuelle JRE ca. 8 MB groß und muss immer noch für viele Betriebssysteme extra heruntergeladen werden.

Außerdem kann man den kompilierten Code von Java dekompilieren. D. h. dass der Quellcode so ziemlich frei für jedermann zugänglich wäre.

Außer man benutzt ein Verschlüsselungsprogramm, wobei aber dann die Fehlersuche zur Laufzeit zu einer echten Herausforderung wird.

Also, falls es jemals zu einer jTAM kommen würde stelle ich mich gerne freiwillig zur Verfügung, da ich bereits einiges an Erfahrung in der Entwicklung mit Java besitze.

@Martin: Ein Compiler, der verschiedene Formate ausgibt wäre ein "Utopia" für viele TAG-Entwickler :lol:

Unter Umständen wäre das vielleicht sogar angebrachter als eine Portierung, jedoch würde ich lieber noch mit der TAM spielen...

Außerdem denke ich, dass das bei dem heutigen Stand einfach ZU aufwendig wäre.

Hallo

ich bin zufällig beim surfen auf Tag gestoßen und es hat mich gleich faziniert, was man alles damit machen kann.

Da man aber leider "nur" unter MS Dos entwickeln kann, bin dann vorerst auf Inform umgestiegen, da ich die Spiele unter linux wie unter Dos entwickeln kann und sogar auf meinen alten Psion 5 spielen kann !

Aber wie ich sehe wird ja schon an einer Umsetzung für Linux gearbeitet, super. Ich freu mich auf die Umsetzung !!

Hallo, nochmal zum Thema VisualTag:

Ich stelle mir das etwa so vor, wie Martin es unter dem Topic "Umfrage: Visual Tag?" beschrieben hat: Dass das Programm dir dabei hilft, im Quelltext zu navigieren. Und dass man DOS-Tag aus dem Programm heraus bequem aufrufen kann. Die Umfrage fällt ja auch für das Programm aus.

Ich wäre zumindest bereit dazu, etwas in der Richtung mit Delphi zu programmieren... Bin aber noch in der Anfangsphase... Bräuchte also gaaanz, ganz viel Unterstützung... Und das ganze würde dann erst mal nur unter Windows laufen...

Malte:

Die Umfrage fällt ja auch für das Programm aus.

Wenn man diejenigen, die sich das Programm vielleicht mal anschauen würden, als unentschlossen zählt, dann gibt es einen Gleichstand.

VisualTAG ist ja ganz schön, und wenn jemand das umsetzen möchte, soll er. Meiner Meinung nach ist aber eine bessere Unterstützung der Spieler durch Portierung der TAM wesentlich wichtiger als eine bessere Unterstützung der Autoren. Ich schreib meine Quelltexte ja auch nicht mehr mit nem DOS-Editor.

Das soll nicht gegen das neue Handbuch oder Ähnliches gehen, sondern nur gegen den Programmieraufwand eines VisualTAG, der bei einer WinTAM besser angelegt wäre.

Ich weiß, es kommt ein bisschen spät, aber vielleicht interessiert es irgendwen:

Man erleichtert sich unter Windows 2000/XP das kompilieren, wenn man im Verzeichnis, in dem tag.exe liegt, eine *.bat - Datei anlegt, mit dem folgenden Inhalt:

command.com /k tag %adv-Datei%

Das hat den Vorteil, dass

a) %adv-Datei% einen (relativen) Pfad enthalten kann

b) das Dos-Fenster geöffnet bleibt (schließbar durch "exit").

@ChrW: Natürlich, Dinge wie Linux-Portierung sind dringender und haben Vorrang, trotzdem kann man doch über weitere Projekte diskutieren.

http://www.textadventures.de/