Die ganzen Diskussionen zur Tile-ID und wie man eventuell ohne auskommen könnte (http://www.xforce-online.de/forum/index.php?action=vthread&forum=20&t opic=1351) haben mich eher zu der Überzeugung gebracht das man doch nicht ohne auskommt - und so wie es aussieht wird in einer der nächsten Versionen diese ID auch tatsächlich eingefügt.

Ich möchte deshalb hier darüber diskutieren, welche Eigenschaften eine Tile-ID haben muss, damit man dort nicht nachträglich Probleme kriegt.

Mein ursprüngliches ID-Konzept hat nämlich eine solche Lücke (auf die mich Jim hingewiesen hat) und hätte deshalb zwar viele aber nicht alle Probleme beseitigt.


Welche Probleme muss die Tile-ID beseitigen?

- Wenn die Tile-ID ausgegeben wird sollte der Spieler ermitteln können woher er das fehlende Tile bekommen kann.
- Ein Tile sollte Tileset-übergreifend identifizierbar bleiben, damit eine Import-Funktion möglich wird.
- Wenn der Tileset-Ersteller sein Tile bearbeitet sollte die neue Version von der alten unterscheidbar bleiben (wird zwar nur bei massiven Änderungen wirklich notwendig, aber das Programm kann den Umfang der Änderungen nicht zuordnen)
- Das Löschen eines Tiles aus einem Tileset darf die ID der anderen nicht verändern.

Gibt es noch andere Punkte die eine ID erfüllen sollte?
Wenn ja bitte posten...


Die bisherigen Vorschläge sind:

Die GUIDs bieten auf jeden Fall eine absolut eindeutige Identifizierung aller Tiles. Dies ermöglicht dann nach belieben Import von Tiles in andere Sets und Löschvorgänge etc, aber der Spieler kann eine GUID nur über eine Datenbank einem bestimmten Tileset zuordnen und man kann auch nur über eine Datenbank auf verschiedene Versionen desselben Tiles zurückschließen.


Mein Konzept bestand aus zwei Komponenten:
- Der Tilesetersteller musste zwangsweise eine Namenskonvention einhalten, die aus einer persönlichen Kennung für den Tilesetersteller plus einem Thema-Namen den Namen des Tilesets zusammensetzte.
- Die Tile-ID wurde dann aus dem Namen des Tilesets plus einer fortlaufenden ID-Ziffer gebildet.

Dieses Konzept hätte die Tiles für den Spieler identifizierbar und importierbar gemacht, aber zum einen wäre es nicht 100% eindeutig (wenn sich zwei Tileset-Ersteller für dasselbe Namenskürzel entschieden hätten wäre es problematisch geworden) und zum anderen gibt es keinerlei Zuordnung von unterschiedlichen Versionen eines Tiles.


Aktuell würde ich mein Konzept um die Versionskennziffer als dritte Komponente erweitern, aber da taucht auch die Frage auf ob ich nicht noch weitere Punkte übersehen habe...

Mal laut gedacht: sollte XML diese Probleme nicht lösen können.

Ich erinnere mich das hier ein Mechanismus für die eindeutige Namensgebung von Objekten vorhanden ist. (dem Domainsystem im Internet ähnlich). Diese würde auch mit den 2 Komponenten deines Konzeptes funktionieren (würden unter der Domain kommen).

Autor.Thema.Setnummer.Tilenummer
sarun.cityaddon.set2.30

Versionen gibt es nicht sondern die Nummer wird immer erhöht. Das ist ähnlich mit "deprecate" in Java - wo man auch alte Klassen zur Rückwertskompatibilität hat - diese aber nicht mehr verwenden sollte (also könnte der Editor warnen).

Statt einer DB könnten dann XML Strukturen (files oder Text-addons) verwendet werden welche im Tileset dabei sind.

<!ELEMENT Tileset(author?,version?,tiles*)>
<!ELEMENT author(#PCDATA)>    
<!ELEMENT version(#PCDATA)>

<!ELEMENT tiles(ID, copyright, depricate, reference)>
<!ELEMENT ID(#PCDATA)>
<!ELEMENT copyright(#PCDATA)>
<!ELEMENT depricate(#PCDATA)>
<!ELEMENT reference(#PCDATA)>

Wenn man aber Tiles löscht so erfolgt ein Mapping (mittels der Referenz) auf die neue Tile oder aber auf einen Dummywert welcher ein leeres Objekt im Standardtileset beinhält. Das würde bedeuten das das Prog. nicht crashed sondern das Resultat einfach kommisch aussieht.

zB:
Loch in der Mauer (blöd)
fehlender Zaun (naja)
fehlende Kiste (no problem)
...


Was meint Ihr?

Bei fortlaufenden Ziffern hat man das Problem dass die IDs doppelt vergeben werden sobald verschiedene Autoren gleichzeitig an einem Set rumwerkeln (wie und warum auch immer).

Vielleicht sollte man da besser einen Zeitstempel benutzen.

@Sarun:
Man sollte die 4 Werte ohne das XML-Drumherum direkt speichern.
1.) spart dies Speicherplatz (20 Bytes statt 200 Bytes pro Tile machen eine Menge aus, wenn man ein Tileset mit 40 Tiles downloaden will)
2.) bringt die Verwendung von XML keinerlei zusätzliche Vorteile, da die Editoren geschlossene Programme ohne XML-Funktionalität sind...

@Andiana:
Nein, denn genau daraus entstehen die Probleme aktuell. Es darf nicht sein das mehrere Autoren gleichzeitig an einem Tileset arbeiten. Sie MÜSSEN nacheinander die jeweils neueste Version des anderen erweitern oder (noch besser) gleich eigene Tilesets erstellen.
Deshalb sollen die Tilesets laut Planung auch einen Passwortschutz erhalten und eine Kennzeichnung des Grafikers tragen, damit die Tilenamen eines anderen Grafikers auch anders aussehen.

Und kombinierte Tilesets sollen dann über Importfunktionen entstehen, die mit solchen IDs keine Schwierigkeit mehr sind.

Aus meiner Sicht, sind eigentlich zwei Dinge wichtig, um etwas Ordnung ins Chaos zu bringen.

1. Wird Dirk schon schrieb: Passwortschutz fürs Bearbeiten, so dass nicht mehrere Leute an einem Tileset arbeiten. Das bringt im Moment die meisten Probleme.
2. Versionisierung: Heisst, dass es eine Versionsnummer im Tileset gibt. Neue Tiles werden mit der aktuellen Versionsnummer markiert. Im Tileeditor gibts eine Funktion "veröffentlichen", mit der die aktuelle Version als abgeschlossen markiert wird und der Versionszähler erhöht wird. Tiles aus einer älteren Version können NICHT mehr gelöscht werden, da eventuell ein Map-Designer diese bereits benutzt hat.

Im Karteneditor wird man drauf hingewiesen, wenn ein Tileset vorliegt, dass nicht als "Veröffentlicht" vorliegt. Heisst also, die Tileset Designer geben nur noch Versionen raus, die als veröffentlicht markiert wurden. Der Kartendesigner kann dann sicher sein, dass die Tiles in einer neuen Version immer noch vorhanden sind.

Für Karten ist dann nur noch interessant, welches Tileset in welcher Version eingebunden wird. Zusätzlich zur Versionsnummer gibts dann noch einen Zeitstempel der Veröffentlichung, um sicherzustellen, dass die Version des Tilesets die gleiche ist, mit der die Karte erstellt wurde. Sicherlich stellt es dann kein Problem dar, wenn das Tileset in einer neueren Version vorliegt.

Im Online-Updater werde ich dann nur Tilesets zur Verfügung stellen, die als "veröffentlicht" markiert sind. Wer seine Tilesets nicht über den Online-Updater anbietet sollte selbst drauf achten, vorher die entsprechende Funktion im Tile-Editor zu nutzen. Wenn nicht, bekommt er hoffentlich Hinweise von den Karten-Designer, wenn dort im Editor angezeigt wird, dass es sich um eine nicht veröffentlichte Version des Tilessets handelt.
Wozu doppelte Datenhaltung?

Dass ein Passwortschutz kommt hatte ich mir schon gedacht. Nur weiß jeder das der beste Schutz nichts bewirken kann wenn der Benutzer nicht bestimmte Regeln befolgt. Klar kann man dann sagen "selbst Schuld" aber es ist meiner Meinung nach nicht verkehrt wenn man so etwas auch erkennen und entsprechend Handeln kann.

Außerdem was ist wenn es eine Importfunktionen geben sollte. Wird dann eine neue ID mit dem Namen des Importeurs angelegt? Dies würde ja bedeuten dass dann wieder Tiles mehrfach unter anderen Namen auftauchen. Und man kann auch nicht mehr den ursprünglichen Grafiker ausfindig machen falls es zu Copyright-Fragen kommt.
Wird die ID behalten bekommt man die Situation in der mehrere Autoren gleichzeitig ein Tile bearbeiten können.
Es sei denn es wird gesagt das Importierte Tiles nicht mehr bearbeitet werden können. Dann stellt sich aber die Frage warum man Improtieren können sollte.

Das mit der "veröffentlichen" Funktion ist gut.

Arbeitserleichterung für Kartenersteller

Es gibt jetzt schon sehr viele und große Tilesets, das wird nicht weniger werden. Damit erhöht sich aber auch die Zahl der Reiter in der Tilesetliste und die Suchzeit nach speziellen Tiles.

- Wenn ein Kartenersteller nur je 2-3 Tiles aus mehreren großen Tilesets braucht, kann er sie per Import in einem Set zusammenfassen.
- Verschiedene Leute haben unterschiedliche Vorstellung von Themensortierung (Landschaft, Kultur, Missionstyp oder anderes) und wollen das an ihre Bedürfnisse anpassen.

-----------------------

Wenn man eine Einschränkung setzt das nur veröffentlichte Tiles importiert werden können, dann hat man einen weiteren Anreiz zur Veröffentlichung und man kann alle importierten Tiles vor der Veröffentlichung wieder aus den Kartensets herausnehmen, ohne Probleme zu kriegen.

Außerdem wäre es eine Überlegung wert, im Karteneditor den Pfad von dem die Tiles geladen werden einstellbar zu machen. Dann gibt es ein schreibgeschütztes Verzeichnis mit allen veröffentlichten Tilesets und andere Verzeichnisse mit lokalen Zusammenstellungen je nach Wunsch des Kartenerstellers.

Doch - wenn man die ID komplett intern speichert.
D.h. die ID gibt den Namen des Tilesets an und wird zusätzlich in jedem Tile komplett gespeichert.
Beim importieren wird dann natürlich der interne Name des Tiles übernommen, d.h. das Tilesets hat nach wie vor den Namen des Erstellers, das importierte Tile wird aber mit dem Namen seines Originals verwaltet und wenn das Programm das Tile vermisst wird auch nach dem Original-Tileset gefragt...

Das erfordert natürlich ein paar Änderungen in der Ladelogik, deshalb auch die oben überlegt Einschränkung auf "nur veröffentlichte Tiles" - das würde die Ladelogik wieder etwas einfacher machen...

Und importierte Tiles sollen auch nicht mehr bearbeitet werden - weshalb sollte man auch ein Tile bearbeiten wollen das jemand anders schon fertig gestellt hat?

Ich sehe immernoch nicht, wozu das gut sein soll. Wenn jemand seine Karte fertig hat, dann interessiert es ihn doch sowieso nicht, wenn eine neue Version des verwendeten Tilesets rauskommt. Er wird einfach weiterhin die alte benutzen. Und anderweitige Konflikte mit Versionen sehe ich zumindest nicht, da ja Tileset + Karte sowieso im Spielsatz gespeichert werden müssen. Das Löschen von Tiles zu verbieten (egal aus welchem Grund) finde ich gerade verkehrt. Denn das eigentliche Problem ist doch die derzeit schlechte Bedienbarkeit/Flexibilität des Tileset- und des Karfteneditors.


Weil man es z.B. farblich an die eigenen Tiles anpassen will?

Jep, wer Tiles aus verschiedenen Quellen importiert, der möchte auch dass diese zusammen passen und nimmt u. U. kleine Änderungen vor.

DirkF, gibt es denn ein fertiges Konzept wo man nachlesen kann was wie umgesetzt werden soll? Denn ohne das hat hier jeder ne andere Vorstellung von dem was die ID erfüllen sollte und es wird nur über anderes diskutiert. Ich z. B. kann absolut nicht erkennen warum es eine Importfunktion geben sollte. Die würde nur Sinn machen wenn man nun doch nicht mehrere Tilesets in einer Karte benutzt.

Da verwechselt Ihr Tiles und Bitmaps - kleine grafische Manipulationen an Tiles sind nicht möglich da die Bitmap nicht extrahiert werden kann. Und wenn man die Bitmap hat kann man auch gleich ein neues Tile anlegen und braucht keinen Import.
Allerdings habt Ihr in sofern recht, das man ja eventuell die Zerstörbarkeit vereinheitlichen will etc.


Das Problem ist genau die Einschränkung die Du hier triffst:
"Wenn die Karte fertig ist"

Kartenersteller B benutzt das Tileset von A in Version 1 zur Kartenerstellung. Während er noch an seiner Karte arbeitet, bringt A eine Version 2 heraus, in der einige Tiles gelöscht wurden, dafür aber andere hinzugefügt.

Kartenersteller B findet einige der neuen Tiles gut, braucht aber zwangsweise noch einige der gelöschten Tiles. Was soll er machen?
- die neue Version für die neuen Tiles kann er nicht benutzen, da dann die Karte nach den jetzt fehlenden Tiles schreit.
- nur die alte benutzen bedeutet auf die neuen grafiken zu verzichten.
- die neue umbenennen ruft später Probleme hervor, wenn die Tiles eventuell wild gemischt werden oder noch andere Versionen herauskommen.

Das sich Tiles aktuell nicht löschen lassen ist ein Schutz für den Kartenersteller, der sich andernfalls auf zahllose Unwägbarkeiten einlässt. Die ID soll dies reduzieren, damit begrenzt eine Löschfunktion eingeführt werden kann - aber unbegrenztes Löschen würde dem Kartenersteller nur Ärger bringen und wird deshalb nicht kommen.


Fertige und getestete Karten werden im Spielsatz importiert, da hast Du recht. Und was ist mit dem großen Rest???

Wenn ich aus dem Netz einen Kartensatz herunterlade, dann will ich jede einzelne testen ob sie zu meinem Spielsatz passt bevor ich sie importiere. Das gleiche gilt wenn ich selber eine spezielle Missionskarte erstelle - die wird kaum beim ersten Versuch perfekt sein.
Ich werde aber wohl kaum während dieser Tests immer wieder die Karten importieren, testen, löschen, nächste Version und von vorne.
Das würde lediglich den Spielsatz etwas fragmentieren, eventuell kann man bei einbindungen etwas zu löschen vergessen und davon abgesehen ist das einfach unnütze Arbeit.

Und damit habe ich noch nichteinmal diejenigen Spielsatzersteller genannt, die keine Lust auf ein Balancing und Auswahl von Bodenkarten haben sondern einfach nur Aliens erstellen und wollen das die mit jeder Karte funktionieren.

Was ich mir wünsche sind 2 Flags im Spielsatz und zwar "interne Karten verwenden ja/nein" und "externe Karten verwenden ja/nein". Wenn ich dann teste schalte ich die fertigen internen Karten ab und lege die fraglichen Karten einzeln in das Verzeichnis für externe Kartendateien.

Sobald man aber mit externen Karten arbeitet, kann man auch nicht mehr so einfach garantieren das alle Tilesets in einer spezifischen Version vorliegen.
Deshalb ist die Sperre das offiziell veröffentlichte Tiles in zukünftigen Versionen des Tilesets nicht mehr gelöscht werden dürfen sehr wohl notwendig.

Es gibt kein Konzept außer meiner Einleitung in diesem Post und den verschiedenen Ideen zur Realisierung. Hier ist im Endeffekt noch alles offen, wobei die Importfunktion von mir ursprünglich nur zur Sortierung und Verwaltung gedacht war, damit man nicht immer 50 Tilesets von 10 verschiedenen Erstellern nach einem bestimmten häufig genutzen Tile durchsuchen muss.

Wie würdest du so schön sagen: "Jein" (*lol*)
Das ist einer der Punkte, die ich mit Bedienbarkeit der Editoren meine. Es sollte einfach möglich sein, einzelne Tiles aus einem Tileset zu bearbeiten (z.B. mit einer Funktion "Tile als Bitmap in die Zwischenablage kopieren" und einer Funktion "Bitmap aus Zwischenablage für dieses Tile übernehmen").


Unvollständige Karten sollten doch garnicht erst veröffentlicht werden. Und der Kartenersteller sollte ja nun wirklich keine Probleme haben, seine Daten zu verwalten. Schließlich haben Dateisysteme schon seit Jahrzehnten Ordnerstrukturen, so dass er für jede Karte in Arbeit ein extra Verzeichnis mit den verwendeten Tilesets anlegen kann.
Ganz einfach. Er importiert die Tiles die ihm gefallen in das von ihm verwendete Tileset. Und das ist auch gleich ein Grund mehr, warum man einzelne Tiles löschen können sollte. Nehmen wir an, unser Kartenersteller verwendet Tilset A, findet aber in Tileset B eine schönere Straße. Jetzt wird er die entsprechenden Tiles aud B nach A importieren. Logischer Weise will er dann die alten Straßentiles löschen, um die Übersichtlichkeit zu wahren. Und im Sinne der Benutzerfreundlichkeit sollte es dann auch möglich sein, die Reihenfolge der Tiles zu ändern, oder gar Tiles in einem Tileset zu gruppieren.


Wieso importieren, ltesten, löschen ...??? Natürlich müssen die Karten auch direkt im Spielsatz bearbeitet werden können, so wie das bei den Skripten ja auch gehandhabt wird. Und die Skripte habe ich zumindest bisher immer gleich im Spielsatz angelegt.

Ja, das ist natürlich viel einfacher (Sarkasmus). Nur musst du dann dazu erstmal alle Standardkarten aus dem Verzeichnis rausschmeißen (wodurch dann andere Spielsätze Probleme kriegen), sonst musst du ja ewig spielen, bis die gewünschte Karte mal kommt. Nicht falsch verstehen, dieses Flag halte ich auch für nötig. Aber ich sehe das nicht im Zusammenhang mit Versionskonflikten. Dieses Flag sollte nur dazu dienen, wenn jemand die Standard-Maps nutzen will. Aber ok, wenn du deine Maps so testen willst, warum dann nicht einfach im Spielsatz noch ein Verzeichnis angeben, in dem die zu verwendenden externen Karten und Tilesets zu suchen sind. Dann legst du für die zu testenden Karten ein neues Verzeichnis an, und es gibt keine Probleme.


Sehe ich nicht so. Es sollte nur eine begrenzte Menge an Standardtilesets geben, nämlich diejenigen, welche im offiziellen Spielsatz Verwendung finden. Da diese im Installationspacket enthalten sind, kann daran sowieso nicht jeder dran rumpfuschen (höchstens auf dem eigenen Rechner, aber dann ist man selbst schuld). Alle anderen Tilesets können zwar auch zum Download angeboten werden, werden aber nicht in den Standard übernommen. Stattdessen muss sich ein Kartenersteller die benötigten Tilesets selbst zusammensuchen, und dann zusammen mit der/den Karte(n) speichern. Anders gesagt, bis auf die Standardtilesets werden in Karten verwendete Tilesets immer in dem Ordner gesucht, in dem sich auch die Karte selbst befindet.

@Natter:
So kann man das natürlich auch handhaben, aber dann muss praktisch das ganze Paket von Tileeditor und Karteneditor massiv umprogrammiert werden.
Ich habe absolut nichts gegen Bedienbarkeit wie z.B. eine Tile-Bitmap zu exportieren oder die Tiles beliebig neu ordnen zu können etc. - nur ist das deutlich mehr Programmieraufwand als mit einer Tile-ID und ein paar kleinen Zusatzfunktionen die bestehenden Editoren besser verwendbar zu machen.

Damit liegt die Entscheidung hier flach bis Jim gesagt hat ob die Kapazitäten für so eine größere Reprogrammierung verfügbar sind oder ob er mit möglichst wenig Änderungen an den Editoren auskommen möchte.

Sobald wir das wissen kann man dann wieder gezielter überlegen - bei einer größerem Umprogrammierung würde ich auch einige Punkte anders ansetzen und mehr Natter's Weg folgen (plus einiger eigener Ideen)...

Mag sein. Aber ich glaube eben nicht, dass die bisher vorgeschlagene ID die aktuellen Probleme lösen kann. Warum haben denn alle für ihre eigenen Tilesets die dummy.t3d verwendet? Ich würde mal vermuten, weil das Anlegen neuer Tilesets zu Problemen geführt hat (Fehlermeldungen etc.), und weil die Editoren benutzerunfreundlich sind. Die Einführung einer ID ist sicher nötig, aber die bisher diskutierten Konzepte ändern nichts am Grundproblem.

Nun, ich weiß nicht, ob er das hier überhaupt lesen wird, aber ich würde sagen Jim will sicher so wenig wie möglich an den Editoren programmieren, aber er will auch keine halben Sachen, die ihn später zwingen, das ganze nochmal zu überarbeiten.

Okay ich gebe zu ich habe das ganze nicht genau gelesen, nur überflogen (genauso wie bei Mehrere Tilests oder nur eins pro Map? aber ist ja egal)

Was mir in den Sinn gekommen ist ist folgendes:

Wir brauchen eine eindeutige ID und das unabhängig vom User! (hoffe mal das ist noch so und nicht schon weiter oben gelöst worden ^^)

Wie wäre es mit Hash oder so was in der Art?

So wie ich das sehe, lösen wir damit ein paar Probleme.

Doppelte Tiles werden vom Spiel identifiziert (gegebenenfalls fragt man den User ob x und y gleich sind und man y aus dem Tileset rauswerfen kann)

Die Karte kann wenn es ein Tile im Set nicht mehr findet, in anderen Tilesets nachschauen ob sie das Tile vielleicht auch enthalten.

Und vielleicht auch ein paar der anderen Probleme mit dennen ihr euch bekriegt habt ;) (wo ist meine Kevlarweste? ^^)

Und Hash dann als ID? Ja das wäre eine möglichkeit finde ich.

Und ich wollte auch mal Tilesets machen, doch dann hab ich gesehen wie "bescheiden" der Editor ist und dann hab ich mir gedacht , lass es doch anderen machen.
Erstmal denke ich sollte diskutiert werden wie man den Tileseteditor vereinfachen kann, und zwar so dass man kein mehrseitiges Handbuch zum bedienen braucht.


Der Updater kontrolliert die, dass wäre sinnvoller zwecks Traffic sparen.

MD5-Hashes sind mir auch gleich als erstes in den Sinn gekommen, nachdem ich das Top-Posting gelesen hatte. :) Aber mal eine andere Frage, wie wäre es denn, wenn die für eine Karte benötigten Tiles gleich zusammen mit der Karte gespeichert werden würden? Bzw. das in einer Karte auf Standardsets refrenziert aber auch spezielle Tiles mit angehängt werden können. Sofern das Problem überhaupt noch aktuell ist. :)

well is a yes no and a maybe https://financialadvisorlubbock.com