Ich würde gerne diese OT Diskusion aus "Tilesets von JohnS" hier gerne fortsetzen.

Ich bin dabei eine größere Auswahl verschiedener Untergründe zu erstellen. Verschiedene Terantypen mit und ohne Verzierungen wie Steine, Pfützen, Schlaglöchern und was mir sonst noch so ein fällt und schaffe um zu setzen (bin eigentlich kein Grafiker). Hinzu kommt der Versuch noch optisch Höhenunterschiede mit ins Spiel einzubringen. Dann soll es noch mehrere Übergänge von jedem Teran zum Anderen in allen mögliche Richtungen geben.
Da kommt viel zusammen und ich hatte mir gedacht ich erstelle ein Tileset pro Terantyp und jeweils ein für den Übergang zwischen 2 Typen. So halte ich es für am sinnvollsten. Wenn hier aber nachher raus kommt dass jeder der eine Karte Erstellt ein passendes Tileset mit nur den benötigten Grafiken erstellen soll dann kann ich mir die mühe auch sparen und über 200 Kacheln wild gemixt in ein Demoset rein hauen.



Das Löschen scheint ja technisch auch nicht so einfach zu sein (Was passiert wenn etwas in einer Karte verwendet wurde?).
Man könnte aber vielleicht im Mapeditor eine Funktion, die alle benutzen Grafiken in ein neues Tileset kopiert und die internen Verknüfungen anpasst, einbauen.

Meiner Meinung nach ist nur 1 pro Map zwar in gewisser Hinsicht umstaendlicher, bringt aber auch Vorteile mit sich. Das ganze waer nicht mehr ganz so wirr und man wuerde einigen Fehlern vorbeugen. Allerdings muesste dann der Feature-Wunsch von mir im Bugtracker [Gruppierungen in den Tilesets oder so irgendwie] umgesetzt werden um die Uebersicht nicht zu zerstoeren.

Meiner Meinung nach würde "nur ein Tileset pro Map" mehr Verwirrung stiften als es lösen würde - und zwar unabhängig von der Sortierungsfrage.

1.) was machst Du bei unterschiedlichen Karten? Bei nur einem Tileset pro Map müstest Du entweder alle Bilder in ein einziges Tileset stecken oder aber Du könntest in einer Karte nicht alle Wandtypen mischen.

2.) Was machst Du wenn verschiedene Leute unterschiedliche Wandbilder erstellen und die zu einem Tileset addieren?
Das Universal-Set wäre in null komma nichts bei jedem Spieler anders und die Karten könnten nicht mehr so einfach getauscht werden.

Außerdem kommt das Problem mit dem Wirrwar nicht daher wieviele Tilesets es gibt, sondern daher das jeder wild benennt und andere Vorstellungen von Ordnung hat. Das kriegst Du aber auch nicht beseitigt wenn Du die Karten auf ein Tileset begrenzt.


Aktuell arbeitet die Tile-Identifizierung zweistufig: Es wird der Name des Tilesets und der Index des Tiles innerhalb des Sets gespeichert.
Deshalb muss man ja auch immer die passenden Tilesets mit genau dem gewählten Namen des Tileset-Creators im Ordner haben. Und dies gibt ein Problem sobald mehrere Leute denselben Tileset-Namen benutzen (sei es die Dummy oder Namen wie Test etc.)

Eine Zuordnung von nur einem Tileset pro Map verschiebt dieses Problem nur, beseitigt es aber nicht.


Ich sehe mehrere verschiedene Lösungsansätze mit unterschiedlichen Vor- und Nachteilen.

1.) Passwort auf Tilesets ermöglichen
Es wird eine Anzahl "offizieller" Tilesets geben, die durch ein Passwort gegen additionen von anderen geschützt sind. Dies behebt schonmal das Problem unterschiedlicher Dummy.t3d's - denn dann kann niemand mehr seine Tiles zu den bestehenden einfach addieren und muss eigene Tilesets erstellen.
Hierzu muss natürlich irgendjemand die Pflege dieser offiziellen Tilesets übernehmen und entscheiden, welches Tile wo addiert wird etc, denn das wird eine fortlaufende Arbeit werden, wenn die Community immer mehr Bilder zusteuert.

