Zitat Zitat von Hippokrates
Gut, ich muss zugeben, dass ich mich damit noch nie befasst habe, weswegen ich dazu auch nicht qualifiziert Stellung nehmen kann :rolleyes:
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.


Zitat Zitat
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 :D
Ah, stimmt. OGRE gehört natürlich in eine gute Engineliste.

Zitat Zitat
- 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 ;)
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...

Zitat Zitat
- 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.
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.

Zitat Zitat
- 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.
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.

Zitat Zitat
- 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.
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.

Zitat Zitat
- 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.
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*