Zusammen mit den neuen Überlegungen zu verbesserten Tilesets haben sich die schon mehrfach gestarteten Diskussionen zu den verschiedenen Vor- und Nachteilen der möglichen Umsetzungen auch wieder neu gestartet...

Nach meiner Erfahrung ist es in so einer Situation ganz gut wenn man mal drei Schritte zurück geht und sich nochmal vor Augen ruft, was man eigendlich ursprünglich erreichen wollte. Und dabei bin ich auf einen neuen Ansatz gestoßen, den man mal durchdiskutieren sollte.


Die Ursache für die ganzen Aufteilungen liegt doch darin, dass kein Mensch alles gleich gut kann. Grafik, Sound, Storytexte, Gamebalancing, Skripte - ich glaube nicht das es irgendjemanden in der Community gibt der in allen Bereichen davon perfekt ist.
Die Aufteilung von Kartendatei, Tileset und Spielsatz sollte es ursprünglich ermöglichen, das jeweils verschiedene Leute ihre Stärken hinzusteuern können.

Und hier sollte man eventuell eine neue Aufteilung suchen, die sich enger an den jeweiligen Fähigkeitsbereichen orientiert. Die Tilesets bestehen momentan aus Grafik- und Spielsatzdaten (Stabilität, Hitpoints etc.) und eines der Probleme ist, das ein Spielsatzersteller der Grafiken haben will auch eventuell unpassende Stabilitätswerte in seine Karten kriegt, wobei Änderungen am Tileset ihm sein Balancing jedesmal kräftig durcheinander werfen können.

Und genau hier würde ich ansetzen und die bestehenden Tilesets schlicht und einfach aufteilen. Ich sehe dabei drei unterschiedliche Ansätze mit verschiedenen Vor- und Nachteilen:

1.) Tilesets ohne Zerstörungsdaten
Die Tilesets bleiben wie bisher bestehen, inklusive der Abfolge der Grafiken bei Beschädigung, Sichtbarkeit, Begehbarkeit usw.
Anstelle der Daten zur Stabilität und zu den Hitpoints (sowie noch hinzukommende wie z.B. Rangeeffekt bei Zerstörung) tritt aber eine einzige Klassifizierung wie "Holztür", "Panzerwand Klasse 3" oder "explodierendes Maschienenobjekt".
Im Spielsatz wird dann in einer neuen Seite festgelegt, wieviele Hitpoints und welche Stabilität etc. jeder dieser Klassifizierungen zugeordnet werden.

Vorteile:
- Spielsätze werden nicht durch unterschiedliche Stabilität durcheinander gebracht
- Änderungen am Tileset sind nicht mehr ganz kritisch, da es im Wesentlichen nur noch um die Grafik geht
- Mapeditor kann wie jetzt unabhängig eingesetzt werden.

Nachteile:
- Änderungen in Begehbarkeit etc können genau wie Löschen immer noch zu Problemen führen, diese Aufteilung behebt nur einen Teil der Probleme.


2.) Grafikdatei und Spielsatztiles
Es gibt eine reine Grafikdatei für die verschiedenen Wände und Objekte, die weder Spieldaten noch Nachfolger definiert.
Im Spielsatz selber werden die Tiles mit allen Eigenschaften festgelegt, lediglich die Grafiken werden auf die externe Datei verlinkt.

Vorteile:
- Ein Spielsatzersteller kann sich die Grafiken "en Block" holen (kein Bitmap-Gewurstel) und die Spieldaten der Tiles beliebig anpassen.
- Konsistensprobleme bei den Grafiken gibt es fast nicht mehr - speziell wenn der Spielsatz eine "Default-Grafik" für nicht gefundene Tiles definiert (sieht dann blöd aus, aber der Einsatz funktioniert)

Nachteile:
- Der Mapeditor funktioniert nur noch Spielsatzbezogen

3.) Grafikdatei, Tiledatei und Zerstörungsdaten
Es gibt eine reine Grafikdatei wie unter Punkt 2. Die Spieldaten wie "Begehbar" oder "Nachfolger" werden in getrennten Tiledateien gespeichert, aber diese Tiledateien enthalten wie unter Punkt 1 eine Klassifizierung statt der Zerstörungsdaten. Die Zerstörungsdaten werden dann im Spielsatz selber definiert.

Vorteile:
- Man kann am einfachsten unterschiedliche Grafiken mit unterschiedlichen Tiledaten kombinieren, den Mapeditor unabhängig benutzen und trotzdem das Balancing im Spielsatz lassen

Nachteile:
- Man hat jetzt drei Datenfelder die koordiniert werden müssen, zwei davon in externen Dateien. Das ist deutlich mehr Verwaltungsaufwand.


Und jetzt bitte Kommentare zu diesen Ansätzen

lso ich kenn mich mit dem ganzen Karten und Tile-Kram nicht aus, also hoffe ich, ich stell mich nicht zu dumm an ^^ Ich weiß ja nicht mal, wies jetzt ist.

Nachteil 1.: Kategorie schön und gut wenns klappt, aber was ist, wenn die Kategorien nicht ausreichen? Dann bräuchte man auch mind. 5 "spezial" Kategorien, im Extremfall noch viel mehr, wenn man verschiedene z.B. explodierende Maschinen hat. (Ein Antrieb explodiert klein, ein Schild zersplittert etc.)
Das klingt gut für "normale" Spielsätze, aber bei Extremen wirds blöd. Und welce Kategorien willst du überhaupt festlegen? Das ist ja nicht vorhersehbar, und "Wandtyp1stärke1" Und "Wandtyp5stärke4" ist schwer zu merken ;)

Bei 2 und 3 versteh ich nicht ganz das Problem.
Wir wollen alle nicht, dass sich eine Karte nicht von einem Spielsatz in den anderen übertragen lässt.
Wir brauchen auch die Möglichkeit, Tile-Bilder neu aufzunehmen oder zu löschen.
Ich würde also sagen, wir haben als Struktur:
a) eine Datei nur mit tiles als Bild
b) eine Datei mit den tiles samt Eigenschaften
c) die komplette Karte