2.) komplette Tiles in Map speichern
Anstelle des Indexes für ein Tile wird die Grafik selber im Kartensatz gespeichert. Dies beseitigt auf jeden Fall alle Kompatibilitätsprobleme für den Spieler, aber zum einen werden die Karten dann deutlich größer und zum anderen können Probleme bei Kartenerweiterungen entstehen - wenn der Karteneditor nicht erkennt das ein bereits intern vorhandenes Wandteil mit einem Wandstück von einem regulären Tileset identisch ist, dann wird hier einiges doppelt gespeichert werden.
Außerdem wird der Mapeditor dann aufwendiger, denn die intern gespeicherten Mauern werden eigene Registerkarte brauchen (für diejenigen Tiles, die bei dem Map-Bearbeiter nicht lokal als T3D vorhanden sind), und darin wird es kaum eine Sortierung geben können.

3.) ZIP aus Karten- und Tile-Dateien
Jim hatte irgendwo erwähnt das die M3D und T3D-Dateien irgendwann vom Mapeditor automatisch als ZIP gebündelt werden sollen.
Das macht meiner Meinung nach nur die Verbreitung einfacher, es beseitigt nicht die Probleme bei gleichen Dateinamen mit unterschiedlichem Inhalt. Im Gegenteil dürfte es hier zu zusätzlichen Problemen führen, da nicht jeder aus einer ZIP erkennen kann ob dies mit seinen eigenen T3D-Dateien in Konflikt kommen könnte.



Namensgebung und Dateitransfer

Unabhängig von dem Lösungsansatz haben die Probleme genau zwei Ursachen:
1.) Jeder benutzt willkürliche Namen, die von anderen schon belegt sein können
2.) Man kann die Tiles in fertigen Tilesets weder vernünftig auf andere Tilesets übertragen noch irgendwie anders zusammenstellen

Zu 1 ist eine unmittelbare Lösung nur möglich, wenn wir uns auf eine verpflichtende Namenskonvention einigen und alle bestehenden Tilesets von ihren Erstellern nach dieser Konvention neu sortiert werden. Die Namenskonvention könnte z.B. lauten XXXTTTTT.t3d, wobei XXX ein Kürzel des Tileseterstellers ist und TTTTT das Thema des Tilesets nennt.
Zu 2 benötigen wir auf Dauer irgendeine Funktion, die ein Tile aus einem bestehenden Set herausnehmen kann (Passwortschutz für Copyright natürlich möglich).

Nun gut nun gut.
Also okay, deine Idee 2.:



Ist ja wohl DIE Idee.
Alles andere kann man erst mal vergessen.
Durch Umsetzung werden wahrscheinlich die meisten Probleme, die auftreten koennten behoben sein.

Ideen dazu:
m3d-datei Beinhaltet Map-Datei und Tileset-Dateien.
Der Tileset-Editor sollte komplett wegfallen. Import und Export von Tilesets sollten in einem Extra-Dialog des Mapeditors gesteuert werden. Diese Funktionen sind dann nur noch fuer Tiletransfer wichtig.
Des weiteren sollte die Tileverwaltung fuer jedes Tileset auch in einem Extra-Bildschirm moeglich sein. Darin kann man dann Tiles hinzufuegen, attribute aendern, loeschen und bearbeiten [mit Standard-Bildbearbeitungsprogramm oeffnen]

Und wie wird dann die Grafik aufgerufen? Man sollte IDs verwenden. Das ist die wohl beste Loestung fuer alles.

Richtig, die Maps werden groesser, aber die Tileset-Dateien fallen weg.
Wie gesagt soll es im Karteneditor moeglich sein, Tiles zu loeschen und hinzuzufuegen und Eigenschaften zu aendern [z. B. ist gespiegelte Version von ...].

Versteh ich net. Klar wird der Map-Editor aufwaendiger. Aber was hat das mit den Waenden da zu bedeuten? Es sollten dann nur noch intern gespeicherte Tiles verwendet werden koennen.


