Wer ist für ein VisualTAG für Win/Linux? Würde mich interessieren wer nun alles für das komfortable Entwickeln unter Win/Linux (X-Window) ist.

Ich bleibe beim alten DOS TAG/TAM :!:

Aber man muss dem Fortschritt platz machen, also soll das sogenannte "VisualTAG" kommen

Wieder die alte Leier von mir: Wer würde/könnte denn dabei mitmachen (mit oder ohne Programmiererfahrung)???

Ich fände die Idee auch nicht schlecht und könnte auch als Programmierer (Pascal/Delphi) mithelfen. Die Idee ist mir übrigens auch schonmal gekommen.

Da fällt mir ein... eine Entwicklungsumgebung wie Pascal auf der Console wäre auch nicht übel... da könnte man dann varianten für DOS und/oder UNIX/LINUX machen... @Martin: was hältst Du davon??? (nur ein Ansatz einer Idee) leider kann ich nicht in Pascal, Delphi, C, Java programmieren. Die einzigen Sprachen sind VisualBasic(im Ansatz) und dann nur noch ASP und PHP. (HTML kann man ja nicht als "Sprache" bezeichnen) ich glaube das hilft hier nicht viel weiter, aber Ideen liefern und Betatester machen kann ich.

Hmmm. Du brauchst doch gar kein Pascal zu können, um eine IDE für T.A.G. zu schreiben, nur weil der Compiler in Pascal geschrieben ist.

Ich stelle mir eine IDE etwa so vor: Die IDE lädt das Projekt ein. Die Syntax des Quelltexts von T.A.G. ist ja bekannt. Intern wird das Spiel geordnet und in eine übersichtliche Form gebracht. Der Autor editiert bequem seinen Datensatz. Wenn er ihn ausprobieren will, wird der Quelltext gespeichert und im Hintergrund wird T.A.G. aufgerufen. Das Logfile wird analysiert und der Autor auf Fehler aufmerksam gemacht.

Etwa so, wie ein HTML-Editor auch einen externen Browser aufruft, um die Seiten anschauen zu können.

Wer so etwas machen möchte - gerne. Ich werde mich aber nicht beteiligen, höchstens um das IDE-Team zu unterstützen.

Eine Variante für andere Plattformen als Windows macht natürlich solange T.A.G. nicht portiert ist keinen Sinn.

Ja, genauso habe ich mir das vorgestellt. Nicht den Compiler neu schreiben sondern eine IDE entwickeln die den compiler einbindet. Einen Ansatz hat ja Proton und der MBEditor mit der Kommandozeile (unverzichtbar :!: ). Nur daß man bei der TAG IDE dann per Knopfdruck kompilieren kann (oder Tastendruck bei einer DOS/LinuxConsole-IDE).

PS: Wenn mein Linux auf dem Laptop zufriedenstellend läuft werde ich dann auch Andreas TAM-Portierung testen wenn es fertig ist (gespannt bin )

binzl:

Ja, genauso habe ich mir das vorgestellt. Nicht den Compiler neu schreiben sondern eine IDE entwickeln die den compiler einbindet. Einen Ansatz hat ja Proton und der MBEditor mit der Kommandozeile (unverzichtbar :!: ). Nur daß man bei der TAG IDE dann per Knopfdruck kompilieren kann (oder Tastendruck bei einer DOS/LinuxConsole-IDE).

