Danke soweit für die Beteiligung, ich versuche einmal auf die genannten Punkte einzugehen so gut ich kann:
Soetwas würde ich persönlich nicht gut finden.Zitat von Kelven
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.
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#Pat...streitigkeiten
OGG ist jedoch ein super Format; perfekt geeignet für soetwas wie Videospiele.
Auch Wave und Midi sind leicht umzusetzen.
Das ist vollkommen außer Frage. Das wäre das mindeste auf das ich mich einlassen würde.
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.
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.
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.
Ich denke ich würde absolut beliebige Tilegrößen erlauben. Auch 13 x 17 oder dergleichen. Technisch gesehen macht das überhaupt keinen Unterschied.
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.
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.
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.
Zitieren