BTW: Thread gehoert eher in Spielmechanik

Und wie willst Du dann vorgehen, wenn Du die Karte eines anderen Kartenerstellers erweitern willst?

Das Problem ist und war nie die Verwaltung der Tiles, sondern immer die Problematik wenn unterschiedliche Bearbeiter unterschiedliche Wände zu ein und derselben Karte zusteuern wollen.
Und sobald das gemacht wird, stößt die Idee mit den internen Tiles nämlich auch an ihre Grenzen - der jetzt bestehende Wildwuchs würde dann dazu führen, dass ein und dieselbe Grafik mehrfach mit mehreren IDs in der Karte gespeichert ist...

Ja, und? Ich sehe da kein prinzipielles Problem. Das Installationspaket wird nur die Tilesets beinhalten, die auch wirklich für den/die Standardspielsätze gebraucht werden. Alles andere muss dann zwangsläufig im Spielsatz integriert werden (schon weil es viel zu komplieziert wäre, wenn ich beim runterladen eines Spielsatzes noch überlegen muss, wo ich welche Tilesets herbekomme bzw. hinkopiere). Und dort ist es doch dann egal, wie die genannt wurden. Bei den Missionsskripten gibt das doch auch kein Problem, da kann jeder Spielsatzersteller die gleichen verwenden.

Ganz einfach: Import eines Tilesets. Evtl. Doppelt vorhandene und unnoetige Tiles werden entfernt. Eine Tileset-Update funktion, die nach unterschieden zwischen Tilesets sucht und diese dann synchronisiert taete es auch.

Ich sehe im Bereich Karten/Tilesets drei grundverschiedene Anwendungsbereiche.

1.) offizielle Karten/Tilesets
2.) Spielsatzbezogene Karten/Tilesets
3.) Der Rest - Tilesets und Karten, die von Leuten erstellt wurden die keinen eigenen Spielsatz machen wollen/können.

Die aktuelle Lösung deckt mehr schlecht als recht die Gruppen 1 und 3 ab, da die 3. Gruppe momentan zu durcheinander gewürfelte Tilesets produziert.

Die von Natter vorgeschlagene Lösung würde 1. und 2. abdecken, aber je nach Umsetzung die dritte Gruppe entweder mit dem jetzigen Zustand in der Luft hängen lassen oder aber zwingen, ihre Tilesets bei anderen Leuten in die Spielsätze integrieren zu lassen.

Ich versuche aber irgendwie eine Lösung zu finden die alle drei Gruppen gleich gut verwalten kann. Wenn eine Umsetzung einer vernünftigen Verwaltung für die dritte Gruppe zu aufwendig wird, dann würde ich auch auf Natter's Ansatz setzen.
Bisher bin ich aber noch nicht davon überzeugt das man nicht doch noch eine bessere Lösung finden kann, auch wenn ich selber noch rate und herumsuche ;-)


