Neues Forenprojekt - portabler RPG / Adventure Maker ?

[Entstanden aus "Suche Team Mitglieder für eine Spiele IDE"]

hm .. man koennte natuerlich als Progforenprojekt (aehnlich wie bei Onsetsu) versuchen einen portablen Maker auf die Beine zu stellen. Ein CVS wird sich sicherlich auch irgendwo einrichten lassen, und der Rest sollte sich dann von allein ergeben, wenn die Grundlagendiskussionen erledigt sind, z.B. mit welcher Programmiersprache man das ganze machen will.

falls wir uns aber auf den GCC festlegen sollten, waere das auch nicht das grosse problem, da das Objectformat doch afaik einheitlich ist, und somit praktisch doch egal sein sollte, mit was was geschrieben ist, solange es die GCC compilieren kann und ld es linken, oder ?

Als scriptsprache wuerde ich generell dynamisch gelinkte bibliotheken vorschlagen, bei denen auf eine von uns gestellte API zurueck gegriffen wird. Das hat den Vorteil, dass man praktisch mit beliebigen Programmiersprachen "skripten" kann, wodurch das gesamte Potential einer Sprache ausgeschoepft wird und desweiteren keine eigene Scriptsprache implementiert werden muss.

Wer wuerde sich denn fuer sowas bereiterklaehren ?

Ich wäre generell interessiert, vor Allem für Planungs- und Verwaltungskram.

Wenn wir das Projekt opensourcen kriegen wir bei SourceForge CVS und Webspace; ansonsten müßte ich mal sehen, wie's bei der Uni aussieht - ich kann mir zwar ein CVS-Repository anlegen, weiß aber nicht ob das auch für außeruniversitären Code erlaubt ist.
Vielleicht würde es auch Sinn machen, sich mal mit SVN zu befassen; das wird aber AFAIK nicht von SF zur Verfügung gestellt.

Hmm ich würde schon gern mit machen ..aber ich denke das ist ein bisschen zu groß für mich ^^ an Portable Maker hab ich noch nie gedacht. Aber vielleicht kann ich ja doch was helfen <_< is nämlich ne echt coole idee ..jaja

Ich könnt ein paar meiner Tilesets zur Verfügung stellen, für Templates oder einfach nur zum Testen. Ansonsten hab ich eher wenig Erfahrung mit portabel Programmieren, zwar mit C kein Problem, aber da ich mit der WinAPI meine Fenster gestalte ist da nix mit portabel...

Nun ja ... wenn wir eine fertig GraphikAPI nehmen, die von grundauf portabel ist, dann ist das nicht viel anders, als plattformabhaengiges Programmieren.

Zur Not koennten wir aber vielleicht in der Planungsphase auch mal ueber die Verwendung von Java diskutieren. Seit meinen Java 1.1 Zeiten soll sich, was Schnelligkeit angeht, ja einiges getan haben. Ob es allerdings fuer soetwas komplexes reicht, wage ich zu bezweifeln.

Eventuell koennte man auch etwas kleiner anfangen, und sich an einem Adventure (Monkey Island Stil) Maker versuchen. Der wuerde wegen seinen grossflaechigen Graphiken zumindest von der Engine her wesentlich einfacher sein, und man koennte viel Code auch spaeter fuer den RPG Maker wiederverwenden.

Ich stuende zwar auch nicht unbedingt zur Programmierung bereit, allerdings wuerde ich mich auch an Planung und Verwaltung beteiligen.

Ich würde evtl. mitmachen (wollen), das Problem:

Code:

---

mq.kentnisse("Java") == 0
mq.kentnisse("Delphi") == 0
mq.kentnisse("C(++)") == 0.2

---

Am besten kenne ich mit mit Php und Python aus (letzteres soll angeblich sogar recht gut in C(++) integrierbar sein), aber die Sprachen werden dann wohl nicht zur Anwendung kommen; und mit grafischer Programmierung habe ich mich auch noch nicht wirklich beschäftigt.
Oder ich mach 'ne Website und ein Forum (wobei Dingsi sich dafür wohl auch anbieten würde, womit ich wieder arbeitslos wäre), was bei dieser frühen "Planungsphase" allerdings etwas übertrieben ist.

Hi! Hab mich zwar grad erst angemeldet, aber ich wäre auf jeden Fall gerne mit dabei! Was ich für das Projekt beitragen könnte wäre:

- Programmierung (Ich kann mehrere Sprachen ein bisschen)
- Website-Programmierung
- Schreiben von irgendwelchen Texten (aber nur deutsche Texte. Fremdsprachen sind nicht so mein Ding *g*)
- Planung oder sowas in der Art
- (vielleicht noch was, das ich vergessen hab)

Die Idee find ich auf jeden Fall super! :)

Ich könnte eine wap site für eventuellen seitenzugriff maker bezüglich basteln.
mit portable sprachen kenne ich mich nicht so aus!

Ich würde mal sagen, da die meisten Leute eher nichts mit der richtigen Arbeit, nämlich dem Programmieren, zu tun haben wollen, wird das wohl nichts werden. Jeder möchte zwar irgendwo mitmachen aber auch nicht zu viel und dann beratend. Das ist also alles irgendwie ein Projekt welches aus einer Laune heraus entstanden (oder besser - enstehen soll) und keiner sich richtig reinhängen wird.

Zitat:

---

Zitat von Ynnus

Ich würde mal sagen, da die meisten Leute eher nichts mit der richtigen Arbeit, nämlich dem Programmieren, zu tun haben wollen, wird das wohl nichts werden. Jeder möchte zwar irgendwo mitmachen aber auch nicht zu viel und dann beratend. Das ist also alles irgendwie ein Projekt welches aus einer Laune heraus entstanden (oder besser - enstehen soll) und keiner sich richtig reinhängen wird.

---

Ich glaube nicht, dass es so sinnvoll ist, bereits jetzt das Projekt zum Scheitern zu verurteilen...

Zitat:

---

Zitat von Frozen Reality

Ich glaube nicht, dass es so sinnvoll ist, bereits jetzt das Projekt zum Scheitern zu verurteilen...

---

Ich geb Sunny... wtf... Ynnus o.ô - aber trotzdem mal volles Dito.

Natuerlich habt ihr recht, aber vielleicht finden sich doch ein paar mutige, die es zumindest versuchen wollen, und wenn sie erstmal bei Sourceforge sind, koennten sich durchaus noch andere Leute dazugesellen.

Mit diesem Thread wollen wir in erster Linie zeigen, dass wir solch ein Projekt unterstuetzen wuerden. Es liegt im Prinzip einer Idee, das sie das Potential hat, andere Leute zu begeistern, und wer weiss, vielleicht wird es ja ein Selbstlaeufer.

In jedem Fall kann man allerdings durch die Diskussionen zu dem Thema sehr viel lernen. Sei es nun, welche Graphikengines sich dafuer anbieten wuerden, sei es, wie man eine API aufbaut, sei es, wie man am besten Multylayertilesetstrukturen verwaltet.

Dabei spielt es keinerlei Rolle, ob das Projekt wirklich mal fertig wird, denn der Weg ist das Ziel.

Also ich währe sofort dabei.

Muss halt nur 1 bis 2 Wochen mich umgewöhnen von Pascal und PHP auf C / C++
Sobald das fertig ist währe ich bereit ^^ ich muss aber alle vorwahnen ich habe noch nie mit Porablen sachen gearbeitet und mit OpenGL (was woll benutz wird) auch nett aber das kann man nachollen ^^

Zitat:

---

Zitat von dadie

Muss halt nur 1 bis 2 Wochen mich umgewöhnen von Pascal und PHP auf C / C++
Sobald das fertig ist währe ich bereit ^^ ich muss aber alle vorwahnen ich habe noch nie mit Porablen sachen gearbeitet und mit OpenGL (was woll benutz wird) auch nett aber das kann man nachollen ^^

---

PHP, VB und Java kann ich auch oO
und C / C++ lernen kann ich auch oO

Aber ich glaube trotzdem, dass ich dabei kaum eine große Hilfe sein kann
(höchstens bei ner Website, Forum.. etc. aber dann kommt wieder Dingsi und schnappt mir das weg :( )

Naja falls mich einer brauchen sollte: PN ;)

Zitat:

---

Zitat von Ynnus

Ich würde mal sagen, da die meisten Leute eher nichts mit der richtigen Arbeit, nämlich dem Programmieren, zu tun haben wollen, wird das wohl nichts werden.

---

Komisch. Das habe ich auch beim ersten Lesen dieses Threads gedacht.
Btw, ich find's auch toll und wuerde gerne helfen. Aber nur was HTML und Textformatierung mit WordPad angeht. Achja, und schwachsinnige Ideen kann ich auch bieten, aber davon habt ihr ja scheinbar schon genug. :p

