Projektvorstellung: 2D-Map Editor für ein geplantes Spiel

[Ynnus]

Hallöchen,

Zur Erhaltung des Progforums fehlt hier das Lese-Material, daher stell ich mal mein Projekt vor. Vielleicht gibt es ja Leser die gern was über die Projekte der anwesenden erfahren würden. Ich wär' jedenfalls nicht abgeneigt, auch mal was über eure Projekte zu lesen.


Also, es handelt sich dabei jedenfalls um einen Map-Editor (KEINEN Maker) der anfänglich auf Tiles basierte und man damit schon komplexe Karten mit beliebigen Layern anlegen konnte. Das Ganze wird in C/C++ und der WinAPI sowie OpenGL für die Grafikanzeige programmiert. Die GUI besteht zu 100% aus WinAPI und wurde durch ein selbsterstelltes Button-Kit zusammengebastelt. Es wird also keine Linux-Version geben.

Die Optik vor ca. 3 Monaten:
http://derfeind2k.de/daten/mapedit 3.0.png

Ein aktuelleres Bild (vor ca. 2 Monaten):
http://derfeind2k.de/daten/mapedit 6.0.png

Die ursprünglich Idee war ein RPG-Maker-Ähnliches Spiel mit besserer Grafik und einfach mehr Möglichkeiten durch pixelgenaues Bewegen usw. Daraus ist dann immer mehr was eigenes entstanden. Und wie gesagt, es sollte ein Karteneditor werden und kein Maker. Also die Grafik wird mit dem Programm erstellt, das Spiel welches ich geplant habe, wessen Karten dann mit dem Editor erstellt werden, dann in C++ unabhängig dieses Programms. Das erspart Einem ungemein Arbeit (da keine Scriptsprache benötigt wird).

Irgendwann hat es dann nicht mehr ausgereicht, dass alles auf Tiles basiert zu machen. Da dachte ich an einen komplett freien 2D-Editor bei dem man Sprites platziert, beliebig in Größe und Form ändern kann, mit Transparenzen und Farbänderung. Praktisch gesehen musste ich dafür fast den gesamten Quellcode überarbeiten, ca. 80 % sind dabei über Bord gegangen weil es für Tiles bestimmt war und das Mappen mit Sprites ganz anders funktioniert. Es mussten Routinen für das Einladen von Texturen her, frei bewegliche Objekte, ein Eigenschaftenfenster für diese (links unten) und eine bequeme Möglichkeit damit immer noch gut aussehende Karten zu erstellen.

Der Stand, wie es derzeit aussieht:
http://derfeind2k.de/daten/mapedit%209.0.png

Auf den Ersten Blick wird man sehen, die GUI wurde stark überarbeitet (bis auf einige Fragmente die entweder noch entfernt werden oder übernommen werden konnten). Man sieht auch, die erstellte Test-Karte bietet noch nicht viel. Man kann Objekte platzieren und verschieben, in Größe und Form ändern und eine Textur zuweisen usw. Links oben gibts das Objekt-Fenster in dem man die gesetzten Objekte aufgelistet bekommt. Rechts befindet sich das Textur-Fenster in dem die eingefügten Texturen aufgelistet werden. Bisher noch recht unschön anszusehen.

So soll es mal aussehen:
http://derfeind2k.de/daten/mapedit%209.0_soll.png
Man sieht, die Karte ist noch vom Vorgänger (die Tileversion) kopiert, dort habe ich sie aber so gemappt. Es ist also kein Photoshop-Zusammengeklicke was die Karte betrifft.

Derzeit noch nicht eingefügt aber fest geplant sind Sachen wie Kollisionsmasken, die man auf die einzelnen Objekte zuschneiden kann. Dazu noch Animationen, also Auswahl von Frames für Objekte, die dann in Zyklen durchlaufen werden. In wie fern noch eine Scriptsprache hinzu kommt mit der man etwa Türen bei Knopfdruck animieren kann, weiß ich noch nicht. Andernfalls wird das direkt im Spiel-Quellcode passieren.
Wie gesagt, es wird kein Maker sondern lediglich ein Map-Editor und eigentlich auch nur um ein geplantes Spiel von mir umsetzen zu können. Da ich aber mit der Zeit immer höhere Ansprüche habe hat sich daraus ein eigenes Projekt ergeben.
Zum Spiel selbst lässt sich noch nichts sagen, bis auf eine Idee und ein paar Grafiken existiert noch nichts. Einfach deshalb weil erst der Karteneditor fertig sein muss bevor ich anfangen kann, damit etwas zu machen.