Für a) gibt es den tileeditor, in dem die tiles grafisch bearbeitet werden können
b) findet zusammen mit c) in Karteneditor statt. Man wählt die tiles aus, die man braucht, legt die Eigenschaften fest und setzt sie zu Karten zusammen.
Dabei kann man eine Datei exportieren, die die Egienschaften speichert und jederzeit bei wem anders im Karteneditor mit diesen Eigenschaften eingelesen werden kann. (Nur halt keine Kartendaten)
Diese Eigenschaften-Datei wird auch verwendet, wenn man verschiedene Karten mit (fast) den gleichen tiles machen möchte.
Die fertige Karte widerum kann im Spielsatz eingelesen werden (so ähnlich wie jetzt die scripte- man könnte also aus dem Spielsatzeditor den Karteneditor aktivieren und dort dann Grafikdateien einlesen- alle Schritte wären möglich, auch das exportieren von so angelegten Karten als b) oder a) ).
Damit hat man Karten passend zum Spielsatz und trotzdem jede Ebene der Integration.

Genau da liegt aber das Problem, denn diese Aussagen sind momentan nicht gleichzeitig zu verwirklichen.
Wenn eine Karte beliebig zwischen den Spielsätzen wandern soll, dann darf es nicht möglich sein Tiles zu löschen. Wenn Du es aber erlaubst, ein Tile nachträglich aus einem Tileset zu löschen, dann ist die Karte nicht mehr mit jedem Spielsatz kompatibel - es hängt dann nämlich davon ab, welche Version des Tilesets dann in dem jeweiligen Spielsatz vorliegt - die alte mit dem in der neuen Version gelöschten Tile oder die neue Version.

Außerdem müssen die Eigenschaften von Tilesets mit dem Spielsatz abgestimmt sein, und das ist momentan nicht wirklich möglich (es sei denn die Tilesets werden nach der Erstellung niemals geändert).


Und jetzt denke mal über folgendes Scenario nach: Spielsatz A benutzt die Durchschlagkraft um verschiedene Waffentypen wie Pistole und Gewehr darzustellen. Ein Tileset für Spielsatz A setzt also z.B. die Holzwand mit Panzerung 20 und die Betonwand mit Panzerung 50 an.
Spielsatz B benutzt die Durchschlagkraft dagegen für unterschiedliche Technologiestufen und setzt eine Betonwand bei Panzer 35, eine außerirdische Kraftfeldmauer bei Panzerung 70 an.

Was meinst Du was passiert wenn jetzt ein weiterer Spielsatzersteller die Karten und damit die Tilesets der beiden Spielsätze A und B verwenden will und anfängt die zu mischen...
Auf einer Karte zerfetzt seine kleine Kanone jede Wand, und auf der nächsten Karte schafft es der Raketenwerfer nicht die Holzwand zu durchdringen etc.

Das Problem ist einfach das eine Änderung an einem Tileset, die der Originalersteller für seinen eigenen Spielsatz für notwendig erachtet, enorme Probleme für diejenigen bedeutet die seine Tilesets gut fanden und selber verwendeten, aber bei ihren Planungen nicht mit der neuen Änderung rechneten.

Entweder bleibt jegwede Änderung an bestehenden Tilesets verboten, oder jeder Spielsatzersteller muss seine eigenen Tilesets definieren oder man versucht so wie in dem Ansatz oben die bisherigen Definitionen aufzutrennen und zu verteilen - was je nach Einzelfall wieder andere Probleme bereiten kann.

Diejenige, die mit dem Spielsatz in diesem gespeichert ist.
In dem Fall muss derjenige die Werte halt selbst auch neu vergeben. Genauso, wie man bei einer Waffe die Werte für seinen Spielsatz anpassen muss. Da kann man auch nur übernehmen, was passt.

Dann können sie doch die alte Version verwenden.

Das ist die grundlegende Frage der Kompatibilität- weshalb ich immer von 3 Ebenen rede: komplette Karte, Tiles mit Information und Tiles ohne Information.
eine Standardkarte mit "normalen" Werten kann in jeden "normalen" Spielsatz 1:1 übernommen werden- eine Sache von ein paar Klicks, wenns richtig funktioniert.
Eine Karte mit unzerstörbaren Alienwänden ist für einen anderen, der die zerstören will, in dieser Form ohnehin nicht geeignet. Er verändert also entweder in seinem Spielsatz die Tileinfornationen oder fängt neu an und entnimmt nur die Grafiken. (Etwas verändern muss er sowieso, ganz egal wie es mit den tiles/Karten funktioniert.)
Ergo:

Je nach Spielsatz muss er das sowieso, also sind wir wieder da, wo ich dein Problem nicht ganz verstehe- Etwas kann autreten, das aber bei jeder Variante auftritt, mal stärker, mal schwächer. Das ist nicht umgehbar. Also sollten wir es möglich machen, auf verschiedenen Ebenen einen Austausch zu ermöglichen. Grafikset, Informations-tileset und Komplettkarte.

Ich versteh ehrlich gesagt auch nicht ganz das Problem. Die meisten Probleme mit unterschiedlichen Versionen sollten doch durch meinen Vorschlag (bisher nur Teamintern veröffentlicht) beseitigt werden. Gegen meine Variante spricht natürlich der hohe Aufwand in der Umsetzung. Aber deine Vorschläge bedeuten ja auch massive Änderungen.

Damit wir hier diskutieren können, hier nochmal meine Überlegungen:

Ich bevorzuge folgende Aufteilung:
* fester Satz an offiziellen Tilesets + Zufallskarten
* Spielsatzbezogene Maps kommen direkt in den Spielsatz, inklusive eventuell benötigter zusätzlicher Tilesets.
* Karten(sets) ohne festen Spielsatzbezug können ebenfalls installiert weden. Sie bekommen im Map-Verzeichnis einen Unterordner (Name wird vom Kartenersteller vergeben; kann gegebenenfalls vom Spieler umbenannt werden, falls erforderlich). Brauchen diese Karten ein Tileset, welches nicht zum Standard gehört, so wird selbiges im Ordner gesucht, wo die Karte gespeichert ist. Selbstverständlich muss das Tileset zusammen mit der Karte zur Verfügung gestellt werden.
* Karten ohne Tileset werden nicht per Onlineupdater angeboten (es sei denn, sie benötigen nur die offiziellen Tilesets).

Sollte eine neue Karte einen Ordnernamen verwenden, der bereits auf der Festplatte vorhanden ist,kommt eine Warnmeldung. Entweder der Spieler legt für die neue Map einen anderen Ordner an, oder der Inhalt des Ordners wird gelöscht, und mit den neuen Daten gefüllt. Natürlich sollte auch ein Abbruch der Installation möglich sein. (Eventuell könnte man auch überlegen, Ergänzungen zu erlauben. Z.B. könnte JohnS den Unterordner JohnS beanspruchen. Dann könnte er nach und nach neue Maps anbieten, und auf die Tilesest zurückgreifen, die schon vorher installiert wurden. Das würde den Traffic gering halten. Allerdings müsste man sich dann eine Versionsprüfung ausdenken.)

