Banner left   Banner center   Banner right

Germanenglish Home · News · Diary · Screenshots · Documentation (Wiki) · Downloads · Guestbook · Forum

Home · Benutzer registrieren · Suchen · Statistik · FAQ · Benutzerliste

Zur Zeit online: keiner ausser dir

 X-Force - Fight For Destiny - Forum —› Quellcode / Programmierung —› Meinung zu extrenen Tools

Autor Mitteilung
verfasst am: 22.05.2011, 13:45
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
Mit externen Tools meine ich XFTools, die nicht von den X-Force-Programmieren und in einer x-beliebigen Programmiersprache entwickelt werden.

Es gibt vielleicht den einen oder anderen der keine Delphi IDE besitzt aber trotzdem etwas für X-Force programmieren möchte.
Diejenigen können in eigenständigen Projekten an den Tools arbeiten. Z.B. einen neuen MapEditor entwickeln oder ein Tool das beim übersetzen hilft (ich glaub das gibt es noch gar nicht).

Der Vorteil liegt klar auf der Hand: Die Gamesetersteller und Co. bekommen ggf. bessere Tools und ihre Wünsche könnten schnell umgesetzt werden.
Im Optimalfall können sich die Delphi-Leute auf das Spiel konzentrieren und die Tools den anderen überlassen.

Aber es gibt auch Nachteile:
- Am Ende könnte es x Tools in x verschiedenen Programmiersprachen geben. Wenn dann jemand an mehr als einem Tool mithelfen möchte dann muss er sich mit mehreren Sprachen und IDEs auseinandersetzen.
- Die Spielprogrammierer müssen weiterhin die internen Tools pflegen oder im dem oben genannten Problem zurechtkommen wenn sie selbst Anpassungen an eine neue Version vornehmen wollen oder müssen.
- Es könnte sein dass die Tools die bearbeiteten Dateien nicht 100% in dem selben Format speichern wie es die internen Tools es tun und es dann im Spiel zu "unerklärbaren" Bugs kommt.
- ggf. müssen Änderungen an den Dateiformaten vorgenommen werden oder Dateiformate besser dokumentiert werden.

Mich interessiert nun wie eure Meinungen zu solchen Projekten sind. Besonders natürlich die der Programmierer.

Sollte es da bestimmte Einschränkungen geben?
Oder sollte einfach erstmal jeder der will ein eigenes Projekt erstellen (oder sich eins anschließen) so wie er es mag, Hauptsache die Delphi-Leute erhalten nicht zusätzliche Arbeit?
Oder findet ihr dass sowas nicht unterstützt werden sollte und stattdessen überlegt werden sollte ob die Tools (nicht das ganze Spiel) nach und nach in einer anderen Sprache portiert werden sollten?
verfasst am: 22.05.2011, 14:39 · Edited by: sujin
Spielsatz Alliances

Registrierdatum: 14.07.2004, 14:47

 Beiträge: 1185
An was für Tools dachtest du denn? Eigentlich sind die bisherigen sehr umfassend und gut, besonders wenn man die Anzahl und Zeitinvestition der Programmierer bedenkt. Davon was neu zu implementieren macht wenig Sinn, denke ich. Vor allem mit den erwähnten Probleme.

Zitat: Andiana
Oder sollte einfach erstmal jeder der will ein eigenes Projekt erstellen (oder sich eins anschließen) so wie er es mag, Hauptsache die Delphi-Leute erhalten nicht zusätzliche Arbeit?

Das letzte ist wichtig. Wird sind aber nicht ganz vermeiden lassen (beim zerlegen der Dateiformate z.B.), deshalb sollte schon ein gewisser Mehrwert dabei rumkommem können.
Zitat: Andiana
Oder findet ihr dass sowas nicht unterstützt werden sollte und stattdessen überlegt werden sollte ob die Tools (nicht das ganze Spiel) nach und nach in einer anderen Sprache portiert werden sollten?