Der Status sieht zur Zeit so aus, dass man die Karten noch nicht 100%ig speichern und laden kann. Objekte werden zwar wieder eingeladen aber das Objektfenster links bleibt noch leer, lässt sich aber flott einrichten. Die Prioritäten liegen aber derzeit woanders. Nämlich das Mapping-Verhalten oder auch, das Handling wie man Karten erstellen kann. Etwa, dass man unter der Registerkarte "Prefabs" fertige Objekte abspeichern kann und diese dann aus der Liste heraus schnell erneut setzen kann. Somit kann man dann Bäume oder andere Objekte schnell duplizieren ohne das Objekt von Grund auf neu zu erstellen und mit Textur zu versehen. Diese Prefab-Listen sollen sich dann auch speichern und exportieren lassen um die Objekte auf anderen Karten erneut einsetzen zu können. Man kann sich also eine Art Datenbank von Objekten erstellen auf die man zurückgreifen kann. Dies erleichtert die Platzierung dieser und die gestaltung komplexerer Karten.
Bisher funktioniert das Anlegen und Speichern von Listen sowie die Aufnahme von Prefabs und das neuplatzieren dieser. Es fehlt noch Exportieren, Importieren und etwas feinhandling.

Layer wird es keine Geben, ist auch unnötig da beliebig viele Objekte angeordnet und übereinander gestapelt werden können ohne sich an Tilegrößen orientieren zu müssen. Es steuert sich also etwa wie ein Grafikprogramm (etwa Photoshop).

Zur Grafik noch etwas, unterstützt werden Texturen von 2er Potenzen. Also 32 x 32, 64 x 256, 512 x 1024 usw... Diese lassen sich auf ein Objekt platzieren und so zuschneiden das beliebige Teile angezeigt werden. Der Baum oben etwa ist von einem großen Tileset von 1024 x 1024 Pixeln heraus "gestanzt" und auf das Objekt gelegt.
Das besondere ist, das was man rechts im Fenster sieht ist praktisch schon das Resultat per OpenGL, so wird es aussehen. Das ist die Karte per (eigene OGL) Engine dargestellt, so werde ich es später auf dem ganzen Bildschirm darstellen und das Spiel darstellen. Welche Auflösung man dann allerdings verwendet steht frei. Hinzu kommen selbstveständlich noch Interface-Elemente usw. Dies ist ja nur die rohe Karte.

Zur Zeit besteht das Programm aus ca. 8770 Zeilen Quellcode.

Soweit zu meinem Projekt. Ich hoffe es war ein wenig informativ und hat einen Einblick gegeben womit ich mich zur Zeit beschäftige. Kommentare sind natürlich erwünscht.


Grüße,

Ynnus

[raian]

Hmmm.. hört sich interessant an! Aber in welchem Format werden die karten gespeichert? Könnte man damit eventuell auch Karten für dne RPGMaker entwerfen? (Auch wnen man dafür meines wissens die Verschlüsselung des Makers knacken müsste)

Hört sich sehr interessant an. Würde gerne näheres erfahren!

[Lukas]

RPGMaker entwerfen? (Auch wnen man dafür meines wissens die Verschlüsselung des Makers knacken müsste)

...

Das ist keine Vertschlüsselung, das ist ein nicht offen gelegtes Dateiformat. DFYX hat das mal für den Minerva aufgeschlüsselt, will die Daten afaik aber nicht so gerne rausgeben.
Außerdem, was soll dir das bringen, damit für den Maker zu mappen? Du kannst die Features, die der Editor dem Maker vorraus hat, eh nicht benutzen.

@ topic:
Hört sich interessant an. Wirklich viel hab ich dazu aber nicht zu sagen. Außerdem verwende ich Linux, weshalb das für mich wohl nicht wirklich interessant ist.

[Crash-Override]

Wow, wie sich das Teil gewandelt hat. Ich erinnere mich noch an die Version die du mal im Internen RPG-Main Forum gepostest hast. Sieht gut aus...