Ein Spielsatz verwendet standardmäßig die default-Zufallskarten. Karten in den Unterordnern werden ignoriert. Es gibt aber ein Menü, in dem weitere Verzeichnisse angegeben werden können, in denen nach Zufallskarten gesucht wird (hierzu zählt auch das Verzeichnis suche im Spielsatz, falls Zufallskarten in selbigen gespeichert sind). Wenn ein Verzeichnis nicht existieren sollte, wird es einfach ignoriert.

Sondermissionen und Storymaps werden ausschließlich im Spielsatz gespeichert. Falls eine Map neben den Standardtilesets noch weitere benötigt, so werden diese im Spielsatz gesucht.



* Strukturierung

- Tile (enthält Bitmaps, Eigenschaften etc.; eventuell aufgeteilt in Boden, Mauer, Objekt) Ein Mauertile würde z.B. sämtliche Ansichten/Positionen dieser Mauer enthalten, plus Angaben über Hitpoints, Stabilität etc. Angaben zum Nachfolgetile bei Zerstörung gehören nicht dazu, sondern sind Bestandteil des Tilesets
- Tileset - Sammlung von Tiles und deren Verwaltung
- Kartendatei

* wünschenswerte Funktionen für den Tileseteditor

- Import und Export aus einem Tileset (überlegenswert wäre es, wenn es zusätzlich für Tiles ein eigenes Dateiformat gäbe)
- Import/Export von Bitmaps
- Direktes bearbeiten der Bitmaps eines Tiles aus dem Tileseteditor heraus
- Löschen von Tiles aus einem Tileset
- Verschieben von Tiles inerhalb eines Tilesets
- Ersetzen von Tiles (dadurch keine Änderung an bestehenden Karten nötig)
- Passwortschutz
- Ergänzung um Copyrightangaben (selbiges gilt gegebenenfalls für Einzeltiles)

Auch sollte die Gruppierung im Tileseteditor überdacht werden. Ich halte es für unpraktikabel, das man jede Positionierung extra auswählen muss (bezogen auf Mauern). Statt dessen sollte man das Mauertile auswählen können, und dieses dann mit zusätzlichen Buttons drehen können (ein Tile enthält ja alle Ansichten). Dadurch wird es wesentlich übersichtlicher und leichter zu arbeiten. Selbiges sollte im übrigen auch für Objekte und Bodentiles eingeführt werden. Es ist z.B. sehr umständlich, die richtige Ecke einer Rasenfläche zu finden, da es ja 4 Varianten gibt. Man sollte einfach das Tile auswählen, und dann drehen können (die 4 Positionierungen sind auch hier im Tile gespeichert). Dadurch wird auch wesentlich die Übersichtlichkeit erhöht.


Was interessiert das den Spielsatzautor? Wenn der sich einmal für ein Tileset + Karten entschieden hat, sollen die ja im Spielsatz gespeichert werden. Wieso sollte es zu der Situation kommen, das er plötzlich ausversehen eine andere Version im Spielsatz reinbekommt? Und falls ihm eine bistimmte Grafik noch fehlt, so könnte er die ja bequem per Export/Import ergänzen. Und wenn einige Tiles verbessert wurden, auch kein Problem. Dafür hab ioch ja die "Ersetze durch..." Funktion vorgeschlagen.


Wenn man im Tileset die Stabilität angibt (Holz, Beton, unzerstörbar etc.) und im Spielsatz die Werte festlegt, ist das noch keine Lösung. Einerseits weiß man ja nie, wieviele Kategorien gebraucht werden (vor allem bei den Hitpoints). Andererseits garantiert ja keiner dafür, das im Tileset die Kategorien so zugeteilt wurden, wie der Spielsatzautor das gerne hätte.


Ähh, also Änderungen an der Grafik finde ich wesentlich gravierender als Änderungen an den Werten. Die wenigsten Maps werden darauf angelegt sein, dass man unbedingt eine Wand zerstört. Aber wenn eine Grafik verändert wird, oder gar fehlt, sieht das der Spieler sofort bzw. die Map funktioniert nicht mehr. Daher darf bei einer fertigen Map nicht mehr das Tileset verändert werden (oder die Karte muss wieder angepasst werden).

Hmm, sehe da nicht wirklich eine große Verbesserung. Überhaupt sollte man es dem Spielsatzersteller lieber vereinfachen, das Tileset anzupassen, als da nochwas rauszulagern (und somit dem Mapersteller jegliche Möglichkeit zu nehmen, seine Karte zu "designen"). Z.B. indem man Filterfunktionen einbaut, oder indem man einen Wert für mehrere Tiles ändern kann (eine deutliche Vereinfachung ergäbe sich auch schon, wenn man alle 4 Seitenansichten als ein Tile speichern würde).


Die Spieldaten der Tiles kann er doch sowieso anpassen. Und ein Bitmapgewusel gibt es auch nicht. Einfach alle Bitmaps eines Tilsets (die man z.B. per Exportfunktion gewinnen könnte... hehehe) in eine Zip packen. Im Tileseteditor ist es doch schon jetzt möglich, mehrere Bitmaps auf einmal zu importieren.


Wenn schon, dann sollte man überlegen, diese Daten in der Karte zu speichern (als eine Art backup). Ich glaube, dadurch würde sich die größe der Karten nichteinmal allzusehr ändern (die Anzahl der Tiles pro Karte ist ja nicht allzu hoch). Allerdings wäre es besser, inkompatibilitäten von vornherein zu vermeiden (eben z.B. indem zwar Tilesets allein veröffentlicht werden können, aber Karten immer nur zusammen mit den passenden Tilesets - siehe mein Vorschlag).


In dieser Variante sehe ich den größten Zeitaufwand in der Praxis. Das wird doch ein hoffnungsloses gefummel ...
Was mir dabei aber einfällt, man könnte ja in den Tileseteditor eine Funktion einbauen: "Eigenschaften von ... übernehmen für ..."

