Neues Forenprojekt - portabler RPG / Adventure Maker ?

[Jesus_666]

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 ^__^.

...

Auchg bekannt als 16 Bit-PNG mit Alphakanal.

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.

...

Ich denke, daß ein Bitmapformat zur Darstellung der Tileverteilung am besten wäre; man könnte allerdings generell 24+8bittiges PNG verwenden und einfach in einer XML-Datei festlegen, wie es interpretiert wird - falls uns 32 Bit pro Tile nicht reichen können wir immer noch ein Tile als n*n Pixel definieren, was uns 32*n² Bit gibt.

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.

...

Also legen wir den Unterschied zwischen zwei Ebenen als den kleinsten Höhenunterschied, den die Engine verarbeiten kann, fest? Ich bin mir nicht sicher, ob es 3D-Engines gibt, die nichtperspektivische Darstellung unterstützen, also könnten wir an der Größenänderung nichts machen.


@Ruby vs. PHP: IMO hat Ruby mehr syntaktischen Zucker als PHP und ist ein Stück einfacher zu lernen; beides wertvolle Eigenschaften für unsere Skriptsprache. Mann könnte natürlich auch versuhen, Unterstützung für mehrere Sprachen zu bieten - obwohl uns das auch in Teufels Küche bringen könnte.
Generell kann man jede Skriptsprache, die man in einer dynamisch gelinkten Bibliothek unterbringt, vom Hauptprogramm unabhängig updaten - das ist kein direkter Vorteil von PHP gegenüber Ruby oder Lua.
Lua würde ich übrigens wohl nicht weiter beachten - es ist Ruby sehr ähnlich, hat aber weniger syntaktischen Zucker. Und der ist für uns wichtig.