Das ist ein enormer Aufwand - nicht so groß wie das ganze Spiel zu portieren, aber trotzdem ein ziemlicher Aufwand. Ich denke nicht, dass die Chancen allzu gut stehen.
verfasst am: 22.05.2011, 17:23
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Hmm bei den aktuellen Tools (vor allem den wichtigen) sehe ich nicht, wie sich das so ohne weiteres machen lässt. Die meisten sind nämlich eng mit dem eigentlichen Spiel gekoppelt. So sind z.B. die Tileformate für den Mapeditor, den Tileseteditor und im Spiel identisch, und werden in der gleichen Unit definiert. Wenn man also dort was ändert (z.B. neue Eigenschaft oder Prozedure) wirkt sich das automatisch auf alle Tools aus. Diesen Vorteil verliert man bei einer Aufspalltung. Noch mehr gilt das wohl für den Spielsatzeditor und medit. Am besten wäre natürlich eine Komplettumstellung auf eine andere Sprache (inklusive des eigentlichen Spieles) - allerdings ist der Aufwand enorm, selbst wenn man nur zu Lazarus (ähnlich wie Delphi, aber OpenSource) wechseln würde.
verfasst am: 24.05.2011, 11:38
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
> An was für Tools dachtest du denn?
Hier geht's prinzipiell um alles an den sich neue Programmierer heran trauen.

> Eigentlich sind die bisherigen sehr umfassend und gut, besonders wenn man die Anzahl und Zeitinvestition der Programmierer bedenkt.

Das ist richtig und ich sage ja auch nicht dass sie schlecht sind, aber besser/mehr geht immer.
Um beim Beispiel des MapEditors zu bleiben: Da gab es z. B. schon vor Jahren den Wunsch Kartenteile aus einer Map in eine andere kopieren zu können. Das geht aber jetzt erst seit der 917 und auch nur indem man die Maps in einem Texteditor bearbeitet. Das ist i.O aber halt nicht sehr komfortabel und auch eine mögliche Fehlerquelle.

> Das ist ein enormer Aufwand - nicht so groß wie das ganze Spiel zu portieren, aber trotzdem ein ziemlicher Aufwand. Ich denke nicht, dass die Chancen allzu gut stehen
Ja es ist ein Aufwand den man schlecht abschätzen kann. Aber diesen Aufwand betreiben dann Leute die sonst gar nicht da wären. Also im dem Sinne schadet es XForce nicht wenn das ganze dann doch nicht klapt. Es hängt da nur von den neuen Programmieren ab, ob sie das Risiko eingehen.

> So sind z.B. die Tileformate für den Mapeditor, den Tileseteditor und im Spiel identisch, und werden in der gleichen Unit definiert. Wenn man also dort was ändert (z.B. neue Eigenschaft oder Prozedure) wirkt sich das automatisch auf alle Tools aus. Diesen Vorteil verliert man bei einer Aufspalltung.
Das ist in der Tat ein Nachteil der gegen eine Teil-Portierung spricht.
Aber nur bedingt gegen externe Tools. Da die Entwicklung des Spiels nicht so schnell von statten geht, ist es nicht weiter tragisch wenn zusätzliche Tools ne Zeit lang inkompatibel sind. Nur die Delphi-Leute müssen zusehen dass sie ihre internen Tools schnellstmöglich kompatibel bekommen, so oder so.

Um es mal mit einem anderen Beispiel zu sagen:
Mann kann sagen dass in Windows integrierten Tools eigentlich ausreichen und warten bis MS ersehnte Funktionen einbauen.
Man kann aber auch sagen "Ich kann halbwegs vernünftig programmieren und versuch ein eigenes (subjektiv) besseres Tool zu entwickeln. Und ich sch*** was drauf dass ich mir mehr Arbeit mach als nötig und ich nach jeden "Service"-Pack wieder alles umschreiben muss".
Ich hab jetzt noch nie ein Windows-Programm geschrieben, aber tendiere da zum letzten. (Ok mehr dazu dass andere es machen ;))

Nur will ich (und sicher auch noch andere) im Gegensatz zum Beispiel euch damit unterstützen, nicht umbedingt ein neues Tool haben.
verfasst am: 24.05.2011, 16:00
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
Das Hauptargument gegen nicht-Delphi-Tools ist im wesentlichen die dann entstehende nicht-kompatibilität der Units.
Das ist keineswegs trivial, denn sobald gespeicherte Daten nicht mehr kompatibel sind, werden die externen Tools schlichtweg unbenutzbar.
Denn was bringt z.B. ein externer Karteneditor, wenn das Hauptprogramm die dadurch gespeicherten Karten nicht mehr verwenden kann (weil z.B. die Felder um neue Eigenschaften ergänzt wurden, die vom externen Karteneditor noch nicht unterstützt werden)?

