Archiv verlassen und diese Seite im Standarddesign anzeigen : Was wäre euch wichtig an dem "perfekten" Maker?
Hallo zusammen.
Ich war vor kurzem dabei mit dem Gedanken zu spielen, wie es wohl wäre, eine eigene Maker-Engine zu programmieren.
Ich hatte so ein wenig nachgedacht und geplant; aber letzten Endes ist das doch eine recht komplizierte Angelegenheit es jedem recht zu machen.
Daher wollte ich einmal sehen was der Rest der Community wohl dazu zu sagen hat.
Also: Was wäre euch wichtig an dem "perfekten" Maker? Was für Arten von Features müssen unbedingt vorhanden sein? Was wäre Nice-To-Have?
Ich hoffe auf zahlreiche Beteiligung.
Unbedingt:
- eine höhere Programmiersprache hinter dem Klick-Editor, damit man nicht auf den Event-Code angewiesen ist (also so wie auf den neuen Makern)
- Unterstützung gängiger Musikformate wie MP3 und OGG
- 24-bit Farben + Alphatransparenz
- ein Map-Editor, der mindestens so viele Layer hat wie auf dem XP
Wäre schön:
- die Charsets bewegen sich Pixel für Pixel, anstelle von Tile für Tile
- der Maker sollte nicht zu stark auf die alten SNES-RPGs ausgerichtet sein, es sollte auch möglich sein, Action-Adventures und -Rollenspiele zu entwickeln
- unterschiedliche Auflösungen, Wahl zwischen 16x16 und 32x32 Tiles
- beliebig große Charsets mit angepasster Kollisionsbox
- Pathfinding bei "Step toward hero"-Kommando
- das Standardsystem (also Menü, Charakter-Management und KS) sollte variabler sein
Objektorientierung. Furchtbar ist es, Charsets zu kopieren und für Posen den Grafik wechseln zu müssen und mit Eventseiten und dann jedes mal das Event wieder aus der Liste suchen.
Geil wären "Charakter X"-Objekte und enen gibt man dann die Möglichkeit Posen anzunehmen, Animationen abzuspielen, sie hinlaufen zu lassen etc.
Unbedingt:
- eine höhere Programmiersprache hinter dem Klick-Editor, damit man nicht auf den Event-Code angewiesen ist (also so wie auf den neuen Makern)
- Unterstützung gängiger Musikformate wie MP3 und OGG
- 24-bit Farben + Alphatransparenz
- ein Map-Editor, der mindestens so viele Layer hat wie auf dem XP
Wäre schön:
- die Charsets bewegen sich Pixel für Pixel, anstelle von Tile für Tile
- der Maker sollte nicht zu stark auf die alten SNES-RPGs ausgerichtet sein, es sollte auch möglich sein, Action-Adventures und -Rollenspiele zu entwickeln
- unterschiedliche Auflösungen, Wahl zwischen 16x16 und 32x32 Tiles
- beliebig große Charsets mit angepasster Kollisionsbox
- Pathfinding bei "Step toward hero"-Kommando
- das Standardsystem (also Menü, Charakter-Management und KS) sollte variabler sein
Davon ist fast alles doch auf dem VX/Ace möglich.. ob Pixelgenau oder Kollisionsbox, almost everything. Hört sich für mich nur danach an, als ob du nen 2k Ace haben möchtest.
Genauso auf dem XP, aber Cornix hat ja auch nicht gefragt, ob wir mit den Makern unzufrieden sind.
Danke soweit für die Beteiligung, ich versuche einmal auf die genannten Punkte einzugehen so gut ich kann:
Unbedingt:
- eine höhere Programmiersprache hinter dem Klick-Editor, damit man nicht auf den Event-Code angewiesen ist (also so wie auf den neuen Makern)
Soetwas würde ich persönlich nicht gut finden.
Der Grund dafür klingt vielleicht ein wenig esoterisch, aber meiner Meinung nach spaltet soetwas nur die Community.
Die einen bleiben beim GUI-Code und wollen keine Programmiersprache lernen um das Programm zu verwenden; die anderen stürzen sich nur auf die Programmiersprache, da der GUI-Code unnötig wird sobald man eine Sprache im Hintergrund bedienen kann.
Dadurch entstehen zwei Lager, und beide bringen Resourcen und Systeme raus, welche zueinander nur bedingt, oder garnicht kompatibel sind.
Anstatt dessen würde ich persönlich eher versuchen den GUI-Code so ausgiebig und mächtig zu machen wie möglich, und dennoch leicht damit zu arbeiten.
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.
- Unterstützung gängiger Musikformate wie MP3 und OGG
MP3 ist ein Problem wegen den Lizenzen. In den letzten Jahren hat sich die Situation in diesem Bereich deutlich zugespitzt:
http://de.wikipedia.org/wiki/MP3#Patente_und_Lizenzstreitigkeiten
OGG ist jedoch ein super Format; perfekt geeignet für soetwas wie Videospiele.
Auch Wave und Midi sind leicht umzusetzen.
- 24-bit Farben + Alphatransparenz
Das ist vollkommen außer Frage. Das wäre das mindeste auf das ich mich einlassen würde.
- ein Map-Editor, der mindestens so viele Layer hat wie auf dem XP
Es ist absolut kein Problem beliebig viele Layer zu erlauben. Es ist nur so, dass man die Performance des ganzen opimieren kann, wenn man eine feste Obergrenze an Layern hat.
Ich würde aber schon sagen, dass 3 - 5 Layer für so ziemlich jedes Spiel mehr als ausreichend sein sollten.
- die Charsets bewegen sich Pixel für Pixel, anstelle von Tile für Tile
Das ist auch kein Problem, benötigt jedoch ein Kollisionssystem, welches für den Entwickler leicht zu verwenden und zu bearbeiten ist. Eine Pixel genaue Bewegung mit dem Tile-basierten Kollisionssystem ist nicht sehr schön anzusehen.
- der Maker sollte nicht zu stark auf die alten SNES-RPGs ausgerichtet sein, es sollte auch möglich sein, Action-Adventures und -Rollenspiele zu entwickeln
Ich dachte auch daran 2D Spiele allgemein damit erstellen zu können, nicht nur RPG's.
Also ganz besonders auch Strategiespiele, Dungeon-Crawler, Tower Defense Games, Jump-n-Runs, etc.
- unterschiedliche Auflösungen, Wahl zwischen 16x16 und 32x32 Tiles
Ich denke ich würde absolut beliebige Tilegrößen erlauben. Auch 13 x 17 oder dergleichen. Technisch gesehen macht das überhaupt keinen Unterschied.
- Pathfinding bei "Step toward hero"-Kommando
Das ist eine recht komplizierte Sache. Bei einfacher Tile-basierter Bewegung und Kollision ist Pathfinding sehr simpel und schnell implementiert.
Wenn nun aber kompliziertere Bewegungssysteme und Kollisionsabfragen dazu kommen wird das Pathfinding entsprechend auch schwieriger.
Wenn nun alle Charaktere beliebige Kollisionsboxen haben können, und sich Pixel genau bewegen, wird dieses relativ simple Problem sehr schnell zu einem schwierigen Problem.
- das Standardsystem (also Menü, Charakter-Management und KS) sollte variabler sein
Dafür bin ich auch; es ist nur nicht so einfach sich ein gutes System zu überlegen, welches erstens flexibel genug ist, aber zweitens simpel genug, damit man sich schnell und einfach einarbeiten kann.
Objektorientierung. Furchtbar ist es, Charsets zu kopieren und für Posen den Grafik wechseln zu müssen und mit Eventseiten und dann jedes mal das Event wieder aus der Liste suchen.
Geil wären "Charakter X"-Objekte und enen gibt man dann die Möglichkeit Posen anzunehmen, Animationen abzuspielen, sie hinlaufen zu lassen etc.
Ja, es war auch meine Idee alles sehr "objektorientiert" zu halten.
Vor allem was Animationen angeht, so würde ich wahrscheinlich versuchen das 3D Modell Prinzip zu verwenden. Also, dass der Entwickler beliebig viele Animationen in ein Set zusammenpacken kann; dann einem Sprite solch ein Set zuweist, und diesen Sprite dann Animationen aus dem Set abspielen lassen kann.
Wie kompliziert oder simpel man soetwas dann implementiert ist noch etwas schwammig, von der groben Idee her finde ich dies aber simpel genug um es schnell verstehen zu können, und flexibel genug um auch kompliziertere Spiele einfach erstellen zu können.
Danke soweit für die Beteiligung, ich hoffe es finden sich noch einige weitere Meinungen.
Cyangmou
30.12.2013, 23:56
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
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:
// 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
31.12.2013, 02:25
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:
19358
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
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.
@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.
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
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
31.12.2013, 11:30
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*
Luthandorius2
31.12.2013, 11:46
Der Grund dafür klingt vielleicht ein wenig esoterisch, aber meiner Meinung nach spaltet soetwas nur die Community.
Die einen bleiben beim GUI-Code und wollen keine Programmiersprache lernen um das Programm zu verwenden; die anderen stürzen sich nur auf die Programmiersprache, da der GUI-Code unnötig wird sobald man eine Sprache im Hintergrund bedienen kann.
Dadurch entstehen zwei Lager, und beide bringen Resourcen und Systeme raus, welche zueinander nur bedingt, oder garnicht kompatibel sind.Sowas haben wir doch jetzt schon mit den verschiedenen Makerversionen und den Leuten die gegeneinander arbeiten. Ist eher ein Problem der Community. Glaube kaum, dass es in der englischsprachigen Community Probleme geben würde - da sind einfach viel mehr Leute, die englisch sprechen. Demnach auch mehr Resourcen.
Und Kelven hat ja als Grund auch noch genannt:
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.Es kann sicher auch vorkommen, dass es zwischen den zwei Extremen("komplett nur mit Programmiersprache, aber Maker, damit keine Engin und Editor selber geschrieben werden muss" vs. "komplett ohne Programmiersprache") auch Leute gibt, die sich vielleicht nur bestimmte Sachen verfeinern möchten und dazu sich ein Skript ziehen oder selber was schreiben(oder Skript ziehen + selber etwas verfeinern).
Denen würden natürlich Einschränkungen dann nicht helfen(gar keine Programmiersprache vs. sie sollen komplett alles in Programmiersprache machen).
@Cornix
Niemand ist heutzutage dazu gezwungen eine Engine zu bauen. Soetwas bekommt man inzwischen überall im Internet als Template.
Aber auch auf die speziellen Bedürfnisse eines typischen Makerspiels zugeschnitten? Weißt du, ich sehe das immer aus der Perspektive eines Entwicklers, der mehr Interesse an der Entwicklung als der Programmierung hat, aber trotzdem ein möglichst mächtiges Werkzeug haben möchte, bei dem ich nicht zu viele Umwege gehen muss, um ans Ziel zu kommen. Ein typisches Problem der alten Maker ist z. B. dass es keine richtigen Arrays gibt und dass man Pictures außer mit Cherrys Patch nicht direkt über eine Variable referenzieren kann. Beim XP kann man auch ohne tiefere Ruby-Kenntnisse die Methode show von Game_Pictures aufrufen und als ID eine Variable nehmen.
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.
Das kann ich dir nicht sagen. Ich hab nur mal gehört, dass es beim XP Lags geben soll, wenn man eine OGG als Hintergrundmusik wählt. Was auch stimmt, hab es mal eben getestet. Ich weiß natürlich nicht, ob das am XP oder der OGG liegt.
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).
Wenn man ein Tile platziert wird dessen Grafik ermittelt anhand der 8 Tiles, welche es umgeben.
Je nachdem welche von den 8 Tiles drum herum den gleichen Tile-Typen hat haben wir eine andere Situation.
Ein benachbartes Tile kann entweder von dem gleichen Typen sein, oder von einem anderen.
Das bedeutet, dass wir für jedes Tile einen von zwei Zuständen haben (Gleich / Ungleich). Und außerdem 8 benachbarte Tiles.
Jede Kombination von Zuständen dieser acht Tiles ist eine andere Situation für unser zu bestimmendes Tile.
Dementsprechend berechnet sich die Anzahl der Situation als 2 ^ 8 == 256.
Es werden im Maker zwar keine 256 verschiedene Varianten benutzt (sondern nur 48) aber das Potential dafür ist da.
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*
Tut mir leid, aber ich verstehe nicht ganz worauf du hinaus willst.
Was genau würdest du gerne im Maker suchen und ersetzen? Textzeilen?
@Cornix
Aber auch auf die speziellen Bedürfnisse eines typischen Makerspiels zugeschnitten? Weißt du, ich sehe das immer aus der Perspektive eines Entwicklers, der mehr Interesse an der Entwicklung als der Programmierung hat, aber trotzdem ein möglichst mächtiges Werkzeug haben möchte, bei dem ich nicht zu viele Umwege gehen muss, um ans Ziel zu kommen. Ein typisches Problem der alten Maker ist z. B. dass es keine richtigen Arrays gibt und dass man Pictures außer mit Cherrys Patch nicht direkt über eine Variable referenzieren kann. Beim XP kann man auch ohne tiefere Ruby-Kenntnisse die Methode show von Game_Pictures aufrufen und als ID eine Variable nehmen.
Das ist alles eine Abwägung von: Flexibilität + Macht gegen Einfache Bedienung + Schnell zu lernen.
Ein Nutzer, welcher programmieren kann, braucht nicht solch eine kindische Software zu nutzen. Diese Personen sind garnicht Teil der Zielgruppe.
Sie können sich eine beliebige fertige Engine schnappen, ihre Resourcen dort einfügen, und dann an dem Code rumwerkeln bis das gewünschte Ergebnis erzielt wurde.
Der einfache Nutzer, welcher nicht programmieren kann, hat diese Möglichkeit nicht. Für ihn bedeuten die meisten Fachwörter auch nicht viel, oder nichts konkretes. Er möchte eine Software, welche leicht zu lernen und zu verstehen ist, aber ihm trotzdem viele Möglichkeiten bietet.
Sobald man als Entwickler erlaubt eine Programmiersprache in dem Maker zu verwenden verlässt man sich zu schnell darauf. Man verliert seine Zielgruppe aus den Augen. Features werden nichtmehr unterstützt, mit der Begründung, dass die Nutzer doch einfach ein Script selbst schreiben können. Soll sich die Community doch darum kümmern.
Das Ergebnis ist aber oftmals von minderer Qualität. Oder inkompatibel mit anderen Scripten. Außerdem für einige Mitglieder der Community schnell Teufelswerk.
Ich will dem Ganzen wenn möglich ausweichen. Die Zielgruppe der Software wäre klar definiert und für diese Menschen wird dann auch das Produkt zugeschnitten.
Das kann ich dir nicht sagen. Ich hab nur mal gehört, dass es beim XP Lags geben soll, wenn man eine OGG als Hintergrundmusik wählt. Was auch stimmt, hab es mal eben getestet. Ich weiß natürlich nicht, ob das am XP oder der OGG liegt.
Ich kann es dir sagen, denn genau so wird es im XP getan.
Erst sobald versucht wird die Musik ab zu spielen wird sie von der Festplatte geladen. Sofern man also vorher noch nicht versucht hat die Musik zu spielen wurde sie auch vorher noch nicht geladen.
Wenn du bedenkst, dass diese Ladezeit nur eine oder zwei Sekunden beträgt, oder vielleicht noch weniger, ist es hoffentlich ersichtlich, dass es kein großes Problem ausmachen würde die Musik einfach bereits im Vorfeld zu laden. Dann gäbe es auch keine Probleme während des Abspielens mehr.
Daen vom Clan
31.12.2013, 14:50
Tut mir leid, aber ich verstehe nicht ganz worauf du hinaus willst.
Was genau würdest du gerne im Maker suchen und ersetzen? Textzeilen?
"Alles!"
Also in markierten Scriptzeilen bestimmte Inhalte suchen und ersetzen, beispielsweise Variablen und auch Textzeilen. :)
@Cornix
Ich denke auch, dass sich der RPG Maker und ähnliche Werkzeuge vor allem an die Entwickler richten, die nicht programmieren wollen - unabhängig davon, ob sie es können oder nicht. Aber umgehen die Maker-Entwickler das Programmieren wirklich? Der Eventcode des Makers ist im Prinzip auch eine Programmiersprache und wenn man ein komplexeres Script schreibt, dann stecken dahinter ähnliche Überlegungen wie bei einer Funktion/Methode einer höheren Programmiersprache. Natürlich ist die Gruppe, die Custom-Menüs und -Kampfsysteme baut, nur eine von mehreren und viele aus ihr machen das nur, weil sie das Standardsystem für zu eingeschränkt oder zu langweilig halten. Trotzdem solltest du nicht vergessen, dass es diese Gruppe gibt - Entwickler, die zwar nicht richtig programmieren können/wollen, aber dennoch die höchstmögliche Flexibilität bevorzugen.
@Cornix
Ich denke auch, dass sich der RPG Maker und ähnliche Werkzeuge vor allem an die Entwickler richten, die nicht programmieren wollen - unabhängig davon, ob sie es können oder nicht. Aber umgehen die Maker-Entwickler das Programmieren wirklich? Der Eventcode des Makers ist im Prinzip auch eine Programmiersprache und wenn man ein komplexeres Script schreibt, dann stecken dahinter ähnliche Überlegungen wie bei einer Funktion/Methode einer höheren Programmiersprache. Natürlich ist die Gruppe, die Custom-Menüs und -Kampfsysteme baut, nur eine von mehreren und viele aus ihr machen das nur, weil sie das Standardsystem für zu eingeschränkt oder zu langweilig halten. Trotzdem solltest du nicht vergessen, dass es diese Gruppe gibt - Entwickler, die zwar nicht richtig programmieren können/wollen, aber dennoch die höchstmögliche Flexibilität bevorzugen.
Der GUI-Code ist selbstverständlich Turing-Vollständig und damit einer Programmiersprache ebenbürtig. Das stelle ich auch keinesfalls außer Frage.
Ich habe ja vor dem GUI-Code enorme Macht zu geben und ihn noch sehr viel weiter aus zu bauen als er im Maker vorkommt. Er würde einer richtigen Programmiersprache schon sehr ähnlich werden, mit globalen und lokalen Variablen, Datenstrukturen und einer objektorientierten Datenbank im Hintergrund.
Aber ich will dennoch keine richtige Programmiersprache zur freien Verfügung stellen. Alleine schon aus technischer Sicht wäre es mir persönlich ein zu großer Aufwand, vor allem auch die Sicherheits bedenkenfalls jemand die Möglichkeiten missbraucht.
Caine Luveno
31.12.2013, 15:55
Der einfache Nutzer, welcher nicht programmieren kann, hat diese Möglichkeit nicht. Für ihn bedeuten die meisten Fachwörter auch nicht viel, oder nichts konkretes. Er möchte eine Software, welche leicht zu lernen und zu verstehen ist, aber ihm trotzdem viele Möglichkeiten bietet.
Je mehr Möglichkeiten du dem Anwender gibst desto komplizierter wird das Programm. Der RPG Maker geht da schon einen guten Mittelweg.
Der Witz ist eigentlich das der Click-Code im Prinzip eine makereigene Programmiersprache darstellt. Das Ding hat Bedingungen, Schleifen, Variablen und diverse Befehle mit denen sich wer weiß was anstellen lässt. Der große Knackpunkt ist dass der Click-Code dem Anwender die Syntax abnimmt und ihm eine grafische Ansicht und Auswahl von Funktionsparametern ermöglicht.
Das Grundproblem, die Logik des Programmierens zu erlernen, bleibt aber bestehen. Je komplexer du die GUI also gestaltest, desto mehr komplizierte logische Abläufe erden möglich und desto schwieriger wird das ganze zu bedienen.
Daher ist die Lösung des XP und VX(Ace) sehr gut. Die einfache Bedienung des 2k/2k3 bleibt erhalten, aber dank Ruby hat man die Möglichkeit das Backend "dahinter" zu verändern, falls nötig.
Features werden nichtmehr unterstützt, mit der Begründung, dass die Nutzer doch einfach ein Script selbst schreiben können. Soll sich die Community doch darum kümmern.
Das Ergebnis ist aber oftmals von minderer Qualität. Oder inkompatibel mit anderen Scripten. Außerdem für einige Mitglieder der Community schnell Teufelswerk.
Schon mal versucht im RM2k ein fremdes Menüscript einzubinden und anzupassen welches z.B. unendlich viele Itemslots bietet? Da kriegst du bedeutend mehr Inkompatiblitätsprobleme als mit einem Ruby-Script, vorallem wenn du mehrere Fremdscripte kombinieren möchtest. Das Argument zieht also eher schlecht.
Und eben da kann die Community helfen. Alleine schon wenn es darum geht zwei inkompatible Scripte zueinander kompatibel zu machen, was im RM2k per Definition, ohne das Zielprojekt selbst zu besitzen, nicht möglich ist.
Ein Nutzer, welcher programmieren kann, braucht nicht solch eine kindische Software zu nutzen. Diese Personen sind garnicht Teil der Zielgruppe.
Sie können sich eine beliebige fertige Engine schnappen, ihre Resourcen dort einfügen, und dann an dem Code rumwerkeln bis das gewünschte Ergebnis erzielt wurde.
Das was du beschreibst, Grafiken reinkloppen und am Code rumwerkeln ist genau dass was XP und VX(Ace) einem Entwickler in der einfachen Form erst ermöglichen. Eine Grafikengine bietet da deutlich weniger, nämlich nur grundlegende Funktionen welche auf beispielsweiße OpenGL oder DirectDraw(Direct3D) aufsetzen welche dir die Möglichkeit geben "zeichne Würfel an Position X und rotiere mit Geschwindigkeit S um Achse Y mit Textur C", sodass du nicht mehr 6 einzelne Quadrate selber zeichnen, positionieren und rotieren musst oder gar 12 Dreiecke, sondern in einem Aufrund deinen ganzen Würfel hast. Da ist nichts mit "Ressourcen reinkloppen" weil die Engine nicht einmal weiß was "Ressourcen" wären und dies gar nicht wissen kann.
Der RPG Maker geht da deutlich weiter. Vom komplett vorhandenem Editor, welchen dir auch keine Grafikengine (Unreal-Engine mal außen vor gelassen) bietet, will ich gar nicht anfangen.
@Topic
- Variable Auflösung (entweder mit Highres-Grafiken oder eben einer Skalierung über den sichtbaren Bildschirmbereich)
- "Echtes" Pixelmovement mit allem was dazu gehört (Pixelgenaue Kollision z.B.).
- Erweiterung der Maker-GUI, z.B. um eigene Event-Befehle für selbstgeschriebene Scripte (Plugin-System?)
Halt die Dinge welche selbst mit RGSS3 nahezu unmöglich zu realisieren sind, da man die halbe Engine umschreiben müsste.
Vielen Dank für den Beitrag, sehr hilfreich.
Je mehr Möglichkeiten du dem Anwender gibst desto komplizierter wird das Programm. Der RPG Maker geht da schon einen guten Mittelweg.
Leider kann ich nicht zustimmen.
Der Maker geht meiner Meinung nach keinen wirklichen Weg. Die meisten Features scheinen zufällig gewählt worden zu sein und lassen in meinen Augen nicht auf überhaupt irgendein Muster schließen.
Auf der einen Seite kann man Variablen als Indizes auf andere Variablen nutzen, ähnlich zu Pointern in Arrays. Auf der anderen Seite ist dieses Feature allerdings nur in wenigen Bereichen möglich, zum Beispiel nicht für Pictures oder dergleichen.
Es ist inkonsistent ohne ersichtlichen Grund. Der Aufwand zum Implementieren wäre minimal, komplexer würde das Ganze dadurch auch nicht werden.
Dann gibt es wiederum Event-Code mit gewissen Bedingungen und Aktionen, die allerdings bei weitem nicht alles abdecken, auch wenn es sehr einfach geworden wäre dies zu ermöglichen. Zum Beispiel die Event-Seiten für Kampfspezifische Events. Dort gibt es nichteinmal nahezu ausreichend Möglichkeiten Auslöser zu definieren.
Für mich schließt das alles auf Unentschlossenheit und keine ausgereifte Planung der Software.
Das Grundproblem, die Logik des Programmierens zu erlernen, bleibt aber bestehen. Je komplexer du die GUI also gestaltest, desto mehr komplizierte logische Abläufe erden möglich und desto schwieriger wird das ganze zu bedienen.
Daher ist die Lösung des XP und VX(Ace) sehr gut. Die einfache Bedienung des 2k/2k3 bleibt erhalten, aber dank Ruby hat man die Möglichkeit das Backend "dahinter" zu verändern, falls nötig.
Das Interessante daran ist, dass das Programmieren sehr sehr simpel ist sobald man das Grundgerüst und die kryptische Syntax von Programmiersprachen ignoriert.
Wie du selbst festgestellt hast ist es schon sehr einfach, auch für jemand unerfahrenen, simple Abläufe im Maker umzusetzen. Das ist bereits Programmierung.
Die Idee hinter dem GUI-Code ist es, die komplizierten Gegebenheiten von Programmiersprachen sauber und ordentlich nach Außen an den Anwender zu bringen und die Hässlichkeiten zu verstecken. Außerdem werden alle Möglichkeiten aufgelistet und kategorisiert und direkt mit einer Beschreibung versehen.
Zudem wird die Möglichkeit für Programmfehler vermindert.
Wie leicht oder kompliziert das Endprodukt wird hängt stark davon ab wie viel Mühe man sich damit macht es "ordentlich" zu gestalten. Es sollte möglichst intuitiv und selbsterklärend sein. Dann können auch Anfänger sehr schnell lernen damit umzugehen.
Was die RPG-Maker machen ist es Features in Form von Event-Commands abzulösen und die Arbeit auf den Endnutzer zu überwälzen. Die Entwickler von Enterbrain sind nicht motiviert genug um tiefergehende Event-Commands zu implementieren und geben daher dem nutzer den Source-Code und sagen ihm "da, mach dir selbst.".
Das sieht auf den ersten Blick zwar nach einer tollen Möglichkeit aus um allerlei mächtige Funktionalität einzubauen, in Wirklichkeit ist es meiner Meinung nach aber eine schlechte Unternehmenspolitik, welche sich versucht zu verbergen.
Es ist wie eine Waage: Wie viel Arbeit macht sich der Software-Entwickler und wie viel Arbeit muss der Endnutzer letzten Endes übernehmen. Enterbrain ging mit dem XP den Weg so gut wie alles auf den Endnutzer ab zu wälzen.
Ich stimme dieser Taktik schlichtweg nicht zu.
Schon mal versucht im RM2k ein fremdes Menüscript einzubinden und anzupassen welches z.B. unendlich viele Itemslots bietet? Da kriegst du bedeutend mehr Inkompatiblitätsprobleme als mit einem Ruby-Script, vorallem wenn du mehrere Fremdscripte kombinieren möchtest. Das Argument zieht also eher schlecht.
Und eben da kann die Community helfen. Alleine schon wenn es darum geht zwei inkompatible Scripte zueinander kompatibel zu machen, was im RM2k per Definition, ohne das Zielprojekt selbst zu besitzen, nicht möglich ist.
Die RPG Maker 2k und 2k3 sind, meiner Meinung nach, von grundauf schlecht designed. Kompliziertere Systeme sind nur dann möglich, wenn man bereit ist wie ein Sklave zu arbeiten, für ein Ergebnis, welches mit einer ordentlichen Programmierung nur wenige Minuten gedauert hätte.
Das hat nichts damit zu tun, weil eine Scriptsprache nicht zur Verfügung steht. Das hat damit zu tun, dass Enterbrain eine schlechte Arbeit geleistet hat.
Wenn man ordentliche, typisierte Variablen definieren könnte, und zwar lokal und global, dann würde das ganz anders aussehen.
Das was du beschreibst, Grafiken reinkloppen und am Code rumwerkeln ist genau dass was XP und VX(Ace) einem Entwickler in der einfachen Form erst ermöglichen. Eine Grafikengine bietet da deutlich weniger, nämlich nur grundlegende Funktionen welche auf beispielsweiße OpenGL oder DirectDraw(Direct3D) aufsetzen welche dir die Möglichkeit geben "zeichne Würfel an Position X und rotiere mit Geschwindigkeit S um Achse Y mit Textur C", sodass du nicht mehr 6 einzelne Quadrate selber zeichnen, positionieren und rotieren musst oder gar 12 Dreiecke, sondern in einem Aufrund deinen ganzen Würfel hast. Da ist nichts mit "Ressourcen reinkloppen" weil die Engine nicht einmal weiß was "Ressourcen" wären und dies gar nicht wissen kann.
Der RPG Maker geht da deutlich weiter. Vom komplett vorhandenem Editor, welchen dir auch keine Grafikengine (Unreal-Engine mal außen vor gelassen) bietet, will ich gar nicht anfangen.
Ich habe nicht gesagt, dass ein Programmierer sich lediglich eine Grafikengine nehmen soll.
Es gibt sehr gute Spieleengines zur kostenlosen (und auch kostenpflichtigen) Nutzung im Internet.
Jeder dürfte sich jederzeit eine dieser Engines nehmen und sofort anfangen das Spiel zu programmieren.
Schau nur einmal hier:
http://de.wikipedia.org/wiki/Liste_von_Spiel-Engines
Dort findet sich unter anderem:
CryEngine (http://de.wikipedia.org/wiki/CryEngine)
Unreal Engine (http://de.wikipedia.org/wiki/Unreal_Engine)
Quake-Engine (http://de.wikipedia.org/wiki/Quake-Engine)
und viele weitere bekannte Namen. Alles kostenlos zu nutzen.
Das sind nicht nur Grafikengines. Du hast bereits ein komplettes fertiges Spiel in manchen Fällen. Dieses kannst du dann ganz einfach mit neuen Resourcen und zusätzlichem Code bearbeiten.
@Topic
- Variable Auflösung (entweder mit Highres-Grafiken oder eben einer Skalierung über den sichtbaren Bildschirmbereich)
- "Echtes" Pixelmovement mit allem was dazu gehört (Pixelgenaue Kollision z.B.).
- Erweiterung der Maker-GUI, z.B. um eigene Event-Befehle für selbstgeschriebene Scripte (Plugin-System?)
Halt die Dinge welche selbst mit RGSS3 nahezu unmöglich zu realisieren sind, da man die halbe Engine umschreiben müsste.
Ein Plugin-System wäre vielleicht ganz interessant, möglicherweise aber schwer umzusetzen. Darüber muss ich ein wenig nachdenken.
Bei den Beispiel-Engines fehlen jetzt natürlich gerade die für uns interessanten, nämlich die für 2D-Retro-RPGs. Vielleicht könnte man die mit dem GameMaker umsetzen, aber das stelle ich mir viel aufwändiger als mit dem Maker vor. Man müsste wirklich mal schauen, wer weniger Aufwand hat: Ein Programmierer mit Spiel-Engine oder der Maker-Entwickler.
guck dir mal Unity3D an. Das hat seit neustem nen 2D Modus. Wie gut der ist, keine Ahnung, aber Unity ist von Haus aus sehr mächtig (und bietet portiertungen von Haus aus an.)
Bei den Beispiel-Engines fehlen jetzt natürlich gerade die für uns interessanten, nämlich die für 2D-Retro-RPGs. Vielleicht könnte man die mit dem GameMaker umsetzen, aber das stelle ich mir viel aufwändiger als mit dem Maker vor. Man müsste wirklich mal schauen, wer weniger Aufwand hat: Ein Programmierer mit Spiel-Engine oder der Maker-Entwickler.
Was mehr oder weniger Arbeit bedeutet kann man, denke ich, nicht beantworten.
Wenn man sich auf die Grundfunktionalität des Makers beschränkt ist die Art von Spielen, welche man erstellen kann, sehr begrenzt. Wenn man sich innerhalb dieser Grenzen bewegen will ist der Maker wahrscheinlich einfacher. Immerhin ist er bereits dafür ausgelegt.
Sobald man aber ein klein wenig von der Norm abweichen wird, wird es wohl sehr schnell einfacher eine "professionellere" Engine zu verwenden.
Außerdem: Jede 3D Engine bietet auch 2D Grafikmöglichkeiten.
Immerhin haben auch 3D Spiele ein 2D overlay und/oder HUD.
Das ist nicht viel anders als Sprites anzuzeigen. Außerdem gibt es soetwas wie 2D-Grafik für eine Grafikkarte garnicht mehr. Dort wird alles nurnoch mit der gleichen Technik wie für 3D realisiert. Es wird halt einfach nur "flach" gezeichnet.
Ich stimme auch dafür das man nur beim Eventcode bleibt, denn als RMXP Nutzer mit vielen RGSS Scripten, laufe ich ständig über Probleme, auch bzgl. Inkompatibilität.
Dafür ist es natürlich umso wichtiger das ich so ziemlich alles frei in einem mächtigen Event-Editor basteln kann. Beispiel: Ein Menü basteln, so wie ich es will. Mit flexiblen Fenstergrößen, Schriftarten, Einblendezeiten, Balken, Zahlen, Farben, Formen, Transparenzen, Sortierungen etc. Verstehst du wie ich meine?
Überhaupt alles im Eventeditor sollte dynamisch ansprechbar/änderbar sein. Keine festen Werte, die man nur fix im Editor einstellen kann.
Performance ist auch wichtig. Ich will 200 Zombies auf eine Map platzieren können, die von je 3 Schmetterlingen umzingelt werden und die alle mich jagen. Mit Schritt-, Flatter-, und Gröhlsounds...und Pathfinding. ;)
Kurzum: Eigentlich sollte man nie das Gefühl haben, das man eine Scriptsprache bräuchte um XY umzusetzen. Es sollte theoretisch alles was per Script ginge, auch mit dem Event Editor umsetzbar sein. Und das mindestens genauso komfortabel.
Ich stimme auch dafür das man nur beim Eventcode bleibt, denn als RMXP Nutzer mit vielen RGSS Scripten, laufe ich ständig über Probleme, auch bzgl. Inkompatibilität.
Dafür ist es natürlich umso wichtiger das ich so ziemlich alles frei in einem mächtigen Event-Editor basteln kann. Beispiel: Ein Menü basteln, so wie ich es will. Mit flexiblen Fenstergrößen, Schriftarten, Einblendezeiten, Balken, Zahlen, Farben, Formen, Transparenzen, Sortierungen etc. Verstehst du wie ich meine?
Überhaupt alles im Eventeditor sollte dynamisch ansprechbar/änderbar sein. Keine festen Werte, die man nur fix im Editor einstellen kann.
Es wird so wenige Konstanten geben wie möglich. Idealerweise wird man während des Spiels eine Menge Werte ändern können.
Performance ist auch wichtig. Ich will 200 Zombies auf eine Map platzieren können, die von je 3 Schmetterlingen umzingelt werden und die alle mich jagen. Mit Schritt-, Flatter-, und Gröhlsounds...und Pathfinding. ;)
Das wird überhaupt kein Problem sein. Auf meinem kleinen Laptop ohne dedizierte Grafikkarte komme ich immerhin auf 20 000 animierte Sprites + Tilemap.
Auf meinem PC sind es mehrere Millionen.
Eine 3D Landschaft ist etwas sehr kostspieliges für einen Computer. Eine Grafikkarte, welche soetwas problemlos anzeigen kann, kommt auch ohne Probleme mit nahezu beliebig vielen 2D Grafiken zurecht. Die kosten so gut wie garnichts.
Kurzum: Eigentlich sollte man nie das Gefühl haben, das man eine Scriptsprache bräuchte um XY umzusetzen. Es sollte theoretisch alles was per Script ginge, auch mit dem Event Editor umsetzbar sein. Und das mindestens genauso komfortabel.
Wie bereits angesprochen, ich denke nicht, dass ich eine Scriptsprache erlauben würde. Alleine wegen der Gefahr, dass sie jemand missbraucht um Viren zu übertragen oder andere Arten von Malware in einem Spiel zu verstecken.
Wie bereits angesprochen, ich denke nicht, dass ich eine Scriptsprache erlauben würde. Alleine wegen der Gefahr, dass sie jemand missbraucht um Viren zu übertragen oder andere Arten von Malware in einem Spiel zu verstecken.
Ich kann dir auch aus jeder X-beliebigen RPG.exe nen Virus bauen. Geht ganz einfach ;) Ist für mich also eigentlich kein Argument, warum man auf die Macht einer Script- bzw. Hochsprache verzichten sollten (bei mir z.B. gebe ich dem User ein Projekt mit an die Hand, welches er mehr oder weniger beliebig beschreiben kann, als .DLL kompiliert und dann zum Start geladen wird).
Point&Click ist zwar echt eine nette Sache und erleichter auch mega viel, ist aber auch mega aufwändig, das halbwegs potent zu designen.
Die Projekte werden auch nicht als .Exe verbreitet.
Meine Idee wäre es eine Runtime-Enviroment und einen Maker separat zu veröffentlichen. Projekte können nur gespielt werden sofern die Runtime-Enviroment auf dem Computer vorhanden ist. Es handelt sich dabei um eine Art von virtueller Maschine, in welcher ein Spiel gespielt wird. Diese Runtime-Enviroment beeinflusst die Art und Weise wie das Spiel auf System-Resourcen zugreifen kann und diese beeinflusst. Der Spieler kann zum Beispiel in seiner Runtime-Enviroment festlegen in welchem Ordner Spielstände gespeichert werden oder temporäre Dateien erstellt werden dürfen; außerdem wird es auch weitere Optionen für den Spieler geben um das Verhalten von Spielen global zu beeinflussen.
Dadurch ist es so ziemlich unmöglich, oder zumindest extrem schwierig, die Spiele zu missbrauchen um schädliche Software zu verbreiten.
Lares Yamoir
03.01.2014, 02:49
Ich kann es dir sagen, denn genau so wird es im XP getan. Erst sobald versucht wird die Musik ab zu spielen wird sie von der Festplatte geladen. Sofern man also vorher noch nicht versucht hat die Musik zu spielen wurde sie auch vorher noch nicht geladen. Wenn du bedenkst, dass diese Ladezeit nur eine oder zwei Sekunden beträgt, oder vielleicht noch weniger, ist es hoffentlich ersichtlich, dass es kein großes Problem ausmachen würde die Musik einfach bereits im Vorfeld zu laden. Dann gäbe es auch keine Probleme während des Abspielens mehr.
Generell kann man Ogg genauso wie MP3 streamen, also stückweise laden, während die Musik abgespielt wird. Der XP macht das nicht, richtig, aber man kann über RGSS sich nen externen Soundmanager machen um das Problem zu umgehen.
Wenn man nen eigenen Maker/Engine/sonstwas in der Richtung machen möchte, sollte man grundsätzlich ermöglichen Musikdaten zu streamen, unabhängig vom Format.
Was ich mir von einen Maker wünschen würde:
- Möglichkeit andere Maparten zu wählen (Isometrische Maps)
- Unterstützung mehrerer Videoformate (.mp4 und der ganze Kram. Ist natürlich eine Frage der Lizenzrechte)
- Ruby oder besser noch ne richtige Programmiersprache um auch Standardalgorithmen des Makers für das Spiel ändern zu können:
Was passiert wenn eine Map geladen wird?
Wann werden Objekte gelöscht?
Was sind die Standardeigenschaften für GUI-Elemente?
Was wird in ein Savefile gespeichert?
Ein Mappingsystem ähnlich dem XP
Partikelsystem
- Veränderbare Auflösung, Tastenbelegung, etc. im Spiel (der Entwickler sollte die Möglichkeit haben selbst ein Optionsmenü entsprechend des heutigen Spielstandards machen zu können)
Soll erstmal reichen, sonst Fallen mir noch zig Sachen ein die "nice to have" sind. Die obere Liste orientiert sich an dem, was andere Tools, wie Unity bsp. bieten.
Generell denke sich, dass ein Tool, was sich zwischen RPG Maker und Unity, CryEngine, UDK etc. befindet optimal wäre (Von den Aspekten der Flexibilität und Einsteigerfreundlichkeit her).
Die Projekte werden auch nicht als .Exe verbreitet.
Meine Idee wäre es eine Runtime-Enviroment und einen Maker separat zu veröffentlichen. Projekte können nur gespielt werden sofern die Runtime-Enviroment auf dem Computer vorhanden ist. Es handelt sich dabei um eine Art von virtueller Maschine, in welcher ein Spiel gespielt wird. Diese Runtime-Enviroment beeinflusst die Art und Weise wie das Spiel auf System-Resourcen zugreifen kann und diese beeinflusst. Der Spieler kann zum Beispiel in seiner Runtime-Enviroment festlegen in welchem Ordner Spielstände gespeichert werden oder temporäre Dateien erstellt werden dürfen; außerdem wird es auch weitere Optionen für den Spieler geben um das Verhalten von Spielen global zu beeinflussen.
Dadurch ist es so ziemlich unmöglich, oder zumindest extrem schwierig, die Spiele zu missbrauchen um schädliche Software zu verbreiten.
Hat aber wiederum das Problem, das alle Spiele, die mit deiner Engine gemacht werden auch auf allen späteren Engine Versionen laufen müssen. Diesen Schuh wollte ich mir nicht anziehen, zumal dann Private Änderungen an der Engine kaum möglich sind. Vielleicht habe ich dich auch nicht richtig verstanden, aber den Enduser eine Art RTP zu geben, dass dann wie in Java komplett abwärtskompatibel sein muss (und keine Custom Änderungen erlaubt*), halte ich für fatal! Gerade in der heutigen Zeit, wo OpenSource immer beliebter wird. Ich persönlich würde keine Engine nutzen wollen, die nicht Quelloffen ist und custom Änderungen nicht erlaubt
*Natürlich ist es bei einer gut gebauten Engine auch selten nötig, das er Nutzer etwas nachjustieren muss, aber möglich kann es sein.
Generell kann man Ogg genauso wie MP3 streamen, also stückweise laden, während die Musik abgespielt wird. Der XP macht das nicht, richtig, aber man kann über RGSS sich nen externen Soundmanager machen um das Problem zu umgehen.
Wenn man nen eigenen Maker/Engine/sonstwas in der Richtung machen möchte, sollte man grundsätzlich ermöglichen Musikdaten zu streamen, unabhängig vom Format.
Ja das stimmt wohl.
- Möglichkeit andere Maparten zu wählen (Isometrische Maps)
Sollte machbar sein, allerdings würde ich mich zunächst auf die "normalen" Maps beschränken und erst danach eine isometrische Alternative erstellen.
- Unterstützung mehrerer Videoformate (.mp4 und der ganze Kram. Ist natürlich eine Frage der Lizenzrechte)
Das ist schon schwieriger. Ich weis noch nicht recht was ich in dieser Richtung anbieten kann.
Was passiert wenn eine Map geladen wird?
Ist schon dabei.
Wann werden Objekte gelöscht?
Ist schon dabei.
Was sind die Standardeigenschaften für GUI-Elemente?
Ist schon dabei.
Was wird in ein Savefile gespeichert?
Der Entwickler soll die Möglichkeit haben selbstständig Dateien auf dem Computer des Spielers zu erstellen und zu speichern. Es können auch mehrere Dateien sein.
Allerdings kann der Entwickler sich nicht entscheiden wo er diese Dateien anlegt (der Ort wird von dem Spieler bestimmt) und der Spieler kann auch eine Obergrenze für die (kombinierte) Dateigröße festlegen.
Ein Mappingsystem ähnlich dem XP
Sogar noch ein Stückchen besser wenn es geht.
Partikelsystem Darüber lässt sich reden. Wie genau stellst du dir das in 2D vor?
- Veränderbare Auflösung, Tastenbelegung, etc. im Spiel (der Entwickler sollte die Möglichkeit haben selbst ein Optionsmenü entsprechend des heutigen Spielstandards machen zu können)
Ist schon dabei.
Hat aber wiederum das Problem, das alle Spiele, die mit deiner Engine gemacht werden auch auf allen späteren Engine Versionen laufen müssen. Diesen Schuh wollte ich mir nicht anziehen, zumal dann Private Änderungen an der Engine kaum möglich sind. Vielleicht habe ich dich auch nicht richtig verstanden, aber den Enduser eine Art RTP zu geben, dass dann wie in Java komplett abwärtskompatibel sein muss (und keine Custom Änderungen erlaubt*), halte ich für fatal! Gerade in der heutigen Zeit, wo OpenSource immer beliebter wird. Ich persönlich würde keine Engine nutzen wollen, die nicht Quelloffen ist und custom Änderungen nicht erlaubt
*Natürlich ist es bei einer gut gebauten Engine auch selten nötig, das er Nutzer etwas nachjustieren muss, aber möglich kann es sein.
Ja, dieses Problem existiert durchaus. Auf der anderen Seite gibt es dem Entwickler aber auch mehr Sicherheit und stabilität. Alle Versionen der Runtime-Enviroment werden vom Hersteller produziert und ihre Funktionalität wird garantiert. Wenn es auf einem Computer funktioniert, dann wird es auf jedem Computer funktionieren. (Sofern die Hardware ausreichend mächtig ist)
Es ist eine uralte Diskussion wie "sinnig" oder "unsinnig" eine virtuelle Maschine ist. Es ist allerdings die Herangehensweise, welche ich persönlich am sinnvollsten empfinde.
Immerhin soll das nicht das non-plus ultra der Spielerstellung werden. Es soll ein nettes kleines Programm für nette kleine Leute sein; Das Alter der (Haupt) Zielgruppe zwischen 10 und 20.
Wär mehr Macht will sollte programmieren lernen und sich nicht mit solchem Kinderspielzeug wie einem Maker befassen und seine Zeit damit verschwenden.
Aber Danke euch beiden für die Kommentare.
Lares Yamoir
03.01.2014, 18:10
Partikelsystem
Darüber lässt sich reden. Wie genau stellst du dir das in 2D vor?
Man hat einen Spawner, der immer wieder die gleiche zuvor ausgewählte Textur als Sprites (wichtig Mehrzahl!) erstellt.Diesen Spawner kann man entweder an ein bestimmtes Game Objekt befestigen, oder frei positionieren. Die Textur, so wie die Attribute für die Sprites (Lebensdauer, RGBA-Werte-Veränderung, Bewegungsmuster, Menge der Sprites, ...) können vom Entwickler festgelegt werden. So etwas macht sich vor allem gut für Feuer, Bluteffekte, Fußspuren, aufgewühlten Staub, Wetter oder eben (Kampf-)Fähigkeiten und erleichtert für nicht so gute Pixler den Arbeitsaufwand erheblich.
Das sollte leicht machbar sein.
IndependentArt
05.01.2014, 12:00
"Alles!"
Also in markierten Scriptzeilen bestimmte Inhalte suchen und ersetzen, beispielsweise Variablen und auch Textzeilen. :)
suchen ist mit einem cherry-tool möglich, soweit ich verstehe, wie du das möchtest. ist äußerst praktisch, wenn man zB danach sucht, wo man einen befehl überall verwendet hat. ersetzen muss man dann trotzdem manuell.
Caine Luveno
06.01.2014, 01:30
Der Maker geht meiner Meinung nach keinen wirklichen Weg.
[...]
Es ist inkonsistent ohne ersichtlichen Grund. Der Aufwand zum Implementieren wäre minimal, komplexer würde das Ganze dadurch auch nicht werden.
Sehe ich anders. Ich schätze bei den alten Makern 2k/2k3 wurde lediglich die Resonanz und der Erfindungsgeist der Community unterschätzt.
Die Entwickler gingen ursprünglich wohl nicht davon aus das jemand "show picture" für ein Menü missbrauchen würde. Ist aber auch relativ egal, da diese Maker schlichtweg veraltet sind, und zumindest für den 2k3 dank Cherrys DynPatch einiges möglich wurde.
Dann gibt es wiederum Event-Code mit gewissen Bedingungen und Aktionen, die allerdings bei weitem nicht alles abdecken, auch wenn es sehr einfach geworden wäre dies zu ermöglichen.
Ich glaube nicht dass es möglich ist alles was z.B. Ruby kann in eine GUI zu quetschen welche gleichermaßen die Programmierung vereinfacht und eine schnellere und flexiblere Arbeit ermöglicht als der Texteditor.
Das Interessante daran ist, dass das Programmieren sehr sehr simpel ist sobald man das Grundgerüst und die kryptische Syntax von Programmiersprachen ignoriert.
Da muss ich entschieden widersprechen. Die Syntax ist dass einfachste am Programmieren da man diese einfach auswendig lernen kann. Die Schwierigkeit liegt in der Logik, was sich sehr gut auch hier im Technikforum für den RM2k zeigt.
Die Idee hinter dem GUI-Code ist es, die komplizierten Gegebenheiten von Programmiersprachen sauber und ordentlich nach Außen an den Anwender zu bringen und die Hässlichkeiten zu verstecken. Außerdem werden alle Möglichkeiten aufgelistet und kategorisiert und direkt mit einer Beschreibung versehen.
Zudem wird die Möglichkeit für Programmfehler vermindert.
Die Möglichkeiten welche dir eine Script/Programmiersprache bietet sind aber zu viele als dass du sie in einer GUI unterbringen könntest ohne diese komplizierter als die eigentliche Scriptsprache zu machen. Microsoft hat das in Access versucht und ist (meiner Meinung nach) glorreich gescheitert.
Dazu kommt dass eine GUI sich auch nicht selbst erklärt, vor allem wenn sie so komplex ist dass sie eine ganze Scriptsprache ersetzen kann.
Wie leicht oder kompliziert das Endprodukt wird hängt stark davon ab wie viel Mühe man sich damit macht es "ordentlich" zu gestalten. Es sollte möglichst intuitiv und selbsterklärend sein. Dann können auch Anfänger sehr schnell lernen damit umzugehen.
Dein Wunsch wäre also folgendes:
Eine GUI welche eine komplette Scriptsprache ersetzt, die Entwicklung dabei vereinfacht und dennoch intuitiv und unkompliziert bedienbar bleibt? Dazu kann ich nur ganz ehrlich sagen: Wenn du das hinbekommst würde ich an deiner Stelle sofort mit der Entwicklung anfangen, denn damit könntest du einen Haufen Geld verdienen. Es hat schon seine Gründe warum auf Script bzw. Interpretersprachen zurückgegriffen wird um dynamische Aspekte in Programmen/Spielen zu realisieren.
Was die RPG-Maker machen ist es Features in Form von Event-Commands abzulösen und die Arbeit auf den Endnutzer zu überwälzen. Die Entwickler von Enterbrain sind nicht motiviert genug um tiefergehende Event-Commands zu implementieren und geben daher dem nutzer den Source-Code und sagen ihm "da, mach dir selbst.".
[...]
Ich stimme dieser Taktik schlichtweg nicht zu.
Das klingt nun arg nach Ich-Bin-Dagegen-Stammtischgerede, vor allem der letzte Absatz.
Ich mag so etwas nicht weil Diskussionen dazu neigen sich dran aufzuhängen wenn die Argumente dünn werden aber: Nehmen wir mal Pixelmovement als Beispiel. Du könntest nun hingehen und eine GUI entwerfen welche es dem Entwickler ermöglicht Schrittweite, Tilegröße und Frameanzahl der Laufanimation sowie den Multiplikator nach wie viel Spiel-Frames die Animation zum nächsten Frame wechselt einzustellen. Dazu kommt natürlich ein Hit-Box Editor für jedes popelige Tile, da dir die Schrittweite ja unbekannt ist. Lässt du auch nur ein Element davon weg kann deine GUI nicht mehr dass leisten was irgendeiner von hunderten Entwicklern irgendwann brauchen könnte.
Du gewinnst an Flexibilität aber erhöhst die Komplexität und den Arbeitsaufwand enorm, und bist dennoch nicht in der Lage alle möglichen Ideen der Entwickler abzudecken, da deine GUI eben nur die Optionen bietet an welche du als Entwickler gedacht hast.
Die Alternative wäre ein GUI Editor welcher es dir ermöglicht ein Ruby-Script genau so zu schreiben wie mit einem Texteditor. Das Problem was dann entsteht: Wozu noch die GUI? Um eine Syntax zu verstecken deren Lernaufwand den der GUI kaum übersteigt und dazu noch Geschwindigkeitseinbußen durch diverse Mausklickerei hinzunehmen? Ähm, nö. Würde ich als Entwickler niemals anrühren.
Wenn man ordentliche, typisierte Variablen definieren könnte, und zwar lokal und global, dann würde das ganz anders aussehen.
Das ändert an Kompatiblitätsproblemen gar nichts. Ganz besonders "globale Variablen" machen es nur noch schlimmer. Die Rubyscripte von EB sind auch voll davon, was mich regelmäßig zur Weißglut treibt.
Ich habe nicht gesagt, dass ein Programmierer sich lediglich eine Grafikengine nehmen soll.
[...]
Du hast bereits ein komplettes fertiges Spiel in manchen Fällen. Dieses kannst du dann ganz einfach mit neuen Resourcen und zusätzlichem Code bearbeiten.
Du sagtest warum ein "richtiger" Programmierer zum Maker greifen sollte wenn es doch die Top-Level-Programmiersprachen-Engines gibt, als Gegenargument zur Implementierung einer Scriptsprache, kommst nun aber mit kompletten Spiele-Engines um die Ecke. Wenn ich mir deine Beispiele so ansehe, insbesondere dieses mit "ein fertiges Spiel welches nur noch angepasst werden muss" fällt der Maker selbst in den Bereich der Spiele-Engines, womit die Diskussion arg in eine Engine-Diskussion abzudriften droht.
Sehe ich anders. Ich schätze bei den alten Makern 2k/2k3 wurde lediglich die Resonanz und der Erfindungsgeist der Community unterschätzt.
Die Entwickler gingen ursprünglich wohl nicht davon aus das jemand "show picture" für ein Menü missbrauchen würde. Ist aber auch relativ egal, da diese Maker schlichtweg veraltet sind, und zumindest für den 2k3 dank Cherrys DynPatch einiges möglich wurde.
Das kannst du ruhig anders sehen, dagegen habe ich nichts. Deine Meinung entspricht dann in diesem Fall lediglich nicht meiner.
Ich glaube nicht dass es möglich ist alles was z.B. Ruby kann in eine GUI zu quetschen welche gleichermaßen die Programmierung vereinfacht und eine schnellere und flexiblere Arbeit ermöglicht als der Texteditor.
Nun, man könnte lediglich eine Turing vollständige GUI-Code sprache erstellen, welche es erlaubt native Funktionen aufzurufen und schon hätte man es geschafft eine GUI-Programmierung zu ermöglichen, welche exakt genau so mächtig ist wie Ruby.
Das ist aber überhaupt nicht mein Ziel, ich will sie gezielt weniger mächtig machen damit gewisse Funktionen nicht missbraucht werden können.
Da muss ich entschieden widersprechen. Die Syntax ist dass einfachste am Programmieren da man diese einfach auswendig lernen kann. Die Schwierigkeit liegt in der Logik, was sich sehr gut auch hier im Technikforum für den RM2k zeigt.
Da muss ich auch entschieden wiedersprechen.
Ein gewisser Grad an Logik ist jedem Menschen in die Wiege gelegt, dafür braucht man nichts zu lernen. Falls die Syntax wie folgt aussieht:
Falls Button A gedrückt
dann
öffne menü
dann wird dieses Programm wohl für jeden noch so grünen Anfänger verständlich sein.
Falls die Syntax jedoch wie folgt aussieht:
if ( keyboard.press?(0x66) )
{
goto 42
}
Dann wird da wohl der ein oder andere seine schwierigkeiten haben damit klar zu kommen.
Du siehst, beide Code-schnipsel könnten möglicherweise das selbe machen, doch der erste Fall benutzt intuitive (und in diesem Fall auch deutsche) Sprache und Konstanten.
Das ist ein reiner Unterschied in Syntax und Programmierstil; die Logik bei beiden Fällen ist gleichsam trivial.
Die Möglichkeiten welche dir eine Script/Programmiersprache bietet sind aber zu viele als dass du sie in einer GUI unterbringen könntest ohne diese komplizierter als die eigentliche Scriptsprache zu machen. Microsoft hat das in Access versucht und ist (meiner Meinung nach) glorreich gescheitert.
Wie schon gesagt, ich habe nicht vor die gleichen Möglichkeiten zu bieten. C++ bietet weniger Möglichkeiten als Assembly, trotzdem benutzt niemand letzteres.
Es geht nicht um Möglichkeiten beim Programmieren, es geht darum, dass man das tun kann was man will.
Alles was man nicht will braucht man auch nicht tun zu können. Kannst du zufälligerweise mit diesem Programm nicht das tun was du willst, dann hast du schlichtweg das falsche Programm gewählt.
Dazu kommt dass eine GUI sich auch nicht selbst erklärt, vor allem wenn sie so komplex ist dass sie eine ganze Scriptsprache ersetzen kann.
Ich glaube ein GUI-Code hat eine einfachere Möglichkeit sich selbst zu erklären als der einer interpretierten Scriptsprache.
Ich kann bei dem GUI-Code zu jedem Befehl eine Beschreibung hinzufügen, welche automatisch angezeigt wird, sobald der Nutzer mit der Maus drüber fährt. Sobald man dem Nutzer erlaubt eigenen Code zu schreiben verliert man die Möglichkeit ihn dazu zu zwingen alles ausreichend zu dokumentieren und mit Kommentaren zu versehen.
Das heist nicht, dass es unmöglich ist ein Script zu schreiben, welches sich selbst erklärt; es heist lediglich, dass ich der Meinung bin, dass es mit einem GUI-Code einfacher ist ihn selbsterklärend zu machen.
Eine GUI welche eine komplette Scriptsprache ersetzt, die Entwicklung dabei vereinfacht und dennoch intuitiv und unkompliziert bedienbar bleibt? Dazu kann ich nur ganz ehrlich sagen: Wenn du das hinbekommst würde ich an deiner Stelle sofort mit der Entwicklung anfangen, denn damit könntest du einen Haufen Geld verdienen. Es hat schon seine Gründe warum auf Script bzw. Interpretersprachen zurückgegriffen wird um dynamische Aspekte in Programmen/Spielen zu realisieren.
Das will ich zwar nicht ganz genau so, wie du es hier sagst, aber man sollte doch immer nach den Sternen greifen, wenn man sich schon die Mühe und Zeit nimmt.
Das klingt nun arg nach Ich-Bin-Dagegen-Stammtischgerede, vor allem der letzte Absatz.
Ich mag so etwas nicht weil Diskussionen dazu neigen sich dran aufzuhängen wenn die Argumente dünn werden aber: Nehmen wir mal Pixelmovement als Beispiel. Du könntest nun hingehen und eine GUI entwerfen welche es dem Entwickler ermöglicht Schrittweite, Tilegröße und Frameanzahl der Laufanimation sowie den Multiplikator nach wie viel Spiel-Frames die Animation zum nächsten Frame wechselt einzustellen. Dazu kommt natürlich ein Hit-Box Editor für jedes popelige Tile, da dir die Schrittweite ja unbekannt ist. Lässt du auch nur ein Element davon weg kann deine GUI nicht mehr dass leisten was irgendeiner von hunderten Entwicklern irgendwann brauchen könnte.
Ich habe vor kurzem eine sehr interessante Vorlesung von einem renommierten Soziologieprofessor hören dürfen, in welcher eine These angesprochen wurde die besagt, wie die Gesellschaft sich heutzutage immer weiter in die Richtung bewegt, dass der Kunde zu einem unbezahlten Arbeiter für den Produzenten wird.
Möbel von Ikea selbst zusammenbauen, automatische Kassen im Supermarkt, online Feedback und Reviews erstellen, etc.
Im gleichen Sinne entwickelt Enterbrain die Maker immer weiter in die Richtung lediglich ein Grafik/Audio-Bündel zu sein, welches mit einer Ruby basierten Game-Engine mit kommt. Dabei werden die eingebauten Features immer weiter abgebaut, und dafür mehr flexibilität für trainierte Nutzer ermöglicht.
Wie ich schon sagte, mann kann das natürlich als etwas positives betrachten. Ich persönlich sehe es allerdings nicht als etwas positives.
Das ändert an Kompatiblitätsproblemen gar nichts. Ganz besonders "globale Variablen" machen es nur noch schlimmer. Die Rubyscripte von EB sind auch voll davon, was mich regelmäßig zur Weißglut treibt.
Ja, die Scripte von Enterbrain in den neueren Makern lassen manchmal zu wünschen übrig. Bei dem Ace ist es schon sichtlich besser geworden als es noch zu XP Zeiten war; das war ein ziemlicher Alptraum.
Aber globale Variablen haben damit nichts zu tun. Soetwas gibt es seit je her und zwar in jeder Programmiersprache. Es ist nunmal so, dass ein Programm komplett ohne globale Elemente nicht (oder nur schwer) auskommt.
Es führt allerdings, bei korrekter Handhabung, auch bei weitem nicht zu so vielen Problemen wie man denken mag. Jeder Entwickler verwendet seinen eigenen Namespace und Kollisionen sind so gut wie dahin sofern jeder ordentlich arbeitet.
Du sagtest warum ein "richtiger" Programmierer zum Maker greifen sollte wenn es doch die Top-Level-Programmiersprachen-Engines gibt, als Gegenargument zur Implementierung einer Scriptsprache, kommst nun aber mit kompletten Spiele-Engines um die Ecke. Wenn ich mir deine Beispiele so ansehe, insbesondere dieses mit "ein fertiges Spiel welches nur noch angepasst werden muss" fällt der Maker selbst in den Bereich der Spiele-Engines, womit die Diskussion arg in eine Engine-Diskussion abzudriften droht.
Eigentlich gibt es keine Engine Diskussion, zumindest nicht in diesem Thread. Die ursprüngliche Idee scheint langsam abhanden zu kommen; meine Frage ist es, was ihr gerne an Features sehen möchtet.
Das bedeutet jedoch nicht, dass ich auch alles genannte umsetzen werde. (oder dass ich überhaupt irgendetwas umsetzen werde letzten Endes)
Es ist einfach eine lieb gemeinte kleine Diskussionsrunde zu eurem Traumfeatures.
Ich verweise dich mal hier (http://www.multimediaxis.de/threads/133960-Maker-Faszination-oder-reiner-Nutzen) drauf.
Hatte vor einiger Zeit selbst mal danach gefragt, vll bringt dich das ja weiter ;)
Caine Luveno
06.01.2014, 21:39
ich will sie gezielt weniger mächtig machen damit gewisse Funktionen nicht missbraucht werden können.
Damit limitierst du die mögliche Zielgruppe deines Produktes. Deswegen finde ich die Entscheidung Pro-Scriptsprache von Enterbrain eben gut. Das erklärte Ziel des RPG Makers dürfte es gewesen sein jedem ohne Programmierkenntnisse das Erstellen eines Spiels zu ermöglichen.
Dies ist, sowohl mit den alten als auch den neuen Makern, unbestreitbar gelungen. Regelmäßig taucht hier die ein oder andere Perle auf, von Menschen welche mehr als if-then-else nicht verstehen. Zeitgleich ist aber auch das Gegenteil möglich. EB gewinnt, die Spieler gewinnen, die Community gewinnt. Wo ist das Problem?
Da muss ich auch entschieden wiedersprechen.
Englisch als Symbolbezeichner dient der Internationalisierung. Die Bezeichnung von Symbolen hat aber nichts mit Syntax zu tun, womit deine Beispiele sowieso komplett obsolet sind. Ich würde gerne mal ein komplexes Map-Transition oder Pixelmovmeentscript in deinem Beispiel 1 verfasstem Code sehen *hust*.
Es geht nicht um Möglichkeiten beim Programmieren, es geht darum, dass man das tun kann was man will.
Alles was man nicht will braucht man auch nicht tun zu können. Kannst du zufälligerweise mit diesem Programm nicht das tun was du willst, dann hast du schlichtweg das falsche Programm gewählt.
Realitätsfremd. Für kommerzielle Produkte ist eine Philosophie a la "dir fehlt ein Feature? Pech gehabt" der Todesstoß. Selbst kostenlose Produkte werden versuchen "ihrer" Community im Rahmen des angestrebten Ziels entgegen zu kommen. Um absolute Featureüberlastung zu vermeiden bedient man sich dann eben der Scriptsprache.
Wenn es danach ginge ob ein Programm 100% alles exakt so macht wie gewünscht bleibt nur: selber machen oder für teuer Geld Individualsoftware in Auftrag geben. Selbst bei professioneller Software muss man Abstriche machen, so ziemlich immer und überall. Und sogar größere Konzerne (Microsoft und der Start-Button) müssen auf Ihre Konsumenten hören und im Zweifel nachbessern.
Ich glaube ein GUI-Code hat eine einfachere Möglichkeit sich selbst zu erklären als der einer interpretierten Scriptsprache.
Alleine die vielen Begrifflichkeiten welche du mit Alltagswörtern erklären musst machen das Ding schon unverständlich.
Ich kann bei dem GUI-Code zu jedem Befehl eine Beschreibung hinzufügen, welche automatisch angezeigt wird, sobald der Nutzer mit der Maus drüber fährt.
Professionelle IDEs haben dafür Shortcuts welche das Selbe leisten. Mouseover ist beim Entwickeln wohl die größte Hölle die du jemandem beim Code-Lesen antun kannst.
Sobald man dem Nutzer erlaubt eigenen Code zu schreiben verliert man die Möglichkeit ihn dazu zu zwingen alles ausreichend zu dokumentieren und mit Kommentaren zu versehen.
Vielleicht gebe ich dir mal eins meiner alten Menüscripte aus dem 2k3 welches nicht einen Kommentar enthält und mehr als 1000 Zeilen Code benötigt. Ggf. siehst du dann was ich meine warum GUI-Code die von dir genannten Vorteile eben nicht hat. Alternativ schau dir Lachsens Scripte in Velsarbor an.
Das heist nicht, dass es unmöglich ist ein Script zu schreiben, welches sich selbst erklärt; es heist lediglich, dass ich der Meinung bin, dass es mit einem GUI-Code einfacher ist ihn selbsterklärend zu machen.
Dann hast du noch nie wirklich komplexen Code gesehen, Sorry.
Ich habe vor kurzem eine sehr interessante Vorlesung von einem renommierten Soziologieprofessor hören dürfen, in welcher eine These angesprochen wurde die besagt, wie die Gesellschaft sich heutzutage immer weiter in die Richtung bewegt, dass der Kunde zu einem unbezahlten Arbeiter für den Produzenten wird.
Möbel von Ikea selbst zusammenbauen, automatische Kassen im Supermarkt, online Feedback und Reviews erstellen, etc.
Das ganze ist ein zweischneidiges Schwert. Die Balance ist wichtig, und eine Opt-Out Möglichkeit für Leute die das nicht wollen, und das ist gegeben.
Im gleichen Sinne entwickelt Enterbrain die Maker immer weiter in die Richtung lediglich ein Grafik/Audio-Bündel zu sein, welches mit einer Ruby basierten Game-Engine mit kommt. Dabei werden die eingebauten Features immer weiter abgebaut, und dafür mehr flexibilität für trainierte Nutzer ermöglicht.
Ich sehe im VX Ace einen deutlichen Zugewinn an Built-In Features im Vergleich zum 2k/2k3.
Aber globale Variablen haben damit nichts zu tun. Soetwas gibt es seit je her und zwar in jeder Programmiersprache. Es ist nunmal so, dass ein Programm komplett ohne globale Elemente nicht (oder nur schwer) auskommt.
Da irrst du dich. In vielen Sprachen ist es dank OOP möglich Code zu schreiben welcher nicht eine globale Variable benötigt, sondern lediglich einen globalen Einsprungspunkt, welcher sowieso nur einmal aufgerufen wird. Und selbst in prozedualen Sprachen ist es für geübte Programmierer kein Problem globale Variablen zu vermeiden.
Es führt allerdings, bei korrekter Handhabung, auch bei weitem nicht zu so vielen Problemen wie man denken mag. Jeder Entwickler verwendet seinen eigenen Namespace und Kollisionen sind so gut wie dahin sofern jeder ordentlich arbeitet.
Namespacing kaschiert das Problem und ist primär dafür gedacht doppelte Klassennamen/Funktionsnamen in modularen Anwendungen zu vermeiden und nicht schlechte um Programmierung zu unterstützen.
Es ist einfach eine lieb gemeinte kleine Diskussionsrunde zu eurem Traumfeatures.
Wenns danach geht:
- Ein voll anpassbares AKS (nahezu unmöglich da den "richtigen" Nerv zu treffen ohne Anpassungen des Codes durch den Nutzer)
Damit limitierst du die mögliche Zielgruppe deines Produktes. Deswegen finde ich die Entscheidung Pro-Scriptsprache von Enterbrain eben gut. Das erklärte Ziel des RPG Makers dürfte es gewesen sein jedem ohne Programmierkenntnisse das Erstellen eines Spiels zu ermöglichen.
Ich habe auch bereits gesagt, dass ich die Zielgruppe limitiere; ich sehe da kein Problem.
Dies ist, sowohl mit den alten als auch den neuen Makern, unbestreitbar gelungen. Regelmäßig taucht hier die ein oder andere Perle auf, von Menschen welche mehr als if-then-else nicht verstehen. Zeitgleich ist aber auch das Gegenteil möglich. EB gewinnt, die Spieler gewinnen, die Community gewinnt. Wo ist das Problem?
Unbestreitbar ist wohl, dass man ein Spiel erstellen kann, aber sehr wohl bestreitbar ist, dass man nicht gerade das Spiel erstellen kann was man gerne erstellen will.
Englisch als Symbolbezeichner dient der Internationalisierung.
Sag bloß. Entschuldigung, das konnte ich mir nicht verkneifen.
Die Bezeichnung von Symbolen hat aber nichts mit Syntax zu tun, womit deine Beispiele sowieso komplett obsolet sind. Ich würde gerne mal ein komplexes Map-Transition oder Pixelmovmeentscript in deinem Beispiel 1 verfasstem Code sehen *hust*.
Die Bezeichnung von Symbolen hat alles mit Syntax zu tun. Das ist die Bedeutung von Syntax.
Beim Programmieren gibt es gewisse Schlüsselwörter und Symbole; wie diese aussehen wird durch die Syntax festgelegt.
Ein größeres Beispiel würde ich auch gerne sehen. Wer weis, vielleicht wird es das eines Tages geben.
Realitätsfremd. Für kommerzielle Produkte ist eine Philosophie a la "dir fehlt ein Feature? Pech gehabt" der Todesstoß. Selbst kostenlose Produkte werden versuchen "ihrer" Community im Rahmen des angestrebten Ziels entgegen zu kommen. Um absolute Featureüberlastung zu vermeiden bedient man sich dann eben der Scriptsprache.
Doppelmoral. Im Maker wird eben diese Schiene gegangen. Dir fehlt ein Feature im GUI-Code? Pech gehabt, lerne mit Ruby zu programmieren oder frag jemanden der es kann damit dieser es für dich tut.
Es ist niemals gut zu versuchen es jedem recht zu machen. Definiere zuerst deine Zielgruppe und dann erstelle ein Produkt für eben jene; das ist meine Devise hierbei.
Wenn es danach ginge ob ein Programm 100% alles exakt so macht wie gewünscht bleibt nur: selber machen oder für teuer Geld Individualsoftware in Auftrag geben. Selbst bei professioneller Software muss man Abstriche machen, so ziemlich immer und überall. Und sogar größere Konzerne (Microsoft und der Start-Button) müssen auf Ihre Konsumenten hören und im Zweifel nachbessern.
Ich erkenne keinen Kontext zur Diskussion.
Alleine die vielen Begrifflichkeiten welche du mit Alltagswörtern erklären musst machen das Ding schon unverständlich.
Du hast es ja noch nicht gesehen, dann kannst du auch kaum zu diesem Zeitpunkt eine Aussage zu treffen. Dennoch lässt du die Frage offen wie es verständlicher wird wenn man eigene Scripte schreibt.
Professionelle IDEs haben dafür Shortcuts welche das Selbe leisten. Mouseover ist beim Entwickeln wohl die größte Hölle die du jemandem beim Code-Lesen antun kannst.
Das finde ich auch. Zu schade, dass der Maker soetwas nicht bietet. Wenn der Script-Editor des Makers ein wenig besser wäre hätte ich wohl länger damit gearbeitet, aber es wurde auf Zeit schon grob lästig.
Vielleicht gebe ich dir mal eins meiner alten Menüscripte aus dem 2k3 welches nicht einen Kommentar enthält und mehr als 1000 Zeilen Code benötigt. Ggf. siehst du dann was ich meine warum GUI-Code die von dir genannten Vorteile eben nicht hat. Alternativ schau dir Lachsens Scripte in Velsarbor an.
Ich wüsste nicht wo hier der Zusammenhang besteht.
Ich habe ja nie behauptet, dass der GUI-Code genau so aussehen würde wie der Maker code.
Das ganze ist ein zweischneidiges Schwert. Die Balance ist wichtig, und eine Opt-Out Möglichkeit für Leute die das nicht wollen, und das ist gegeben.
Das ist sogar ein sehr kompliziertes und kontroverses Thema. Ich wünschte es würden mehr Vorlesungen wie diese gehalten werden; zumindest hier in meiner Nähe.
Ich sehe im VX Ace einen deutlichen Zugewinn an Built-In Features im Vergleich zum 2k/2k3.
Das mag sein; ich habe mir den Ace kaum mehr angeguckt nachdem ich von dem XP und VX ziemlich enttäuscht gewesen war.
Aber die alten Maker haben einen eigenen Haufen an Problemen unter denen sie leiden.
Da irrst du dich. In vielen Sprachen ist es dank OOP möglich Code zu schreiben welcher nicht eine globale Variable benötigt, sondern lediglich einen globalen Einsprungspunkt, welcher sowieso nur einmal aufgerufen wird. Und selbst in prozedualen Sprachen ist es für geübte Programmierer kein Problem globale Variablen zu vermeiden.
Womit irre ich mich? Kannst du die Textpassage vielleicht einmal zitieren?
Ich erkenne nicht, an welcher Stelle ich etwas derartiges behauptet habe.
Namespacing kaschiert das Problem und ist primär dafür gedacht doppelte Klassennamen/Funktionsnamen in modularen Anwendungen zu vermeiden und nicht schlechte um Programmierung zu unterstützen.
Ich wüsste nicht, welches Feature jemals dafür gedacht gewesen ist schlechte Programmierung zu unterstützen. Das klingt höchst fragwürdig für mich, dass jemand soetwas überhaupt tun will.
Auf der anderen Seite ist Namespacing genau das was überall dafür verwendet wird.
In einer objekt orientierten Programmiersprache besitzt jede Klasse ihren eigenen Namespace an globalen Variablen, jedes Objekt seinen eigenen Namespace für private Variablen und jede Methode ihren eigenen Namespace für lokale Variablen. Das ist so ziemlich die einzige Lösung, welche dafür verwendet wird.
Wenns danach geht:
- Ein voll anpassbares AKS (nahezu unmöglich da den "richtigen" Nerv zu treffen ohne Anpassungen des Codes durch den Nutzer)
"Voll anpassbar" ist schwer zu definieren. Aber anpassbar sollte möglich sein.
Whiz-zarD
06.01.2014, 23:53
Ich glaube nicht dass es möglich ist alles was z.B. Ruby kann in eine GUI zu quetschen welche gleichermaßen die Programmierung vereinfacht und eine schnellere und flexiblere Arbeit ermöglicht als der Texteditor.
Schau dir mal z.B. Scratch (http://de.wikipedia.org/wiki/Scratch_(Programmiersprache)) an. ;)
Das sind zwar Kindgerechte Programmiersprachen, aber die laufen komplett über die GUI. Die Kinder können sich durch Klicken und Schieben ganze Scripte Schreiben. Mitsamt Verzweigungen und Schleifen.
Die Möglichkeiten welche dir eine Script/Programmiersprache bietet sind aber zu viele als dass du sie in einer GUI unterbringen könntest ohne diese komplizierter als die eigentliche Scriptsprache zu machen. Microsoft hat das in Access versucht und ist (meiner Meinung nach) glorreich gescheitert.
Das stimmt so nicht.
Eine Programmiersprache gibt dir nur sehr wenige Möglichkeiten. Die Digitaltechnik besteht auch nur aus UND, ODER und NICHT, und bietet dir alles, was du brauchst. Ja, dein ganzer PC basiert nur auf diesen drei Logik-Gattern. Das XOR besteht auch nur aus den drei Komponenten. Eine Programmiersprache bietet dir also nur eine gewisse Kontrollmöglichkeit. In den gängisten Programmiersprachen hast du lediglich nur Logische- und Bitoperatoren, Verzweigungen und Schleifen. Aus diesen Möglichkeiten werden dann ganze Frameworks gebastelt, die das Leben eines Programmierers erleichtern. Darunter z.B. der Garbage Collector oder Reflection.
Microsoft Access ist auch in vieler Hinsicht Gescheitert. Allein schon, dass Access mit großen Datenmengen nicht mehr arbeiten konnte. Beruflich arbeite ich an einer Software, in der die Kunden über 10 GB Daten in die Datenbank schreiben. Einige Tabellen weisen sogar über eine Million Datensätze auf. Vor ca. 10 Jahren hatte die Firma Access noch unterstützt. Diese Unterstützung wurde aber aufgrund der Unperformance aufgegeben.
Dazu kommt dass eine GUI sich auch nicht selbst erklärt, vor allem wenn sie so komplex ist dass sie eine ganze Scriptsprache ersetzen kann.
Wie gesagt, eine Programmiersprache ist nich so komplex, wie sie aussieht. Ein Compiler ist auch nur ein paar Kilobytes groß, und ein Compiler übersetzt den gesamten Quellcode in Maschinensprache.
Einige Compiler sind sogar sehr rudimentär. Einige bestehen zum Großteil nur aus Verzweigungen.
Eine GUI welche eine komplette Scriptsprache ersetzt, die Entwicklung dabei vereinfacht und dennoch intuitiv und unkompliziert bedienbar bleibt? Dazu kann ich nur ganz ehrlich sagen: Wenn du das hinbekommst würde ich an deiner Stelle sofort mit der Entwicklung anfangen, denn damit könntest du einen Haufen Geld verdienen. Es hat schon seine Gründe warum auf Script bzw. Interpretersprachen zurückgegriffen wird um dynamische Aspekte in Programmen/Spielen zu realisieren.
Der Grund liegt eher in der Engstirnigkeit einiger Entwickler, die nicht über ihren Schatten springen können, und nur das für Gut befinden, was sie kennen.
In der Firma, wo ich arbeite, sind wir nun von VSS (Visual SourceSafe) auf TFS (Team Foundation Server) umgestiegen, und gerade die älteren Entwickler vertrauen z.B. das Auto-Merging von TFS nicht, und machen es stattdessen weiterhin manuell.
Es ist zwar richtig, dass man über eine Programmiersprache meist schneller zu einem Ergebnis kommt, aber das heißt lange nicht, dass eine GUI schlecht ist. Schaue dir z.B. die SPS-Programmierung an. Dort läuft es nämlich genau andersrum. Dort wird hauptsächlich nur über Drag'n'Drop entwickelt. Siemens hatte mit ihrer S7 erst Chancen auf dem Markt gehabt, nachdem sie den Kontaktplan uind Funktionsplan in ihre IDE integriert haben. Davor musste man die Befehle eintippen und die S7 war regelrecht ein Ladenhüter.
Da irrst du dich. In vielen Sprachen ist es dank OOP möglich Code zu schreiben welcher nicht eine globale Variable benötigt, sondern lediglich einen globalen Einsprungspunkt, welcher sowieso nur einmal aufgerufen wird. Und selbst in prozedualen Sprachen ist es für geübte Programmierer kein Problem globale Variablen zu vermeiden.
Hast du schon mal was von statischen Objekten/Klassen gehört?
Für viele Zwecke sind sie sehr hilfreich und je nach Sichtbarkeit können sie Global sein. In Java ist z.B. die Math-Klasse eine statische Klasse, die global verfügbar ist.
Caine Luveno
12.01.2014, 22:32
Das stimmt so nicht.
Eine Programmiersprache gibt dir nur sehr wenige Möglichkeiten. Die Digitaltechnik besteht auch nur aus UND, ODER und NICHT, und bietet dir alles, was du brauchst. Ja, dein ganzer PC basiert nur auf diesen drei Logik-Gattern. Das XOR besteht auch nur aus den drei Komponenten. Eine Programmiersprache bietet dir also nur eine gewisse Kontrollmöglichkeit. In den gängisten Programmiersprachen hast du lediglich nur Logische- und Bitoperatoren, Verzweigungen und Schleifen. Aus diesen Möglichkeiten werden dann ganze Frameworks gebastelt, die das Leben eines Programmierers erleichtern. Darunter z.B. der Garbage Collector oder Reflection.
Und was hat die absolut niedrigste Abstraktionsebene mit der Umsetzung einer Top-Level-Programmiersprache als GUI zu tun? Richtig: Nichts.
Wie gesagt, eine Programmiersprache ist nich so komplex, wie sie aussieht. Ein Compiler ist auch nur ein paar Kilobytes groß, und ein Compiler übersetzt den gesamten Quellcode in Maschinensprache.
Einige Compiler sind sogar sehr rudimentär. Einige bestehen zum Großteil nur aus Verzweigungen.
Was eine Programmiersprache einem Entwickler für Werkzeuge in die Hand gibt und was eine Maschine rbaucht um diese Werkzeuge in für sich lesbaren Code umzuwandeln sind zwei verschiedene paar Schuhe.
Es ist zwar richtig, dass man über eine Programmiersprache meist schneller zu einem Ergebnis kommt, aber das heißt lange nicht, dass eine GUI schlecht ist. Schaue dir z.B. die SPS-Programmierung an. Dort läuft es nämlich genau andersrum. Dort wird hauptsächlich nur über Drag'n'Drop entwickelt. Siemens hatte mit ihrer S7 erst Chancen auf dem Markt gehabt, nachdem sie den Kontaktplan uind Funktionsplan in ihre IDE integriert haben. Davor musste man die Befehle eintippen und die S7 war regelrecht ein Ladenhüter.
Ich habe nie behauptet das GUIs generell schlecht wären sondern das eine GUI für den hier diskutierten Zweck nicht das leisten kann was sie müsste um ihrem Anspruch gerecht zu werden. Das heißt nicht das ich den aktuellen Click-Code oder GUI Umsetzungen anderer Programme generell schlecht finde.
Hast du schon mal was von statischen Objekten/Klassen gehört?
Für viele Zwecke sind sie sehr hilfreich und je nach Sichtbarkeit können sie Global sein. In Java ist z.B. die Math-Klasse eine statische Klasse, die global verfügbar ist.
Jap habe ich. Und das ist der gleiche Dreck wie globale Variablen. Die Math-Klasse in Java ist nichts weiter als eine Sammlung von Funktionen welche als statische Klasse zusammengeschnürt wurden nur damit die Sprache "rein" objektorientiert arbeitet -> Müll.
Der einzige Fall wo so etwas ggf. sinnvoll ist sind globale Mechanismen zum Debuggen oder zur Fehlerbehandlung.
Whiz-zarD
13.01.2014, 11:53
Ich habe nie behauptet das GUIs generell schlecht wären sondern das eine GUI für den hier diskutierten Zweck nicht das leisten kann was sie müsste um ihrem Anspruch gerecht zu werden. Das heißt nicht das ich den aktuellen Click-Code oder GUI Umsetzungen anderer Programme generell schlecht finde.
Was muss denn eine GUI können, was nur ein Texteditor kann?
Jap habe ich. Und das ist der gleiche Dreck wie globale Variablen. Die Math-Klasse in Java ist nichts weiter als eine Sammlung von Funktionen welche als statische Klasse zusammengeschnürt wurden nur damit die Sprache "rein" objektorientiert arbeitet -> Müll.
Du hast so keine Ahnung ...
Weißt du überhaupt. wie Java funktioniert? In Java gibt es nur zwei Arten von Datentypen. Objekte und native Datentypen, wie int, long, etc.
Methoden können also nur in Objekten geschnürt werden. Eine andere Möglichkeit hast du dort nicht. Ja, selbst Class erbt von Object.
Möchtest du also jedes Mal ein Math-Objekt instanzieren, damit du auf mathematische Methoden zurückgreifen kannst?
Ist dir überhaupt klar, dass das Instanzieren von Objekten, Reservieren und Freigeben von Speicher wieder Rechner-Instruktionen und unnötigen Speicherverbrauch bedeutet?
Eine statische Klasse befindet sich nur einmal im Speicher. Sie wird einmal erzeugt und dann nie wieder. Findest du so was Müll? Na dann Prost Mahlzeit ...
Also bitte erzähle hier nicht so ein Bullshit, wenn du davon keine Ahnung hast ...
Rein interessehalber: Wie hättest du die Math-Klasse in Java denn gelöst, damit sie in deinen Augen nicht "Dreck" ist?
IronChef
13.01.2014, 15:21
Ich weiß nicht obs schon mal irgendwo hier genannt wurde, aber wenns schon um den perfekten Maker geht wäre es für mich (und vermutlich auch viele andere die mit Overlaymapping arbeiten) eine absolut großartige Arbeitserleichterung wenn man fürs Mapping verwendete Bilder auch direkt im Mapeditor anzeigen lassen könnte. Momentan arbeite ich noch so, dass ich anhand des geöffneten Bildes die Passierbarkeitsebene im Mapeditor erstelle und mich dann z.B. bei der Eventplatzierung hauptsächlich daran orientieren muss, da der eigentliche grafisch sichtbare Teil der Map komplett in den pics steckt. Dementsprechend wärs natürlich auch schon nett wenn so ein Maker die notwendigen Vorraussetzungen für praktikables Overlaymapping von Haus aus mitbringt und nicht wie beim Ace extra Skripte notwendig sind. Keine Ahnung ob sowas möglich ist, aber das wäre eine Funktion wo ich, sofern die anderen für mich wichtigen Funktionen des Ace nicht beschnitten sind, wirklich über einen Wechsel nachdenken würde.
Ich glaube nicht dass es möglich ist alles was z.B. Ruby kann in eine GUI zu quetschen welche gleichermaßen die Programmierung vereinfacht und eine schnellere und flexiblere Arbeit ermöglicht als der Texteditor.
Schau dir mal z.B. Scratch (http://de.wikipedia.org/wiki/Scratch_(Programmiersprache)) an. ;)
Das sind zwar Kindgerechte Programmiersprachen, aber die laufen komplett über die GUI. Die Kinder können sich durch Klicken und Schieben ganze Scripte Schreiben. Mitsamt Verzweigungen und Schleifen.
Etwas praxisnaher wäre hier übrigens Stencyl (http://www.stencyl.com/), welches auch tatsächlich in der Produktion verwendet wird.
Whiz-zarD
13.01.2014, 15:49
Etwas praxisnaher wäre hier übrigens Stencyl (http://www.stencyl.com/), welches auch tatsächlich in der Produktion verwendet wird.
Google hatte da auch mal was für Android-Apps gebastelt. Das wurde aber mit Google Labs eingestampft.
http://de.wikipedia.org/wiki/App_Inventor
Ich weiß nicht obs schon mal irgendwo hier genannt wurde, aber wenns schon um den perfekten Maker geht wäre es für mich (und vermutlich auch viele andere die mit Overlaymapping arbeiten) eine absolut großartige Arbeitserleichterung wenn man fürs Mapping verwendete Bilder auch direkt im Mapeditor anzeigen lassen könnte. Momentan arbeite ich noch so, dass ich anhand des geöffneten Bildes die Passierbarkeitsebene im Mapeditor erstelle und mich dann z.B. bei der Eventplatzierung hauptsächlich daran orientieren muss, da der eigentliche grafisch sichtbare Teil der Map komplett in den pics steckt. Dementsprechend wärs natürlich auch schon nett wenn so ein Maker die notwendigen Vorraussetzungen für praktikables Overlaymapping von Haus aus mitbringt und nicht wie beim Ace extra Skripte notwendig sind. Keine Ahnung ob sowas möglich ist, aber das wäre eine Funktion wo ich, sofern die anderen für mich wichtigen Funktionen des Ace nicht beschnitten sind, wirklich über einen Wechsel nachdenken würde.
Das ist sehr einfach möglich; ist notiert und danke für die Beteiligung.
Kasenoru_
13.01.2014, 18:24
Ich weiß nicht ob es schon genannt wurde, aber wie wäre es eigentlich mit einem dynamischen Dungeon-Generator? Also das man zur Laufzeit nach bestimmten Einstellungen zufällige Maps generieren kann um z.B. sowas wie die Ahnenhöhle in Lufia oder den Turm von Azure Dreams, wer die Spiele kennt, umzusetzen. Verbessert mich, aber der Dungeon-Generator vom VX ist ja nur statisch?
Klar gibt es sicher Scripts für den XP/VX, aber ich persönlich hätte das schon gerne im Editor mit drin, natürlich mit mächtigen Einstellungen um die Items, Monster, usw. festlegen zu können. Ein Konzept dazu habe ich mir zwar noch nicht überlegt, aber sowas würde ich toll finden. Gerade weil ich damals so viele Stunden mit Lufia und Azure Dreams verbracht habe ^-^
Ich weiß nicht ob es schon genannt wurde, aber wie wäre es eigentlich mit einem dynamischen Dungeon-Generator? Also das man zur Laufzeit nach bestimmten Einstellungen zufällige Maps generieren kann um z.B. sowas wie die Ahnenhöhle in Lufia oder den Turm von Azure Dreams, wer die Spiele kennt, umzusetzen. Verbessert mich, aber der Dungeon-Generator vom VX ist ja nur statisch?
Klar gibt es sicher Scripts für den XP/VX, aber ich persönlich hätte das schon gerne im Editor mit drin, natürlich mit mächtigen Einstellungen um die Items, Monster, usw. festlegen zu können. Ein Konzept dazu habe ich mir zwar noch nicht überlegt, aber sowas würde ich toll finden. Gerade weil ich damals so viele Stunden mit Lufia und Azure Dreams verbracht habe ^-^
Das ist eine knifflige Angelegenheit, da es schwer wird soetwas jedem Recht zu machen. Immerhin kann ja jeder Nutzer sein Spiel so handhaben wie er will, mit eigenen Kampfsystemen, Equipmentsystemen, Menüsystemen, etc.
Was natürlich sehr einfach wäre, ist es die Möglichkeit ein zu bauen, dass der Nutzer ganze Karten dynamisch zur Laufzeit erstellen kann. Dann kann man natürlich mit genügend Aufwand einen eigenen Kartengenerator programmieren. Ob ich selbst soetwas zur Verfügung stellen würde kann ich noch nicht sagen; es würde aber definitiv nicht die höchste Priorität genießen.
Trotzdem danke für die Anregung.
MagicMaker
13.01.2014, 22:10
Es sind für so ein Tool überhaupt keine ultrakomplexen Generatoren nötig, denn so ein Ding ist immer noch dazu da,
den Erstellern eine Grundstruktur für Höhlen und solchen Kram vorzuschlagen und mehr nicht.
Ausnahmsweise mal eine Sache, wo eb! bei VX einen guten Griff mit einer wirklich sehr einfachen Sache geleistet hat,
man muss nur den dümmsten unter den Usern klar machen, dass sie die ausgeschissene BodenWandDecken-Kombi
nicht als fertige Map nutzen sollen.
Das ist bei Random-Maps zur Laufzeit natürlich was anderes... vielleicht.
Powered by vBulletin® Version 4.2.3 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.