Ich könnte helfen, auch wenn ich noch nie was grafisches (also Fenster like) mit C[++] auf die Beine gestellt habe (lag allerdings daran das ich der WinAPI nix abkann und Linux noch nicht kannte). Kann PHP, Pascal (Delphi und halt standart Pascal), Basic, (bisschen) Assembler, (bisschen) Virsual Basic [Mag ich aber nicht besonders] und klar C(++) [Erfahrung: Linux und Windows Konsolen-Programme und OS-Dev [Betriebssystemprogrammierung]]
--Signature.
Ich finde das Projekt auf jeden Fall eine vernuenftige Idee und waere auch bereit, bei der Programmierung mitzuhelfen. Zumindest, solange es sich um C++ handelt XD Zur Not waere ich aber auch bereit, meine (bestimmt irgendwo noch vorhandenen) Javakenntnisse wieder aufzupolieren
Allerdings waere es tatsaechlich sinnvoll, wenn noch ein paar mehr Programmierer dabei waeren ^^;
Und ich persoenlich wuerde es sehr befuerworten, wenn wir Ineluki oder Jesus_666 oder beide zum "Chef" machen. Es wird naemlich auf Dauer noetig sein, dass irgendwer bei Streitfragen das Wort hat. Sonst haben wir 17 Leute im Team mit 17 verschiedenen Ideen zu der Frage ob man "int iFoo" oder "int foo" schreibt. Das wuerde dann nicht wirklich zu was fuehren.
Natuerlich ist es immer am Besten, moeglichst viel gemeinsam zu entscheiden, aber letztenendes muss jemand da sein, der sagt wo es langgeht sonst geht man unter XD
Ich jedenfalls haette auch kein Problem damit, mich jemand anderem unterzuordnen. Solange derjenige sein Geschaeft versteht und ein Team fuehren kann ist die Wahrscheinlichkeit, dass am Ende etwas dabei rauskommt naemlich vergleichsweise hoch.
Was die zu verwendende Technik angeht, so waere ich ebenfalls dafuer, dass man eine plattformunabhaengige Engine verwendet. Da muss man dann vielleicht noch etwas dran rumbasteln aber es sollte schneller gehen als eine eigene zu schreiben ^^;
---------Edit------------------
Ich muss allerdings gleich dazusagen, dass ich im Moment in Japan bin und bis zu meiner Rueckkehr in 3 Monaten und 2 Wochen keinen PC habe, auf dem ich programmieren kann ^^;
Allerdings sollten wir uns eh ein bisschen Zeit nehmen und vernuenftig planen
--Bin zur Zeit in Japan und habe deswegen keinen PC zu Hause
Geändert von Hippokrates (27.04.2005 um 10:52 Uhr)
Jo ich würde Programmieren ! Mit Kylix kenn ich mich zwar nicht aus hab aber ein Buch dazu! Wenn wir ihn in Delphi schreiben bin ich dabei^^ ich kann auch noch ein bisschen VB,PB,C++ und html ...aber ich würde lieber Proggen wenn wir Delphi nehmen ^^
--Greetz to xD Helldog,bloody,Raiden,Chaik,Chuck und wer wars noch ...*überleg* dadie,Jesus,Crash und Manie
Geändert von Aretures (27.04.2005 um 12:09 Uhr)
Das ganze mit Delphi abzuwickeln wäre EXTREM Blöd -.-°
Man kann ja nicht DelphiX und nix benutzen und einen Maker auf der Basis von TImage bzw. TPaintBox vile Spaß *hust*.
Das wir C(++) oder Java nehmen steht also schon von vorneherein im Raum
--Signature.
Wenn das ganze in Java programmiert wird, würde ich auch mitproggen
Ich bin zwar nicht wirklich ein Meister darin, aber ich denke mal, das wird trotzdem reichen. Von Grafikprogrammierung hab ich allerdings keine Ahnung
--
Ich denke, es gibt für C++ die meisten und besten Engines. Viel Auswahl haben wir ja auch nicht. Immerhin sollten sie portabel und Open-Source sein. Außerdem sieht man hier ja, dass man mit C++ wenigstens auf einen kleinen gemeinsamen Nenner kommt. Ich beherrsche C++ auch ganz gut (ich kann zumindest alle wichtigen Grundlagen inklusive OOP, Pointer, type-casting etc.).
Wegen der Idee, dass wir unbedingt einen Chef brauchen, der manchmal auch über unsere Köpfe hinweg entscheidet: Das fänd ich nicht so klasse. Lieber hätte ich es, wenn wir gemeinsam alles ausdiskutieren.
Wie man an der Frage der Programmiersprache sehr gut sehen kann gibt es immer viele Meinungen. Das kann letztendlich zu einem Kompromiss fuehren, muss es aber nicht. Was aber macht man, wenn man sich nicht auf einen fuer alle akzeptablen Kompromiss einigen kann?
Meiner Meinung nach braucht man an solchen Punkten jemanden, der die Verantwortung uebernimmt und es entscheidet. Sonst kann man naemlich nur aufgeben, da man nicht weiterkommt, wenn man keine Einigung findet. Es geht hierbei nicht darum, "alles ueber unsere Koepfe hinweg zu entscheiden" sondern darum, dass es jemanden geben muss, der im Zweifelsfall das letzte Wort hat, weil man sonst eventuell ueber die laecherlichsten Probleme das ganze Projekt aufgeben muss.
--Bin zur Zeit in Japan und habe deswegen keinen PC zu Hause
Dann frage ich mich, warum wir nicht einfach demokratisch abstimmen, wenn wir keinen geeigneten Kompromiss finden können. So wären dann doch zumindest die meisten Leute zufrieden. Außerdem muss so eine Abstimmung sich nicht unendlich lange hinziehen. Man kann immer noch ein zeitliches Ende setzen und dann die Stimmen auszählen.Zitat von Hippokrates
<_> das als AQbstimmung zu machen wäre nicht gut ...denn fast jeder würde seine Sprache wählen und dann würde die halt auch gewinnen <_> das könnte sogar Logo oder Rubby werden ...es kommt nur drauf an wie viele Leute von jeder Sprache mit abstimmen .... wenn die meisten mit Delphi Proggen wirds Delphi ..wenn die meisten mit C(++) Proggen wird's C(++) und so weiter ..ich fänds besser wenn der Big Boss das enscheiden würde ..wenn wir einen hätten ..einen Leiter des Projekts sozusagen ^^
--Greetz to xD Helldog,bloody,Raiden,Chaik,Chuck und wer wars noch ...*überleg* dadie,Jesus,Crash und Manie
Wo ist denn das Problem? Wenn die meisten C++ können, dann werden sie C++ auch wählen. Hinterher benutzen wir die Sprache, die die meisten Projektmitglieder beherrschen und haben umso mehr fähige Programmierer...
Dann wird das ganmze also in C++ geschrieben ..verdammt ...und was soll ich jetzt machen <_> ich will auch helfen ...*C++ lern*
--Greetz to xD Helldog,bloody,Raiden,Chaik,Chuck und wer wars noch ...*überleg* dadie,Jesus,Crash und Manie
Ich denke ebenfalls, dass es durchaus auch moeglich ist, mit Java sowas auf die Beine zustellen. Zumal Java auch schon bei weitem nicht mehr so langsam ist, wie anfangs.
Allerdings gibt es, wie gesagt, fuer C++ die meisten Bibliotheken (meines Wissens auch GUI-Libraries), was die Arbeit erleichtern koennte.
Zum Beispiel muesste man eben keine eigene Engine schreiben, sondern koennte keine fertige Engine benutzen.
@dadie:
Also erstens ist es sowieso keine sonderlich gute Idee, irgendwas Pixel fuer Pixel zu rendern und ausserdem koennte man, selbst wenn man das taete noch lange nicht einfach die Perspektive kippen
Da muesste man schon eine komplette 3D Terrain Engine verwenden. Das wurde uebrigens bei Grandia gemacht, was auch IMHO sehr cool aussieht. Man hat einfach eine 3D Umgebung genommen und 2D Charaktere reingesetzt - IMHO sehr stylisch, aber fuer einen Maker wohl nicht das richtige XD
@Jesus_666:
Da du (und Ineluki ja wohl auch) an der Programmierarbeit ja wahrscheinlich nicht mitwirken koennt, wuerde ich es sehr begruessen, wenn ihr euch verstaerkt um die Planung und Verwaltung des Projektes kuemmern wuerdet. Waere das ok?
--Bin zur Zeit in Japan und habe deswegen keinen PC zu Hause
Dummerweise gibt es für C++ kein GUI-Toolkit, das sich überall wirklich gut integriert; ich würde in der Hinsicht aber GTK+ und wxWidgets für ausreichend befinden.
Ein Array von Pixelwerten halte ich auch für unsinnig. Es gibt fertige Engines, die Texturen verarbeiten können, und falls wir tatsächlich eine 3D-Umgebung mit Sprites machen (wofür wir mit Irrlicht und CrystalSpace gute Engines zur Verfügung haben) werden wir sowieso mit Texturen arbeiten.@dadie:
Also erstens ist es sowieso keine sonderlich gute Idee, irgendwas Pixel fuer Pixel zu rendern und ausserdem koennte man, selbst wenn man das taete noch lange nicht einfach die Perspektive kippen
Da muesste man schon eine komplette 3D Terrain Engine verwenden. Das wurde uebrigens bei Grandia gemacht, was auch IMHO sehr cool aussieht. Man hat einfach eine 3D Umgebung genommen und 2D Charaktere reingesetzt - IMHO sehr stylisch, aber fuer einen Maker wohl nicht das richtige XD
Sicher, sicher. Ich melde mich ja schon für die rechtliche Verwaltung freiwillig und würde auch allgemein den Maintainer spielen, besonders für OS X-Binaries. Ich denke, ich könnte uns auch eine Roadmap erstellen, wenn wir das Projekt bis zur Startfähigkeit organisiert und uns auf die Grundlagen geeinigt haben.
Folgendes muß auf jeden Fall noch ausdiskutiert werden:
- Machen wir das Projekt Open Source oder geschlossen? (Open Source ist wahrscheinlicher, weil wir so Zugriff auf die ganzen Bibliotheken kriegen)
- Welche Lizenz verwenden wir? (Vermutlich GPL, aus dem selben Grund)
- Welche Zielgruppe haben wir? Leute mit Programmiererfahrung, typische Maker-User, beide?
- Wie setzen wir dann das Skripting um? Dabei müssen wir auf die Zielgruppe achten. Mit welcher Skriptsprache arbeiten wir?
- Was sollen Grafik- und Soundengine leisten können? Wollen wir den Stand des RMXP erreichen oder den von Ragnarok Online? Ist es realistisch, daß wir unser Ziel erreichen? Macht es das Programm zu kompliziert?
- Welches Datenformat verwenden wir? Hier müssen wir bei einem Binärformat beachten, daß auf dem Mac die Byteendigkeit anders ist.
Gut, ich muss zugeben, dass ich mich damit noch nie befasst habe, weswegen ich dazu auch nicht qualifiziert Stellung nehmen kann
Ich persoenlich favorisiere ja die OGRE-Engine (www.ogre3D.org) weil sehr gut strukturiert und sehr weit fortgeschritten. Es gibt auch eine Erweiterung der Engine, um mit einem GUI-System zusammenzuarbeiten.
Aber in Sachen Engine wird man sich sicher einigen koennen
Find ich schonmal gut, wenn du dabei bist
- Ich waere natuerlich fuer Open-Source. Sowieso wegen des Zugriffs auf andere Projekte, als auch deswegen, weil es ja ein Forenprojekt ist und moeglichst viele Leute davon profitieren sollen. Das Teil soll ja nicht verkauft werden, sondern viele Leuten Spass machen
- Ich behaupte mal, dass es sich nicht wirklich lohnt, Menschen mit Programmiererfahrung zur Zielgruppe zu machen. Ich waere eher dafuer, das Programm flexibel, aber benutzerfreundlich und leicht verstaendlich zu machen. Man koennte sich allerdings ueberlegen, ob man dem Maker eine Art "Einsteigermodus" verpasst, sodass Leute ohne Programmiererfahrung erstmal mit "Click&Play" arbeiten koennen um dann spaeter auf die Skriptsprache umzusteigen. Dazu koennte man zum Beispiel vorgefertigte Skripte etc. mitliefern.
- Skriptsprachen gibt es ja relativ viele. Und ich selbst habe nicht sonderlich viel Erfahrung damit. Allgemein wird Lua ja recht viel verwendet und scheint dank LuaBind auch recht einfach zu integrieren sein. Wenn man allerdings Lua verwendet muesste der Nutzer des Makers ein gewisses Verstaendnis von Programmiersprachen haben. Dieses Problem liesse sich allerdings, wie oben erwaehnt, durch so etwas wie einen "Einsteigermodus" abmildern.
- Bei der Grafikengine sollten wir uns nicht zuviel vornehmen. Auch wenn man eine tolle 3D-Engine verwendet muss man ja nicht all ihre Features nutzen. Auch sollte man Ruecksicht auf Menschen nehmen, die keine Radeon 9800 Pro besitzen und deshalb nicht unbedingt Vertex-Shader fuer eine Tile-Map verwenden XD Ausserdem muss man ja auch immer bedenken, dass eine komplexere Engine es auch schwieriger macht, Gamecontent zu erzeugen. Wenn man, zum Beispiel, eine Grafik-Engine wie in Grandia verwenden wuerde, saehe sich der Benutzer aufeinmal gezwungen fuer alles und jedes 3D-Modelle zu bauen ^^; Das ist zwar machbar, duerfte aber gerade fuer Anfaenger doch eine ziemliche Huerde sein. Auch das kann man durch mitgelieferte Modelle etc. abmildern - man muss sich aber die Frage stellen, ob man wirklich eine 3D-Grafik haben muss.
- Als Dateiformat waere ich ja ehrlich gesagt extrem fuer XML. Es gibt Freeware Parser (TinyXML), es ist absolut plattformunabhaengig und sowohl einfach zu verstehen, als auch einfach zu verwenden und zu warten. Bei binaeren Daten hat man ja schon immer das Problem, dass man sie sich nicht mal eben anschauen oder per Texteditor veraendern kann
Allerdings ist XML natuerlich nicht fuer ein Tile-Map Dateiformat geeignet. Da muesste man dann wahrscheinlich wieder mit binaeren Daten arbeiten. Man koennte aber die Level-Definitionsdateien, die Informationen ueber Trigger, Scripte, NPCs und so weiter enthalten in XML schreiben.
(ich habe in meinen Text ganz oft das Wort "ich" eingefuegt um klarzustellen, dass das nur meine eigene subjektive Meinung ist
--Bin zur Zeit in Japan und habe deswegen keinen PC zu Hause
Die meisten TKs, die zwischen Windows und Linux gut funktionieren scheitern an OS X, weil sie da X als Grafikserver voraussetzen - was bei OS X nur als Unterprogramm realisiert ist, sich nicht mit dem normalen OS X-Look-and-feel integriert und vergleichsweise häßlich aussieht. Keine Ahnung, wie's mit wxW aussieht.
Ah, stimmt. OGRE gehört natürlich in eine gute Engineliste.
Denke ich auch, wir gewinnen nichts, wenn wir es closed machen. Aber manche Leute sind ja der Meinung, daß niemand jemals ihren Code sehen darf...
Wahr. Ich würde vorschlagen, daß wir eine Skriptsprache integrieren und den Usern erlauben, über ein Point-and-Click-Interface wie bei den Makern einfach Code zu erstellen, wobei sie Zugriff auf alle nötigen Grundfunktionen haben. Man könnte den so erstellten Code als Metacode speichern (beispielsweise als XML) und dann vor der Ausführung in den richtigen Code übersetzen. So können die User grundsätzlich im grafischen Interface bleiben (wenn wir gleich zu richtigem Code übersetzen könnte die Rückübersetzung Probleme machen, wenn man per GUI was ändern will) und wir haben intern trotzdem alles in einer Sprache.
Lua ist eine Idee; Ruby wäre eine andere. Ich weiß nicht, wie es mit dem C(++)-Binding aussieht, aber Ruby hat natürlich den Vorteil, daß es einfach und mächtig ist.
Auch wahr. 3D würde das Programm sowohl in der Programmierung als auch in der Verwendung wesentlich komplizierter machen.
Allenfalls 2D-Maps mit einer Heightmap und Sprites drauf könnte ich mir gut vorstellen.
Wenn wir dann noch die zlib oder LZO mit reinnehmen hätten wir plattformübergreifend komprimiertes XML, das Platz spart (allerdings auch etwas langsamer ist). Für die Maps müßten wir mal sehen, wie wir das machen. Da wäre alles möglich, von einem eigenen Binärformat bis hin zu einem Metaformat wie es von OpenOffice verwendet wird (mehrere Dateien in einem Archiv; so könnten wir binäre Mapdaten (vielleicht als 8-bittige PNGs?) und Skriptdaten zusammen speichern).
Hmm, ich scheine heute meinen kreativen Tag zu haben. ^_^ *freut sich auf seinen DSA-Abend*
Das haette ich zum Beispiel garnicht gewusst
Das sind dann aber definitiv nicht die Leute, die wir suchen
Solange wir es schaffen, alle Features des Makers in ein Point-and-Click Interface zu bringen, ohne, dass es all zu kompliziert wird, ist das wohl die beste Idee. Allerdings sollten wir sehr genau ueber die Variablen nachdenken. Ich fand es immer extrem nervig, im RM2K alle Variablenoperationen ueber ein extra Dialogfenster zu regeln =_=
Ich habe mich mit Ruby nie befasst und kann daher dazu nichts sagen. Aber wenn es einfach an C++ anzubinden ist, steht einer Verwendung ja an sich nichts im Wege
Da muesste man dann allerdings aufpassen, ob die Tiles nicht verzerrt werden und ganz graesslich aussehen ^^;
Ein Metaformat ist sicher eine gute Idee. Allerdings wuerde man bei der Verwendung von 8-bit PNGs fuer die Mapdaten vorraussetzen, dass es nur 1 Tileset mit maximal 255 Tiles gibt. Da muesste man dann ueberlegen, ob das reicht.
*freut sich auf Jack Daniels (mit gekauftem Eis und eventuell Cola) und Password: Swordfish (laeuft heute im japanischen Fernsehen XD)*
--Bin zur Zeit in Japan und habe deswegen keinen PC zu Hause
Hmm, offenbar gibt es für Qt und GTK Ports, die auf Cocoa (OS X-Toolkit) aufbauen und sich besser integrieren. Das Problem ist, daß die meisten Leute nicht-native Versionen installiert haben, um Abhängigkeiten zu befriedigen. Man müßte da also entweder die Bibliothek doppelt installieren oder Inkompatibilitäten riskieren oder mit schlechtem Fook-and-Feel leben.
Die mangelnde Einbindung von X zeigt sich vor Allem darin, daß jedes X-Programm seine eigene Menüleiste hat und nicht das OS X-Aussehen übernimmt. Das beißt sich schon arg mit dem Rest des Interfaces.
Das sind die Leute, die alle bisherigen Makerklone gebastelt haben. :/
Das Variablenmanagement der Maker-Serie ist allgemein grottig. Ich denke schon, daß Zuweisungen á la $blubb = $foo + $bar - (4 / $quux) machbar sein sollten.
Die gesamte Funktionalität werden wir wohl nicht in ein PnC-Interface packen können, aber die wichtigsten Sachen schon. Wenn wir eine komplette OOP-fähige Skriptsprache wie Ruby unter dem Kasten haben können wir viel Funktionalität in ihr implementieren, was den Usern die Möglichkeit gibt, Subklassen von unserem Kram anzulegen und damit ihren Spaß zu haben. Der RMXP hat mit RGSS genau das und es gefällt mir... Für Point-and-Click ist es natürlich etwas zu heftig, aber das wird die meisten User wohl auch nicht stören.
Ich hatte Ruby bisher nur als eigenständige Skriptsprache; es gibt ein C++-Binding namens C++Ruby. Außerdem könnte man auf SWIG zurückgreifen.
Ruby ist eine sehr bequeme Sprache mit konsequentem OOP - alles ist ein Objekt. Das erlaubt Konstrukte wie folgendes:
Yup. Wie gesagt, das ist das dreidimensionalste,was ich mir vorstellen könnte.
Kommt drauf an... Mehrere Ebenen würde ich ohnehin dadurch realisieren, daß im Archiv mehrere PNGs sind - dann könnte man auch jeder PNG ein Tileset zuweisen. Mit 8 Bits ist ein Tileset zwar auf 256 Tiles beschränkt, alles darüber würde aber IMO entweder zu unübersichtlich großen Tilesets führen (65536 Tiles pro Set?), die Mapdateien ineffizient oder die Verwendung von PNG unmöglich machen - und damit würden wir uns ein gutes, verlustfrei komprimiertes Bitmapformat durch die Lappen gehen lassen.
Man könnte natürlich sehen, ob man nicht n Bit zur Speicherung des Tile-Indexes und den Rest zur Speicherung sonstiger Daten nimmt. So könnte man ein 16-bittiges PNG verwenden, in dem 10 Bits für den Tile-Index (1024 Tiles) und 6 Bits für sonstige Informationen wie Passierberkeit stehen.
Du Sau! Was empfängst du Glückspilz japanisches Fernsehen? Daß du in Japan bist ist keine Entschuldigung! *g*
Geändert von Jesus_666 (29.04.2005 um 13:34 Uhr)
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 ...
--
Auchg bekannt als 16 Bit-PNG mit Alphakanal.
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.
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.
Geändert von Ineluki (30.04.2005 um 21:42 Uhr)
Sehr schoen, dann haben wir mit Jesus_666 und Ineluki schon mal jemanden an der Hand, der das ganze steuert
Allerdings wirds jetzt ja erst richtig kompliziert, weil wir anfangen muessen, alle Grundlagen zu durchdenken und noch ein paar Leute zu gewinnen, die mitmachen
Wir muessten uns also ueberlegen:
1) Wo wir die weitere Diskussion fuehren - hier oder woanders. Wir sollten uns auf jeden Fall eine Moeglichkeit suchen, unsere Ideen irgendwie zu ordnen, sonst geht das alles in einem 100-Seiten langen Thread unter XD
2) Wir muessten sehen, dass wir mindestens 4 Programmierer (Jesus und Ineluki aussen vor) haben (IMHO). Grafiker und Tester und so weiter werden wir auch brauchen, zunaechst aber reichen ja Programmierer. Spaeter, wenn wir schon was vorzuzeigen haben, koennen wir auch sehen, ob es Leute gibt, die das Programm testen und Content erstellen, den wir mitliefern koennen.
3) Wir muessen eine Programmiersprache festlegen (sieht bis jetzt sehr nach C++ aus).
4) Wir muessen uns auf eine Engine einigen (Reine 2D-Engine oder doch lieber 2D-Grafiken mit einer 3D-Engine anzeigen?).
5) Wir muessen eine Skriptsprache festlegen (zur Sicherheit). Sieht schonmal sehr nach Ruby aus.
6) Wenn sich genuegend Leute finden, die mithelfen, muessen wir eine Roadmap erstellen und anfangen, Aufgaben zu verteilen ^^;
Naja, das sind so meine Gedanken. Alles weitere ueberlasse ich Ineluki und Jesus_666 XD
@frozen_reality:
Natuerlich kann man mit XML "alles" darstellen. Bloss hatte ich mir zu der Zeit, als ich den Post geschrieben habe halt gedacht, dass das einen recht grossen Overhead erzeugen wuerde, weil eine Mapdatei ja sehr_viele Informationen enthaelt. Wenn man es zippt, gehts aber wahrscheinlich ^^
--Bin zur Zeit in Japan und habe deswegen keinen PC zu Hause
Berechtigungen
Zitieren