Man kann also entweder nur Tools extern vergeben, bei denen die Kompatibilität egal ist (was nur in wenigen Fällen gegeben wäre) oder aber wenn der externe Programmierer eine von uns durchgeführte Änderung der Formate in den Schnittstellen sehr zügig übernehmen kann.

Anstatt hier irgendwelche theoretischen Diskussionen zu führen, könnte man aber mal ein paar konkrete Fälle überlegen.

Mach doch mal einen Vorschlag, was man eventuell als externen Editor realisieren könnte und dann diskutieren wir konkret, was dafür notwendig wäre.

Ein paar Sachen sind da durchaus denkbar, allerdings wäre genau der Editor an den ich gerade denke noch nicht möglich - das wäre ein Zusatzeditor für ein noch nicht implementierten Bereich der Modellumsetzung, da muss man mindestens warten bis ich die Grundstruktur der Projektliste fertig habe und mit der Umsetzung der Basismodelle beginne...
verfasst am: 25.05.2011, 02:24
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
Gut dann werde ich mal konkret.
Ich beschäftige mich seit einigen Tagen mit der Flash-Programmierung bzw. dem Flex SDK (MXML & ActionScript).
Da ich die Tage auch über die XML-Ausgabe im neuen TilesetEditor gestolpert bin, dachte ich mir es sei interessanter dies XML in meinem Übungsprojekt zu benutzen als irgendwelche fiktiven Adressenlisten. Und nun denke ich dass ich daraus weitaus mehr machen kann, einen vollwertigen TilesetEditor.
Hier die bisherige FlashApp. Die Bilder für arrow, stonetilesA und B hab ich mit hochgeladen damit man sich besser anschauen kann wie es werden könnte.

Inzwischen habe ich mich durch den XForce Code gekämpft und bin mir nun sicher dass ich das Speichern der TileSets alleine hinbekomme.
Das direkte Laden und Anzeigen der Bilder wird an der LHA-Komprimierung scheitern. Aber das Problem lässt sich auch lösen.
Ich für meinen Teil werde unabhängig davon was ihr nun dazu sagt daran weiter arbeiten. Den als Lernprojekt finde ich es klasse und wenn es dann von dem einen oder anderen benutzt wird ist es noch besser. Aber ob es weiter nur mein Lernprojekt bleibt oder mehr draus wird, hängt vom Ergebnis dieser Diskussion ab.
Damit animiere ich vielleicht noch andere nicht-Delphi-Programmierer aktiv zu werden.
verfasst am: 25.05.2011, 08:49
Registrierdatum: 22.08.2008, 15:51

 Beiträge: 403
Ich finds sehr interessant, die Auflistung ist besser als im Original.
verfasst am: 25.05.2011, 13:23 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zumindest als Ideengeber ist so ein Projekt sehr interessant. Mir gefällt besonders, dass man sofort per Symbol das Layer und die Begehbarkeit sieht. Solange man in den "normalen" Tools einfachen Im- und Export von XML-Dateien zulässt, kann so ein Tool auch durchaus mal nützlich sein (das müssten allerdings die Grafiker entscheiden). Leider kann es imho das normale Tool nicht ersetzen, weil man dann ja immer auf einen entsprechenden Programmierer angewiesen ist, der nötige Änderungen umsetzt (ich hab z.B. noch nie mit Flash gearbeitet). Bin mal gespannt, wie du die anderen Tilearten umsetzt. Wenn man da die Grafiken anzeigen will, wird die Tabelle deutlich unübersichtlicher. Man könnte natürlich bei den Dateinamen bleiben (gibt ja wie du sagtest eh Probleme mit der Komprimierung), aber dann fehlt so ein wenig die sofortige Kontrolle, ob alle Grafiken richtig zugeordnet sind (und da gabs schon oft Probleme).
Übrigens hatte ch auch noch eine weitere "Tileart" angedacht, nur noch nicht umgesetzt. Dabei geht es darum, Kartenausschnitte (z.B. ein Has oder ähnliches) aus mehreren Tiles direkt im Tileset abzuspeichern, um sie dann im Mapeditor als Ganzes setzen zu können. Vielleicht hast du ja auch dafür eine gute Idee.

Denkbar wäre auch noch ein Tool für die Städteliste (die hab ich irgendwann mal auf XML umgestellt, wenn ich mich recht entsinne).
verfasst am: 25.05.2011, 16:56 · Edited by: Andiana
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
@Kreks Danke :)