Nur leider ist genau das keine triviale Lösung. Nehme doch einfach nur mal die Reifen, die JohnS (ich glaube er war's, oder?) als erste Demo für Objekte online gestellt hat.
Diese Reifen sind mittlerweile in unterschiedlichen Tilesets eingebunden, wahrscheinlich sogar mit unterschiedlichen Eigenschaften.
Wonach willst Du jetzt feststellen das zwei Tiles identisch sind?
Ein reiner Grafikvergleich auf Bitbasis ist nicht ausreichend, da dann sogar Wände verschwinden die man gezielt mit unterschiedlichen Eigenschaften versehen hat.
Ein Vergleich nach der internen ID ist auch nicht möglich, da verschiedene Leute die BMPs in unterschiedliche Tilesets eingebunden haben und dabei natürlich unterschiedliche IDs entstanden.
Ein Vergleich über alle Eigenschaften inklusive der Grafik wird die Reifen mehrfach vorhanden lassen - und sei es nur weil der eine Tilesetersteller den Reifen mehr Hitpoints gegeben hat als der andere.
Ein manueller Vergleich ist den meisten nicht möglich - zumal sie eventuell dabei übersehen ob die eine Wand als Geheimtür passierbar ist und die andere nicht, weil sie ja identische Grafiken haben.


Was den Import angeht so muss so etwas natürlich eingeführt werden - in welcher Variante auch immer. Die Spielsätze müssten dann ja auch die Tilesets importieren können.
Das Problem ist aber auch hier welcher Bearbeiter von welchem Tileset welches Tile importiert, denn dadurch entstehen ja die doppelten - ob nun schon im Tileeditor oder erst im Karteneditor hat nur wenig Unterschied.

Das lesen deiner Romane wird langsam etwas kopflastig.

Zum Thema 'Identifizierung identischer Tiles'
Das ganze funktioniert noch gar nicht mit IDs. Vergleich der ID wuerde in diesem Fall aber eh nix bringen.

Na bitte, hast du doch deinen Unterschied. Und wems nicht passt, der soll das Tile selbst loeschen.


Import und Export von Tilesets
Nein, die Spielsaetze muessten dann nur Map-dateien importieren koennen.


+++
Bitte nochmal formulieren. Danke.


Wirkung der Loesung auf die verschiedenen Verwendungen von Karten und Tilesets

Man kann es ja so machen:
Im Spielsatz-Editor, der dann irgendwann mal Mapsets aufnehmen kann, gibt es die Option "Nur eingebundene Karten verwenden". Ist sie aktiviert, werden zwanglaeufig nur Maps aktiviert, die in den Spielsatz importiert wurden. Ist die Option aus, werden alle im 'Maps'-Ordner gespeicherten .m3d-Karten aufgerufen sowie die im Spielsatz eingebundenen.

Die erste Gruppe ist abgedeckt. Der Spielsatz entscheidet, ob oeffentliche Karten aktiviert sind oder nicht.
Die zweite Gruppe sowieso
Die dritte Gruppe auch, hier entscheidet auch der Spielsatz ob Karten verwendet werden oder nicht.


+++
Die groesste Staerke dieser Loesung ist ja, dass die Dateien zusammen haengen und nicht mehr einzeln herumfliegen, was zum einen Uebersicht erzeugt und zum anderen bewirkt, dass es keine fehlenden Dateien oder auf andere Weise nicht funktionierende Maps mehr geben kann.

Die ganze Sache hier ist uebrigens keine triviale Loesung, sondern ein komplexes Thema bei dem auch die Loesung nicht einfach sein wird, wenn sie je gefunden ist...

Das würde doch vorraussetzen, dass die Tilesets im Standardinstallationspacket enthalten sind, oder? Und das wiederum halte ich für unpraktikabel, da ich es durchauch für wahrscheinlich halte, dass es in 1-2 Jahren mehrere 100 MB an Fantilesets gibt. Das gleiche gilt übrigens auch für die von DirkF angesprochene "3. Gruppe", welche nur Karten erstellt. Deren Karten können doch sowieso nicht in den Standard übernommen werden (mal ganz davon abgesehen, was das an Qualitätsprüfungen erfordern würde). Wer will, kann seine Karten und Tilesets doch zum Download für Spielsatzersteller anbieten, wenn er keinen eigenen Spielsatz macht.

Ähm eine kurze Pause mal bitte. Ich wollte zwar hier auch Vorschläge zur Verbesserung der Situation in Zukunft sammeln, aber in erster Linie geht es mir erstmal darum wie sich jetzt die Ersteller von Grafiken und die Ersteller von Karten (Ich zumindest will nicht beides gleichzeitig sein.) verhalten sollten.

Also konzentriert euch jetzt erstmal auf die Frage "Nur 1 Tileset für ein Mapset, Ja oder Nein?" Und dann lasst uns eine verbindliche Namenskonvention festlegen.

Also für "Ja, nur 1 Tileset für ein Mapset" spricht:
- Namensgebung ist leicht: .t3d und .m3d haben den gleichen Namen
- Man weiß gleich welches Tileset für welches Mapset benötigt wird
(- die Wartung ist einfacher? Ich glaube das trieft nur zu wenn nur 1 Mensch an einem Mapset arbeitet)

Dagegen:
- die Tilesets werden bei abwechslungsreichen Karten groß und unübersichtlich
- IMO führt diese Lösung dazu dass es unnötig viele Kopien von beliebten Grafiken erstellt werden müssen
- Wer nur ein paar Karten erstellen möchte, müsste sich erstmal die notwendigen Grafiken zusammen suchen und daraus ein Tileset erstellen. Man ist aber faul und möchte gleich loslegen und kopiert sich erstmal ein bestehendes Tileset auch wenn man weiß das man nur die Hälfte daraus verwenden möchte. Was man nicht benötigt kann man aber derzeit nicht löschen.

Für mehrere Tileset spricht:
- Man kann kleine Basis-Tileset erstellen die in jeder Karte verwendet werden können und einmal erstellt auch nicht gewartet werden müssen. Karten- / Spielset-spezifische Sachen kommen einfach in neue Sets.
- Den Rest der Liste schenke ich mir, das sind nur Umkehrungen der o. g. Sachen

---

Also ich bin ganz klar gegen die "nur 1 Tileset für ein Mapset" Strategie.
Ich lass mich aber auch gerne mit guten Argumenten davon überzeugen dass ich einfach nur meine Bildchen hoch lade und die drecks Arbeit mit dem Einbinden in Tilesets den Mapset erstellen überlassen kann. ;)