[Ynnus]

Wow, wie sich das Teil gewandelt hat. Ich erinnere mich noch an die Version die du mal im Internen RPG-Main Forum gepostest hast. Sieht gut aus...

...

Ja, ich hab es in der Tat fast komplett neu machen müssen. Wie beschrieben sind nur knapp 20% des Quellcodes übernommen worden. Es geht aber flotter voran beim 2ten Mal weil man neue Kenntnisse gesammelt hat die einem hier zu Gute kommen.

Aber in welchem Format werden die karten gespeichert? Könnte man damit eventuell auch Karten für dne RPGMaker entwerfen?

...

Ich kenne kein verbreitetes Format welches ich für diese Zwecke nehmen könnte daher hab ich ein eigenes entworfen. Aufgrund der vielen Möglichkeiten die geboten werden sollen passt es zu keinem Format und erfordert eine eigene Methode der Speicherung.
Da wären Objekte mit einer Vielzahl von Eigenschaften welche alle gespeichert werden müssen (Größe und Form, Farbe, transparenz, textur + Auflösung, Frames und Animationszeiten, Ereignisse bei Berührung/klick und vieles mehr), Texturlisten (Pfadangaben), die Prefabs (werden aber einzeln in eigenen Prefablisten gespeichert), die Karteneinstellung (Größe und Name). Das genaue Format steht noch nicht fest da es ständig in der Weiterentwicklung ist. Ich weiß ja noch nicht genau welche Eigenschaften noch alles zum Objekt hinzu kommen. Demnach würde sich die Menge der zu speichernden Daten ständig ändern, sich jetzt schon festzulegen wäre nicht möglich.
Aber die Dateieindung wird *.mem sein was für "Map Edit! Map" steht. Dies werden auch die ersten 3 Byte in der Datei sein zur Identifizierung dieser (ähnlich wie die Byte "BMP" in der Bitmap-Datei)

Das Dateiformat für die Prefab-Liste sieht dahingegen recht simpel aus. Es werden einfach der Reihe nach die Eigenschaften der Objekte gespeichert. Vorangestellt eine boolsche Variable, welche den Typ angibt (gespeichert mit Textur oder ohne) sowie eine short Variabel welche die Objekt-Name Länge angibt, gefolgt vom Objektnamen selbst. Dann folgen einfach stumpf die Objekteigenschaften durch welche dann beim Platzieren eines Prefabs auch wieder so ausgelesen werden. Eventuell füge ich noch eine eindeutige ID für die Prefabs hinzu, wird sich zeigen ob es ohne auch gut geht.

Also es wird keinerlei Kompatiblität mit dem Maker-Format geben. 1. kenne ich das Format nicht und 2. ist es ein vollkommen anderes als das meine. Ich habe keine Tiles mehr sondern nur noch Objekte, dafür hat der Maker events mit Scriptanweisungen die ich nicht habe. Es passt einfach nicht zusammen. Ebenso würde es keinen Sinn machen, Maker-Maps einladen zu können, da diese sich aus Tiles zusammen setzen. Das in Objekte zu packen wär' entweder ein aufwändiges zusammengeflicke von passenden Tiles zu einem großen Objekt oder man hätte jedes einzelne 16 x 16 pixel Tile als Objekt was wenig Sinn ergibt. Und noch dazu verwende ich derzeit nur *.TGA (targa) Grafiken mit Alphatransparenz als Tilesets. PNG wird später vielleicht noch hinzugefügt.

[MagicMagor]

Klingt interessant.

Schade finde ich, daß du anscheinend so stark auf WinAPI setzt. Wäre schön gewesen zumindest die Möglichkeit einer Portierung noch offen zu haben, aber gut, jedem das seine. Gespannt bin ich auch mal wie du die Kollisionsmasken machen willst, ob automatisch ein Objekt als "solid" markieren kann und das Programm automatisch, anhand der Transparenzwerte (so das durchsichtig auch durchgehbar ist), eine Maske erstellt.