Ja das ist halt die Frage ob fremdsprachige Tools hier nun in der Form unterstützt werden, indem die bisherigen Tools mit In- und Exportfunktionen erweitert werden.
Pro: Man kann sich mehr darauf verlassen, dass die Daten wirklich einheitlich gespeichert werden.
Kontra: Das belastet die Delphi-Leute mit Zusatzarbeit.

Ich wäre aber dafür das ein Tool geschrieben wird das die Archive (alles läuft über die components/ArchivFile.pas) einfach nur in ein anderes Format (unkomprimiert) konvertiert. Dann ist zwar kein verlass mehr auf den Inhalt der Archiv aber jeder könnte ohne Umwege sämtliche Daten bearbeiten. Daran könnte ich mich auch dransetzen, falls ihr das wollt.

Ja die extrenen Tools kann man nur als Alternativen für die Benutzer sehen, nicht als Ersatz.
Eigentlich fände ich es besser wenn diese allesamt mit Lazarus erstellt werden. Das würde alles etwas weniger Problematisch machen und ermöglicht dann einen späteren Umstieg. Aber dass passt momentan nicht mit meinen Planen mich mit Flash zu beschäftigen zusammen. Da müssten sich dann noch andere für melden.

Das mit der neuen Tileart ist interessant, ich hab da auch noch eine Idee. Aber erstmal werde ich die bisherigen in mein Tool integrieren.

Ach ja:
Die Bilder der Tile plane ich alle unter der Tabelle anzuzeigen. So wie es nun auch bei einem Klick auf die GT stonetilesA und B ist.
verfasst am: 25.05.2011, 17:55
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: Andiana
Eigentlich fände ich es besser wenn diese allesamt mit Lazarus erstellt werden. Das würde alles etwas weniger Problematisch machen und ermöglicht dann einen späteren Umstieg. Aber dass passt momentan nicht mit meinen Planen mich mit Flash zu beschäftigen zusammen. Da müssten sich dann noch andere für melden.

Ja, dafür könnte ich mich auch eher erwärmen. Zumal dann wohl auch ausgewählte Units gemeinsam nutzbar wären (also von Delphi und Lazarus). Vor allem der Mapeditor wäre da in meinen Augen ein Kandidat, inklusive Umstellung auf OpenGL. Der bisherige ist in gewisser Weise nur eine Notlösung, weil die Komponente zum Darstellen der Karte nicht mehr wirklich über Turbo-Delphi bearbeitet werden kann.
verfasst am: 26.05.2011, 02:33
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
Jap mit
{$IFDEF FPC}
  {$MODE Delphi}
{$ENDIF}


kann ich tatsächlich ohne weitere Anpassungen die Unit ArchivFile verwenden. :D
Also kann ich die Achive nach bedarf umwandeln, in meinem Tool benutzen und wieder zurückwandeln.

Oh auch noch OpenGL? Na dann wird's vielleicht ja doch noch etwas mit der Linux Portierung ;)
verfasst am: 26.05.2011, 14:58
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: Andiana

Oh auch noch OpenGL? Na dann wird's vielleicht ja doch noch etwas mit der Linux Portierung ;)

Naja, da würde schon mehr dazugehören, als nur die Umstellung von DirectX auf OpenGl ;)
Ich wäre schon zufrieden, von DelphiX wegzukommen (basiert noch auf DirectX 7 und wird nicht gewartet) - denn das ist wohl das größte Hindernis beim Wechsel zu einer freien Programmierungebung. Allerdings müssten dazu auch sämtliche Seiten im Spiel umgestellt werden - die ISO-Engine ist da noch das kleinste Problem - leider kann man die Umstellung im Spiel nicht Stufenweise vornehmen - daher traue ich mir eine solche Umstellung nicht zu.
verfasst am: 27.05.2011, 20:08
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
Na dass war mir schon klar.
Aber es wäre schon mal der erste Schritt in die Richtung und zumindest besteht die Hoffnung dass die Tools dann unter Wine besser laufen. Das ist ja völlig ausreichent.
verfasst am: 12.06.2011, 01:30
Grafiker

Registrierdatum: 06.03.2005, 16:04

 Beiträge: 460