PS: Auch für den Karteneditor sollte man sich eimige Features überlegen. Z.B. sollten sich Karten laden lassen, selbst wenn ein Tile fehlt. Die entsprechenden stellen sollten dann deutlich hervorgehoben werden. Und eine Prüfung, ob jeder Punkt von jedem Punkt erreichbar ist wäre auch nett.

Ich habe auch nirgendwo behauptet das diese Lösungsansätze perfekt wären - da sind nicht umsonst auch Nachteile genannt.
Dies sollte einfach nur einen neuen Ansatz (Aufteilung der Daten statt Beibehaltung der bisherigen Tileset-Definitionen) in die Diskussion bringen und gucken ob man daraus Vorteile gewinnen kann.

Außerdem widerspricht sich das nicht mit Natter's Idee der Tileset-Daten im Spielsatz, es ist nur die Frage ob alle bisher bestehenden Tilesetdaten im Spielsatz landen oder ob man dies eventuell aufteilt.


Das hatte ich dabei ja auch ausdrücklich als Nachteil genannt mit der Aufteilung in drei Dateien.


Genau das meinte ich ja mit Grafik "en Block" - keine einzelnen Bitmaps mehr, sondern eine Zuordnung für die gesamten Ansichten eines Tiles.
Denn der Import von Bitmaps wie bisher arbeitet nur mit Spiegelung und wenn man (wie im bisherigen Default-Tileset) mit unterschiedlicher Helligkeit je nach Wandrichtung arbeiten will, dann klappt dieser Massenimport von Bitmaps gerade nicht und man muss alles einzeln zuordnen.

Da hast Du recht - aber das Problem liegt von der anderen Seite. Wenn jemand die Stabilität verringert weil z.B. ein stärkeres Material am oberen Ende der Skala benötigt wird, und ein anderer vorher seine Waffen an dieses Tileset angepasst hatte sodass die Wände gerade nicht zerstört werden können...

Ganz abgesehen davon entspricht die zweite Variante doch im wesentlichen Natters Idee, nur das man sich den Import/Export der Tiledaten schenken kann. Denn die sowieso an den Spielsatz anzupassenden (und kaum importierbaren) Tileeigenschaften werden dann in dieser Form auch direkt im Spielsatz gespeichert, während die (platzmäßig aufwendigeren) Grafikdaten extern gespeichert und referenziert werden.

Natürlich, aber der Karteneditor wäre der Schritt nach dem Tileeditor - alles andere wäre unnötige Arbeit, wenn das Tileset noch nicht endgültig definiert ist.

Nett ja - aber aufgrund des Zufallsaufbaus der fertigen Karten doch etwas problematisch. Der Test müsste zumindest mehrere unterschiedliche Durchläufe des Zufallskartenskriptes beinhalten. Denn diese Abfrage auf einzelne Räume zu beschränken würde das Zusammensetzen von Häusern aus mehreren Räumen erschweren.

Hmm, dein Grafikblock soll also lediglich die Grafiken eines Tiles enthalten? Ich hatte das so verstanden, dass alle Grafiken eines Sets ich einer Datei landen. Und da hätte man dann vermutlich genau die gleichen Probleme, irgendwas zu löschen etc. (wie referenziere ich die Bilder in den Tilesets? Per ID? Dann bräuchte man aber 2 IDs, einmal für die Bilder, und einmal um die Tiles in der Map zu finden).


Hmm, es ist aber ein Unterschied, ob ich die Eigenschaften lediglich anpassen muss (was oft garnicht nötig ist), oder ob ich sie komplett neu erstellen muss, weil in der Bilddatei nichts enthalten ist.

Hmm, so wie ich das verstanden habe, braucht man für die Tiledaten einen Spielsatz. Dann wäre aber das verteilen von Maps und Tilesets ohne Spielsatz nicht mehr möglich, was ein großer Nachteil wäre. Man könnte natürlich auch die Datei mit den Tileeigenschaften extra anlegen. Dann bräuchte man für eine Map mindestens 3 Dateien (Bilddatei, Tileset, Map).

Ja. Vielleicht liegt ja hier mein Problem. Ich finde die Aufteilung so wie sie jetzt ist nämlich völlig in Ordnung. In meinen Augen liegen die Probleme derzeit einzig in der fehlenden Bedienerfreundlichkeit, und den Problemen mit unterschiedlichen Versionen von Tilesets. Letzteres lässt sich wohl nur lösen, wenn Karten immer zusammen mit passenden Tilesets vertrieben werden, und die Speicherung im Gegensatz zu jetzt, dezentral erfolgt (auch wenn dadurch der Trafic sicher erhöht wird, da manche Tilesets mehrfach geladen werden).

Die jetztige Aufteilung folgt einer Programmierlogik - was hängt zusammen und wie kann der Programmierer am einfachsten Arbeiten.
Meine Idee ganz oben legt die Aufteilung nach dem Motto "Wer muss was verändern" an. Lennstar's Variante davon geht nach "Wann wird etwas verändert" - denn beim Karteneditor fällt einem als erstes die fehlende Tile/Tileeigenschaft auf.
Und wenn man etwas intensiver nachdenkt fallen einem vielleicht noch ein halbes Dutzend weiterer in sich logischer Aufteilungen ein...

Die Frage ist jetzt nur, welcher Aufteilung man folgt. Die Programmiererlogik wäre vielleicht die wenigste Arbeit - und der Zugriff aus XScript auf die Kartendaten muss sowieso auf ähnlichen Strukturen beruhen, sonst wird das da unnötig schwer.
Aber der Programmierer arbeitet nur einmal an der Logik - ein Dutzend Spielsatzersteller aber laufend damit. Und deshalb ist es imho eine ernste Überlegung wert, ob man nicht als Programmierer etwas mehr Arbeit hineinsteckt, damit anschließend die Benutzer besser damit klar kommen.


Fast - der Grafiksatz würde zwar alle Bilder enthalten, aber in Tiles gruppiert und dann mit einer ID pro Tile. Die zweite ID kann man sich dann schenken, da man auf die einzelnen Bilder sowieso keinen direkten Zugriff hat sondern sie erst als komplettes Tileobjekt laden muss.
Dabei wäre es auch eine Überlegung wert ob man ein Tile wie bisher lediglich aus den 4 Wandgrafiken definiert, oder gleich 4 Wand- plus 4 passende Eckgrafiken einsetzt. Letzteres wäre aber eine später zu klärende Detailfrage.