Nein, mal im Ernst. Hier haben sich, soweit ich das ueberblicken kann, noch nicht sehr viele fuer den richtigen Schwerpunkt (das Programmieren) gemeldet. Wie soll das etwas werden? Ist ja schoen und gut, dass der Weg das Ziel ist und die Fertigstellung keine Rolle spielt. Aber grosse Projekte anfangen, die nie fertig werden, kann jeder alleine, denke ich.
Naja ich will mal nicht zu gemein sein, also viel Spass und Glueck. Oder ist dieser Thread einfach eine zynische Satire auf die ganzen 'Projekt-Vorstellungen'?

Um doch mal etwas ernsthaftes zu schreiben: Ich finde so ein Projekt auch interessant. Aber ein Projekt mit 10 Mitarbeitern, von denen 2 programmieren, ist da schon weniger interessant. 'Qualitaet vor Quantitaet' sollte auch ein gutes Prinzip fuer die Zusammenstellung eines Teams sein.

freundliche Gruesse. Rolus

Zitat:

---

Zitat von Xecrypt 2k

PHP, VB und Java kann ich auch oO
und C / C++ lernen kann ich auch oO

---

Du musst es Lernen ich muss mich nur umgewöhnen ;) ich kann ja C (teilweisse) nur der Syntax ist eben ein Komplett anderrer als bei z.B. Pascal auch sind manche befehle anderrs
naja in iener woche sage ich mal wie weit ich bin ^^

Auserdem muss ich mich auch beim C umstellen den ich nutze den MS Optimierten Compiler
Microsoft Visual C++ Toolkit 2003 (nicht schlagen)

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]]

Zitat:

---

Zitat von dadie

Also ich währe sofort dabei.

Muss halt nur 1 bis 2 Wochen mich umgewöhnen von Pascal und PHP auf C / C++
Sobald das fertig ist währe ich bereit ^^ ich muss aber alle vorwahnen ich habe noch nie mit Porablen sachen gearbeitet und mit OpenGL (was woll benutz wird) auch nett aber das kann man nachollen ^^

---

Ich denke mal, dass nicht OpenGL direkt benutzt wird, sondern eher eine portable Open-Source-Grafikengine. Macht ja auch viel mehr Sinn, fertige Bibliotheken zu benutzen, als alles von Grund auf zu programmieren.

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

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

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

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 :D

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"

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.

Zitat:

---

Zitat von Hippokrates

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.

---

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.

<_> 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 ^^

Zitat:

---

Zitat von Blade

<_> 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 ^^

---

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

Zitat:

---

Zitat von Ineluki

Nun ja ... wenn wir eine fertig GraphikAPI nehmen, die von grundauf portabel ist, dann ist das nicht viel anders, als plattformabhaengiges Programmieren.

Zur Not koennten wir aber vielleicht in der Planungsphase auch mal ueber die Verwendung von Java diskutieren. Seit meinen Java 1.1 Zeiten soll sich, was Schnelligkeit angeht, ja einiges getan haben. Ob es allerdings fuer soetwas komplexes reicht, wage ich zu bezweifeln.

---

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.

Zitat:

---

Zitat von Jesus_666

Außerdem mag ich C++ nicht besonders.

---

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? :confused:

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.

Zitat:

---

Zitat von Archeo

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.

---

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

Zitat:

---

Zitat von Ynnus

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? :confused:

---

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.

Zitat:

---

Zitat von dadie

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

---

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

Zitat:

---

Zitat von Ynnus

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*

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?

Zitat:

---

Zitat von Hippokrates

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.

---

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.

Zitat:

---

@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

---

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.

Zitat:

---

@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?

---

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.

Zitat:

---

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.

---

Gut, ich muss zugeben, dass ich mich damit noch nie befasst habe, weswegen ich dazu auch nicht qualifiziert Stellung nehmen kann :rolleyes:

Zitat:

---

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.

---

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

Zitat:

---

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.

---

Find ich schonmal gut, wenn du dabei bist :D

- 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 :D)

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:

---

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:

---

- 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:

---

- 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:

---

- 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:

---

- 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:

---

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

Zitat:

---

Zitat von Jesus_666

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.

---

Das haette ich zum Beispiel garnicht gewusst :D Fragt sich nur, was man dagegen tun kann ^^;

Zitat:

---

Ah, stimmt. OGRE gehört natürlich in eine gute Engineliste.

---

:D

Zitat:

---

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

---

Das sind dann aber definitiv nicht die Leute, die wir suchen ;D

