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 —› Spielmechanik —› Tilesets: Daten von Wandtiles

Seite: 1 [2] >>

Autor Mitteilung
verfasst am: 01.10.2006, 11:38
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Der vierte Datenbereich von Tilesets sind die Daten von Wänden.

Aktueller Stand:

1.) 4 Grafiken für Links/Rechts/Gespiegelt/Rückseite
Dies entspricht ausdrücklich nicht genau den 4 möglichen Positionen BL/BR/TL/TR, da einige Bilder auch noch intern gespiegelt werden.

2.) 1 Grafik Rahmen
wird wohl im Zusammenhang mit der Türeigenschaft genutzt, habe ich ehrlich gesagt noch nicht genau durchprobiert.

3.) Eigenschaft "als Tür"
Aktuell ein Auswahlfeld keine Tür - Links öffnend - Rechts öffnend

4.) Eigenschaft "durchgehbar"

5.) Eigenschaft "durchschaubar"

6.) Eigenschaft "Mauerecke"
Auch wenn klar ist was das bedeutet, müsste man mal überprüfen was genau dieses Flag im Spiel bewirkt.

7.) Eigenschaft "als Fenster" mit Farbe
Ich vermute das ist eine veraltete Eigenschaft, denn sie macht mit aktuellen Definitionen keinen Sinn mehr.
Die Transparenzfarbe ist seit einigen Versionen allgemein Festgelegt auf 255,0,255 und braucht nicht mehr wie früher extra definiert werden (im Gegenteil macht die Extra-Definition über ein Eckpixel jetzt Probleme, siehe Mantis)
Und das "Durchschießen" wird mit dem neuen Schadensmodell über die Panzerwerte geregelt, man muss nicht noch extra angeben wenn man eine Wand nicht durchlaufen aber durchschießen kann.

8.) Zerstörungsdaten
Hitpoints, Panzerung und Nachfolgetile bei Zerstörung sowei ein Flag ob das Wandtile zerstörbar ist.

---------------------
BEKANNTE PROBLEME

Dadurch das die Grafiken nicht den vier Seiten entsprechen sondern automatisch gespiegelt/gedreht erscheinen, gibt es keine Möglichkeit mit nur einer Grafik "Mauerecke" alle 4 Ecken zu belegen, man benötigt zwei Tiles dafür.
1088

---------------------
Mögliche Erweiterungen

9.) Name für das Wandtile
Hier wahrscheinlich noch wichtiger als für die Untergründe und Objekte, da man für entsprechende Spezialkarten wohl häufiger Wände mit identischer Grafik aber unterschiedlichen Eigenschaften braucht.

10.) Signalisierung "Wand zerstört"
Für die verschiedensten Zwecke auf Karten wird man wohl eine Signalisierung brauchen, das ein bestimmtes Wandtile zerstört wurde. Das reicht von gescripteten Folgeschäden (zerstöre die Kabelverbindungen in Wand X und der Energieschild vor Tür Y verschwindet) über Aktionsauslöser (zerstöre die Panzertür und der Gegner stürmt) bis hin zu einfachem Zählen (Sie haben 45% unseres Dorfes in ihrem Kampf zerstört. Wir erwarten Entschädigungen in Höhe von Z credits).
Dabei sehe ich drei Ansätze:
- EVENT:
Es wird einfach ein Event an eine Funktion der Kartendatei geschickt, die dann alles passend manipuliert. Das hat dann nichts mehr mit den Tilesets zu tun.

- Rangeeffekt bei Zerstörung:
Es wird für einige andere Punkte höchstwahrscheinlich einen Scriptauslöser als Rangeeffekt geben. In dieser Form könnte man dann ein solches Skript auch bei Zerstörung eines Tiles auslösen lassen, und dann muss der Scriptname irgendwie dem Tile zugeordnet werden.
Das gibt aber das Problem das die Tilesets extrem stark mit den Karten verknüpft sind, da solche Skripte sich zum großen Teil auf die Karten beziehen und selten klein sind.