Genau da habt ihr das imho nicht weit genug durchgedacht.
Man braucht in einem Spielsatz nicht jeden einzelnen möglichen Wert - der Spieler merkt sowieso nichts davon, ob ein Zaun nun Panzerung 10 und Hitpoints 50 oder Pz12/HP45 hat.
Natürlich braucht man eine vernünftige Anzahl an Kategorien - aber 20-30 dürfte die Obergrenze sein, selbst wenn man es sehr detailliert machen will.
Und diese Werte einmal im Spielsatz zuzuordnen ist mit sicherheit weniger Arbeit, als wenn man jedes einzelne Tile in jedem verwendeten Tileset auf die Größe der Hitpoints/Panzerung überprüfen müsste.

Und eine Klassifizierung könnte man auch im Karteneditor einfacher per Icon anzeigen, sodaß eine Kontrolle ob der Tilesetersteller dieselben Vorstellungen zur Klassifizierung hatte sogar einfacher ist als eine Kontrolle, welche Werte er für seine Tiles eingegeben hat.

-----------

Aber zurück zur Hauptfrage:
Nach welcher Logik teilen wir die Daten am besten auf? Nach der aktuell verwendeten Programmiererlogik (vereinfacht die Umsetzung sowohl im Programm wie im XScript deutlich), nach der Bearbeitungslogik mit Klassifizierung (macht es imho dem Spielsatzersteller etwas einfacherer) oder nach welcher anderen?

Hmm, aber bei 20 Kategorien wird der Tilesetautor diese mehr oder weniger zufällig verteilen, so dass der Spielsatzautor mit den Kategorien nichts mehr anfangen kann (bzw. er muss nachsehen, welches Tile welcher Kategorie zugeordnet wurde).

Im zweifelsfall bin ich dafür es dem Spielsatzautor leichter zu machen. Allerdings bin ich noch nicht davon überzeugt, dass dies durch ein Einstellen der Werte (pro Kategorie) im Spielsatz zu realisieren ist.

Perfekt kriegt man es nie hin. Wenn man den Kategorien aber vernünftige Namen gibt und das eventuell mit passenden Icons zur Anzeige im Karteneditor unterstützt, dann wird das meiner Meinung nach einfacher als wenn man die Einzelwerte kontrollieren müsste.

Denn ein Tilesetersteller, der sowas zufällig verteilt, der würde auch die bestehenden Zuordnungen von Hitpoints/Panzerung beliebig verteilen. Und letzten Endes würde er sich durch so eine Handlung selber disqualifizieren - wenn die Spielsatzersteller merken das die Tilesets eines bestimmten Grafikers die Werte sinnlos verteilen, dann werden sie dessen Tilesets seltener nutzen.


Ich habe mich auch noch nicht festgelegt - es kann ja auch sein das morgen jemand dazu stößt der eine noch bessere Idee hat.
Aber wir sind uns glaube ich darin einig, das entweder die Panzerwerte der Tiles an den Spielsatz angepasst werden müssen oder umgekehrt, sonst geht das Balancing nicht sauber.

Und in so einem Fall halte ich es für einfacher wenn der Spielsatzersteller nicht jeden Wert einzeln kontrollieren/setzen muss, sondern eine feste Gruppe von Werten automatisch zugewiesen wird. Auf jeden Fall muss er sich nicht mehr um jedes einzelne Tile kümmern, falls er z.B. seine Waffenskala nachträglich ändern muss und dann jedes Tileset hinterher editieren müsste.

Schließlich kann man selbst bei bester Planung nie davon ausgehen, das eine bestimmte Werteeingabe auch das Balancing überlebt - und wenn man bei Problemen mit dem Waffenabgleich immer wieder alle Tilesets neu anpassen müsste, dann wird man sich automatisch auf weniger Tilesets und damit weniger Bodenkarten entscheiden...

--------

Was die anderen Punkte angeht, bin ich aber nach einigem Nachdenken der Meinung, das eine Dreiteilung der Tiledaten doch nicht so gut ist.
Es gibt ja genau genommen 3 Datengruppen bei einem Tile:
- Die Bilddaten
- Die allgemeinen Spieldaten (begehbar, Tür, Fenster, durchschaubar, Nachfolger etc.)
- Die Zerstörungsdaten (Panzerung, Hitpoints)

Die Zerstörungsdaten sind sehr stark von der Ausrüstung und Planung eines Spielsatzes abhängig.
Die allgemeinen Spieldaten sind dagegen sehr oft auf die Grafik bezogen und machen nur begrenzt Sinn, wenn sie gewechselt werden (Ausnahmen wie z.B. eine Wand mit Türgrafik die per Skript gegen eine echte Tür mit derselben Grafik getauscht werden kann mal ausgenommen).

Deshalb würde ich jetzt die allgemeinen Daten und die Grafikdaten in einer Tiledatei zusammenfassen, aber die Möglichkeit einer Tilekopie bzw. eines Imports für Änderungen an diesen Daten ermöglichen.

Auf jeden Fall sollte aber die Speicherung eines Tilesets von dem bisherigen einfachen Stream umgeändert werden in eine Objektspeicherung, wobei jedes Einzelobjekt eine ID innerhalb des Tilesets hat und sich aus allen Bildern und Daten eines Tiles zusammensetzt. Zugriff auf die Einzeldaten kann man dann nur kriegen, wenn man das komplette Objekt/Modell lädt und dann auf die einzelnen Eigenschaften zugreift.

Das hängt ja alles zusammen: In meiner Variante wäre es wie folgt:
Sämtliche Daten eines Spielsatzes befinden sich in diesem. So wird der über den updater heruntergeholt.
Der updater "entpackt" die, und erstellt Unterverzeichnisse. Heißt (als Beispiel): im jetzigen Ordner gamesets wird ein ein unterordner angelegt, der wie das gameset heißt- z.B. Dark Age
In diesem Unterverzeichnis befinden sich die jetzigen 3 Dateien - eine .pak, eine .m3d und eine .t3d (und entschuldigt, wenn ich im folgenden was falsch zuordnen sollte. Aber zumindest das Prinzip sollte klar sein)
Die tiledatei trägt Eigenschaftsinformationen der tiles, die aber jederzeit herausgenommen werden können: tileeditor- Grafikdatei exportieren. (.g3d ;))
Die .m3d referenziert auf die .t3d. Sie gibt an, wann welches tile wo verwendet wird.
Im .pak wiederum ist festgelegt, welche .m3d der Spielsatz verwendet. (bzw. wann welcher Teil der .m3d verwendet wird) Dabei könnten auch mehrere .m3d angewählt werden. Das verhindert Kompatibilitätsprobleme. So könnte Dark Age.pak auch Stargate.m3d einbeziehen.