Was das Format angeht, vielleicht wäre XML eine Idee. Hat den Vorteil, daß es einsichtig ist und es wohl relativ einfach sein dürfte für andere Programmierer das Format dann in ihren eigenen Projekten zu unterstützen. Nachteil ist natürlich, daß die Map-Informationen offen liegen. Aber gut, da kann man für das Spiel ja immer noch eine Verschlüsselung/Komprimierung whatever davor schalten. Ansonsten, dokumentier das Format vernünftig und Kompabilität dürfte sich einrichten lassen =).

Wirst du den Editor so zum freien Download stellen, da du ihn ja immerhin primär für den eigenen Gebrauch geschrieben hast und wenn ja, Open Source oder nicht?

[Ynnus]

Wenn der Editor zu dem Status kommt, dass man mit ihm was anständiges machen kann, dann werde ich ihn wahrscheinlich auch zum Download anbieten. Im Grund genommen ist er für den eigenen Gebrauch geschrieben aber wenn es Leute gibt die sich da einarbeiten wollen und ihr eigenes Spielchen damit basteln wollen, warum nicht?
Open Source halte ich aber für unwahrscheinlich aus dem einfachen Grund, dass ich jetzt schon die Leute hören kann die da sagen "warum hat er das denn so gemacht? Voll doof!", "Das hätte so gehen müssen" oder "Da muss man erstmal ordentlich aufräumen". Da behalte ich lieber dieses Schmutzige Geheimnis des Quellcodes als Beweis meiner Unfähigkeit für mich.^^
Solange es funktioniert sollte das ja ausreichend sein. Infos zum Mapformat usw. werden natürlich veröffentlicht wenn es soweit ist. Daraus soll kein Geheimnis gemacht werden, nützt ja auch keinem etwas.
Nur, es ist eben kein Maker sondern nur ein Editor. Demnach wird man sich die Engine entweder selbst schreiben müssen oder sich an dem Orientieren wie ich es im Ansichtsfenster rechts umsetze. Jedenfalls liefert die Map nur die Infos zu den Grafikobjekten, alles weitere liegt bei dem Programmierer. Und so ist es auch gedacht.

Was die Maskengenerierung für die Kollision betrifft, da es 2D ist wird es schwer für das Programm zu erkennen sein, was tatsächlich blockieren soll und was nicht. Beispiel Baum. Dieser steht auf dem Boden, der Stamm blockiert das Vorankommen. Doch die Blätter weiter oben sind Höhentechnisch auf anderer Ebene als der Spieler und dürften demnach nicht blockieren. Sind aber dennoch nicht transparent und würden daher als Maske für die Kollision falsche Werte geben.
Ich werde es wohl so machen. dass man ein Vieleck (wie viele Vertics es sein werden weiß ich noch nicht) am Objekt platzieren kann welches die Kollision übernommt. Sprich, eine Berührung der Kollisionsmaske des Spielers mit dieser maske löst die Blockierung der Bewegung aus. Und je mehr Eckpunkte diese Kollsionsmaske des Objekts hat desdo Pixelgenauer kann man die Maske anlegen. Am unkompliziertesten auch Rechentechnisch wäre wohl ein simples Viereck, dafür auch bei unförmigen Objekten eine schlechte Kollisionserkennung.
Also so ganz sicher ist das noch nicht. Die Priorität liegt jetzt derzeit daran, die Objekte möglichst komfortabel so platzieren zu können und die Textur genau drauf legen zu können wie der User es möchte. Das soll alles möglichst einfach ablaufen. Wenn das klappt mache ich mich an die Elemente welche für das resultierende Spiel wichtig sind wie die Kollision und die Möglichkeit von Animationen, dauerhaft, bei Berührung und bei Klick in Radius von X Pixeln (soll einstellbar sein).

[Jesus_666]

Eine Möglichkeit für die Kollisionsabfrage wäre, daß du eine zweite, schwarzweiße Bilddatei nimmst. Die wird nicht anezeigt, aber zur Kollisionsabfrage mit dem anderen Sprite verundet. Der Vorteil ist, daß man für jedes beliebige Objekt ein brauchbares Clipping angeben kann, ohne im Editor selbst aufwendiges Gefummel zu haben (und eine Kollisionsmaske dürfte sich im Grafikprogramm auf Grundlage des Sprites einfach erzeugen lassen).

[Ynnus]

(und eine Kollisionsmaske dürfte sich im Grafikprogramm auf Grundlage des Sprites einfach erzeugen lassen).

...