- Spezifische Folgen:
Bei diesem Ansatz werden nur die denkbaren allgemeinen Folgen einer Zerstörung im Tile gespeichert, für Kartenspezifische Ereignisse ist die Eventsteuerung des ersten Ansatzes da.
Dies würde wahrscheinlich zu mehreren Zusatzeigenschaften führen, die in den meisten Fällen ungenutzt bleiben - aber die Eventprogrammierung der Karte deutlich vereinfachen.
Denkbar wären Felder wie "Kosten bei ziviler Zerstörung" (was natürlich bei UFO-Wänden leer bleibt), Flags ob eine Zerstörung das Event melden soll oder nicht (um die entsprechende Verwaltung zu vereinfachen, eventuell auch mit mehreren Event-Flags) etc.

11.) Einseitigkeit
Wenn man eine Wand benutzen will um z.B. ein Schutzfeld in einem UFO darzustellen, dann wäre es nett wenn man sagen könnte das sie von der einen Seite durchschossen und durchgangen werden kann und von der anderen Seite nicht.
Allerdings ist dies eine größere Änderung und da wäre es auch eine Überlegung wert ob man sowas noch mit einer Wand darstellt oder nicht besser ein weiteres Objekt oder eine Funktion dazu erstellt.
verfasst am: 01.10.2006, 11:44
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Die Wände sind der einzige Bereich der Tileset-Daten, wo ich Überlegungen für eine komplette Umstellung für angebracht halte.
Die Fenster-Daten sollten besser sowieso verschwinden, und die Probleme mit den Ecktiles lassen sich auch nicht ohne größere Änderungen bewältigen.

Ein Wechsel auf 4 Grafiktiles mit direkter Zuordnung an die vier Wandrichtungen hat aber auch das eine oder andere Problem - man müsste sich entweder von einer Spiegelungsfunktion im Karteneditor verabschieden oder man bräuchte für jede der 4 Wände auch noch 4 Rückseitengrafiken.
Diese 8 Grafiken können natürlich wie bisher auch aus einer Ursprungsgrafik berechnet werden, aber wenn ein Tilegrafiker mit Schriftzügen auf der Wand arbeitet dann muss er einiges austauschen um Spiegelschrift zu verhindern...
verfasst am: 01.10.2006, 15:48 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: DirkF
Diese 8 Grafiken können natürlich wie bisher auch aus einer Ursprungsgrafik berechnet werden, aber wenn ein Tilegrafiker mit Schriftzügen auf der Wand arbeitet dann muss er einiges austauschen um Spiegelschrift zu verhindern...

Ist derzeit denke ich ganz gut gelöst. Wird automatisch gespiegelt. Bei Bedarf kann man aber einzelne Bilder selbst zuweisen. Und das braucht man nicht nur für Schrift. Auch wenn man eine vernünftige Licht- Schattenwirkung will, kommt man wohl nicht um extra einzelbilder drumherum.
verfasst am: 01.10.2006, 17:18
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Zitat: Natter
Ist derzeit denke ich ganz gut gelöst. Wird automatisch gespiegelt. Bei Bedarf kann man aber einzelne Bilder selbst zuweisen.

Die aktuelle Spiegelung führt aber zu den Problemen, das ein beliebiges Ecktile nur auf 3 der vier Ecken gesetzt wird, die vierte Grafik ist immer das doppelte von einer anderen Ecke..
Diese fehlende 4. Grafik sollte aber wenn schon dann auch automatisch entstehen - und dafür müsste man einiges an den bestehenden Funktionen zur Spiegelung ändern...
verfasst am: 01.10.2006, 20:03 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Ohje. Hab mir das jetzt mal angesehen, weil ich echt nicht wusste, wie das mit den Ecktiles funktioniert.

Problem 1: Die Zuordnung der Ecktiles mit Begriffen wie "oben Links" oder meinetwegen auch "Norden" ist nicht eindeutig, denn wer sagt, ob die linke oder die rechte Ecke in die selbe Richtung zeigt, wie die dazugehörige Mauer.

Wenn man nach der Bezeichnung geht, dann sind sämtliche Mauern falsch zugeordnet (oder der Einsatz eines Ecktiles wird fraglich).