Was ist der Vorteil?
Durch die Verzeichnisstruktur ist sichergestellt, dass jeder Spielsatz genau die Karten samt tiles benutzt, die er soll.
Gleichzeitig können die jederzeit ausgetauscht werden (z.B. bei Eigenschaftsänderung) ohne den Spielsatz noch einmal komplett zu "installieren". Ob so auch nachträglich neue Karten eingefügt werden können, weiß ich nicht, im Moment werden die verwendeten Kartensets ja nur beim Spiel erstellen überprüft, oder? Stelle mir das aber nicht so schwer vor, das zu ändern.
Außerdem könnten so Spielsätze oder Karten getrennt behandelt werden. Wenn jemand einen Spielsatz nur mit vorhandenen Kartenmaterial (z.B. den Standardkarten) erstellt, braucht er nur den Spielsatz zum download anbieten und sagen, diese Dateien müssen in den Spielsatz-Ordner kopiert werden. Festplattenplatz dürfte ja kein Problem sein ;)


Eine kurze, einfache Anwort? Ja - wenn du weiterhin willst, dass andere Leute Spielsätze erstellen ;)



Ich frage an dieser Stelle mal andersrum: Wer vergibt diese Werte? Jemand, der wie ich einen Spielsatz erstellt, aber von Karten keine Ahnung hat?
Nein.
Was hätte der also davon?
Er könnte die Eigenschaftswerte der tiles relativ leicht ändern.
Macht er das?
Ich denke nicht.
Wenn doch, wären ihm die Kategorien vllt. nützlich. Je mehr Karten, desto nützlicher.
Kernpunkt: Muss es zwingend Kategorien oder Einzelwerte geben?
Wie wäre es mit den Einzelwerten aber ebenfalls eine Einteilung in Kategorien? Die würden von demjenigen, der die tiles mit Eigenschaften versieht vorher festgelegt. Dann werden die tiles gemacht, und dabei kann man die Eigenschaften noch ändern.
So hätte man per drop-down Standardwerte, die man in vielen Fällen gar nicht mehr ändern muss. Das dürfte weniger Zeit kosten als alles einzeln einzugeben.
Ein reiner Spielsatzersteller der nun findet, er müsse unbedingt die Werte ändern, kann das in den Kategorien machen. Dabei geht vielleicht eine gewisse Differenzierung verloren, aber zumindest das Grundgerüst steht.
Außerdem kann man die Kategorien als Auswahlkriterium nutzen. Man möchte tiles aus "Stahl, stabil" verwenden, und sucht dann in dieser Kategorie- statt in allen tiles oder wie immer das im Moment aufgeteilt ist.

*DirkF's Post les*

Wenn ich das richtig verstanden hab- ja.
Also du meinst, eine Grafik "Tür" enthält dann auch die Eigenschaft "Tür", HP's, Zerstörbarkeit etc.?
Dann ja klar- damit müsste man dann nämlich auch löschen bzw. einfach hinzufügen können, oder?

Davon abgesehen sollte es nur für Erstellzwecke einen Export/Import mit allein der Grafik geben. Das ist aber nicht unbedingt nötig, spart nur Platz/Aufwand.

Ja, dem stimme ich voll zu.

Kritisch ist doch eigentlich nur die benötigte Durchschlagskraft. Aus diesem Grund wurden damals vermutlich auch die jetzigen Kategorien eingebaut. Vielleicht sollte man das beibehalten, und für Ausnahmefälle eine zusätzliche Kategorie "manuell" einführen, wo bei Bedarf im Tileset ein entsprechender Wert angegeben wird. Für die Standardkategorien (Beton, Holz, Stahl...) etc. könnte man ja die Werte im Tileset festlegbar machen, so dass diese bei Bedarf angepasst werden können.

Stimme ich vollkommen zu.
ZU denn anderen Sachen fällt mir keine Antwort ein ^^

Die Zerstörungswerte von Wänden müssen von demjenigen vergeben werden, der die Waffenwerte festlegt.
Wenn Du die Panzerwerte eines Tilesets unverändert in einen Spielsatz übernimmst, dann legst Du damit fest welche Durchschlagkraft eine Waffe benötigt, um eine bestimmte Wand zu durchschlagen.
Wenn Du die Durchschlagkraft Deines Raketenwerfers aber selber auf andere Sachen wie die Panzerung Deiner Aliens abstimmen willst, dann musst Du die Panzerwerte der Tiles nachkorrigieren oder es kann z.B. passieren das der Raketenwerfer die Mauern erstmal durchschlägt bevor er im Innern des Hauses explodiert.

Das ist das eigendliche Problem - die Tiles von Spielsatz A können auf eine andere Waffenstärke ausgelegt sein als die Tiles von Spielsatz B, und wenn sie trotzdem übernommen werden und die Waffen von Spielsatz B sind stärker, dann wird auf einmal die ganze Karte niedergemäht.


Wenn sie eine Tür sein soll, dann ja. Ich habe aber immer das Beispiel das man mit den entsprechenden Scriptbefehlen später z.B. Missionen erstellen kann, bei denen das Lösen einer bestimmten Aufgabe ein Skript auslöst, welches ein unzerstörbares Wandtile mit Türgrafik gegen ein echtes Türtile mit derselben Grafik austauscht. Der Spieler kriegt dann lediglich eine Meldung "Codesequenz eingegeben" ohne das sich an der Grafik was ändert - aber die Tür geht dann auf einmal auf...


Das Problem des nicht-löschens hatte nie mit den Tileeigenschaften zu tun, das Problem war einfach das eine ältere Karte mit einem in einem neueren Tileset gelöschten Tile nicht mehr geladen werden kann.
Da gibt es aber andere Ansätze um so einen Fehler zu verhindern, aber es ist nicht ganz so einfach...
Man kann zwar die Existenz eines Tiles sicherstellen indem man die Tiledatei in den Spielsatz anfügt, aber was macht man wenn der Ersteller zwischenzeitlich eine Version 2 herausbringt, die neben einem für den Spielsatz wichtigen aber jetzt gelöschten Tile auch drei neue Tiles hat, die man unbedingt haben will - Tileset tauschen klappt da momentan nicht wirklich...


