spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

als Code Referenz, kann man auch gut das hier Empfehlen

https://github.com/bjorn/tiled

Das ist weniger eine Engine, mehr ein reiner Level Editor. Er bietet sogar einstellungen für die Ecken, https://github.com/bjorn/tiled/wiki/Automapping

Das tolle daran ist, dass man die Karte später Exportieren kann, und die dann in seiner eigenen Favorisierten Sprache verwenden kann..

http://blackscorp.github.io/tiled2crafty/kinetic/ das ist meine JavaScript umsetzung(Bilder sind Open Source, nicht von mir)

Hi!

Mach doch lieber ein Spiel anstatt einer Engine!

Nein, ich finde das richtig gut, dass es auch so Leute wie dich gibt, die halt
etwas anderes, also z.B. eine Engine, machen. Das ist ja schließlich kein Forum
ausschließlich Computerspiel-Projekte.

Und dafür das du das in einer Woche gemacht hast, Respekt. Es gibt Leute, die sitzen Jahre an der Planung
eines Spiels und lassen es dann doch Falle.

Also bleib am Ball und viel Spaß noch.

MfG Merlin

Cool, kann man auch schon was damit programmieren (sry wenn die frage blöd is) ? Ich denke ich werde diese Engine selbst benutzen wenn sie rauskommt, dann könnten wir evtl. ja was zusammen machen?
Grüße, Suskritor