Denn entwedet man sagt, eine Mauer gehört zu dem Feld, auf dem sie gebaut wird (und danach wir derzeit auch die Ausrichtung zugeordnet). Dann wären alle Mauern nach innen gebaut (stehen also im Feld). Dadurch ergibt sich nie eine Lücke für ein Ecktile. Wäre ja optimal, aber probiert es mal aus, 4 Mauern auf ein Feld zu setzen. Das führt zu unschönen Überschneidungen.

Oder man sagt, Mauern stehen immer außerhalb. Dann wären die Richtungszuordnungen aber alle falsch (außerdem werden die Mauern derzeit immer in dem Feld gebaut, auf das man klickt, obwohl man sie vermutlich als Begrenzung des Nachbarfeldes gedacht hat). Dann braucht man aber auch für jede Ecke ein extra Ecktile. Mit der derzeitigen Lösung klappt das aber auch nicht, denn die Ecktiles würden die Mauern ersetzen.

Alternativ kann man Variante innen und außen auch mischen. Dann hat man saubere Abschlüsse und man kommt ohne Ecktile aus. Der Nachteil ist allerdings, dass dadurch ein eingemauertes Feld nicht mehr Quadratisch ist. Auch das positionieren von Objekten an Wänden (z.B. Schrank) dürfte so erschwert werden.


Fazit: Hier muss eine Grundlegende Richtlinie erstellt werden, wie vorgegangen weren soll.
verfasst am: 01.10.2006, 21:16
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Es ist genau genommen sogar noch schräger. Das Problem ist nur der oberste Punkt, wo TL und TR zusammenstoßen.

Immer dann wenn TL und TR eines Feldes gleichzeitig gesetzt werden, überschneiden sich die obersten Linien und TR liegt vor dem TL.
Alle anderen Tiles werden bei korrekter Mauerdicke automatisch angepasst und überlappen sich ohne Grafikfehler (bei dünneren oder dickeren Mauern gibt es einen Versatz).
Insbesondere kann man mit drei Mauern eine korrekte Umgrenzung schaffen, solange diese Umgrenzung auf einer der oberen Seiten offen (bzw. mit einem Tile aus einem angrenzenden Feld belegt) bleibt.

Das Problem ist nur, dass man diesen Fehler nicht ohne massive Umstellungen aus der Welt schaffen kann, und deshalb werden wir einfach wie bisher auch darum herum arbeiten müssen.
Ich kann mir auf Anhieb zwei theoretische Lösungen vorstellen, die in der Praxis aber viel zuviel Arbeit bedeuten:
1.) Ecke und Wand trennen - die Wand belegt nur den Mittelteil der Seite, die Ecke wird passend platziert.
Führt leider dazu dass ein Kartenersteller ca. 50% mehr Tiles setzen/klicken muss, sonst wäre das realisierbar.
2.) Wände liegen zwischen den Feldern - dadurch bräuchte man sogar nur 2 Wandrichtungen und eine Ecke, aber dies würde eine komplette Umprogrammierung der gesamten Kartenspeicherung und Grafikengine erfordern. Für die Arbeit braucht man aber imho einen besseren Grund als diese Überlappungsprobleme.

Damit landet das bei der aktuellen und praktikablen (aber nicht sehr genauen) Lösung 3:
3.) Kartenersteller kontrolliert das grafisch und akzeptiert auch nicht quadratische Säulen...


Man könnte 3 noch unterstützen, indem man ein spezielles Ecktile für Norden erzeugt, das nur ein "Dach" auf die Mauern setzt und den Grafikfehler ausgleicht. Das wäre dann aber ein 5. Eckbild, denn die reguläre Ecke oben kann das nicht lösen (sie hat ja noch zusätzlich ein Mauerstück zum Boden).
verfasst am: 02.10.2006, 00:09 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: DirkF
1.) Ecke und Wand trennen - die Wand belegt nur den Mittelteil der Seite, die Ecke wird passend platziert.
Führt leider dazu dass ein Kartenersteller ca. 50% mehr Tiles setzen/klicken muss, sonst wäre das realisierbar.

Das Problem daran wäre ja, das man dann auch bei einer geraden Wand Ecken setzen müsste (denn Wandteile würden nicht mehr abschließen). Scheidet daher aus.