Also ich auch. Nicht, dass ich aus Erfahrung mit den Karteneditoren sprechen könnte, aber getrennte Tilesets, die nach Bedarf in ein mapset eingebaut werden, klingen von vornherin besser, und meine Überlegungen und die Argumente hier sagen das auch.

Dass 'nur 1 Tileset pro Map' nicht gut ist, darauf haben sich DirkF und ich schon geeinigt. Ist irgendwie doch net so gut.

Warum das denn? Jeder Spielsatz kann beliebig viele Maps haben und jede Map beliebig viele Tilesets.

Natürlich - aber wie kommen die Kartenersteller an die neuen Tilesets, wenn sie nicht einzeln verfügbar sind?

Wenn die Tiles nur in den Karten enthalten sind und keine eigenen Dateien mehr möglich sind, dann werden Kartenersteller schwerpunktmäßig nur die Standarttilessets benutzen können.
D.h. wenn man so arbeitet muss man trotzdem eine Möglichkeit haben neue Grafiken ohne Karte verbreiten zu können.


Außerdem wird es den Spielsatz aufblähen, sobald mehrere Kartendateien jedesmal die gleichen Bilddaten enthalten - deshalb ist es für eine derartige Technik besser wenn man Tilesets und Maps getrennt in den Spielsatz laden kann.

Es gibt halt keine ideale Lösung, man muss gucken welches Gesamtkonzept für die jeweils gewünschten Ziele am besten ist. Im Falle einer Einbindung von Karten in Spielsätze ist dies eine Trennung von Karten und Tiles - nur wenn die Karten einzeln verbreitet werden ist eine Kombination von Tiles und Maps in einer Datei sinnvoller.

Ah das muss ich überlesen haben

Sind sie doch. Export und Import von Tilesets in Kartendateien ist doch moeglich.
Warum sollte man mehrere Karten mit den selben Tilesets in dem Spielsatz haben?

Es stimmt aber im ganzen schon was du sagst.
Vielleicht sollten Karten, die in Spielsaetzen eingebunden sind [muss ja nicht unbedingt sein] alle karteninternen Tilesets [doppelte loeschen] als Tile-Dateien in den Spielsatz automatisch kopieren sodass die Karten auf die Spielsatz-Tilesets zugreifen koennen. Parallel dazu kann man einzelne Karten mit darin eingebundenen Tilesets veroeffentlichen.

Sind halt einfach beide Loesungen in einer.
[bin grad ganz gut drauf weil der Bus net gekommen ist :) ]

Tileset: Stadt