Zitat:

---

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.

---

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 =_=

Zitat:

---

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.

---

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

Zitat:

---

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.

---

Da muesste man dann allerdings aufpassen, ob die Tiles nicht verzerrt werden und ganz graesslich aussehen ^^;

Zitat:

---

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

---

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)*

Zitat:

---

Zitat von Hippokrates

Das haette ich zum Beispiel garnicht gewusst :D Fragt sich nur, was man dagegen tun kann ^^;

---

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.

Zitat:

---

Das sind dann aber definitiv nicht die Leute, die wir suchen ;D

---

Das sind die Leute, die alle bisherigen Makerklone gebastelt haben. :/

Zitat:

---

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 =_=

---

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.

Zitat:

---

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

---

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:

Code:

---

5.times do
 print "OMG! Ruby kann zählen!\n"
end

---

Zitat:

---

Da muesste man dann allerdings aufpassen, ob die Tiles nicht verzerrt werden und ganz graesslich aussehen ^^;

---

Yup. Wie gesagt, das ist das dreidimensionalste,was ich mir vorstellen könnte.

Zitat:

---

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.

---

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.

Zitat:

---

*freut sich auf Jack Daniels (mit gekauftem Eis und eventuell Cola) und Password: Swordfish (laeuft heute im japanischen Fernsehen XD)*

---

Du Sau! Was empfängst du Glückspilz japanisches Fernsehen? Daß du in Japan bist ist keine Entschuldigung! *g*

Zitat:

---

Zitat von Hippokrates

Allerdings ist XML natuerlich nicht fuer ein Tile-Map Dateiformat geeignet.

---

Soweit ich weiß ist XML für alles geeignet :)
PS: Ich wäre auch sehr stark für Open Source! Wenn erfahrene Leute ein Feature einbauen wollen, dass wir nicht berücksichtigt haben, machen die es einfach über den Quellcode. Wär doch klasse.

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

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 :D
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 ^^

Ich kann euch zwar nicht Aktiv helfen, da Onsetsu meine Zeit komplatt verschlingt... aber wenn ihr wollt könnt ihr gern Webspace auf dem Onsetsu Server haben bis alles geregelt ist und ihr eventuell zu SourceForge zieht.
PHP5 und MySQL Datenbank sind bei um ein Forum einzurichten.

Allerdings find ich schade das ihr, Ineluki und Jeez euch so viel vornehment obwohl gerade du Luki, nicht die Zeit findest ins Onsetsu Forum zu sehen um dich ein wenig zu beteiligen... da wir gerade in einer so schweren Phase sind.
Aber du wirst schon deine Gründe haben :(

Zitat:

---

Zitat von Hippokrates

5) Wir muessen eine Skriptsprache festlegen (zur Sicherheit). Sieht schonmal sehr nach Ruby aus.

---

Ich währe STARK dagegen !

es gibt um einiges bessere Script sprachen die auch um einiges einfacher sind.
Meine Idee währe eine PHP abwandlung (mit möglichkeit Variablen zu beschreiben [int , blob usw.] )

Ruby ist GUT
Ruby ist einfach
PHP ist etwa genausogut aber NOCH einfacher.

ICh währe darum für PHP

Und recht leicht einzubauen, um das mal zu ergänzen. Da wüsst ich euch schon jemanden, der euch da helfen könnte. Ein weiterer Vorteil ist, dass man durch Auswechseln der php5ts.dll PHP unabhängig vom Restlichen Maker updaten kann. Dazu kommt, dass es für PHP viele Extensions gibt, die sich alle verwenden lassen.

Naja, zu PHP kann ich nix sagen, weil ich das noch nie benutzt habe XD
Allerdings kannte ich es bis jetzt auch nur als serverseitige Skriptsprache fuer das Web und habe noch niemanden getroffen, der es fuer ein Spieleprojekt eingesetzt hat ^^;
Naja, man lernt ja nie aus XD

Ich bin ja sowieso nach wie vor fuer Lua, bin aber auch mit jeder anderen Skriptsprache zufrieden - solange sich denn eine ueberzeugende Mehrheit fuer eine der Sprachen findet ;)

Zitat:

---

Zitat von dadie

Ich währe STARK dagegen !

es gibt um einiges bessere Script sprachen die auch um einiges einfacher sind.
Meine Idee währe eine PHP abwandlung (mit möglichkeit Variablen zu beschreiben [int , blob usw.] )

Ruby ist GUT
Ruby ist einfach
PHP ist etwa genausogut aber NOCH einfacher.