Zitat: DirkF
2.) Wände liegen zwischen den Feldern - dadurch bräuchte man sogar nur 2 Wandrichtungen und eine Ecke, aber dies würde eine komplette Umprogrammierung der gesamten Kartenspeicherung und Grafikengine erfordern. Für die Arbeit braucht man aber imho einen besseren Grund als diese Überlappungsprobleme.

Hmm, das wäre vielleicht sogar machbar. Hätte auch den Vorteil, dass dickere Wände möglich wären (geht momentan nicht, weil sonst Einheiten in Wänden verschwinen würden). Man könnte auch überlegen, Wände mitten auf dem Feld langgehen zu lassen, und dieses dafür nicht begehbar zu machen.

Zitat: DirkF
3.) Kartenersteller kontrolliert das grafisch und akzeptiert auch nicht quadratische Säulen...

Nun, das Nichtquadratische stört mich auch nicht sonderlich. Was mich ärget ist die Tatsache, das ich bei dieser Variante 5 mal soviel Zeit brauche. Ich hab noch garnicht viel mit den Maps gearbeitet, und trotzdem nervt es mich schon, das ich immer erst den falschen Radiergummie verwende. Und da die Wände ja nicht immer richtig abschließen (je nachdem, welche man gerade ausgewählt hat), muss man häufig löschen. Auch bei den Innenräumen macht man öfter Fehler, so dass z.B. keine Tür passt, weil die eine Wand nach "außen" zeigt, die andere nach "innen".