Karte1: zufälliger Bodeneinsatz in Stadt
Karte2: gescripteter Terrorangriff auf Stadt
Karte3: Sondermission - finde den geflohenen Außerirdischen
Karte4: Story-Mission in überfallener Forschungseinrichtung

usw.
;-)

Ich möchte auch noch meine 2 Groschen dazugeben und meine Idee fuer 1 Tileset- 1 Mapset verteidigen.

Mein Hauptgedanke - wie angedeutet - ist, dass die Wartung der Tilesets nicht machbar ist wenn man mehrere verwendet. Die Verfasser der Originale werden diese früher oder später modifizieren und dann funktioniert nix mehr richtig und finden wird man auch nix - Stichwort "Backward compatibility" (meine Erfahrung mit der professionellen Softwarewartung bringen mich zu diesem Schlussatz).

Ein oftmals angedeutes Problem ist das man die selben Grafiken in den Tilesets wiederholt haben muss. Das stimmt durchaus. Ich sehe das aber doch eher gut weil dann die Karte (die ja mit einer Designüberlegung erstellt wurde) mit der Grafik (in der Version auf der die Designüberlegung basiert) zusammenpasst. Man könnte natürlich einwenden das dies eine Menge unnötigen Speicherplatz verschwendet. Aber Hand aufs Herz - bei den heutigen Festplattengrößen macht es wohl nix wenn ein paar MB mehr (meinentwegen auch GB - was aber wohl unrealistisch ist) verbraucht werden. Weiters arbeitet Jim auch daran ein Tool zu erstellen, welches die Redundanz soweit wie möglich reduziert.

Was ich aber unterstütze ist eine Importfunktion aus anderen Tilesets in das eigene! Das würde das Arbeiten deutlich erleichtern. Wie das aber mit Urheberrechten aussieht weis ich dabei nicht genau (weil auseinader zu halten welche Grafik von Wem kommt wenn man selber kopiert denke ich, wird nicht ganz leicht).



ad 1) Größe sollte wie erwähnt nicht wirklich ein Problem darstellen.
ad 2) Es stimmt das es viele Kopien gibt - aber dann hat man doch wengistens die richtigen bilder. Ich glaube nämlich (und arbeite auch danach) das ich die Tilesets immer wieder modifiziere. Und mit Jim's Tool (das unnötige Grafiken eliminiert) kannst man auch davon ausgehen das Grafiken von Version zu Version verschwinden werden.
ad 3) Ah - wir reden davon das wir Hacking understützen wollen. Aber mal ehrlich - das erstellen von Karten und Grafiken ist eine Menge Arbeit. Mal eben so hingesetzt und ein paar Karten gemacht funktioniert sowieso nicht. Zuerst mal ein Konzept und dann die Tests - das dauert schon einige Zeit. Das bisschen was man braucht um die Tilesets zu erstellen ist da vernachlässigbar!

ad 1) Die Mapsets sollten ja sowieso ein Thema haben. Wenn man Wände mischen will dann kopiert (importiert) man diese.

Ich habe in meinen Karten versucht verschiedene Tilesets zu haben. Bin aber darauf gekommen das ich dies nicht schaffe weil (dankenswerterweise) die Leute immer wieder neue Bilder veröffentlichen die ich natürlich importieren wollte. Ich bin dann zu meiner 1-1 Lösung übergegangen (leider noch nicht online weil ich keine Zeit habe dies fertig zu machen).

ad 2) Stimme ich dir zu. Daher nicht das Universalset manipulieren sondern ein eigenes Kartenset verwenden. Damit sind die anderen Designer in der Lage auf das Universalset (welches sich nicht verändern wird/sollte) zu bauen und die neuen Tiles in ihr add-on zu tun.



Ich denke das dies im Gegenteil die einzige Lösung ist. Wenn das Tileset mit der Karte eine Einheit bildet dann sollten genau diese Vorstellungen aus einem "Guss" sein. Ergo die passen zusammen.


Das ist die Lösung die ich unterstütze! Mein Vorschlag geht dahin dies mit der momentanen Infrastruktur zu machen !!! Ich denke nämlich ob man das ganze in eine Datei oder in 2 tut ist rein kosmetisch!