Stimmt natürlich, daher gestalte ich mein Programm ja auch so, dass es sich möglichst wie ein Grafikprogramm steuern lässt. Man soll diese Kollisionsmasken deshalb ja auch im Editor selbst erstellen können ohne ein zusätzliches Programm heranziehen zu müssen. Das mit dem 1-bit monochrom Sprite als Maske ist aber eine gute Idee, mal sehen in wie fern sich das umsetzen lässt.

[Ynnus]

Hier ein weiterer Screenshot, ganz aktuell von eben gerade. Einige Objekte sind per Grafikprogramm hinzugefügt worden, aus Gründen des Zeitaufwands. Der Boden, das Haus, der See, das Boot usw sind aber per editor gesetzt. Die Zierde-Objekte wie Fässer, Palmen und der Römer sind dann im Nachhinein reingesetzt worden.

Die Grafiken sind alle per PC handgemalt..

[Ichthys]

Sieht ja genial aus, haste gut hinbekommen und hört sich hinteressant an. Muss ich auch mal ausprobieren.

~Ichthys~

[Milchbox]

gute arbeit ich freu mich schon auf die downloadbare version

[MuadDib]

Das Ganze wird in C/C++ und der WinAPI sowie OpenGL für die Grafikanzeige programmiert.

...

Bez. OpenGL: Verwendest du ein GL Overlay für deine Arbeit oder bist du klassisch am eigens erstellte GL_QUADS texturieren? Die Grafikanzeige sieht nicht so aus, als ob du sehr dreidimensional vorgehen würdest, eher, als ob du (naheliegend) jedes "Tile" als QUAD aneinanderstöpselst und eine Textur raufklatschtst. Ist das auch bei der "Figurgrafik" so, wie man sie im unteren Screenshot sieht, oder ist das ein Polygon-Männchen, das auf dem QUAD (wenns überhaupt so gemacht wird...) steht.

Dann würd mich noch interessieren wie du es mit den Texture handhabst. Sind deine Geländegrafiken in einem Bitmap-File gespeichert, welches du als eine Textur hochlädst (damit du anschliessend mit den Texturkoordinaten spielen kannst, um die richtigen Tiles auszuwählen, ev. glSubTexImage) oder ist jedes "Tile" als solches als Textur hochgeladen. Wenn letzteres: Wie bekommst du das mit der Auswahl geregelt? Ständiges Binden mit Objekten ist ja irgendwann langweilig, und IIRC ist der object space auch begrenzt.

Die GUI besteht zu 100% aus WinAPI und wurde durch ein selbsterstelltes Button-Kit zusammengebastelt. Es wird also keine Linux-Version geben.

...

Button-Kit = Widget Toolkit, mit dem du deine GUI malst? Hab das nicht ganz verstanden, schätze aber, dass du irgendeine Ebene höher arbeiten wirst, als auf reiner WinAPI Ebene... ausser du bist Masochist.

Interessanter Beitrag, btw.

EDIT: Sorry, ich glaub ich hab etwas falsch verstanden: Der Editor ist schon Kachelbasiert, oder nicht?

[Ynnus]

@MuadDib:

Der Editor WAR mal Tileorientiert und da war es so, dass man eine Textur, das Tileset, hatte, und dann kleine 32 x 32 Pixel große QUADS gesetzt hat, welche die Textur dieses Tilesets hatten. Das hatte sogar eine recht beachtliche Leistung, man könnte mehrere tausend QUADS setzen und alle Texturiert und mit Alpha-Blending. Damit hätte man so etwa 15 Layer mit jeweils 32 x 24 Tiles füllen können. (ca. 11000 QUADS) Und das sollte selbst für komplexe Karten ausreichen, da ja nicht mehr las 32 x 24 Tiles pro Bildschirm angezeigt werden.