Ganz schlimm wird es aber, wenn man versucht, ein Objekt so anzuordnen, das es an der Wand "anliegt", eben z.B. bei einem Schrank. Genaugenommen bräuchte man alle Schränke etc. doppelt, je nach dem, welche Wand man gerade gewählt hat (gibt ja 2 Verschiedene von Nord nach Süd, und 2 Verschiedene von West nach Ost.

Vielleicht liegt ein Teil des Problemes auch darin, das man beim Auswählen keinen Unterschied zwischen TL + BR bzw. TR + BL sehen kann. Dafür werden exakt die gleichen BMPs verwendet, nur das sie dann vom Programm anders interpretiert werden.

Ok, es mag sein, dass wir keine Lösung dafür finden. Aber wir sollten es wenigstes versuchen.

PS: Wenn man alles so lässt, wie bisher, dann ließen sich Ecken übrigens besser als eine Art Objekte realisieren. Da wäre auch kein Spiegeln oder ähnliches nötig, sondern nur ein verschieben.
verfasst am: 02.10.2006, 08:57 · Edited by: Marauder
Registrierdatum: 16.05.2006, 10:18

 Beiträge: 174
PS: Wenn man alles so lässt, wie bisher, dann ließen sich Ecken übrigens besser als eine Art Objekte realisieren. Da wäre auch kein Spiegeln oder ähnliches nötig, sondern nur ein verschieben.

Sorry, wie meintst du das ? Du mußt das Objekt ja auch drehen, damit die Ecken passen...
Aber wenn ich ehrlich sein soll - das mit den TL,BL, TR,BR im Karteneditor ist schon ziemlich verwirrend - einfacher wäre man würde nur eine Leiste mit jeweils einen Tile dieses Satzes haben (von mir aus die Frontseite) und könnte ihn dann je nach Bedarf drehen. Vielleicht neben dem Mauscursor´n kleiner Kompass, der die momentane Ausrichtung der Wand anzeigt, und das ganze wäre schon annähernd perfekt...

Das Ganze würde jedoch voraussetzen, daß im Tileeditor jedes Tile in 4 Raumrichtungen bearbeitbar sein muß - nicht wie momentan: Links, Rechts, Gespiegelt, Hinten... da kann man momentan noch nicht wirklich drehen - nur spiegeln...
verfasst am: 02.10.2006, 15:41 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: Marauder
Sorry, wie meintst du das ? Du mußt das Objekt ja auch drehen, damit die Ecken passen...

Mir gings mehr darum, dass ich bei einem Objekt sofort am Bitmap sehen würde, zu welcher Ecke es gehört. Davon abgesehen ist mir nicht ganz klar, warum eine Ecke überhaupt gespiegelt werden sollte. Wenn das Licht von links kommt, dann ist die Linke Seite hell, und die rechte Seite dunkel, ganz egal, welche Ecke das Ecktile nun abdecken soll. Und drehen würde bei einem Objekt nur Verschieben bedeuten (bei Objekten ist der Platz zum nach oben verschieben da).
verfasst am: 02.10.2006, 19:02
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Zitat: Natter
Man könnte auch überlegen, Wände mitten auf dem Feld langgehen zu lassen, und dieses dafür nicht begehbar zu machen.

Streich das - man bräuchte 15 verschiedene Wandtiles pro Wandgrafik, um alle Kombinationen von Wänden aus den 4 Richtungen darzustellen.

Das Problem lässt sich aber auch nicht durch den Ansatz 2 oder die Objekte lösen, denn es ist ein perspektivisches Grafikproblem.

Die Grafikengine arbeitet, indem sie von hinten/oben nach vorne/unten alle Tiles komplett übereinander legt. Dabei kommt es vielfach zu perspektivischen Überlappungen, aber die meisten sind entweder automatisch verdeckt oder sogar notwendig um durchgehende Wände zu erzeugen.

Die obere Ecke ist die einzige Stelle wo diese Überlappung Probleme bereitet. Man kann die entsprechenden Wandtiles aber auch nicht kürzen, denn diese Überlappung ist bei langen Wänden notwendig um die Kante einer TR-Wand in dem Feld oben links zu verdecken.

Die einzige "einfache" Variante die ich mir vorstellen kann wäre ein Eingriff in die Engine. Man baut eine Abfrage ein, damit nur im Fall das sowohl TL alsauch TR belegt sind die linke Kante des TR-Tiles transparent geschaltet wird.
Dies hat immer noch Probleme sobald man mit unterschiedlichen Wänden aufeinander trifft, und nichts davon behebt die Probleme wenn man die Dicke einer Wand von der vorgesehenen Pixelzahl abweichen lässt - wie man an Marauder's Holzwand-Tiles sieht muss man bei abweichenden Pixelstärken höllisch aufpassen oder es entsteht ein Versatz zwischen den Wänden.

Alles andere würde aber eine sehr große Umprogrammierung der Grafikengine erfordern - und das ist es imho nicht wert.
verfasst am: 02.10.2006, 20:20
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: DirkF
Streich das - man bräuchte 15 verschiedene Wandtiles pro Wandgrafik, um alle Kombinationen von Wänden aus den 4 Richtungen darzustellen.

Keine Ahnung, wie du auf 15 kommst. Ich bräuchte 2 Wände und 4 Ecken.

Zitat: DirkF
Das Problem lässt sich aber auch nicht durch den Ansatz 2 oder die Objekte lösen, denn es ist ein perspektivisches Grafikproblem.

Von welchem Poblem sprichst du? Wenn es nur um die fehlende Ecke geht, die ist kein großes Problem. Da muss halt nur eine zusätzliche Grafik eingebunden werden (wie ja schon in einigen Tilesets zu finden). Mir geht es um die Probleme, welche beim Erstellen einer Map auftreten (siehe oben). Ich würd ja ein Beispiel hochladen, aber ich hab momentan keinen Webspace.
verfasst am: 02.10.2006, 21:03
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Zitat: Natter
Keine Ahnung, wie du auf 15 kommst. Ich bräuchte 2 Wände und 4 Ecken

Und was ist mit den T-Verbindungsstücken und der Kreuzung zweier Wände im Hausinnern? Und gegebenenfalls noch Endstücke, auch wenn man auf die verzichten könnte (dann sind es aber immer noch 11 Tiles pro Wandtyp).

Zitat: Natter
Von welchem Poblem sprichst du?

Zitat: Natter
Wäre ja optimal, aber probiert es mal aus, 4 Mauern auf ein Feld zu setzen. Das führt zu unschönen Überschneidungen.

Die Überschneidung in der Ecke zwischen TL und TR, wenn Du beide Mauern innen auf ein Feld setzt.
verfasst am: 02.10.2006, 21:21 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: DirkF
Und was ist mit den T-Verbindungsstücken und der Kreuzung zweier Wände im Hausinnern? Und gegebenenfalls noch Endstücke, auch wenn man auf die verzichten könnte (dann sind es aber immer noch 11 Tiles pro Wandtyp).

Hab ich auch gerade gemerkt, als ich das mal ausprobiert habe (ist ja schon möglich, wenn man die Mauern als Objekt definiert). Das Problem ließe sich umgehen, wenn man die Wände "überstehen" ließe (auch schon möglich), aber dann gibts wieder Probleme mit falschen Überlappungen. Wofür du Endstücke brauchst, versteh ich aber nicht.

Zitat: DirkF

Die Überschneidung in der Ecke zwischen TL und TR, wenn Du beide Mauern innen auf ein Feld setzt.

Naja, das ist kein wirkliches Problem. Der Mapersteller muss die Wand halt außen um das Feld bauen (ist zwar unschön, aber nicht sehr tragisch, da dies wohl selten nötig wird).
verfasst am: 03.10.2006, 08:42
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Zitat: Natter
Naja, das ist kein wirkliches Problem.

Wofür dann die Überlegungen mit den Wänden mitten auf den Tiles? Ich hatte das so verstanden das Du das überlegt hast um genau diese grafische Überschneidung in der oberen Ecke zu verhindern.

Oder auf welche anderen Probleme beim erstellen einer Map beziehst Du Dich?
verfasst am: 03.10.2006, 17:36
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: DirkF
Oder auf welche anderen Probleme beim erstellen einer Map beziehst Du Dich?

Zitat: Natter
Was mich ärget ist die Tatsache, das ich bei dieser Variante 5 mal soviel Zeit brauche. Ich hab noch garnicht viel mit den Maps gearbeitet, und trotzdem nervt es mich schon, das ich immer erst den falschen Radiergummie verwende. Und da die Wände ja nicht immer richtig abschließen (je nachdem, welche man gerade ausgewählt hat), muss man häufig löschen. Auch bei den Innenräumen macht man öfter Fehler, so dass z.B. keine Tür passt, weil die eine Wand nach "außen" zeigt, die andere nach "innen".

Ganz schlimm wird es aber, wenn man versucht, ein Objekt so anzuordnen, das es an der Wand "anliegt", eben z.B. bei einem Schrank. Genaugenommen bräuchte man alle Schränke etc. doppelt, je nach dem, welche Wand man gerade gewählt hat (gibt ja 2 Verschiedene von Nord nach Süd, und 2 Verschiedene von West nach Ost.

Vielleicht liegt ein Teil des Problemes auch darin, das man beim Auswählen keinen Unterschied zwischen TL + BR bzw. TR + BL sehen kann. Dafür werden exakt die gleichen BMPs verwendet, nur das sie dann vom Programm anders interpretiert werden.

OK, 5 mal so lange ist vielleicht etwas übertrieben, aber nervend ist es schon.
verfasst am: 03.10.2006, 18:52
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Das ist dann eher eine Frage des Karteneditors und nicht des Tilesets.
Irgendwo weiter oben war ja sowieso schon gesagt worden, das man die zusammengehörenden Wandtiles in einem Icon zusammenfassen soll und die Richtung per Tastatur/Buttons bestimmt statt mit 4 verschiedenen Iconreihen.
Das würde auch das Radiergummi auf einen Button reduzieren und z.B. per Pfeiltasten umschaltbar machen.

Und noch eine Idee für den Mapeditor: Wir können ja ein Flag für die Umschaltung zwischen einfacher und erweitertem Tileset machen. Bei einfachem Tileset werden nur die BR/BL-Tiles und die entsprechenden Ecken verfügbar sein, sodass ein Kartenersteller schon per Leertaste zwischen den beiden einzigen Radiergummi-Wänden umschalten kann.
Und die Kartenersteller die es aufwendiger wollen (weil sie z.B. für einige Bereiche doppelte Wände haben wollen) stellen das auf die erweiterten Tilesets, die dann wieder alle 4 Richtungen beinhalten.
Das sollte dann schon einiges helfen...
verfasst am: 03.10.2006, 19:35 · Edited by: Natter
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: DirkF
Das ist dann eher eine Frage des Karteneditors und nicht des Tilesets.

Nicht wirklich. Die Probleme liegen ja am Tileset und nicht am Mapeditor. Das es 2 verschiedene horizontale Wände gibt, kann man im Mapeditor nicht mehr verhindern. Mag sein, dass man die Probleme ablindern kann, aber man wird sie im Mapeditor nicht beseitigen können. Eiene Tür passt eben nicht, wenn ich links und rechts verschiedenme Wände genommen habe (und wer will vorschreiben, das man nur die Nordwand oder nur die Südwand verwenden darf). Um doppelte Objekte (Schränke etc.) kommt man auch nicht drumherum, wenn man die Wandtiles so lässt, wie sie derzeit sind.

Und für den Tilesetersteller, der alle 4 Seitenansichten extra erstellen will, ist auch nicht unbedingt ersichtlich, wieso die Nordwand genauso positioniert werden muss, wie die Südwand (obwohl die eine doch über das Feld, die andere unter das Feld gehört). Verwechslungen sind vorprogrammiert.
Zitat: DirkF
Bei einfachem Tileset werden nur die BR/BL-Tiles und die entsprechenden Ecken verfügbar sein, sodass ein Kartenersteller schon per Leertaste zwischen den beiden einzigen Radiergummi-Wänden umschalten kann.

Hmm, was spricht eigentlich dagegen, sich auf diese 2 Wände zu beschränken? Die anderen von mir genannten Probleme würden sich (soweit ich das überblicke) auch erübrigen. Und man bräuchte nur noch eine Ecke.

Wenn es trotzdem die erweiterte Version gäbe, würden auch die Probleme erhalten bleiben. Für eine dickere Wand kann man diese auch als Objekt definieren (macht es dem Mapersteller auch leichter).
verfasst am: 03.10.2006, 19:51
Programmierer, allgemeines

Registrierdatum: 06.06.2004, 17:19

 Beiträge: 3186
Zitat: Natter
Hmm, was spricht eigentlich dagegen, sich auf diese 2 Wände zu beschränken?

- Man müsste wohl auf das drehen von Karten verzichten.
verfasst am: 03.10.2006, 20:12
Admin, Spielsatz GalWar

Registrierdatum: 31.08.2005, 21:51

 Beiträge: 5596
Zitat: Natter
- Man müsste wohl auf das drehen von Karten verzichten

Nicht automatisch - aber die Routine zum Umrechnen der Wandpositionen wären deutlich aufwendiger zu programmieren...

Oder man würde doch wieder die Idee von den Wänden zwischen den Tiles aufgreifen - wenn man die Grafikroutine auf BR/LR beschränkt dann würde das sogar einfacher sein als ich ursprünglich dachte. Und damit wäre dann auch wieder eine Drehung berechenbar.

Das Problem ist dann eher das es eine komplett andere Abspeicherung ist und eine Umprogrammierung der Routinen zur Sichtlinie und Hindernissen etc. erfordert.

Da das Drehen von Karten sowieso noch nicht funktioniert würde ich eher Vorschlagen das wir uns als Provisorium auf die BR/BL-Einschränkung unter Beibehaltung der bisherigen Routinen einigen und dann später mal kontrollieren, ob wir die Kartenspeicherung umstellen können.
Das ist dann auch deutlich weniger Programmieraufwand.
verfasst am: 04.10.2006, 09:20
Registrierdatum: 16.05.2006, 10:18

 Beiträge: 174
Also wenn die Tiles in der Mitte plaziert werden sollen, und eine BR/BL gilt, dann schlage ich vor, daß man diese gleich so dick wie Objekte macht (64 statt 40 Pixel).
Daß würde Grafikern enorm viel Spielraum in der Gestaltung der Wandtiles schaffen und die "Portierung" von alten Wandtiles auf das neue Format wäre fast schon trivial (einfach den Bitmap verschieben). Die Rotationsroutine denke ich, ist auch wesentlich einfacher zu programmieren, als es momentan der Fall ist.

Allerdings benötigt man so oder so 4 Seiten, wenn man die Tiles wirklich jemals drehen können soll - da geht denke ich kein Weg vorbei.

Seite: 1 [2] >>




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

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