<<schnipp>> - gekürzte, ich beziehe mich trotzdem auf die ganze Beschreibung

Wenn man einen Spielsatz alleine aufbaut und die Daten nur für diesen Spielsatz hat, dann gibt es keine Probleme.
Die ganzen Probleme entstehen dadurch, das ein Spielsatzersteller eventuell Karten und Tiles verwenden möchte, die für einen anderen Spielsatz entworfen werden und die sich eventuell noch in der Entwicklung befinden.

Wenn ein Tileset geändert wird, nachdem es in einem Spielsatz eingebaut worden ist dann kann alles mögliche passieren - deshalb hat Jim ja früher immer wieder darauf hingewiesen, das die Tilesetersteller nichts am dummy ändern sollen sondern neue Tilesets.


Die Durchschlagkraft ist der deutlich kritischere der beiden Werte, da stimme ich zu - allerdings kann sich ein unterschiedliches Hitpoint-Niveau auch auswirken, und da habe ich auch schon Spielsätze mit unterschiedlichen Ansätzen gesehen.

Wenn wir es nur bei den Panzer-Kategorien belassen, dann würde ich die aber trotzdem leicht überarbeiten und die Wertevergabe im Spielsatz vornehmen lassen - dann braucht man auch kein "manuell" mehr.
Außerdem sollte es in diesem Falle eine Richtschnur geben, damit die Betonwand nicht bei dem einen Tileset 50 und beim nächsten 5000 HPs hat.

Oder man setzt alternativ die Hitpoints fest auf 100, und stabilere Wände brauchen dann mehrere Nachfolger-Tiles, während sich immer mehr Risse zeigen.
So nach dem Motto nach 100 Treffern wird das Betontile gegen Tile "Beton mit wenigen Rissen" ausgetauscht, nochmal 100 HP später "Beton mit vielen Rissen", nochmal 100 Punkte später "Beton mit Löchern" und danach "Beton-Wandruine"...
Würde grafisch auch besser aussehen, aber einige Zusatzarbeit (zwischenstufenbilder) für die Grafiker bedeuten...

Das mit den Tiles ist Sache der Programmierer ;) Deshalb ja die oben angedachte Sache mit den tile-IDs die halt nicht von der Position in der Datei o.ä. abhängen.

Und wegen den maps hatte ich ja (auch deshalb) gesagt, maps kommen (standardmäßig) mit den tilesets zusammen. (3 Ebenen, du erinnerst dich? Spielsatz: Alles; Map: Mapinformationen und dazugehörige(s) tileset; tileset mit den tileinformationen - und dazu wahlweise (aber nicht unbedingt nötig, nur traffic-sparend) auch nur map-daten und nur Grafik-daten für die Bastler)
Das bedeutet in vielen Fällen zusätzlichen traffic- aber das dürfte selten ein Problem sein. Selbst mit modem sind 10MB leicht in einer Stunde schaffbar, und da kannst du ganz schön was reinstecken. (z.B. Einen Spielsatz doppelt so groß wie der Standardsatz und 5 Kartensets [heißt 5 Mal versch. tiles])
Im Spielsatz muss dann nur auswählbar sein, welche Karte wann zum Einsatz kommt. Dann hast du halt 2 Varianten des gleichen Kartenmaterials auf deiner Festplatte. *schulterzuck* Theoretisch könntest du auch das fehlende tile in das neue Kartenmaterial einfügen und auf der alten Karte das tile ersetzen.

Das ist im Grunde "nur" eine Sache des leichten Imports/Exports der Daten in die verschiedenen editoren und ggf. des benamsens. Und natürlich der Sache mit den eineindeutigen IDs ;)

EIne leichte Überarbeitung wäre sicher nötig. Was mich halt stört, ist die Verlagerung in den Spielsatz. Wenn ich 3 verschiedene Tilesets habe, mit unterschiedlich dicken Stahlwänden, dann haben die vielleicht alle die Eigenschaft Stahl (denn keiner will 100 verschiedene Kategorien), sollten sich aber trotzdem voneinander unterscheiden (daher mein Vorschlag, das im Tileset einzustellen). Noch schwieriger wird es aber, wenn die Mauern auch noch im selben Tileset vorkommen. Dann hat man mit Kategorien keine Chance mehr. OK, man könnte dann eben doch mehr Kategorien einbauen. Nur dann hilft das dem Spielsatzautor nicht mehr, denn es ist nicht sofort ersichtlich, ob eine Wand nun aus dünnem Stahl, Stahl, dickem Stahl oder was auch immer besteht. Daher mein Vorschlag mit dem zusätzlichen manuellen Wert. Ist abr auch nicht ideal.

Ich glaube immernoch, das man das Problem lieber dadurch lösen sollte, dass das Arbeiten im Tileseteditor leichter wird (z.B. sortieren/filtern, ändern einer Eigenschaft für mehrere Tiles gleichzeitig etc.).


Hmm, deshalb ist ja die Trennung von Projektil und Ranged-Effect bei Raketen vorgenommen wurden. Wenn schon, dann macht doch der Fall Probleme, wo ein Spielsatzautor möchte, das die Rakete genau eine Wand durchschlägt, und dann an der nächsten explodiert (und nicht auch noch diese durchschlägt). Aber im Normalfall werden Kämpfe sowieso nicht darauf ausgelegt sein, das man sie durch Wände hindurch ausführt.

Daher ist auf der Prioritätenliste eine Import-Funktion ja ganz oben anzusiedeln.

In wie fern? Für den Spieler gibt es jedenfalls kontinuität, denn es kommt ja immer das gleiche Tileset (pro Spielsatz) zum Einsatz. Und der mögliche Schaden der Handwaffen gibt doch garnicht soviel Spielraum her, das 100 HPs mal viel sind, und mal wenig.
Panzerung und HP müssen definitiv getrennt behandelt werden. Wenn man denn die HP wirklich per Kategorie festlegen würde, dann mit einer eigenen (sprich 2 Kategorien; eine für Panzerung und eine für HP). Im übrigen, es kann doch Absicht sein, das Betonwände so unterschiedlich viel einstecken können (eine Map ist darauf ausgelegt, das man den Feind durch eine neue "Tür" in den Rücken fällt weil man sonst keine Chance hat; eine andere Map würde zu leicht werden, wenn man von überall Problemlos kommen könnte).

Ganz schlecht. Dann sind ja alle auf die Grafiker angewiesen , und keiner kann mehr das umsetzen, was er gerne möchte.

