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
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
--
Jup, auch wenn ich ich C++ nahe legen möchte, denn jeder hat da wohl schon so erfahrungen gemacht und kommt, selbst wenn nicht, Pascal, Java usw. lässt sich wunderpar in C++ "vereinen"
--Signature.
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...
Ich nicht. Mit Java sind komplette MMORPGs machbar - eine Spiele-IDE für tilebasierte 2D-Games sollte da kein Problem sein.
Enginetechnisch ist C++ natürlich überlegen - da haben wir Zugriff auf OpenAL, SDL, als 3D-Engine Irrlicht oder CrystalSpace, als 2D-Engine Kyra... Außerdem ist C++ natürlich schnell und hat viele Sprachbindings, was die Integration einer Skriptsprache vereinfacht.
IMO liegt der größte Vorteil von Java darin, daß wir ein portables GUI-Toolkit haben. Und mir fällt immerhin eine 3D-Engine ein, jIrr (ein Irrlicht-Port).
C++ wäre wahrscheinlich besser geeignet, weil bis auf die GUI-Verwaltung für den gesamten internen Kram eine Vielzahl von erprobten portablen Engines und Bibliotheken zur Verfügung steht.
Natürlich muß man dann auch aufpassen, daß die Lizenzen zusammenpassen - was im Endeffekt darauf hinausläuft, daß wir unser Projekt GPLen und nachsehen, ob alle Komponenten GPL-kompatibel sind. Ich würde mich für den lizenzrechtlichen Kram freiwillig melden; ich habe mich schon etwas mit dem Thema befaßt.
Coden möchte ich übrigens deshalb vermeiden, weil ich wenig Zeit habe und schon an einem größeren Projekt arbeite. Ich würde als Coder wahrscheinlich nicht viel Arbeit getan kriegen.
Außerdem mag ich C++ nicht besonders.
@Blade: Ruby ist gar keine so schlechte Idee - als Skriptsprache. Da glänzt Ruby.
So .
Also wenn das Projekt mit C++ gemacht wird so bin ich von nunan sofort an Board.
Wobei ich lieber bei der Engine als beim Interfase Helfen würde.Irgentwie sehen meine Interfase Gresstlich aus <_<
Also ich währe dafür das wir nun folgendes machen :
1-2 Wochen warten ob noch anderre Interesse Hätten.
Topic schliessen.Alle die Interesse hatten anschreiben nachfragen/testen.
Dann dürfte ein Guttes team von so 3-15 Leuten Übrig bleiben die Teilen sich dann auf in Engine - Interfase - usw.
--
Huuh, seit wann denn das? DU warst doch immer der Verfechter von C++, der Basic oder andere Sprachen für schlechter hielt (neuerdings allerdings nicht mehr, keine Ahnung warum) und sich dann mit C++ befasst hat und noch auf der Nato begeistert davon gesprochen hat. Was ist denn mit dir los?
--
Beschränkt ihr euch auf 2D oder auf 3D-Engine?
Das Projekt interressiert mich.Erinnert mich ein wenig an den Minerva wenn ich den Sinn des Threads richtig verstanden hab.
--Wegen wiederholter Beleidigung gebannt! ~ Knuckles
Ich Persönlich währe Stark für eine einfache 3D Engine also wo jedes eben-teil (Map viereck teil da wie beim Rpg mk2k) in jewals ihre Pixels unterteilt ist ich währe für eine 20x20 Pixel aufteilung.
jedes Fällt hat seinen eigenen Arrary mit 20 stellen wobei jede Spalte für einen Pixel steht.
Somit könnten wir schön Flächen Modelieren ^^ +1 steht für 1 pxel hoch -1 1 Pixel runter usw.
Dadurch könnten man ganz einfach die sicht auch verändern von Vogel auf Hinter sicht.
Jedenfalls währe das meine idee
--
Ich hatte Streß mit C++; vor Allem das lausige Stringhandling und die Abwesenheit eines zentralen GUI-Toolkits haben mich gestört. IMO merkt man C++ deutlich an, daß jemand C genommen und OOP draufgeschraubt hat.
Die abwärtskompatibilität zu C macht IMO die Sprache nicht gerade benutzerfreundlich; ich bevorzuge Sprachen, die aus einem Guß sind. Java ist ein Schritt in die richtige Richtung, setzt OOP aber nicht konsequent um. Trotzdem bleibe ich bei Java, weil die Sprache mit sich selbst voll kompatibel ist (im Gegensatz zu C++, wo man oft hin und hercasten muß, um mit den zahlreichen C-Komponenten zu interfacen) und ein eigenes GUI-Toolkit hat.
Also Dialoge schreiben solltest du jedenfalls nicht, so viele Rechtschreibfehler sind schon echt peinlich. (währe, Fällt, Arrary, Modelieren, jewals...)
Ansonsten, 20 x 20 Pixel sind bei Auflösungen von 1280 x 1024 viel zu klein. Wer braucht so exaktes Terrain? (Gerade bei 3D Grafik viel zu genau und unnötig belastend).
Es reichen da 128 x 128 Pixel völlig aus. (Sollte möglichst auch 2er Potenz sein, ist zumindest empfehlenswert wenn es eine eigene Engine werden soll. Dann lässt sich das mit OpenGL leichter händeln).
--
Das weiss ich auch nur wen ich an Maker denke dann an Max. auflösung 640 x 480 dafür währen 20x20 Kästchen Perfekt ^^ aber sonst stimm ich dir zu wenn wir es auflösung unabhänig machen währe das alle mal besser.
*in die Ecke geh und schäm*
--
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
Berechtigungen
Zitieren