Das wurde mir später aber zu langweilig, weil alles so gleich aussieht und eben durch Raster begrenzet ist. Ich wollte alles etwas freier gestalten, freie Größen, Farben und Position auf der Karte. Daher hab ich das komplette System verworfen und nun Unterteilt in "Polygon" und "Objekt". So nenne ich meine 2 Bestandteile. Dabei arbeiten "Polygone" wie in 3D-Programmen, man setzt Primitive (QUADS) und spannt eine Textur darauf. Man kann die Vertices verformen und die Textur skalieren, versetzen usw. Diese "Polygone" werden eingesetzt um den Boden zu erstellen, das Wasser, Wände. Eben Dinge die eine gekachelte Textur haben. Daher ist die Textur ein einzelnes TGA-File, damit es kachelbar ist.
Der zweite Typ heißt schlicht "Objekt" und man setzt wieder ein QUAD, diesmal passt sich die Textur aber dem Objekt an. Man wählt sich also ein Teil der Textur aus, welches dargestellt wird, und beim verformen und Vergrößern des Objekts wird die Textur mit skaliert. Dies bietet die Möglichkeit, Bäume, Sträucher, Büsche, Blumen und allerlei Gegenstände in verschiedenen Größe, Formen und Farben darzustellen. Daher verwende ich dort eine Art "Tileset" wo die Objekte drauf sind, also eine TGA-Datei. Man wählt dann beim Platzieren des Objekts genau den Bereich aus, der auf die Ränder des Objekts gespannt wird. Die Ränder kann man aber auch nachher noch on-the-fly immer ändern. Das bietet auch die Möglichkeit, Objekte abzuschneiden und nur teils darzustellen.

(oben im Bild: Ein Polygon ist also etwa der Sandboden und die Hauswand, ein Objekt ist das Boot, das Netz, der Hammer, die Palme usw.)

Warum ich diese Arten trenne? Stimmt schon, im Endeffekt könnte jedes "Objekt" ein "Polygon" ersetzen und ein "Polygon" auch ein "Objekt", aber es würde mehr Arbeit machen. Auch mit einem "Objekt" kann man mittels den Einstellungen für Texturskalierung und Versatz einen gekachelten Boden erstellen. Wenn man sich dann aber überlegt, den Boden ein paar Pixel größer zu ziehen, zieht man die Textur mit, denn bei "Objekten" passt sich diese ja der Form an. Also nimmt man lieber "Polygone" und kann bequem die Größe und Position ändern, die Textur bleibt unbeeinflusst. (Man könnte aber auch bei Polygonen genau ein bestimmten Teil der Textur darstellen, mittesl Skalierung, Winkel und Versatz ließe sich der Teil genau rausschneiden. Aber ist eben viel umständlicher als mit einem "Objekt"). Von daher gibt es 2 Arten von Typen die man setzen kann und mit denen man die Karte gestaltet.
Später noch geplant ist auch, dass man "Objekten" Ereignisse zuweisen kann oder Routen und Animationen geben kann. Wie komplex das im Endeffekt noch wird weiß ich aber jetzt noch nicht genau.

Die Texturen und Tilesets werden übrigens alle zentral über die Texturbox rechts eingeladen und ausgewählt. Das, was da im Moment ein schwarzes Quadrat ist, ist in Wirklichkeit das Vorschaubild für das Tileset mit dem Boot, den Palmen, dem Hammer usw. Nur, der Ausschnitt der für das Vorschaufenster verwendet wird, ist zufälliger Weise leer. Das muss ich noch überarbeiten.

Button-Kit = Widget Toolkit, mit dem du deine GUI malst? Hab das nicht ganz verstanden, schätze aber, dass du irgendeine Ebene höher arbeiten wirst, als auf reiner WinAPI Ebene... ausser du bist Masochist.

...

Öhm, so ganz versteh ich das nicht, aber ich beschreibe mal wie ich meine GUI bastle. Also ich male nicht selbst mit Linien und Primitiven die Schaltflächen, was für ein Aufwand.^^
Also ich habe eine Klasse Fenster von der ich andere Klassen erben lasse. Diese Klasse Fenster ist für Hauptfenster. Die erbenden Klassen sind für Textboxen, Radiobuttons, Checkboxen, Trackbars, Listviews usw. Ich hab dann also Klassen von denen ich Objekte erstelle und mit dieser Erstellung wird eine solche Schaltfläche erzeugt. Und dies eben über die bekannte CreateWindowEx() Funktion der WinAPI. Die Messages der Buttons werden dann in einer zentralen Windows-Prozedur ausgewertet, insofern ich dem Fensterobjekt keine andere Callback-Prozedur zugeordnet habe.

[MuadDib]

@MuadDib:

Der Editor WAR mal Tileorientiert und da war es so, dass man eine Textur, das Tileset, hatte, und dann kleine 32 x 32 Pixel große QUADS gesetzt hat, welche die Textur dieses Tilesets hatten. Das hatte sogar eine recht beachtliche Leistung, man könnte mehrere tausend QUADS setzen und alle Texturiert und mit Alpha-Blending. Damit hätte man so etwa 15 Layer mit jeweils 32 x 24 Tiles füllen können. (ca. 11000 QUADS) Und das sollte selbst für komplexe Karten ausreichen, da ja nicht mehr las 32 x 24 Tiles pro Bildschirm angezeigt werden.

Das wurde mir später aber zu langweilig, weil alles so gleich aussieht und eben durch Raster begrenzet ist. Ich wollte alles etwas freier gestalten, freie Größen, Farben und Position auf der Karte. Daher hab ich das komplette System verworfen und nun Unterteilt in "Polygon" und "Objekt"

[...]

...

Alles klar. Das erklärt auch deinen Punkt mit Laden und Speichern, denn Kacheln speichern/laden sollte ja nun nicht wirklich ein Problem darstellen. Sehr interessanter Ansatz und für einen interaktiven Editor eigentlich ganz schön advanced, vor allem, wenn du dir dein Window Toolkit (mit allen Interaktionen) ja auch noch selbst schreibst Wie lange arbeitest du schon an der nicht langweiligen Variante?

Öhm, so ganz versteh ich das nicht,

...

Gut möglich, ich war etwas kurz angebunden und habe dementsprechend unsortiert meine Gedanken losgelassen...

aber ich beschreibe mal wie ich meine GUI bastle. Also ich male nicht selbst mit Linien und Primitiven die Schaltflächen, was für ein Aufwand.^^

...

Schon klar, unter "GUI malen" versteh ich generell das Zusammenbasteln, weils ja mit den richtigen Bibliotheken und/oder Editoren ja nichts anderes ist

Also ich habe eine Klasse Fenster von der ich andere Klassen erben lasse. Diese Klasse Fenster ist für Hauptfenster. Die erbenden Klassen sind für Textboxen, Radiobuttons, Checkboxen, Trackbars, Listviews usw. Ich hab dann also Klassen von denen ich Objekte erstelle und mit dieser Erstellung wird eine solche Schaltfläche erzeugt. Und dies eben über die bekannte CreateWindowEx() Funktion der WinAPI. Die Messages der Buttons werden dann in einer zentralen Windows-Prozedur ausgewertet, insofern ich dem Fensterobjekt keine andere Callback-Prozedur zugeordnet habe.

...

Genau auf das wollte ich hinaus. Du hast dir also eine eigene Bibliothek geschrieben, in der du objektorientiert die verschiedenen WinAPI Teile einfach erstellen kannst. Alles andere wär ja idiotisch, wenn man bedenkt, dass ein WinAPI Code, der Fenster und einen Button anzeigt ja schon 3-4 Seiten Quellcode hat.

Eigentlich ist das der Schritt, für den ich immer zu faul war, das ja schon sehr schöne Widget Toolkits gibt, die einem diese Arbeit abnehmen (GTK beispielsweise...).

[Ynnus]

Wie lange arbeitest du schon an der nicht langweiligen Variante?

...

Die ist noch garnicht so alt. Etwa am 18.7.05 hab ich mich entschlossen, die tilebasierte Variante zu verwerfen und die Objekte und Polygone einzuführen. Also so lange ist das noch nicht her. (Es gibt auch einen Forenthread hier wo ich noch die andere Version hatte und Probleme mit der Z-Anordung der Objekte hatte. Das hat dann den letzten Ruck gegeben, alles zu überarbeiten.)

Das wirklich aufwändige Zeug, die Gui Gestaltung und vor Allem die Erstellung der Klassen für Fenster, Schaltflächen usw. war ja vom vorherigen Projekt noch vorhanden. Das hat richtig Zeit beansprucht. Und fertig bin ich auch noch nicht mit dem Window-Kit, immerhin umfasst die WinAPI sooo viele Sachen, da hat man ne Menge zu tun. Aber die wichtigsten Fenster und Schaltflächen stehen, das konnte ich teils übernehmen. Die Arbeit war also mehr das Handling von diesen Objekten und Polygonen, die neu hinzugekommenen Eigenschaften wie Position, Farbe, Transparenz, Skalierung usw.