Ich glaube da kommt das Verständnisproblem her. Wenn man nur ein einziges Tileset von einem Ersteller nimmt, dann ist das natürlich konsistent - aber gerade das bezweifle ich.

Ich gehe eher davon aus, das es eine ganze Reihe von Tilesets geben wird - genauso wie es jetzt Sarun's Tileset für Saruns Karte gibt, Marauder's Dschungel-Tileset und Karte etc.

Und wenn dann ein anderer Spielsatzersteller beide Kartensätze benutzen will (und vielleicht auch noch einen Wintersatz von X, einen Wüstensatz von Y, Alienbasen von Z usw), dann kommen auf einmal unterschiedliche Tileeigenschaften in einem Spielsatz zusammen. Denn wenn das eine Tileset für ein Spiel mit kleinen Schadenswerten geschrieben wurde und das andere für einen Spielsatz mit hohen Grundwerten, dann kann die Waffe die in der einen Karte die Betonwände reihenweise zerfetzt in der anderen Karte noch nichtmal die windschiefe Hütte wirksam beschädigen - obwohl beide Tilesets und Karten in den Spielsätzen für die sie vorgesehen waren vernünftig arbeiten.

Das ist das Problem was ich sehe, und was sich nicht so ohne weiteres umgehen läßt wenn jedes Tileset seine eigenen absoluten Definitionen zu HP und Panzerung trifft.


Die Angriffsstärke kann momentan zwischen 1 und 1000 liegen. Und für eine Waffe mit 1000 ist die 100 kein Hindernis, während man mit einer Waffe von 10 schon einen guten Teil eines Magazins in die Wand jagen muss.

Man kann jetzt natürlich sagen das man dann die Angriffsstärke begrenzen soll - aber zum einen macht das dann bei einigen Panzer/Durchschlagskraft-Paaren Probleme, und zum anderen geht man dann nur von der anderen Seite an dasselbe Verhältnis heran.
Und meiner Meinung nach macht eine Richtlinie auf der Seite der Tilesets weniger Aufwand alswenn man die Waffenwerte stärker begrenzen würde.


Und woher kommt die Definition der drei verschieden dicken Stahlwände? Vor allen Dingen in Relation zu welchen Waffen?

Im Gegenteil bin ich der Meinung das drei unterschiedlich Dicke Stahlwände nur funktionieren können, wenn sie in einem Tileset oder zumindest von demselben Tileersteller definiert sind.
Denn wenn sie aus drei verschiedenen Tilesets kommen, die für drei verschiedene Spielsätze angesetzt waren, dann ist die "dicke" Stahlwand des einen Tilesets in einem anderen vielleicht der Papiertiger...
Nur wenn unterschiedliche Wandstärken von demselben Ersteller kommen, sind sie auch in korrekter Relation zueinander.


Natürlich - aber gerade deshalb will ich ja die Definition im Spielsatz haben.
Dann würde die "dünne" Betonmauer auch geringere Werte erhalten als die Dicke, aber in Relation zu den Waffen des Spielsatzes. Andernfalls kann es sein, das sowohl die dünne wie auch die dicke Wand für die Waffen eines anderen Spielsatzes kein Problem sind - Bei Waffenstärke 40 wirkt sich ein Verhältnis von 100 zu 500 Hitpoints ganz anders aus als bei Waffenstärke 400 der Spielsatzwaffen.

Den erhöhten Grafikeraufwand habe ich ja ausdrücklich selber als Nachteil genannt. Es wäre aber eine mögliche Lösung gewesen.

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

Andere Idee: Was wäre wenn der Tilesetersteller die zur Zerstörung benötigten Hitpoints als Prozentsatz eines "Basisschadens" angibt, und der Spielsatzersteller in seinem Spielsatz diesen Basisschaden passend zu seiner Waffenplanung festlegt? (oder umgekehrt im Spielsatz ein Faktor für die Hitpoints des Tilesets, das ist nur eine Benennungsfrage)

Dann müsste es das auch für die Panzerung geben. Außerdem glaube ich nicht, dass das funktioniert- rein vom Gefühl. Muss ich noch drüber nachdenken.

???
Wieso müsste es das dann auch für die Panzerung geben?
Die Panzerung hat doch eine ganz andere Funktion, und ein Faktor auf der Panzerung würde das Balancing extrem erschweren - deshalb ist ja die Rede davon die Panzerung absolut über die Kategorien anzupassen.

Nicht vergessen - die Hitpoints sind ein Zähler bis zur Entscheidung, wann ein Tile zerstört ist. Und hier macht es einen Unterschied ob ein Spielsatz einen relativen Basisschaden von 50, 200 oder 500 ansetzt.
Die Panzerung gibt dagegen an, ab welchem Wert für Durchschlagskraft ein Tile von der Waffe durchschlagen wird. Dieser Wert verändert sich nicht egal wie oft das Tile dazu getroffen wird.
Das Verhältnis Panzerung und Durchschlagkraft ist aber absolut und auch deutlich begrenzter als die Werte für Hitpoints und Angriffsstärke.

Fragen wir aber mal anders herum:
Wie würdet ihr denn vorgehen wollen, wenn ihr drei verschiedene Sets von Karten/Tiles/Spielsatz habt und ein vierter Spielsatzersteller gerne Karten aus allen drei Spielsätzen übernehmen will - obwohl der eine Spielsatz mit einem durchschnittlichen Waffenschaden von 30, der zweite mit einem Waffenschaden von 100 und der dritte mit einem Grundschaden von 400 arbeitet und die Wandtiles entsprechend viele Hitpoints erhalten haben.

Wenn ihr dann alle Karten unbearbeitet übernehmt, gibt es nur Chaos im vierten Spielsatz: Wenn der z.B. einen Basisschaden von 200 annimmt, dann würde er die Karten des ersten Spielsatzes platt walzen, des zweiten mühelos zerlegen und beim dritten gäbe es kaum Zerstörungen.

Wollt Ihr dann wirklich in jedem einzelnen Tile in jedem Tileset jeden einzelnen Wert anpassen - und wenn Ihr dann im Balancing feststellt das eure Waffen auf einen Basisschaden von 150 umgestellt werden müssen alles nochmal von vorne?
Oder wenn einer der anderen Spielsatzersteller sein Tileset erneuert und Euch das neue Tileset besser gefällt auch hier alle Änderungen einzeln von vorne anfangen???