ICh währe darum für PHP

---

Ich finde Ruby besser als PHP.
PHP ist mehr für Webanwendungen ausgelegt (Ich habe nicht gesagt das es nur fürs Web ist, weil Jeez oder sonstwer mich sonst zu Tode quasselt das es auch auf Commandline läuft und bla bla).

Und Allgemein, wer will schon PHP im Maker?
Ich finde PHP ist eine grausame Sprache, ich kanns nicht wirklich begründen, aber mir hängt PHP schon zu den Ohren raus. :/


Achja, wegen CVS und so.
Also auf dem Onsetsu Server lässt sich das einrichten, wenn ihr nicht zu SourceForge wollt (ausserdem stinkt SourceForge :P).

Kann jemand mal bitte ein paar mehr Informationen zu Lua geben? Z. B. wie die Syntax aussieht, welche Vor- und Nachteile es hat etc.

Ein bisschen was ueber Lua findest du hier.
Wenn du dich auf der Seite bis zum Wiki durchklickst (unter dem Link "Community" zu finden) kriegst du alle Informationen, die du haben willst.
Generell ist Lua jedenfalls sehr populaer und wurde AFAIK fuer Grim Fandango von Lucas Arts verwendet.

Zitat:

---

Zitat von Ineluki

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.

Zitat:

---

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.

Zitat:

---

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.

Eigentlich muesste man fuer eine nichtperspektivische Darstellung ja nur eine orthogonale Projektionsmatrix setzen (so war das glaub ich XDD). Und das muesste sich eigentlich mit den meisten Engines machen lassen. Oder irre ich mich da ^^;

@Ruby vs. PHP:
Sollte das der Fall sein, wuerde in der Tat sehr vieles dafuer sprechen, Ruby zu nehmen ^^

Öhm, in welcher Sprache wird das jetzt gemacht, oder steht das noch nicht fest? Ich hab' da den Überblick verloren.

Als Scriptsprache würde ich mich auch für Ruby aussprechen. Php kann ich zwar besser, aber Ruby hat deutlich mehr Möglichkeiten, eine einfachere Syntax und eine bessere Objektorientierung.

Wie bindet man solche Scriptsprachen überhaupt in sein Projekt ein? Den Aufwand dafür sollten wir auf jeden Fall auch berücksichtigen.

Zitat:

---

Zitat von Frozen Reality

Wie bindet man solche Scriptsprachen überhaupt in sein Projekt ein? Den Aufwand dafür sollten wir auf jeden Fall auch berücksichtigen.

---

Im Wesentlichen, indem man eine Bibliothek einbindet und ein Objekt erstellt, das die Interpretation von Skripten handhabt.

Die Diskussion hier wird langsam etwas unübersichtlich - man sollte mal sehen, ob sich da nicht eine bessere Möglichkeit finden läßt. Vielleicht ein eigenes Forum?

Zitat:

---

Zitat von Jesus_666

Die Diskussion hier wird langsam etwas unübersichtlich - man sollte mal sehen, ob sich da nicht eine bessere Möglichkeit finden läßt. Vielleicht ein eigenes Forum?

---

Wäre eine gute Idee, ich würde mich auch als Foren-Admin (und evtl. Webiste-Progger) anbieten. Momentan habe ich aber leider nur funpic (ich muss mir unbedingt mal eigenen Space kaufen).
Kannst du das nicht auf rpgmaker.info parken (zumindest vorläufig)?

Zitat:

---

Zitat von masterquest

Wäre eine gute Idee, ich würde mich auch als Foren-Admin (und evtl. Webiste-Progger) anbieten. Momentan habe ich aber leider nur funpic (ich muss mir unbedingt mal eigenen Space kaufen).
Kannst du das nicht auf rpgmaker.info parken (zumindest vorläufig)?

---

Welch schlaue Idee. Ich werde mir mal eine Forensoftware organisieren.

-> http://rpgmaker.info/phpBB2/

Zitat:

---

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

---

Sag das nicht. onsetsu hat genauso begonnen und hat sich prächtig entwickelt.

1. Hab ich zuerst beim Lesen des Threads auch gedacht: "Never.", aber irgendwie hat mich beim weiterguggn doch so eine kleine.. mh.. Euphorie gepackt. Vielleicht wirds ja doch was.

2. Schade um Ineluki und Jeez... ich hoffe, dass ihr dann noch genug Zeit für andere Dinge haben werdet. Habt ihr überhaupt genug Zeit für den XP-RPGM? (XP-RPGM vs RPGM-XP xD) (XP = Cross Platform)