Wenn du was nützliches an Tools machen willst, dann befasse dich mal mit der Animationserstellung. Bzw. dem Workflow der dort in Folge zu verwendenden Tools um am Ende eine Animation zu haben. Samt Anzeige was und wo welche Animation in dem Paket fehlt.

Oder dem automatischen zerlegen einer gerenderten Hintergrundmap in Einzeltiles, um so ruckzuck an passende Tiles zu kommen.

An den funktionierenden Tools gibt es auch aus meiner Sicht wenig auszusetzen, außer dein neuer Tileeditor erlaubt das drehen der Karte ^^ oder ermöglicht asynchrone Animationen.

Als Programmiersprache würd ich schon etwas neueres wie Java(JavaFX), C#(Mono) oder eben FreePascal favorisieren.
verfasst am: 12.06.2011, 02:09
Registrierdatum: 17.12.2010, 20:36

 Beiträge: 59
nunja, die umsetzung in eine andere sprache wird unngefähr so aufwändig wie einer Katze das aportieren beizubringen^^
also lassen wir da lieber....
aber klar ist wir brauchen delphi programmer, die an x-force echt mal was verändern können, weil Dirk und Natter echt schon genug zu tun haben...
also im endeffekt haben die beiden schon genug zu tun, delphi programmer meldet euch :D
verfasst am: 12.06.2011, 11:58
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
Hmm also wenn mein Katerchen spielen will aportiert er sein Spielzeug von allein.

Delphi-Programmierer werden wir dagegen nicht so leicht bekommen.

@JohnS
Eine Funktion die Bilder in Tiles zerlegt habe ich bereits im Zusammenhang mit Natter's neuer Tileart im Hinterkopf. Aus den einzelen Tiles wird dann automatisch eine "TileCombo" erstellt, die man dann mit weiteren Objekten oder Wänden versehen kann. Diese kann man dann im Karteneditor wie Rendertiles setzen. Im Gegensatz zu den Rendertiles brauchte der Kartenersteller danach nicht mehr mit unsichtbaren Tiles hantieren und kann Teile nach belieben ersätzen.
Das selbe Format das für die "TileCombo" verwendet wird, wird dann auch für in- und exportierbare "MapTemplates" benutzt. Der einzige Unterschied wäre dass "MapTemplates" Tileset-übergreifend sind und als Einzeldatei gespeichert werden.
Aber nur wenn ich ein Mapeditor programmiere ;) Aber noch bin ich mit dem TileEditor gut beschäftigt.

Wo liegt denn der große Unterschied zwischen ActionScript3 (Flex) und JavaFX Script? Die Syntax ist nahezu identisch und Features ebenfalls.
verfasst am: 12.06.2011, 12:15
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5595
JohnS Vorschlag, die Animationstools als Ziel einer Nicht-Delphi-Programmierung zu verwenden, hat durchaus einiges für sich.
Diese Programme müssen sowieso überarbeitet und umgestellt werden (aus dengleichen Gründen wie damals der Tileset-Editor), und im Gegensatz zu anderen Bereichen gibt es da relativ wenig Datenüberschneidungen zwischen den Modelldaten und den Game-Daten.

Ich habe jetzt keine Zeit dafür, aber ich werde bei Gelegenheit mal ein Paket aus den bisherigen Tools mit Beispielen und Hinweisen auf Verbesserungsvorschläge zusammenstellen.
verfasst am: 16.06.2011, 00:06 · Edited by: Andiana
Registrierdatum: 21.10.2005, 20:08

 Beiträge: 131
Gut, wenn es soweit ist, werde schauen ob ich das hinbekomme.
Bei meinem TileSetEditor habe ich wohl die größten Hürden überwunden.
Man muss zwar erstmal ein weiteres Tool benutzen um die Tilesets zu decomprimieren, aber ich denke das ist OK. Die Handharbung ist ganz einfach: Tileset draufziehen und dann das Neue aus dem Verzeichniss "output/V0" verwenden.
verfasst am: 16.06.2011, 02:07
Grafiker

Registrierdatum: 24.11.2006, 14:22

 Beiträge: 568
Hey, dein TileSetEditor sieht schon mal ganz schick aus!
Echt nicht schlecht



Du musst dich registrieren um auf dieses Thema zu antworten.
Login :: » Name » Passwort

Ladezeit (sec.): 0.051 · Powered by miniBB 1.6 with parts of 1.7 © 2001-2003