Dipl. User mit summa cum laude
Ich werde mich natuerlich auch gern zur Planung und V erwaltung bereit erklaehren, und auch zu Vorschlaegen von Konzepten und Algorithmen.
Ich und Jeez machen sicherlich auch gerne die Projektleitung mit entscheidungen im Zweifelsfall.
Das mit dem PNG Format klingt schon nett, allerdings ist zu ueberlegen, ob man nicht eventuell zwei Mapformate unterstuetzen sollte. Das eine waere wie gehabt ein png Format, doch ich wuerde 24bit vorschlagen, 10bit Tileinfo, 6 bit MoveInfo und nochmal nochmal 8 bit fuer eventuelle Alphatransparenz, was ganz nette Effekte machen koennte ^__^. Das zweite Format koennte ich mir als absolutes XML vorstellen, welches letztlich gezipt wird. Das haette den Vorteil fuer uns, dass es garantiert beliebig ausbaufaehig ist, und alle unsere eskapaden, die wir vielleicht planen werden, mitmachen wird.
Was die Sktiptsprache angeht, denke ich auch hier eventuell an eine Dreifachloesung ...
Eine primitive (assembleraehnliche) Basissprache, wie sie der Rm2k benutzt, und die vollstaendig KlickiBunti ist, zum zweiten Ruby als Scriptsprache, und zum dritten das compilieren und linken mit der GCC (was eine installierte GCC Version fuer das entwicklungs-System vorraussetzt), was uns eine grosse Auswahl von Sprachen verwenden laesst, wie C++, ObjectPascal, Fortran90, usw ... Eventuell koennte man ja noch JavaBytecode hinzunehmen ...
Das sinnvollste wird auch sein, in der oben genannten Reihenfolge vorzugehen. Wir muessen erstmal die Engine fertig haben und den Mapeditor. Wenn das alles steht, geht es an die Entwicklung einer API, worin wir alles kapseln, was unsere Engine kann. Fuer die API fuehren wir dann die ClickiBunty Sprache ein, die sich wirklich auf das wesentliche konzentriert. Allerdings soll auch diese Sprache, entgegen zum Maker, auch Eingabefaehig sein. Danach schreiben wir einen Port bzw ein Interface unserer API fuer Ruby, und fuehren den Rubyinterpreter in den Kampf. Als Letztes folgt dann nur noch das bereitstellen der API nach aussen hin ueber Headerfiles, und die Unterstuetzung von dynamischem Linken.
Aber die Scriptsprache ist wohl vorerst noch Zukunftsmusik ... da gibt es dringendere Sachen. ...
Die Sache mit der Hightmap finde ich eigentlich ganz hybsch, allerdings bringt uns das in Teufels Kueche, denn um eine drehbare isometrische Ansicht kommen wir dann nicht herum, da in der typischen Maker 90° Perspektive kein unterschied zu sehen waere. Wir muessten also solche sachen wie Skyboxen hinzunehmen, bekaemen probleme mit Kollisonsabfragen bzw Multilayermaps. Und auch die so beliebten Panorama und Picturelayer (die ich gern allesamt beliebig erweiterbar haette) wuerden uns Probleme aufhalsen, da sich die Perspektive je nach Drehwinkel aendert.
Also mein klarer Anspruch heisst somit NEIN zu offensichtlichem 3D.
Natuerlich werden wir aber wohl insgesamt um 3D nicht herum kommen, allerdings nur dazu, dass es uns in unseren Absichten helfen kann.
Die Perspektive wird fest auf senkrecht nach unten gelegt. Allerdings kann jeder Layerposition ein freiskalierbarer Z-Wert zugeordnet werden. Der Held befindet sich immer auf Z=0. Tilemaps befinden sich sinniger weise meist unterhalb des Helden im Minusbereich, genau so wie die Parallaxebenen, die eigentlich nur Bildebenen sind. Im Grunde kann jede Ebene, ob sie nun Mapebene oder Tileebene ist, jeden beliebigen Z wert annehmen, was uns ueberragende Vorteile gegen ueber dem Rm2k bringt. Allerdings wir die Perspektive so gelegt, das keine Verkleinerung mit Entfernung in Z auftritt. Dadurch loesen wir gleichzeitig das Clippingproblem, da durch den Z Puffer automatisch tieferliegende Ebenen von Hoehrliegenden verdeckt werden, es sei den, sie sind transparent.
Nun ja .. das waeren so meine Ideen, die mir spontan einfallen ...
Zitat von Hippokrates
Zitieren
Fragt sich nur, was man dagegen tun kann ^^;
