Was wäre euch wichtig an dem "perfekten" Maker?

[Cyangmou]

Generell alles nice to have, aber vmtl is das meiste schwer nachträglich einzubauen, da es doch recht tief ins System geht.

Hauptproblem ist, dassder Maker leider kaum Dynamikeinstellungen zulässt, welche jedoch für jedes Spiel fürs Gefühl von äußerster Wichtigkeit sind (wie man das Spiel steuert und sich die Figur bewegt sind das A und O für jedes Spiel und würden auch dementsprechende Einstellungen in jeder Art von 2D-Engine vertragen).
Ich versuch das ganze so gut wie möglich auf den Punkt zu bringen. Wie mans letztendlich dann alles zusammenbaut und obs machbar ist, weiß ich nicht (Hoff es ist zumindest verständlich).

Bzgl. Grafik und Animation kann ich dir mit Sicherheit ziemlich viele Fragen beantworten, da ich dort auch meist imme rauf die selben Probleme stoße


Generelle Grafische Darstellung

Einstellung für Auflösung/Pixel-Zoom/Tilegrößen
Auflösung (nativ) heißt dass man ne Auswahl hat um die gängisten Auflösungen auszuwählen
Zoom (ob man die grafiken mit 100%, 200%, 300% usw. scharf darstellen lässt)
Tilegrößen, würde 8x8, 16x16, 32x32, 48x48 und 64x64 als grundeinstellung vorgeben... kaum wer verwendet andere Tilegrößen, es sei denn für iso Grafiken.

(z.B. 640x360 300% 32x32 Tile Einstellung und man kommt auf ne State-of-the-art HD Aufösung, bzw. mit 200% kommt man auf 720p)

Z-Sortierung von sprites anhand grundfläche/unterkante (wenn man sprites hat die größer als ein tile sind, bzw. höher stehen, unter tiefer stehenden sprites angezeigt werden - eliminirt ziemlich viel clipping)

Zoom (um bei gewissen Events näher ins Geschehen zu Zoomen)
Screenshake (Um bei gewissen Events den Screen schütteln zu lassen)






Hauptcharakterbewegung:

Einstellung für die Zentrierung des Hauptcharakters (um bei größeren Figuren/Missbrauch des Programms bezüglich Genre mehr Kontrolle zu geben)

Feinabstimmung für Geh/Laufgeschwindigkeiten (Frameanzahl & Schrittgeschwindigkeit)

Standardmäßige 8-Richtungsunterstützung für Chars oder zumindest für den Hauptcharakter, für NPCs macht mans meistens aufwandtechnisch eh nicht (für gehen/laufen, 4 richtungen sind für ne Basis OK, fürn Hauptchar isses vor allem bei Action RPGs hakelig, falls nur 4 Richtungen vorhanden sind)

Animationseditor für jegliche Spritesheets (mit Angabe der ms/frame):
bestenfalls zum selber einstellen welche Frames für welche Animationen verwendet werden können - quasi dass man jede Animation für jede RIchtung programmieren kann und dann darauf zugreifen

Gut wäre hierbei jede Animation mit nem Sound verknüpfen zu können, für den man auch nen Offset einstellen kann, wann er abgespielt wird (würd ne gewisse Standard-Sounddynamik bringen)

Bewegung losgelöst vom Tilegrid
Pixelmovement ist nett, im Normalfall ist es für ein RPG allerdings genug 1/2 oder 1/4 Tile Größen für Bewegungen zu haben.
Heißt ne einstellung für schrittweiten wär optimal
Für gehen/Rennen braucht man vmtl verschiedene Schrittweiten (Rennschritte sind weiter und das muss auch in der Engine so vorgesehen werden um die Geschwindigkeit rüberzubringen)
Vor allem wenn man die Frameanzahl fürs und die Relativbewegung des Charakters abstimmt, würden schrittweiten helfen.

Beispiele aus der Praxis:
tilegröße 16x16
ich hab ne schrittweit von 8 pixel und 8 frames für den char, heißt jeden pixel wird n eigener frame angezeigt -> superflüssige Animation, gute kontrolle
beim rennen: selbe schrittweite 16 pixel, 8 frames (4 frames linker fuß, 4 frames rechter fuß) char nimmt immer 2 schritte, falls nur ein schritt möglich ist, wird nur die erste hälfte der frames angezeigt)

ich hab ne schrittweit von 16 pixel und 3 frames für den char -> superhakelige Animation, wenig kontrolle
ich hab ne schrittweite von 8 pixel und 3 frames für den char -> hakelige animation, jedoch noch verschmerzbar, gute kontrolle


Mapping:

Kollisionsmaps:
Passierbarkeit einstellbar via mapbarer Kollisionsmaps, statt Kolisionsabfrage im Tileset
Warum?
Man kann erstmal ne map bauen, ohne sich über Kollision Gedanken zu machen
die Kollision kann nachträglich über die Map gezeichnet werden
Sämtliche Begehbarkeitsfehler gehören der Vergangenheit an

(Für plattformen und dergleichen muss die kollisionsmap natürlich irgendwie ansteuerbar sein, damit man kollisionsblöcke sozusagen ändern kann)

Müsste natürlich verschiedene Kollisionstiles geben von welcher seite man gewisse tiles betreten kann und von welcher seite nicht (ganz praktisch, wenn man eher 3D angehauchte levels bauen will)

Beliebig große Tilesets
bzw. Falls eine standardgröße per tileset, beliebig viele tilesets verwendbar

Animationstiles mit beliebig vielen Frames (losgelöst vom standardtileset) und mit globaler Ansteuerung vom timing
Quasi, dass man Tileanimationen vorher zusammenbauen kann und dann setzt man so ein Animationstileobjekt. Alle laufen exakt gleich, wobei man selbe rnen Zeit/Frameoffset einstellen kann.

Einzeltiles/Meta Tiles
Mappingmäßig wäre es gut wenn man ein tileset auf einzeltiles und Meta-Objekte einstellen könnte.
Meta objekte sind einfach aus mehreren tiles zusammengesetzt.
Wenn ich jetzt nen Baum oder ein Teil Klippe im Tileset habe, will ich meistens alles hinsetzen, mit ner Einstellung diesbezüglich im Vorfeld kann man die Mappingeffizienz stark erhöhen (da ich im Tileset nur irgendwo af nen baum klicken muss und ein klick setzt alles hin, ist vor allem bei nicht Maker-Standardisierten Tilesets (sprich solche die den Grid verstecken und viele unterschiedliche tileansammlungen verwenden) von enomen Vorteil

Advanced Auto Tile System:
Automatisierte Texturtiles fürn Boden wie sie der Maker hat sind ja ganz nice, ist aber sehr basic
z.B. Fehlt die Möglichkeit Variationen für Ecken und gerade Tiles vom Programm automatisch stezen zu lassen.
Stell dir mal vor du hast fürn Autotile verschiedene Stücke für gerade tiles und Ecken und das Programm setzt diese Automatisch per Zufall - Mappingeffizienz und Mappinggeschwindigkeit sowie Mapstruktur werden mit ner kleinen Änderung am programm besser

Riesenvorteil für das System wäre auch eigene Autotile Einstellungen für Klippen, da Klippen immer sehr Zeitintensiv zum Mappen sind

Ebenfalls nice wäre es, wenn man größere Ecken für gewisse Texturen setzen könnte

Hat alles sehr viel mit know-how wie man organische Tilesets baut zum tun und relativ wenig mit Maker Standards.
Makerautotiles würden mit dem System vmtl noch funktionieren, wenn mans gut programmiert.
Dass Makermaps generell "scheiße" und "blockig" aussehen, hat halt mal mit der Tilestruktur und der inflexibilität des Makers diesbezüglich zum tun


Mehrere Layer
Optimal wären:
Layer unter sprites (x2)
Layer über sprites (x2)
Layer mit ner z-sortierung (teilweise überlappung, hohes Gras z.B.)

Mit ner durchdachten Kollisionsmap und so ner Layer-einstellung kommt man grafisch recht weit

Steuerung:

Frei einstellbare Tasten

Standardeinstellungen um gewisse Aktionen/Menüs anzusteuern
Kommt drauf an was man hat, mit nem Maker ist es allerdings derzeit recht schwer mit shift in nen Rennmodus zu wechseln und mit nem Druck auf I das Inventar zu öffnen.
Die Sachen sind Gamedesgintechnisch so ziemlich 0815, aber essentiell um ne gute Kontrolle zu ermöglichen
Natürlich muss es ne Möglichkeit geben das abzuschalten bzw. DInge gut ansteuerbar zu machen.

Sonstiges:

Zufallsgenerator für Items:
KA ob umsetzbar, hängt. vmtl stark von der Datenbankstruktur ab, aber das Feature wär (wenn man ne gute idee hat wie mans umsetzbar macht) für jegliches RPG echt nice

[Cornix]

Okay, da ist eine Menge dabei, aber ich versuche einmal zu allem was zu sagen.

Einstellung für Auflösung/Pixel-Zoom/Tilegrößen
Auflösung (nativ) heißt dass man ne Auswahl hat um die gängisten Auflösungen auszuwählen
Zoom (ob man die grafiken mit 100%, 200%, 300% usw. scharf darstellen lässt)
Tilegrößen, würde 8x8, 16x16, 32x32, 48x48 und 64x64 als grundeinstellung vorgeben... kaum wer verwendet andere Tilegrößen, es sei denn für iso Grafiken.

(z.B. 640x360 300% 32x32 Tile Einstellung und man kommt auf ne State-of-the-art HD Aufösung, bzw. mit 200% kommt man auf 720p)

...

Ich persönlich würde es dem Entwickler erlauben jede beliebige Fenstergröße zu verwenden. Man kann auch gerne 777x123 benutzen wenn man es wirklich mag.
Allerdings muss eine gängige Fenstergröße benutzt werden wenn das Spiel im Fullscreen gespielt werden soll, andernfalls macht die Grafikkarte das nicht mit.

Zoomen soll sowieso generell möglich sein. Ich denke im Moment an eine Art von Viewports, welche der Entwickler definieren kann. Zum Beispiel 1 Viewport für die Karte mit den Kartenobjekten (Held, NPC's, Bäume, etc), ein Viewport für das Interface, vielleicht ein weiterer Viewport für Dialogfenster oder ähnliches.
Jeder von diesen Viewports könnte separat gezoomt, gescrollt, rotiert oder andersweitig beeinflusst werden.

Z-Sortierung von sprites anhand grundfläche/unterkante

...

(wenn man sprites hat die größer als ein tile sind, bzw. höher stehen, unter tiefer stehenden sprites angezeigt werden - eliminirt ziemlich viel clipping)

...

Das verwende ich in meiner RPG-Engine derzeit sowieso.
Allerdings würde ich dem Entwickler wohl auch die Möglichkeit geben auf die Sortierung Einfluss zu nehmen. Auch wenn ich derzeit noch keine genaue Vorstellung habe, wie es im Detail aussehen könnte.

Zoom (um bei gewissen Events näher ins Geschehen zu Zoomen)
Screenshake (Um bei gewissen Events den Screen schütteln zu lassen)

...

Lässt sich leicht machen, wie ich schon vorher angesprochen habe. Einen Screenshake-Effekt man durch schnelles scrollen eines Viewports nach Links und Rechts.

Einstellung für die Zentrierung des Hauptcharakters (um bei größeren Figuren/Missbrauch des Programms bezüglich Genre mehr Kontrolle zu geben)

...

Ich glaube mal eine Programmierbare Kamera wäre sowieso ganz förderlich.
Immerhin sollten auch andere Genres als nur RPG's möglich sein.

Feinabstimmung für Geh/Laufgeschwindigkeiten

...

(Frameanzahl & Schrittgeschwindigkeit)

Standardmäßige 8-Richtungsunterstützung für Chars oder zumindest für den Hauptcharakter, für NPCs macht mans meistens aufwandtechnisch eh nicht (für gehen/laufen, 4 richtungen sind für ne Basis OK, fürn Hauptchar isses vor allem bei Action RPGs hakelig, falls nur 4 Richtungen vorhanden sind)

...

Derzeit tendiere ich zu freier 360° Bewegung von Objekten mit Geschwindigkeitsangabe als Gleitkommazahl. Sprich: Die Bewegung setzt sich aus einem Winkel und einer Geschwindigkeit zusammen.
Dieses Bewegungssystem funktioniert allerdings nur bedingt, je nachdem wie das Kollisionssystem aufgebaut.

Animationseditor

...

für jegliche Spritesheets (mit Angabe der ms/frame):
bestenfalls zum selber einstellen welche Frames für welche Animationen verwendet werden können - quasi dass man jede Animation für jede RIchtung programmieren kann und dann darauf zugreifen

Gut wäre hierbei jede Animation mit nem Sound verknüpfen zu können, für den man auch nen Offset einstellen kann, wann er abgespielt wird (würd ne gewisse Standard-Sounddynamik bringen)

...

Ich kann einmal ansprechen wie ich Animationen derzeit in meiner RPG-Engine löse (in Java programmiert).
Eine Animation ist eine Hintereinanderreihung von Kommandos. Zwischen jedem Kommando kann eine Wartezeit definiert werden bis das nächste Kommando ausgeführt wird. Mögliche Kommandos sind das setzen des Ausschnitts von der Textur, das setzen eines Ankerpunktes für den Ausschnitt (eine Bewegung des Sprites relativ zur Position des Objektes); das Skalieren, Rotieren und Färben des Sprites; das Abspielen von Sounds, das Wechseln der verwendeten Textur / dem verwendeten Shader; horizontale und vertikale Spiegelung des Bildausschnitts aktivieren / deaktivieren, und noch einige weitere kleine Spielereien.
Soetwas ermöglicht sehr flexible und mächtige Animationen; bedeutet allerdings auch ein klein wenig Aufwand für den Entwickler beim Erstellen von Animationen.

Um ein Beispiel zu nennen, in Pseudo-Code könnte eine Animation wie folgt aussehen:

Code:

// Setze die zu verwendende Textur (Bilddatei) für den Sprite
setzeTextur ( "Graphics/Charsets/MeinHeld.png" )
// Setze den Ausschnitt, welcher aus der Textur von diesem Sprite angezeigt werden soll. Werte sind x, y, breite und höhe in pixeln
setzeAusschnitt ( 16, 16, 32, 48 ) 
// Die Breite des Sprites wird um diesen Faktor gestreckt
setzeSkalierungX( 2.5 )
setzeSkalierungY( 2.5 )
// Warte diese Anzahl von Frames bis zur Ausführung des nächsten Kommandos
wait ( 5 )
setzeAusschnitt ( 16, 64, 32, 48 )
wait ( 5 )
setzeAusschnitt ( 16, 112, 32, 48 )
wait ( 5 )
setzeAusschnitt ( 16, 160, 32, 48 )
wait ( 5 )

Das könnte zum Beispiel eine simple Laufanimation mit 4 Einzelbildern sein. Es wird jeweils 5 Frames zwischen jedem Einzelbild gewartet, bis das nächste angezeigt wird.

Aber das ist natürlich nur das System, welches ich derzeit in meinem eigenen Hauptprojekt verwende. (Es ist sogar noch ein wenig komplexer als das, aber lassen wir es ersteinmal dabei)
Für einen Maker wäre dies vielleicht sogar schon ein wenig zu kompliziert. Man muss dabei bedenken, dass die Zielgruppe nicht ausgebildete Programmierer oder studierte Informatiker sind, es soll von jedem einfachen Ottonormalverbraucher verstanden und benutzt werden können.
Es muss simpel, und dennoch mächtig sein.

Was ich dachte, war vielleicht gewisse, oft vorkommende, Animationstypen schon als Templates bereit zu stellen, aber auf der anderen Seite zu erlauben eigene Animationen zu definieren.
Aber darüber müsste ich mir noch viele weitere Gedanken machen, bis ich das konkretisieren könnte.

Bewegung losgelöst vom Tilegrid

...

Pixelmovement ist nett, im Normalfall ist es für ein RPG allerdings genug 1/2 oder 1/4 Tile Größen für Bewegungen zu haben.
Heißt ne einstellung für schrittweiten wär optimal
Für gehen/Rennen braucht man vmtl verschiedene Schrittweiten (Rennschritte sind weiter und das muss auch in der Engine so vorgesehen werden um die Geschwindigkeit rüberzubringen)
Vor allem wenn man die Frameanzahl fürs und die Relativbewegung des Charakters abstimmt, würden schrittweiten helfen.

Beispiele aus der Praxis:
tilegröße 16x16
ich hab ne schrittweit von 8 pixel und 8 frames für den char, heißt jeden pixel wird n eigener frame angezeigt -> superflüssige Animation, gute kontrolle
beim rennen: selbe schrittweite 16 pixel, 8 frames (4 frames linker fuß, 4 frames rechter fuß) char nimmt immer 2 schritte, falls nur ein schritt möglich ist, wird nur die erste hälfte der frames angezeigt)

ich hab ne schrittweit von 16 pixel und 3 frames für den char -> superhakelige Animation, wenig kontrolle
ich hab ne schrittweite von 8 pixel und 3 frames für den char -> hakelige animation, jedoch noch verschmerzbar, gute kontrolle

...

Vor allem bei anderen Genres wie einem Jump-n-Run würde ich eine Pixel genaue Bewegung schon befürworten.
Vielleicht kann man alternative "Modi" für die Bewegung einstellen.

Mapping:

Kollisionsmaps:

...

Passierbarkeit einstellbar via mapbarer Kollisionsmaps, statt Kolisionsabfrage im Tileset
Warum?
Man kann erstmal ne map bauen, ohne sich über Kollision Gedanken zu machen
die Kollision kann nachträglich über die Map gezeichnet werden
Sämtliche Begehbarkeitsfehler gehören der Vergangenheit an

(Für plattformen und dergleichen muss die kollisionsmap natürlich irgendwie ansteuerbar sein, damit man kollisionsblöcke sozusagen ändern kann)

Müsste natürlich verschiedene Kollisionstiles geben von welcher seite man gewisse tiles betreten kann und von welcher seite nicht (ganz praktisch, wenn man eher 3D angehauchte levels bauen will)

...

Ich persönlich würde eher einen Hybrid anstreben.
Natürlich ist es gut, wenn man Kollisionen per Hand eintragen kann um vollkommene Kontrolle zu besitzen. Bei einer gigantischen Karte mit 300 x 300 Tiles wäre das aber eine fürchterliche Arbeit.
Daher würde ich schon ein System vorschlagen, welches es erlaubt Kollisionen nach gewissen Regeln zu setzen.
Dann kann der Benutzer nocheinmal im Nachhinein von Hand dran gehen um Feinheit auszuarbeiten.

Beliebig große Tilesets

...

bzw. Falls eine standardgröße per tileset, beliebig viele tilesets verwendbar

...

Das ist so eine Sache. Grafikkarten vertragen nur Texturen bis zu einer gewissen Größe. Alles darüber hinaus wird schlichtweg nichtmehr unterstützt.
Und jede Generation von Grafikkarte verträgt eine andere maximalgröße.
Ein kleines Asus Netbook, ein Lenovo Gaming Laptop und ein selbst zusammen gestellter 2500€ Heimcomputer vertragen alle völlig unterschiedliche Maxima, dennoch würde man hoffen ein simples kleines 2D Spiel auf jedem dieser Geräte spielen zu können.

Daher würde ich eher dazu tendieren beliebig viele Tilesets gleichzeitig verwenden zu können anstatt beliebig große Sets.

Animationstiles mit beliebig vielen Frames (losgelöst vom standardtileset) und mit globaler Ansteuerung vom timing
Quasi, dass man Tileanimationen vorher zusammenbauen kann und dann setzt man so ein Animationstileobjekt. Alle laufen exakt gleich, wobei man selbe rnen Zeit/Frameoffset einstellen kann.

...

Könnte man wohl machen.

Einzeltiles/Meta Tiles

...

Mappingmäßig wäre es gut wenn man ein tileset auf einzeltiles und Meta-Objekte einstellen könnte.
Meta objekte sind einfach aus mehreren tiles zusammengesetzt.
Wenn ich jetzt nen Baum oder ein Teil Klippe im Tileset habe, will ich meistens alles hinsetzen, mit ner Einstellung diesbezüglich im Vorfeld kann man die Mappingeffizienz stark erhöhen (da ich im Tileset nur irgendwo af nen baum klicken muss und ein klick setzt alles hin, ist vor allem bei nicht Maker-Standardisierten Tilesets (sprich solche die den Grid verstecken und viele unterschiedliche tileansammlungen verwenden) von enomen Vorteil

...

Könnte man so machen, alternativ könnte man auch einfach zusammengehörige Gebilde nicht als Tileset, sondern als spezielle Kartenobjekte definieren.
Also ist ein Baum tatsächlich ein Baum. Nicht eine Ansammlung kleiner Einzeltiles.
Man könnte dann im Editor nach freiem Belieben, und ohne Bindung an das Tileraster Kartenobjekte verteilen.

Advanced Auto Tile System:

...

Automatisierte Texturtiles fürn Boden wie sie der Maker hat sind ja ganz nice, ist aber sehr basic
z.B. Fehlt die Möglichkeit Variationen für Ecken und gerade Tiles vom Programm automatisch stezen zu lassen.
Stell dir mal vor du hast fürn Autotile verschiedene Stücke für gerade tiles und Ecken und das Programm setzt diese Automatisch per Zufall - Mappingeffizienz und Mappinggeschwindigkeit sowie Mapstruktur werden mit ner kleinen Änderung am programm besser

...

Autotiles sind eine komplizierte Angelegenheit. Die Autotiles wie sie im Maker sind sind schon ein ganzes Stückchen Leistung. Immerhin besitzt jedes einzelne von ihnen 256 verschiedene Variationen.
Wenn du allerdings nur zufällig ausgewählte Versionen willst, so ist das kein Problem.
Wenn du aber kompliziertere Formen von Autotiles möchtest, zum Beispiel, welche die mehr als nur die 8 direkt umliegenden Tiles betrachten, dann wird das schon sehr aufwendig.

Riesenvorteil für das System wäre auch eigene Autotile Einstellungen für Klippen, da Klippen immer sehr Zeitintensiv zum Mappen sind

...

Ich weis nicht wie gut das aussehen würde.
Natürlich, bei Klippen wie im RPG-Maker RTP wäre das sehr simpel. Bei komplizierteren Grafikstilen könnte das aber möglicherweise nicht funktionieren.

Ebenfalls nice wäre es, wenn man größere Ecken für gewisse Texturen setzen könnte

...

Ich weis leider nicht ganz was du damit meinst.

Mehrere Layer

...

Optimal wären:
Layer unter sprites (x2)
Layer über sprites (x2)
Layer mit ner z-sortierung (teilweise überlappung, hohes Gras z.B.)

Mit ner durchdachten Kollisionsmap und so ner Layer-einstellung kommt man grafisch recht weit

...

Das würde dem Viewport-Konzept entsprechen was ich vorher angesprochen habe.
Mit beliebig vielen Viewports könnte man soetwas relativ leicht lösen.

Frei einstellbare Tasten

...

Standardeinstellungen um gewisse Aktionen/Menüs anzusteuern
Kommt drauf an was man hat, mit nem Maker ist es allerdings derzeit recht schwer mit shift in nen Rennmodus zu wechseln und mit nem Druck auf I das Inventar zu öffnen.
Die Sachen sind Gamedesgintechnisch so ziemlich 0815, aber essentiell um ne gute Kontrolle zu ermöglichen
Natürlich muss es ne Möglichkeit geben das abzuschalten bzw. DInge gut ansteuerbar zu machen.

...

Ich würde generell alle Tasten der Tastatur, die Maus und alle Arten von Joysticks und anderen Peripheriegeräten erlauben.

Zufallsgenerator für Items:
KA ob umsetzbar, hängt. vmtl stark von der Datenbankstruktur ab, aber das Feature wär (wenn man ne gute idee hat wie mans umsetzbar macht) für jegliches RPG echt nice

...

Wäre auch ziemlich simpel.

Danke soweit für die Beteiligung. Sehr hilfreich.

[Cyangmou]

Einfach und mächtig ist immer gut, ja.
Ich kann z.B. nicht programmieren, ich hab nur ne theoretische Idee davon wies geht und was machbar ist.
Einfach und mächtig heißt fürn Programmierer meist enormer Designaufwand und extremes Know-How übers Subjekt vonnöten =)

Aber auch n paar zusätzliche Features die man einstellen kann, aber nicht muss, um das ganze dann noch interessanter für Bastler zu gestalten ist denk ich mal nicht verkehrt wenn alles soweit steht.

Zu den Autotiles...

ja der Maker macht viel richtig, wenns drum geht ne platte textur auf den Boden zu setzen.

Würd gern wissen wie du bei autotiles auf 256 Variationen kommst.
soweit ich weiß hast du ohne komplettes texturteil 4 innere Ecken, 4 äußere Ecken und 4 gerade, macht 12 tiles (14 mit positiv und negativ textur).

Aber die Anzahl tut eh nichts zur Sache.

Ich dacht mehr dran dass man für eine Tileart mehrere Varianten hinterlegen kann.

Heißt quasi, wenn man ne Bodentextur hat und von dieser 5 Varianten und man wählt dieses Tile aus und setzt es auf die Map dann wird einfach per Zufallsfaktor eines der hinterlegten Tiles gesetzt.
Perfekt wäre wenn man den Zufallsfaktor dann selber mit ner Prozentangabe einstellen könnte (und diese Einstellungen auch speichern und laden könnte)

Zum Beispiel mappen wir Gras, wir haben 5 16x16 Variationen, einige Texturen, einige Texturdetails
Gras V1, Gras V2, kleine Blumen V1, kleine Blumen V2, große Blumen
dann setzen wir hier % wie das Tile gesetzt wird
30%,30%, 15%, 15%, 10%

Und dann ziehen wir über n 10x10 Feld diese Textur, dann sollten wir eigentlich jedes Mal mit ner sehr detaillierten Textur ändern, die jedes mal anders aussieht, da der Zufallsfaktor viel Arbeit abnimmt.
Heißt in 10 Sekunden mappen wir etwas schönes und detailliertes für das wir sonst an die 5-10 Minuten sitzen.

Durch Einstellungen der Variationen können wir auch ne Wiese mit wenig Blumen und ne Wiese mit vielen Blumen relativ flott darstellen, da wir lediglich eine Einstellungändern müssen.
(Wird dann vmtl Einstellungsdateien oder sowas brauche, wo die Werte gespeichert werden)

Wir setzen noch einen drauf und arbeiten mit n paar zusätzlichen Metatiles (32x32 texturstücke, die nur in dieser Anordnung vorkommen - größere wie 48x48 gehen natürlich auch noch, aber man kann alles ausreizen...)
Heißt erstmal müssen wir bei einer Textur rausfinden wie viel Platz für Metatiles ist, und dann, sofern Platz ist und nach einer Eingabe für Häufigkeit werden random Metas gesetzt

sieht dann so aus:


Die dunkelgrauen sind dann Metas, sowohl für die normalen, als auch für die Metas sind Variationen vorgesehen.

Heißt wir kriegen noch mehr Variation rein gleichbleibendem Mappingaufwand,
Plus metas sind noch für ne andre sache wichtig (heißt das system bräuchten wir noch) - gleich mehr dazu


(Mach dir hie rden Anhang auf um mitzukommen)
Nun gehen wir nen Schritt weiter und arbeiten mit ner klassischen Autotile Textur (G1)
Für dieses Set gibt es wieder beliebig viele Variationen (G2)

Mappingschema ist das selbe wie beim Maker
Der Zufallsfaktor haut nur wieder zufällige Variationen rein
(Beispiel G3)

Nun packen wir wieder das meta Prinzip an - in diesem Falle große Ecken (G4)
Große Ecken für Texturen haben nebst Kantenvariation und Eckenvariation den Vorteil, dass sie das Raster komplett aufbrechen
heißt, dass der Zufallsgenerator random große Ecken verpflanzt, falls möglich und falls nicht zu viele andre große Ecken in der Nähe sind.

Mappingaufwand wär immer noch gleich wie mit nem normalen Maker.
Ein paar Adjustierungen in nem normalen Tilecode
Mit der Methode brauchen wir nur mehr Grafik, aber die macht man einmal und edits sind verhältnismäßig leicht anzufertigen.
Das Resultat sieht allerdings eher wie n großes Bild aus und nicht wie ne ständig kopierte Tileansammlung
Je mehr Variationen man hat, desto besser wird natürlich das Ergebnis.
Ha tman keine Variation, kann mans einstellen oder ne idente Textur einfach 5x abspeichern und iwann mal Variationen nachliefern

Anhang 19357

Wesentlich komplizierter wirds bei Klippen.
Wenn man ne Standardgrafik hat wie G5, sieht man schon dass die Höhe ausschlaggebend für die Anzahl der Ecken ist (G6, G7)
Ganz zu Schweigen von allen Verschnittvarianten von Tiles und Höhen

Heißt für ein Klippenautotile müssten wir nem Tile unbedingt ne Z-information mitgeben (trotz 2D Map)

Programmiert man allerdings 1x ne routine für alle Fälle für eine Höhe und geht davon aus, dass sich die dunkelgrauen Fronttiles bei ner höheren z-Höhe lediglich vermehren (Einstellung von Z) müsste das auch funktionieren.

Heißt man müsste eigentlich mit ner einzelnen Höhe schon gut mappen können

Als Zuckerguss:
Wenn wir nen schritt weiter und uns die Höheninformationen (z-werte) anschauen, dann müsste man eigenlich mit der Tileinformation (Ecke, Gerade, ...) und der Differenz genau errechnen können was für eine Art von Tile auf dem Raster gezeigt werden muss.

Heißt man könnte mit so einer Art von System in sekundenschnelle perspektivisch korrekte Klippen mappen, wenn man erst einmal ein tileset ausgearbeitet hat, dass alle Tilevarianten abdeckt.

Und ums zu perfektionieren:
(natürlich kann man dann auch nochmal nen Schritt weitergehen und große Klippenkanten bauen um ne perfekte Vielfalt zu haben =)

Und wenn man Texturen und Klippen schnell mappen kann, brauchts eig. eh nur noch Details

Die sind meist eh relativ schnell gesetzt
Dann baut man ma richtig geile Maps in 10 minuten, für die man sonst 2-3 Stunden sitzt.v


Wenn interessiert bist sowas für die Allgemeinheit oder grad mal testweise umzusetzen, würd ich mir vmtl sogar die Zeit nehmen und dafür Tiles fürn Testtileset bauen (oder von nem etablierten Stil z.B. Mack&Blue alle Varianten für ne Textur und ne Klippe zu editieren)


Kommen wir nochmal zurück aufs setzen von Objekten:
Objekte als quasi bild setzen funktioniert auch.
Wenn man allerdings Häuser mit Türen setzt usw. (Die pixelgenau am Teleport/Tileraster ausgerichtet sein sollten) sollte man zumindest nen Button für ne Rasterfunktion haben, die diese Grafiken am Tileset ausrichtet.

[Kelven]

@Cornix
Wenn der GUI-Code mächtig genug ist, dann ist eine höhere Programmiersprache wohl wirklich nicht nötig, aber wie würdest du den Code denn gestalten, um diese Mächtigkeit zu erreichen?

Falls jemand wirklich bereit ist eine höhere Programmiersprache zu lernen, dann braucht er auch keinen Maker mehr, das ist für solch eine Person nur eine Zeitverschwendung.

...

Das finde ich nicht, denn dieser jemand müsste ja Engine und Editor selbst schreiben. Dort fließt eine Menge Zeit rein, die mancher Entwickler lieber in das Spiel stecken möchte. Außerdem braucht man die Programmiersprache nicht komplett lernen. Eine "unsaubere" Lösung, bei der man die Sprache nur als Hilfsmittel benutzt, sieht für den Spieler von außen genauso wie eine "saubere" aus.

Von den Lizenzprobleme mit MP3s hab ich auch schon gehört. OGG ist ja eigentlich bei gleicher Qualität sowieso kleiner, meine ich, nur war das nicht so, dass die Datei erst komplett in den Speicher geladen werden muss? Ich meine, dass es beim XP Lags gibt, wenn eine OGG-Datei das erste Mal gespielt wird.

[Corti]

Mal abseits von Tilegrößen etc. ~ ich mag die Idee keine Scriptsprache zu geben, dafür umfangreichere Klickwerkzeuge.

ich hatte in meinem 2k3 - Spiel schon vor DynRPG viele Kampfmechaniken eingebaut, die ich vorher noch in keinem Makerspiel gesehen hatte. Das ging auch, war aber umständlich, dabei gibt es zwei Konzepte.

- DynRPG: Die Callbacks passieren oft, meine Lieblingscallbacks in jedem Frame, bzw. mehrere in jedem Frame, weil ich z.B. Helden- und Monsterfähigkeiten in ihrem Zeichenzyklus erledige, da dies der Callback ist, der genau zu ihnen gehört.
- MakerEventcode: Die EventPages im Kampf sind sehr grobschlächtig.Zuerst einmal muss man sich eine Art Framework basteln, um überhaupt Custommechaniken einbauen zu können. Dazu gehört eine Eventseitenstruktur in jeder Monstergroup und dann entsprechender Code, um aus "Welches Ziel wurde ausgewählt?" und "Wieviel Mana wurde verbraucht?" zu schlussfolgern, was im Kampf passiert ist. Schlussfolgern, ich will nicht schätzen müssen, was die Helden in meinem Spiel gemacht haben!

Hier mein Ansatz:
Events wenn Dinge passieren.

• Betrete die Map -> OnMapEntered
• Verlasse die Map -> OnMapLeft
• Held greift an -> OnHeroAction
• Held ist damit fertig -> OnHeroActionDone
• Held plötzlich tot -> OnHeroDead

Und dann als Parameter, lokale Variable, sowas in der Art, Informationen was genau passiert ist. Wer hat angegriffen, wer wurde angegriffen und womit und hat es kritisch getroffen, hat es verfehlt?
Auf vielen Makermaps ist das Konstrukt ParallelProcess->tu was ->erase. Was der Entwickler will ist etwas beim Betreten der Map zu tun. Die Struktur wird jedes mal neu gebaut. Event an die Map anhängen, tatarataaa.

[Cornix]

@Cornix
Wenn der GUI-Code mächtig genug ist, dann ist eine höhere Programmiersprache wohl wirklich nicht nötig, aber wie würdest du den Code denn gestalten, um diese Mächtigkeit zu erreichen?

...

Das steht noch in Frage ob >ich< dazu in der Lage wäre.
Ganz allgemein würde es bereits ausreichen alle Arten von Attributen mit Get- und Set-Methoden zur Verfügung zu stellen. Dazu einen Variablen-Manager mit dem man alle Arten von Objekten in Spiel referenzieren kann und dann einfache Datenstrukturen wie Arrays und Collections, vielleicht auch noch Sortierbare Listen und definitiv Hashtables die von dem Benutzer verwendet werden können.
Das ganze in einen freundlichen und dokumentierten GUI-Code eingebaut, welcher sich darum kümmert alle illegalen Eingaben von vornherein abzufangen.

Das finde ich nicht, denn dieser jemand müsste ja Engine und Editor selbst schreiben. Dort fließt eine Menge Zeit rein, die mancher Entwickler lieber in das Spiel stecken möchte. Außerdem braucht man die Programmiersprache nicht komplett lernen. Eine "unsaubere" Lösung, bei der man die Sprache nur als Hilfsmittel benutzt, sieht für den Spieler von außen genauso wie eine "saubere" aus.

...

Niemand ist heutzutage dazu gezwungen eine Engine zu bauen. Soetwas bekommt man inzwischen überall im Internet als Template.
Man kann auch immer die eigentliche Spielengine hinter dem Maker direkt als Bibliothek mit ausführlicher API veröffentlichen. Dann brauch sich niemand der wirklich programmieren kann mit etwas so klumpen wie dem Maker beschäftigen.

Von den Lizenzprobleme mit MP3s hab ich auch schon gehört. OGG ist ja eigentlich bei gleicher Qualität sowieso kleiner, meine ich, nur war das nicht so, dass die Datei erst komplett in den Speicher geladen werden muss? Ich meine, dass es beim XP Lags gibt, wenn eine OGG-Datei das erste Mal gespielt wird.

...

Wer sagt, dass man die Dateien erst laden sollte wenn man sie abspielen will? Wenn kommerzielle Spiele das tun würden wäre der Spielspaß gegen null.

[Daen vom Clan]

Meine Welt wäre alleine durch eine "Suchen" und "Ersetzen"-Funktion schon ein ganzes Stück heller.
Aber Gerüchte besagen da ist was Großartiges in der Mache...! *Richtung Grufty schiel*