Aber kann man nicht aus jedem vernünftigen Texteditor heraus per Knofpdruck beliebige Kommandos ausführen? Zumindest mit ConTEXT (http://fixedsys.com/context/) und sicher auch TextPad oder UltraEdit ist es kein Problem, ein Textfile an Mozilla oder beliebige Compiler zu schicken, oder das resultierende Kompilat an einen Interpreter ("tag %p%F.adv").

Weiß nich, ...so richtig kapier ich den Nutzen einer IDE gegenüber dem gewohnten Lieblingseditor noch nicht. Daher auch: Enthaltung.

P.S. Dieses Posting war Windows-zentrisch.

Zitat:

Weiß nich, ...so richtig kapier ich den Nutzen einer IDE gegenüber dem gewohnten Lieblingseditor noch nicht. Daher auch: Enthaltung.

Der Vorteil einer IDE ist eben, dass du alles auf einmal in einem Entwicklungssystem hast. Du siehst den Quelltext mit Syntaxcoloring vor Dir, hast nebendran eine tabellarische Auflistung aller Räume und Gegenstände und vielleicht sogar eine grafische Darstellung deiner Objekte (Räume und Gegenstände, Personen...), worauf du die Eigenschaften der einzelnen Objekte einfach durch Mausklick verändern/setzen kannst...

So gesagt erspart dir eine IDE verdammt viel Arbeit! Die verschiedenen Editoren können auch als IDE angesehen werden, wobei Sie aber allgemein gehalten sind und eben nicht speziell auf Dein verwendetes System abgeschnitten sind.

@Ally: Hast du noch nie mit Delphi oder VisualStudio zu tun gehabt?

Naja, hier ist wohl nicht der richtige Ort um sowas zu diskutieren. Und ich bin verdammt müde :cry:

Ich wünsch euch eine gute Nacht :lol:

Ich muß allerdings sagen, daß ich mir das auch nicht recht vorstellen kann. Nein, ich kenne Delphi und den ganzen Kram nicht. Angeschaut habe ich mir mal ADRIFT - aber von den Ergebnissen bin ich nicht gerade begeistert, um es vorsichtig auszudrücken.

Ich meine, Syntaxhighliting gibt's ja jetzt auch schon für zwei Editoren (Besonders das für Proton gefällt mir. Danke Martin!). Und eine grafische Darstellung all meiner Objekte hätte glaube ich einen begrenzten Nutzen - bei all dem Chaos, daß ich im Quelltext veranstalte. Ständig füge ich irgendwelche Aktionen und Variablen hinzu, die dieses oder jenes Objekt beeinflussen können... das ist es, was mir den Überblick raubt! Oder kann man das auch grafisch darstellen?

Übrigens gibt es schon eine Funktion, mit der man sich all seine TAG-Befehle, -Räume und -Objekte anzeigen lassen kann: tag -l [dateiname.adv]

shadow:

Der Vorteil einer IDE ist eben, dass du alles auf einmal in einem Entwicklungssystem hast. Du siehst den Quelltext mit Syntaxcoloring vor Dir, hast nebendran eine tabellarische Auflistung aller Räume und Gegenstände und vielleicht sogar eine grafische Darstellung deiner Objekte (Räume und Gegenstände, Personen...), worauf du die Eigenschaften der einzelnen Objekte einfach durch Mausklick verändern/setzen kannst...

Hmmja, aber ich habe lieber alles in einem -- Code, der sich hinter Clickety versteckt, macht mich nervös (jedenfalls, wenn ich mit der Sprache selber noch nicht auf ausreichend "lockere" Weise umgehen kann). Die mir bekannten (naja, von mir angesehenen) IF-IDEs generierten darüberhinaus ziemlich ...seltsamen Code. Was ich selber "organisiert" und kommentiert habe, kann ich sicher leichter nachbearbeiten/erweitern. Vielleicht ist es ja möglich, mit einer IDE auf wirklich alle Bestandteile eines Programms zugreifen zu können, aber Gegenstände, Räume, Charaktere usw. sind doch auch "nur" Code und nicht auf bestimmte Eigenschaften festgelegt, insofern führt doch im Endeffekt eh kein Weg am nackten Code vorbei, ob man dafür nun ein paar Icons anklickt oder im Editor in ein anderes geöffnetes File wechselt.

Ein Laufzeit-Debugger nach Art der TADS Workbench (die darüber hinaus ebenfalls Compiler und Wunsch-Editor aufruft) dagegen... (das Teil ist wirklich unverzichtbar... womöglich ist eh alles nur eine Frage der Gewöhnung)

Zitat:

@Ally: Hast du noch nie mit Delphi oder VisualStudio zu tun gehabt?

Nein, aber nicht aus "Prinzip", ich bin einfach nicht besonders aktiv oder erfahren, was das Programmieren betrifft, wegen Rest-Depris etc. halt auch nicht sehr konzentriert oder hartnäckig. Ich habe da so'n Delphi-Tutorial durchgemacht ("wir entwickeln einen Texteditor"), hatte dabei aber eher das Gefühl, vorgefertigte Versatzstücke zusammenzuschustern, als wirklich etwas zu lernen. Da eins der schließlich anzuklickenden Icons dann schlichtweg nicht auffindbar war, bin ich dann auch nicht weiter in die Materie vorgedrungen. Schade eigentlich.

Zitat:

Hast du noch nie mit Delphi oder VisualStudio zu tun gehabt?

Du stellst dir sowas wie Delphis Objektinspektor vor? Die Objekteigenschaften hat man doch bei TAG-Dateien mindestens genauso schnell im Quelltext geändert.

Die tabellarische Auflistung der Räume/Objekte (vgl. Delphis Codeexplorer) wäre vielleicht für die Orientierung/Navigation in großen Spielen ganz sinnvoll, aber prinzipell stände der Aufwand, so ein Integrated-Development-Monster zu entwickeln, doch in keinem Verhältnis zum Nutzen.

Mal ehrlich: Ist der jetzige Zustand (Proton mit Syntax-Coloring und externer Compiler und Interpreter) so schlecht? Da legt man sich zwei, drei Verknüpfungen auf dem Desktop an und dann flutscht das. Ich finde schon die Vorstellung, ein von den Hardwareanforderungen so schlichtes Spiel wie ein Textadventure mit einer IDE zu entwickeln, abwegig.

Aber gut, wenn jemand denkt, dass er das braucht, soll er's programmieren...

Habe grad ein TAG-Syntaxfile gefunden, das ich "damals" für TextPad (okayer Windows-Editor, http://www.textpad.com) gemacht hatte. Da ich TextPad nicht mehr benutze, kann ich nicht sagen, wie "toll" es ist (steht jedenfalls ziemlich viel drin ), aber wer TextPad benutzt oder benutzen mag, dem könnte ich es schicken... (Ich hab ebenfalls das soweit ich weiß bisher vollständigste Synfile für TADS 2, falls das hier jemand interessiert)

http://www.textadventures.de/

Walafrid:

Aber wenn es möglich wäre, TAG-Spiele zu erstellen, ohne jemals den Quelltext zu sehen.

Ich denke nicht, dass es sinnvoll ist den Quellentext ganz verschwinden zu lassen. Unter den meisten Bedingungen ist es sicher einfacher den Quellentext selbst zu verfassen. Einzige Ausnahme, dass erstellen von Räumen und Objekten; hier sollte man Attibute und Zustände vieleicht schneller und leichter über Visual TAG erstellen können.

Gerrit:

Walafrid:

Aber wenn es möglich wäre, TAG-Spiele zu erstellen, ohne jemals den Quelltext zu sehen.

Ich denke nicht, dass es sinnvoll ist den Quellentext ganz verschwinden zu lassen.

Auch ich habe nie gesagt, daß ich keinen Quelltext mehr will, ich finde eher, daß der Quelltext am ehesten dazu geeignet ist, frei zu agieren ohne Vorgaben der IDE befolgen zu müssen. Ich habe auch eher an sowas wie eine Oberfläche ähnlich Turbo-Pascal gedacht, die ja nicht mal unbedingt Windows basiert sein muß. Desweiteren wäre hilfreich, wenn die IDE die Texte an der vorgegebenen Zeilenbegrenzung von TAG umbricht, so könnte man flüssiger schreiben. Ich hatte anfangs nämlich das Problem, daß mir die Texte immer abgeschnitten wurden, weil ich auf ebendiesem Umstand nicht achtete.

Fazit: Also Quelltext sollte schon bleiben.

http://www.textadventures.de/

Walafrid:

Für mich macht so eine Entwicklungsumgebung nur Sinn, wenn man dann gar keinen Quelltext mehr braucht.

Ich stelle mir das so vor: Wenn man in der Baumansicht auf einen Eintrag klickt (der ein Objekt repräsentiert), springt die Quelltext-Anzeige zu diesem Objekt, sodass man es direkt (im Quelltext) bearbeiten kann. Damit wäre endlose Sucherei im Quelltext (hoffentlich) vorbei. Wie das zu programmieren wäre, ist eine andere Frage...

Ich denke nicht, daß es möglich ist, den Quelltext ganz zu verstecken, ohne daß die Mächtigkeit des Entwicklungssystems

eingeschränkt ist.

Und mit einem guten Editor ist es möglich, so Dinge wie Vorlagen für bestimmte Arten von häufig benötigten Objekten zu erstellen oder auch automatisch bei 80 Zeichen umzubrechen.

Außerdem läuft man Gefahr, daß ein Wizard massenweise Code erstellt den ich nicht so schnell verstehe und der irgendwo nicht ganz so funktioniert, wie ich das gerade in meinem Spiel haben will und dann wird es schwierig etwas zu ändern.

So ein VisualTAG inist aber sbesondere für Anfänger angenehmer als ein reiner Editor. Man erhält am Anfang schnellere Erfolgserlebnisse, aber irgenwann muß man den Quellcode meiner Meinung nach doch verstehen um wirklich komplexe Dinge zu implementieren und die wird es in fast jedem größeren Spiel geben.

Andrea

Hallo!

Ich arbeite gerade an einem "VisualTAG", mit folgenden Features:

+Links werden alle Räume, Objekte, Befehle,usw... aufgelistet, wenn man darauf klickt kommt man direkt zu dieser zeile

+Man kann direkt aus dem Programm TAG,TAM,"TAGPacker"(auch ein Projekt von mir, mit dem man aus TAG-Dateien EXE-Dateien erstellen kann, damit man TAM.EXE nicht mitliefern muss) aufrufen kann

+Wenn TAG Fehler meldet, analysiert das Programm diese und zeigt die Fehler an

+Automatischer Zeilenumbruch nach 80 Zeichen

Dieses Programm soll auf keinem Fall den Quelltext erstellen, der wird immer noch in einem "integrierten" Editor SELBST geschrieben.

Falls jemand noch Vorschläge hat: bitte melden!

@Martin

Falls du etwas dagegen hast, kann ich das Projekt auch wieder abblasen bzw. unter einem anderen Namen weiterentwickeln.

the_easterbunny:

Dieses Programm soll auf keinem Fall den Quelltext erstellen, der wird immer noch in einem "integrierten" Editor SELBST geschrieben.

Hallo, Easterbunny

das ist auch gut so.