Ich weiß nicht, welches Framework/welche Bibliothek du für den Editor (die grafische Oberfläche) verwendest, allerdings solltest du nach Möglichkeit mal nach einem Docking-System schauen. Es bringt zwar einen gewissen Aufwand, dieses gänzlich zu integrieren (nicht nur das einfügen des Managers und dynamische hinzufügen und entfernen der Panels, sondern auch bspw. die Serialisierung und Deserialisierung, Mindest- und Maximalgrößen für alle Panels definieren, Unterbringen von Paneloptionen, ggf. das Verwalten der Layouts, ...), hat man es aber erst einmal drin, ist es ein enormer Gewinn für die Usability. Vor nicht all zu langer Zeit hatte ich auch mit dem Schreiben eines Editors angefangen, bei dem ich recht schnell ein solches Docking System eingebaut habe. Für das Layout dachte ich mir erst, dass eine ganz bestimmte Anordnung ganz sinnvoll wäre (auf der linken Seite unten eine Projektübersicht unten, darüber das Tileset zur Auswahl der Tiles für die Bearbeitung und darüber die Werkzeuge (Malen, Füllen, ...) und Optionen (Freihändig, Linie, Rechteck, ...). Nach vielen Test in einem anderen Bereich (Serialisierung) und dem dafür notwendigen ständigen neu Anordnen ist mir dann aufgefallen, dass die Wrkzeuge links neben dem Tileset besser aufgehoben sein könnten und musste sie nur dort hin ziehen (und nicht irgendwas im Code ändern). Sollte ich dort in der Breite mal nicht genug Platz haben, könnte für mehr Breite sorgen.
Solltest du ein Docking System haben, kannst du für jeden Tabinhalt der rechten Seite bereits ein Panel anlegen und diese dann frei hin und her schieben (oder wahlweise so liegen lassen).

Ansonsten noch ein paar Kritikpunkte am Interface:
Bei der Mapansicht und (vermutlich) der Tilesetansicht lassen die Scrollbars darauf schließen, dass der Inhalt dieser Container weit größer ist, als er es eigentlich sein müsste. (Es befindet sich alles im sichtbaren Bereich, aber dennoch kann man scrollen.) Das solltest du unbedingt noch so anpassen dass man auch nur so weit scrollen kann, wie Inhalt vorhanden ist.
Es ist zwar eher eine Kleinigkeit, bei einer sauberen Herangehensweise dürfte es aber kein Problem darstellen: Die Map ist nicht zentriert. Da die Map in der Regel das wesentliche Element ist, an dem man arbeitet, sollte es sich auch mittig befinden (nicht nur vom Layout der Elemente her, sondern auch innerhalb seines Containers. In meinem Editor ist das so gelöst, dass ich ein Steuerelement für die Map selbst habe, dessen Größe sich nach der Map (und später der eingestellten Darstellungsgröße) richtet, welcher (bisher nur) in den "MapEditor" (oder eher in einem SCrollViewer dessen) eingebunden wird, welches eine Größe entsprechend der Platzierung im Layout erhält und zusätzlich noch Steuerelemente für die Bearbeitungs (welche Ebene bearbeitet werden soll) und Darstellungsoptionen (wie groß soll die Map dargestellt werden) liefert.
Es ist zwar auch wieder eher eine Kleinigkeit, aber der Hintergrund des Mapcontainers (aus das, was um die Map herum dargestellt wird) sollte nicht weiß bleiben. Weiß liefert im ungünstigsten Falle einen sehr großen Kontrast mit dem eigentlichen Inhalt, was für die Augen anstrengender ist, als ein grauer Hintergurnd. (In dem Fall finde ich WPF gut, weil ich dort mit XAML ein Muster als Ressource definieren konnte, die als Hintergrund für den Mapeditor und die Tile-Auswahl dient, wofür nur die Zuweisung notwendig war. =) ) Ein Muster wäre meiner Meinung nach in diesem Falle auch besser, da man so Transparenzen der Map erkennen kann. (Sollte zwar nicht so sein, kann aber passieren.) Außerdem finde ich, dass mein Editor dadurch (und durch den verwendeten Style, der sehr nach Visual Studio 2010 aussieht) schon wesentlich besser aussieht (auch wenn bisher kaum Funktionalitäten implementiert sind, so fehlen eine Bearbeitungshistorie, Laden und Speichern von Maps, ...).
Die Position der + und - Buttons unter "Tiles" ist unschön. Siem acht zwar eine Zugehörigkeit zum oberen Feld kenntlich, passt aber nicht zur Höhe des Buttons links daneben. Dort wäre ein Abstand der beiden "Elementsammlungen" (Liste/Tileübersicht und die zugehörigen Button) angebracht, sodass die Zugehörigkeit eindeutig ist, es aber dennoch gut aussieht. (Zum Verständnis: wenn man eine horizontale Linie zur Abgrnzung durchziehen kann und die Zugehörigkeiten noch erkennbar sind, ist es richtig/so wie ich es meine.)
Die Gruppierungen im "Dialog"-Dialog sind unsinnig, da bisher nur einzelne Elemente gruppiert werden. Sollten später weitere Optionen hinzukommen, dann haben die Gruppen durchaus ihre Berechtigung, so sollte es aber nicht bleiben...
Der Button im gleichen Dialog hat keine Beschriftung.


Mapformat:
Im Falle von Maps halte ich XML für weniger Sinnvoll. Daten einer XML-Datei besitzen eine hierarchische Struktur, wodurch sich hierarchische Daten damit auch gut abspeichern lassen. Tabellarische Daten (feste Anzahl an Reihen und Spalten) lassen sich damit weniger gut speichern. Abgesehen von dem immer vorhandenen Problem, dass das Dateiformat keine gleichmäßige Anzahl von Reihen oder Spalten sicherstellen kann (ist bei CSV bspw das gleiche), hat man dann entweder für jede Reihe/Spalte ein Element und für jedes Datum ein Element, was für einen großen Overhead sorgt, oder man hat im XML eingebettet wieder Inhalt eines anderen Formats (bspw. CDATA).
Das Format, was du bereits hast, kannst du auch erst einmal weiterverwenden.
Ich speichere in meinem Maps (bisher) am Anfang zeilenweise Daten, wie die Größe, das Tileset etc., gefolgt von den Tiles der Map, die je Zeile durch Komma getrennt die Zeilen der Map darstellen, im Gegensatz zu deinem Format aber nicht durch "[Layer X]" unterteilt werden.