3. Ich würd mich zwar auch gern beteiligen, ich find das ganze äußerst interessant, aber ich schon genug zu tun.. Ich werde aber trotzdem mitlesen.

4. Euer Forum braucht dringend ein besseres Design.

5. Wie wärs mit Yinc! als Skriptsprache? Nein, scherz. ^^ Was praxiserprobtes ist schon gut. Aber wie irgendwo erwähnt wärs vllt wirklich nicht schlecht wenn das ganze offen ist, so dass man ein bestimmtes Interface für ein XPRPGM-Skriptbinding und man dann beliebig Bindings mit diesem Interface schreiben kann. Der Maker selbst würde nur dieses Interface benützen. Mmh.

*wusch*

Mhmmm...
Ich will euch ja nicht den Spass verderben^^.Aber es gibt schon einen Portablen RPG MAker für Pocket Pc´s.Er wird von Smokingfish programmiert.Er hat für das Dingen schon einen Publisher und jede menge Support.Er portet den maker gerade auch auf JAVA Handys.

www.smokingfish.net

Dort findet ihr weiter infos dazu.(dies ist aber keine werbung ;))

Greetz Distarb

Das verlinkte Projekt scheint aber weder unter einer OSS-Lizenz zu stehen noch erweiterte Skriptfunktionen zu haben - das sind zwei Dinge, für für den PortaMaker (aka Yaldabaoth, aka Yao) geplant sind.

Zumal ich mir nicht ganz sicher bist, daß du das richtige "portabel" meinst. Wir sprechen nicht von "tragbar" sondern von "Plattform-agnostisch". Ich bin mir nicht mal sicher, ob man für Handies konzipierte J2ME-Software ohne Weiteres auf normalen J2SE-Systemen benutzen kann. (Und nein, Dotnet ist nicht portabel. Mono wird auf absehbare Zeit nicht in der Lage sein, normale Dotnet-Software auszuführen.)

OK, da klink ich mich mal mit ein. Ich gehör zu den wenigen, die Teile von Smokies Source haben. Ich hatte auch schon dran gedacht, dass wir Smokie fragen, ob wir die s2dmd.j Engine bekommen, aber erstens glaub ich kaum, dass er sie hergibt und zweitens ist die wohl auch nicht so leicht zu portieren.

moin,

die s2dmd engine k&#246;nnt ihr haben wenn ihr wollt. immo existieren eine windows version f&#252;r das pixelformat ARGB8888 und eine Version f&#252;r PocketPcs f&#252;r das format RGB565 (qvga mit gapi, vga mit getrawframebuffer) und i bin sicher die l&#228;sst sich auch noch anderweitig portieren

EDIT:
oh, dfyx i glaub du hast da was falsch verstanden. es gibt keine s2dmd engine f&#252;r java. der pocket maker l&#228;uft unter windows und pocketpc mit dieser engine sowie auf einigen smartphones. auf java benutze ich die standart renderaufrufe (aus midp 1.0). die komplexeren prpgm maps laufen da nur weil ich ne recht performante map engine gebastelt hab - mit der integrierten ist es unm&#246;glich sowas umzusetzen. und i glaub irgentwie net das ihr damit viel anfangen k&#246;nnt , sry ^^

Zitat:

---

Zitat von SmokingFish

moin,

die s2dmd engine könnt ihr haben wenn ihr wollt. immo existieren eine windows version für das pixelformat ARGB8888 und eine Version für PocketPcs für das format RGB565 (qvga mit gapi, vga mit getrawframebuffer) und i bin sicher die lässt sich auch noch anderweitig portieren

EDIT:
oh, dfyx i glaub du hast da was falsch verstanden. es gibt keine s2dmd engine für java. der pocket maker läuft unter windows und pocketpc mit dieser engine sowie auf einigen smartphones. auf java benutze ich die standart renderaufrufe (aus midp 1.0). die komplexeren prpgm maps laufen da nur weil ich ne recht performante map engine gebastelt hab - mit der integrierten ist es unmöglich sowas umzusetzen. und i glaub irgentwie net das ihr damit viel anfangen könnt , sry ^^

---

Ich bin mir nicht sicher ob du was falsch verstanden hast, aber mit portable ist gemeint, das es auf möglichst vielen Plattformen läuft (Win/GNU/UNIX etc)

Spars dir, codec, der Fehler lag bei mir.