Was das Gui-Kit betrifft hast du sicher Recht. Es ist eine unmenschliche Arbeit und verdammt viel Aufwand. Und eigentlich nur Mittel zum Zweck, einen Map-editor zu erstellen. Sprich, vorher viele tausend Zeilen Code nur für Schaltflächen und erst dann anfangen mit dem eigentlichen Projekt, dem Editor. Aber nein, das eigentliche Projekt ist ja das resultierende Spiel welches mit dem Mapeditor gestaltet werden soll. Also, der Editor ist auch nur Mittel zum Zweck. Und der dauert nun schon recht lange. Es ist also eine Menge Arbeit damit verbunden, bis man an das Endpordukt überhaupt erst denken darf.

[Tessio]

muss schön sagen, schöne screens
freu mich tierisch auf die downloadbare version ^^

[Saimon]

Sieht verdammt gut aus.

Ich möchte aber noch was wissen: Was für Bildformate werden für die Grafiken unterstützt? JPG wär recht nützlich.

Und wie kann ich die Karten dann benutzen? Wenn ich es richtig verstanden habe, macht man mit dem Editor nur die Karten und muss dann per Programmieren verwenden?

Was ich außerdem noch seltsam finde ist, dass das Menü oben auf Deutsch ist aber der Rest auf Englisch.

Ansonsten gute Arbeit. Mach weiter so. Ich werde es mir gerne downloaden, falls es erscheint.

[Ynnus]

Sieht verdammt gut aus.

Ich möchte aber noch was wissen: Was für Bildformate werden für die Grafiken unterstützt? JPG wär recht nützlich.

...

Geplant ist wenigstens noch komprimierte TGAs (bisher unkomprimierte) und PNGs. BMP ist auch kein Problem, nur wer benutzt das heutzutage noch? JPEG weiß ich noch nicht genau, allerdings ist das ja auch mehr ein Internet-Format mit teils recht starker Komprimierung und daher eher ungeeignet für solche Sachen. Wenn das Programm steht wird es nicht mehr so viel Arbeit sein, die verschiedenen Formate hinzu zufügen, das kommt dann also später noch. Für die Tests jetzt reicht tga erstmal aus.

Und wie kann ich die Karten dann benutzen? Wenn ich es richtig verstanden habe, macht man mit dem Editor nur die Karten und muss dann per Programmieren verwenden?

...

Nun, die Karte wird als Datei gespeichert und kann dann mit beliebigen Programmen ausgelesen werden. Es ist wahrscheinlich, dass ich noch eine Art Kartenbetrachter schreibe, mit dem man erstellte Karten ansehen kann, wie diese dann aussehen und eventuell per Spielfigur rumlaufen. Also eine mini-engine was man später so machen könnte, mit der Karte.
Wenn man diese Karten dann aber wirklich weiterverwenden will muss man aber tatsächlich selbst ein Programm schreiben welches die Karte ausließt und darstellt. Ich werde aber wohl eine Routine beilegen, wie das Ansichtsfenster rechts die Karte darstellt. Anhand dieser kann man das ja dann einfach nachbauen.

Was ich außerdem noch seltsam finde ist, dass das Menü oben auf Deutsch ist aber der Rest auf Englisch.

...

Das Menü oben ist ein Dummy. Er dient nur als Platzhalter für das kommende Menü. Bisher gibt es dort keinerlei Einträge oder zumindest keine mit Funktion. Das kommt dann später, wenn das Programm sich mehr der Fertigstellung neigt. Ich benutze meist sowieso die Toolbar und nicht das Menü. Dann wird das ganze Programm auch in mehreren Sprachen übersetzt werden. Den Anfang mache ich eben mit englisch. Wenn es dann erste Testversionen gibt oder bald einsatzfähig ist, werde ich mich an eine Übersetzung machen. Aber das sind alles mehr Detailfragen und die werden dann bearbeitet, wenn die groben Dinge stehen. Wichtig ist erstmal, dass die Hauptfunktionen funktionieren, etwa das Erstellen der Karten soll möglichst leicht von der Hand gehen.