Cuina Projekt

Ich arbeite seit kurzem an dem:

Cuina-Projekt (ehemals Java-RPG-Maker)

Dieser beinhaltet den Editor sowie eine dazu passende Game-Engine.
Projektbeginn: ~ Anfang 09.2011

Im großen und Ganzen, wird der Editor etwa so wie der XP aufgebaut sein, da ich mich größtenteils daran orientiert hab.
Das hat u.a. den Vorteil, dass die Ressourcen passen und die damit erstellten Karten mit Hilfe eines Exporters, zum XP kompatibel sind. (noch^^)
Allerdings soll er nicht so starr sein wie die von Enterbrain, sondern durch zusätzliche Plugins erweiterbar sein.
Das soll bisher die Sprache, Datenbank und die Eventfunktionen betreffen.
Ersteres ist bereits realisiert, Datenbank mehr oder weniger und bei den Events muss ich mir noch ein paar Gedanken zur Umsetzung machen.

Ich dachte daran, den Auslöser vom eigentlichen Event zu trennen, da man diesen ja öffter mal häufiger braucht.

Was bereits geht:
Editor:
- Projekte erstellen, laden und speichern.
- Karten erstellen, löschen editieren, importieren
- Karten editieren mit den üblichen Tools: Pinsel, Rechteck, Ellipse, Aufüllen.
- Objekte erstellen, löschen, editieren
- Regionen erstellen, löschen, editieren
- Sprache einstellen
- Objelktvorlagen bearbeiten.
vorhandene Datenbanken:
- Tilesets
- Events
- Objektvorlagen
- Helden (Dummy-Plugin)

Hier mal ein Screen-Shot des aktuellen Editors (Bitte Nicht auf die geklauten Grafiken achten^^):

Die 4 identlischen Symbole oben in der Leiste sind Platzhalter für Kopieren, Einfügen, etc.http://img638.imageshack.us/img638/5994/unbenanntfj.png

noch eben mal ein Projekt mit 2k-Chipset (ohne Zoom):
http://img43.imageshack.us/img43/9480/unbenannt16u.png

Wesentlich schlechter sieht es bei der Game-Engine aus, welche momentan nur ausreichend für Testzwecke funktioniert.
Das Basis-System funktioniert zwar schon sehr gut, was ein experiment bestätigt hat, bei dem ich die Titel-Szene vom XP duch JRuby-Interface-Klassen darauf zum laufen bekommen hab^^.
Die eigentlichen Spielfunktionen gehen aber noch nicht.
Das liegt hauptsächlich daran, dass hier die größte Herausforderung der Erweiterbarkeit liegt und zum Testen die nötigen Daten, die im Editor gesetzt werden müssen, fehlen.

Was aber bereits geht:
- Anzeige von Sprites
- Abspielen von Sounds
- Tastatur- und Maus-Eingaben
- Laden von Maps und Datenbanken
- Fenster (leider fehlen noch Teile vom Rahmen)

Und hier ein Screen von der Game-Engine:

http://img199.imageshack.us/img199/1...benannt2je.png

Die arbeiten daran werden sicher noch länger dauern.
Wer Teil des Entwicklerteams werden will, darf sich gere bei mir melden. (gute Java-kenntnisse sind Grundvoraussetzung)


So, nun würde ich doch geren wissen ob sich jemand vorstellen kann, damit ein RPG zu machen, oder eher nicht? (Und warum/warum nicht)
Irgendwelche Dinge, die ich noch beachten sollte?
Kritik, Ideen, anregungen, ... ?

Hi.
Zunächst: Sieht von dem was man schon sieht und von dem was man schon liest eigentlich erstmal gut aus. Die Frage, mit der du aber immer konfrontiert werden wirst wird sein, wieso man sich einen hobbynachbau des XP holen sollte, wenn man auch den XP nutzen könnte.
Vorstellen könnte ich es mir aber. Einige Fragen hätte ich aber schonmal:
- Wird der Maker explizit auf RPGs ausgelegt sein, oder doch eher auf 2D-Spiele?
- Sind die Spiele auch Java-Programme oder ist nur der Editor in Java geschrieben?
- Wird es die Möglichkeit geben, eigene Klassen oder Java-Code einzufügen?
- Kann man mit den von dir genannten Plugins auch Spiele erweitern oder nur den Editor?

Ich frage mich eher, wie die Performance bei einem featuregefüllten Spiel sein wird.
Und wieviele Mappingebenen wird es geben? Die bekannten 3, die 4 vom XP oder kann man sogar eine eigene Anzahl festlegen?

Zitat:

---

Zitat von Dennis

- Sind die Spiele auch Java-Programme oder ist nur der Editor in Java geschrieben?
- Wird es die Möglichkeit geben, eigene Klassen oder Java-Code einzufügen?

---

Die Antworten auf diese Fragen interessieren mich.

OpenGL, AWT? Was nutzt du?
Partikelsystem?
Skriptbar?
Wie viele Layer?
Quellcode? Lizenz?

Uff. Fragen über Fragen. Ok, ich versuch mal alle zu beantworten:

Zitat:

---

Zitat von Dennis

Zunächst: Sieht von dem was man schon sieht und von dem was man schon liest eigentlich erstmal gut aus. Die Frage, mit der du aber immer konfrontiert werden wirst wird sein, wieso man sich einen hobbynachbau des XP holen sollte, wenn man auch den XP nutzen könnte.

---

Es ist kein XP-Hobby Nachbau. Ich orientiere mich nur daran, er soll allerdings wesentlich besser werden. Was zunächst heißt dass er alle Features vom XP mindestens können sollte, ob er das am Ende auch tut ist eine andere Frage.^^
Außerdem bin ich noch recht am Anfang mit dem Editor zu gange. Und Der Map-Editor vom Enterbrain-Maker ist einer der besten und vor allem einfachsten im Umgang. Von daher hab ich das Grundkonzept davon erst einmal kopiert.^^

Zitat:

---

Wird der Maker explizit auf RPGs ausgelegt sein, oder doch eher auf 2D-Spiele?

---

Er soll für RPG's konzipiert werden. Was man am Ende damit noch machen kann. ka.

Zitat:

---

- Sind die Spiele auch Java-Programme oder ist nur der Editor in Java geschrieben?
- Wird es die Möglichkeit geben, eigene Klassen oder Java-Code einzufügen?
- Kann man mit den von dir genannten Plugins auch Spiele erweitern oder nur den Editor?

---

1. Alles wird in Java geschrieben.
2. Ja, in Form von Plugins, oder was meinst du? Ich hatte zeitweilig die Idee die Events als Sourcecode zu interpretieren, aber das würde eine Onborad-Java-Compiler verlangen und ich weiß nicht ob sich die Mühe wirklich lohnt einen einzubinden.
Dann wäre es natürlich ganz einfach möglich direkt Java-Satemants in Events zu benutzen.
Macht aber vermutlich eher Sinn diese erweitern zu können, als fehlende Features wie beim XP durch Sourcecode auszugleichen.
3. Da ich momentan nur am Editor arbeite kann ich nur sagen wie es bei der Gameengine geplant ist.
Generell ja, aber ich weiß noch nicht wie. Evtl. als Komplettmodule. z.B. das KS komplett austauschen oder so.

Zitat:

---

Zitat von relxi

Ich frage mich eher, wie die Performance bei einem featuregefüllten Spiel sein wird.
Und wieviele Mappingebenen wird es geben? Die bekannten 3, die 4 vom XP oder kann man sogar eine eigene Anzahl festlegen?

---

Die Performance ist gut. Wobei ich allerdings noch keinen echten Leistungstest machen kann und daher keine genauen Äußerungen dazu geben kann.
Ich hab momentan 3 Ebenen + nicht vorhandene Eventebene, was die Maps kompatibel zum XP macht, wodrin ich meinen ersten Test diesbezüglich gemacht habe. Geplant ist noch eine mehr. Mehr als 5 hab ich nie gebraucht, daher erscheint es mir unnötig da es nur unnötig Speicher und Performance zieht.

Zitat:

---

Zitat von niR-kun

OpenGL, AWT? Was nutzt du?
Partikelsystem?
Skriptbar?
Wie viele Layer?
Quellcode? Lizenz?

---

- Bisher Swing, such aber was anderes. Bin grad dabei Slick auszuprobieren.
- Nein,
- Gameengine ist geplant, editor nicht.
- siehe oben.
- Gameengine ist geplant, editor nicht.
- Ich hab mich mit Lizenzen nie beschäftigt, deshalb ka.

Ich hoff ich hab jetzt keine Frage vergessen.

Ich arbeite schon seid naja etwa 3 Monaten an einer RPG Engine (hab es aber irgendwie verpennt mal ne Vorstellung zu schreiben, hab es aber nachgeholt als ich das hier gelesen habe -> http://www.multimediaxis.de/threads/...ava-RPG-Engine).
Vielleicht ist es möglich beide Projekte zu verschmelzen, statt gegenseitig-konkurrierende Projekte zu schaffen.

Falls du Interesse hat, kannst du mich mal anschreiben, gern auch über ICQ oder MSN ;).

Zitat:

---

Zitat von niR-kun

Ich arbeite schon seid naja etwa 3 Monaten an einer RPG Engine (hab es aber irgendwie verpennt mal ne Vorstellung zu schreiben, hab es aber nachgeholt als ich das hier gelesen habe -> http://www.multimediaxis.de/threads/...ava-RPG-Engine).
Vielleicht ist es möglich beide Projekte zu verschmelzen, statt gegenseitig-konkurrierende Projekte zu schaffen.

Falls du Interesse hat, kannst du mich mal anschreiben, gern auch über ICQ oder MSN ;).

---

Wenn ihr euch mit diesem hier zusammenschließt seid ihr bereits 3 welche gleichzeitig solch eine Vorstellung geschrieben haben.

Schaut euch aber bitte nicht nur den Maker an ;) Wenn ihr ein XP 2.0 schreibt dann nutzt ich lieber den XP ehrlich gesagt. Nutzt die Möglichkeit von Java und macht bitte bitte alles editierbar und erweiterbar, kthxbye :)

Ansonsten Respekt, ich hätte keine Lust auf so was, da schreib ich lieber gleich mein Spiel in Java selber x_X Viel Glück (aber wie ich lese nutzt ihr ein Interface zu Ruby... Warum keine eigene Scriptsprache?)

Zitat:

---

Zitat von R.D.

Schaut euch aber bitte nicht nur den Maker an ;) Wenn ihr ein XP 2.0 schreibt dann nutzt ich lieber den XP ehrlich gesagt. Nutzt die Möglichkeit von Java und macht bitte bitte alles editierbar und erweiterbar, kthxbye :)

---

Die Vorstellung hier im Thread hört sich nach einem XP 2.0 an. Ich arbeite an etwas anderem. Das sollte aber schon bei meiner Vorstellung klar sein.

Zitat:

---

Zitat von R.D.

Ansonsten Respekt, ich hätte keine Lust auf so was, da schreib ich lieber gleich mein Spiel in Java selber x_X Viel Glück (aber wie ich lese nutzt ihr ein Interface zu Ruby... Warum keine eigene Scriptsprache?)

---

Warum das Rad neu erfinden? Ruby wird ja im RMXP und RMVX genutzt. Also kann Ruby nicht so schlecht sein.

Ich habe mit TheWhiteShadow schon Kontakt aufgenommen.

@Cornix:
Die ridiculousRPG-Engine soll ja unter Apache Lizenz gestellt werden. Das bedeutet also, dass diese Engine zwar frei ist, aber nicht zwingend OpenSource.
Besonders im Homebrew-Sektor sollte eine Engine von der Community für die Community sein, also eine kommerzielle Nutzung erst mal ausschließen und auf jeden Fall muss der Quellcode der Engine immer frei verfügbar sein. Ein weiteres Problem ist, dass man Forks der ridiculousRPG-Engine unter jeder beliebigen Lizenz stellen darf - egal ob frei oder nicht.

Zitat:

---

Zitat von niR-kun

Die Vorstellung hier im Thread hört sich nach einem XP 2.0 an. Ich arbeite an etwas anderem. Das sollte aber schon bei meiner Vorstellung klar sein.

---

Machst du jetzt auch noch in meinem Thread Werbung für deine Engine?

Es ist doch schön, wenn es ähnlich wie im Xp aussieht. Dann ist die Einarbeitungszeit für Umsteiger geringer.
Die eigentlichen Unterscheide werden später auch noch deutlicher. Und wie niR-kun bereits sagte, arbeiten wir gerade daran, beide Projekte zusammen zu legen. Sollte das Unterfangen von Erfolg gekrönt sein, wird es eh bald eine neue Vorstellung geben.
p.s. Linux sucks. ich editier den Text zuhause noch mal.
Edit: editiert.

Man brauch das Rad mit dem Interface ja nicht immer neu Erfinden.

Und wäre jedenfalls eine Verschwendung von Arbeitskraft, wenn ihr es nicht zusammenlegen würdet.
Ich wünsche jedenfalls viel Erfolg!

Zitat:

---

Zitat von Super17

Man brauch das Rad mit dem Interface ja nicht immer neu Erfinden.

---

Ganau. Für mich ist es die größte, ruhmreichste Errungenschaft, wenn man Quellcode eines anderen versteht und umbauen/warten kann, statt von Grund auf alles neu zu erstellen. Darauf baut mein Verständnis für Zusammenarbeit auch teilweise auf. Ich fühle mich grässlich, wenn mein Gegenüber das vorgibt zu können, aber Quellcode von mir derart ignoriert.
Ich weiß nicht, ob TWS so vom Ehrgeiz zerfressen ist, aber nach Zusammenarbeit sieht es im Moment außer dem gemeinsamen Projektnamen noch nicht aus - bedauerlich sowas.

Ich wage ja zu bezweifeln, dass auch nur einer von den hier vorgestellten rpg makern ein brauchbares stadium erreichen wird.

Solche Posts muessen die Entwickler auch unglaublich motivieren. :A

Zitat:

---

Zitat von nudelsalat

Ich wage ja zu bezweifeln, dass auch nur einer von den hier vorgestellten rpg makern ein brauchbares stadium erreichen wird.

---

Schubladendenken und Vorurteile. Eine Kombination um rumzutrollen.

Seine Zweifel sind durchaus berechtigt. Und solche Beiträge muss man erwarten, bei all den bisherigen Versprechen eine Alternative zum RPG Maker zu entwickeln, die nicht eingehalten wurden.

Was für mich momentan fehlt ist die Antwort auf: Warum deinen Maker nutzen wollen?
Was hat er dem XP voraus? Was macht er besser?
Für mich war z.B. die Performance ein gewisser Grund vom XP die Finger zu lassen.

Und die Zweifel das was dabei rauskommt ist begründet. Ich halte die Vorstellung auch noch für etwas überfrüht.
Wenn was wirklich nutzbares steht wäre sie besser. Zumal ein Mann Projekt immer so eine Sache für sich sind.

Ich finde die Idee toll.
Besonders wenn dieser Maker OpenSource ist und auf beliebige Funktionen & PlugIns erweiterbar ist.

Was ich bisher gesehen habe gefällt mir ganz gut.
Ich sehe da auch eine Menge Potential, wie beliebig große Charsets und nach belieben fein einstellbare Animationen.
Der Rm2k z.B. hat nur 3 Bewegungen pro Richtung für jede Figur, da wäre z.B. eine Erweiterung bis zu 4, 5 oder mehr eine nette Sache.

Viel Erfolg bei deinem Projekt TheWhiteShadow.
Ich bin gespannt was dabei rauskommt.

Grüße
netwarrior

Zitat:

---

Zitat von makenshi

Was für mich momentan fehlt ist die Antwort auf: Warum deinen Maker nutzen wollen?
Was hat er dem XP voraus? Was macht er besser?
Für mich war z.B. die Performance ein gewisser Grund vom XP die Finger zu lassen.

---

Soviel kann ich schon verraten:
Erstens sind der Maker inklusive Engine OpenSource und zweitens wird es einfach möglich sein, auch unter Solaris, MacOS, Linux, sowie Windows zu makern und mit der Engine zu spielen (ohne WINE zu nutzen). Das bietet Möglichkeiten jenseits von dem was Enterbrain je entwickelt hat.
Die Zeichen-Oberfläche der CuinaEngine ist durch OpenGL hardwarebeschleunigt, also im Vergleich zu den Runtimes von Enterbrain extrem leistungsfähig, wenn die Grafikkarte das mit macht.
Wenn du ein uraltes System hast, dann wird ich die CuinaEngine wohl nicht so schnell laufen. Das ist eben der Lauf der Zeit, dass man sich mal einen neuen PC zusammenbauen/kaufen muss.

Zitat:

---

Zitat von makenshi

Und die Zweifel das was dabei rauskommt ist begründet. Ich halte die Vorstellung auch noch für etwas überfrüht.
Wenn was wirklich nutzbares steht wäre sie besser. Zumal ein Mann Projekt immer so eine Sache für sich sind.

---

Hätte ich und TWS das nicht so früh vorgestellt, wäre es nicht zu einer Kooperation gekommen. Es ist also kein 1-Mann-Projekt mehr.
Ich empfehle übrigens auch den Rest des Threads zu lesen, bevor man postet.

Ich weiß, dass es viele Projekte der Art schon mal gab, die alle ein schnelles Ende gefunden haben.
Es ist unsere Pflicht jemanden zu finden, der das Projekt weiter führt, wenn wir es aus persönlichen Gründen nicht mehr fortführen können oder wir das Interesse am Projekt verlieren. Das unterscheidet unser Projekt von anderen.

Für jeden, der sich für OpenSource - und wie das nun funktioniert - interessiert, kann ich empfehlen folgendes zu lesen (auch wenn man nicht alle Begriffe versteht): http://gnuwin.epfl.ch/articles/de/Ka.../catb_g.0.html

Jeder der sich mit Java auskennt, kann sich an uns melden und mit machen. Wir sind sehr dankbar dafür, wenn jemand uns hilft (auch wenn das nur eine Kleinigkeiten ist).

PS: @netwarrior: Es ist unser Projekt. Und danke für die aufmunterden Worte.

Das Raster ist 32x32 Pixel? Ich empfinde es als ziemlich nervig, ständig die alten Grafiken zwecks Bearbeitung hoch- und runterzuskalieren, von daher ist dieser Maker wohl nicht so mein Ding.

Wenns was zum Laden gibt, werd ich ihn mir aber mal angucken. Wenigstens nur mal um zu sehen, ob die Performance besser als beim XP ist.

Ich finde das schon mal sehr interessant und hoffe ihr werdet viel Spaß haben an eurer Idee weiterzuarbeiten. Die Bilder sahen ja schon mal vielversprechend aus :3 Ich würde ja gerne mithelfen, aber ich bin in solchen Dingen eher der Typ der zwei linken Hände, wenn du verstehst xDD Aber da ihr ja jetzt ein Dreier (oder Zweier?) Team bildet, werdet ihr das bestimmt realisieren können. Ich freu mich jedenfalls schon darauf :3

Eine Nette Funktion wäre auch noch, wenn man die Auflösung vom Spielefenster
bestimmen könnte, und eventuell noch die Rasterauflösung zwischen 16x16 und 32x32 wechseln kann.
Keine Ahnung, ob das für euch im Bereich des möglichen ist, ich kenne mich da null aus.

@niR-kun

Ah, ihr habt euch zusammen geschlossen. Das ist was gutes. Dann sinkt die Chance das einer an Überarbeitung zusammenbricht.
Das ich das vorher nicht gelesen habe, liegt daran dass ich nicht genug Interesse dafür habe, als das ich den ganzen Thread dafür durchlese.
Sehe auch noch momentan keinen Grund dafür so viel Interesse aufzubringen.

Was die Engine einzubringen scheint, klingt im Prinzip gut. Nur müsste dafür überhaupt erstmal was fertig sein.
Ich tue mich immer etwas schwer zu jubeln wenn noch keine Ergebnisse zu sehen sind. Verständlich, will ich meinen.
Das die Engine das Spielen nun auch auf verschiedenen Plattformen ermöglicht, ist aus meiner Sicht uninteressant.
Zum Spielen und für Multimedia nutze ich ohnehin Windows, da hier auch die meisten kommerziellen Spiele existieren die mir Spaß machen.
Kann aus anderen Blickwinkel sicher interessant sein, denke ich.

Und abseits von der Engine fehlt es mir, dass der Editor mehr bietet als der XP selbst. Das sollte imo nicht erst durch
den Opensource Gedanken getragen werden, sondern im voraus schon vom Entwickler selbst.

Find die Idee ja ganz nett, gerade weil ich Linuxnutzer bin, aber bevor etwas Lauffähiges vorhanden ist, will ich nicht so recht dran glauben.

Ansonsten wenn der Maker eh Open Source werden soll, dann könntet ihr doch auch etwas offener entwickeln und das Projekt auf Google-Code oder einer ähnlichen Plattform bereit stellen. Ein interessierter Entwickler kann so sehen ob sich ein anschließen lohnt.


Ansonsten gibt es hier noch ein lauffähiges Projekt was ein ähnliches Ziel hat, aber in C++ geschrieben wird: http://gnurpgm.sourceforge.net/
Es scheint aber schon lauffähig zu sein und sich mehr am XP als am 2000er zu orientieren.

Zitat:

---

Zitat von Davy Jones

Das Raster ist 32x32 Pixel? Ich empfinde es als ziemlich nervig, ständig die alten Grafiken zwecks Bearbeitung hoch- und runterzuskalieren, von daher ist dieser Maker wohl nicht so mein Ding.

---

Der Editor unterstützt variable Tile-Größen.
Wie vielleicht aus dem 2. Editor-Sceeen ersichtlich sein sollte, hab ich ein RM2k-Chipset 1:1 benutzt. Allerdings werden diese auch als 16px angezeigt im Gegensatz zun 2k, wo sie auf 32px gestreckt wurden.

@ssj5000
Das Projekt ist auf SourgeForge gelagert.
Auch wenn ich bei der Seite 0 Überblick hab und total froh bin dort überhaupt ein SVN-Service eingerichtet bekommen hab.
Wenn jemand weiß wie man dort eine Projektseite einrichtet, soll er/sie sich melden.

Egal, seit gestern gibt es eine >Homepage< dazu, obwohl da noch so gut wie nichts steht.

Hier gibt es eine Seite die alles erklärt:
https://sourceforge.net/apps/trac/so.../Project%20web

Zitat:

---

Zitat von TheWhiteShadow

Der Editor unterstützt variable Tile-Größen.
Wie vielleicht aus dem 2. Editor-Sceeen ersichtlich sein sollte, hab ich ein RM2k-Chipset 1:1 benutzt. Allerdings werden diese auch als 16px angezeigt im Gegensatz zun 2k, wo sie auf 32px gestreckt wurden.

---

Da hab ich wegen der unterschiedlichen Screenshotgrößen nicht drauf geachtet, aber in diesem Falle könnte das dann doch eine echte Alternative zum 2k/2k3 werden =)

Erstmal warte ich allerdings ab, mal sehen was aus diesem kleinen Hybriden wird =)

Zitat:

---

Zitat von ssj5000

Hier gibt es eine Seite die alles erklärt: https://sourceforge.net/apps/trac/so.../Project%20web

---

Es ist nicht so, dass ich die Anleitungen von der Seite nicht gelesen hätte. Die sind nur alle nicht wirklich zu gebrauchen. Jedenfalls versteh ich dabei nur Bahnhof

Was ist daran so schwer?
1. Man nehme einen FTP Client wie Filezilla
2. Man gebe die Daten ein und verbinde sich
3. man lädt die Daten hoch
4. Seite betrachten

In dem Abschnitt Connection Settings stehen doch alle angaben die du eingeben musst. Ist doch nicht viel anders als bei jedem normalen Webspaceanbieter.

Aso, ne Webseite zu erstellen bekomm ich schon hin. Aber SoureForge bietet auch solche Sachen wie Blog, Ticker und Foren für ein Projekt an.
Nur hab ich keine Ahnung wie ich da zu einem öffentlichen Link komme.

Die Funktionen finden sich unter Projekt Admin > Features > Available Features

Ich würde zwar lieber ein Bild von der Engine zeigen, aber die sieht grad Optisch wie der XP aus und ne Tech-Demo dazu macht mehr Sinn, wenn es irgendwann soweit ist.

Solange muss ein weiterer Screen vom Editor reichen um zu zeigen, dass das Projekt stetig voranschreitet.

http://img443.imageshack.us/img443/1...benanntwyo.png

Ist jetzt zwar zweitrangig, aber könnt ihr keine qualitativ bessere Icons verwenden? :rolleyes:

So schlimm sind die doch nicht. o.o

Aber wenn es doch hübschere gibt, warum sollte man den bei den alten Icons bleiben? :)

Mit deiner Aussage beleidigst du mein kreativers Schaffen. Die Icons sind alle selbst gemacht und Ähnlichkeiten zu denen im RMXP sind gewollt um ein gewissen Maß an Vertrautheit zu schaffen.
Wenn du meinst sie wären nicht gut genug, beteilige dich produktiv daran.

Das sieht doch schon mal ganz gut aus.
Bin dann gespannt wann es die Beta zum testen gibt.

netwarrior

Zitat:

---

Zitat von TheWhiteShadow

Mit deiner Aussage beleidigst du mein kreativers Schaffen. Die Icons sind alle selbst gemacht und Ähnlichkeiten zu denen im RMXP sind gewollt um ein gewissen Maß an Vertrautheit zu schaffen.
Wenn du meinst sie wären nicht gut genug, beteilige dich produktiv daran.

---

Ich sehe da überhaupt keine Ähnlichkeiten zum RMXP und wofür brauche ich Vertrautheit bei den Icons? Also ich kann dir mit Gewissheit sagen, dass zb. bei Programmen das Speichersymbol eine Diskette ist (oder ist der Aufbau gemeint?). Schön für dich, wenn die Icons aus eigener Hand stammen, aber da denke ich mir: wofür, wenn es im unendlichen Internet ja viele frei zur Verfügung stellende Icons gibt? Doch welcher Normalsterblicher interessiert sich schon dafür, ob das Programm schöne oder hässliche Icons hat? Von daher lasse ich das jetzt auf mir ruhen, ich habe schon bereits begriffen, dass du meinen gut gemeinten Ratschlag nicht willst. Es ist dein Projekt, und mir steht es nicht zu, dir Anweisungen zu geben.

Zitat:

---

Zitat von Deamonic

Ich sehe da überhaupt keine Ähnlichkeiten zum RMXP und wofür brauche ich Vertrautheit bei den Icons? Also ich kann dir mit Gewissheit sagen, dass zb. bei Programmen das Speichersymbol eine Diskette ist (oder ist der Aufbau gemeint?). Schön für dich, wenn die Icons aus eigener Hand stammen, aber da denke ich mir: wofür, wenn es im unendlichen Internet ja viele frei zur Verfügung stellende Icons gibt? Doch welcher Normalsterblicher interessiert sich schon dafür, ob das Programm schöne oder hässliche Icons hat? Von daher lasse ich das jetzt auf mir ruhen, ich habe schon bereits begriffen, dass du meinen gut gemeinten Ratschlag nicht willst. Es ist dein Projekt, und mir steht es nicht zu, dir Anweisungen zu geben.

---

oh gott ... :rolleyes:

Ich wüsste nicht was an den Icons hässlich sein sollte. Und ihren Zweck erfüllen sie auch. Das einzige, was du vielleicht noch machen könntest, wäre die Kanten zu glätten (falls die Icons immer eine feste Größe haben).

Zitat:

---

Zitat von Kelven

Das einzige, was du vielleicht noch machen könntest, wäre die Kanten zu glätten (falls die Icons immer eine feste Größe haben).

---

Das sind aber so Sachen, die man hinterher auch noch machen kann.
Das Aussehen der Icons sollte erstmal eine extrem niedrige Priorität haben.

Das ganze klingt schonmal sehr gut - evt. würde ich den sogar nutzen wenn er fertig ist.

Was mich aber noch interessiert ist wie ihr die Events genau behandelt. Insbesondere ob es wie beim XP ein reines "zusammen klicken" von Befehlen ist, oder ob man (zusätzlich) noch die Möglichkeit hat, direkt Code zu schreiben (ähnlich wie der Code-Befehl im XP, nur ohne diesen unsäglichen automatischen Zeilenumbruch und mit genug (aka, soviel wie nötig) Platz).
Ich frage insbesondere wegen eurem angepriesenen Plugin-System für die Engine. Denn wenn ich die Engine um bestimmte Spielobjekte erweitere, möchte ich in Events natürlich auch auf solche Objekte Bezug nehmen und ihre Funktionen aufrufen.

Was mich am XP insgesamt am meisten gestört hat ist diese Beschränkung auf RPGs einer bestimmten Machart, wer etwas anderes als vorgesehen machen wollte musste massig Aufwand betreiben um das zu realisieren - insbesondere wenn es kein RPG war, man aber den tollen Map-Editor vom XP nutzen wollte.
Euer Maker hat durch die Plugin-Möglichkeit da sicherlich das Potential etwas einfacher zu sein, ich hoffe ihr baut im Interface da zumindest keine unüberwindlichen Hürden ein. (bspw. wie schwierig es wäre das Interface an andere Spieltypen anzupassen, immerhin ist das ganze ja Open-Source)

PS:
Eine Chance hier einen Link auf eure Source-Forge Seite zu posten? Zumindest bisher sehe ich hier keine Möglichkeit euren Quellcode einzusehen.

Ich weiß nicht, ob ich es schon mal erwähnt hab, jedenfalls werden die Events in Ruby-Code geschrieben. und greifen über eine Libary auf die Java-Funktonen zu.
Es ist möglich selbst darauf zuzugreifen, wovon ich aber tunlichst abraten möchte, wenn man nicht genau weiß was man tut.
Der Editor soll die wichtigsten Funktionen zum "zusammen klicken" beinhalten, diese lassen sich problemlos erweitern.
Um eigenen Code zu schreiben wird noch ein ein externer Editor benötigt. Ich werde auch keinen Ruby-Editor schreiben. Sollte es also keinen Open-Source-JRuby-Editor geben bleibt es dabei.

Zur Beschränkung:
Es bleibt eine Engine für klassische 2D-RPGs und ein Spiel zu produzieren ist immer enorm viel Aufwand. Die Engine soll den Entwickler eine Basis geben. Wer außerhalb dieser Basis etwas entwickeln will, muss einen Mehraufwand in Kauf nehmen, der aber i.d.R. geringer ist, als bei 0 anzufangen.
Mögliche Hürden lassen sich dabei duch gute Planung reduzieren, aber nicht vermeiden. Von daher sind wir auf angergierte Alpha/Beta-Tester angewiesen.

Der Editor ist auf die Engine abgestimmt und erlaubt Erweiterungen nur da, wo die Engine diese auch aufnehmen kann.
Allerdings kann man Exporter als plugins einbinden, wodurch man die damit erstellten Karten auch anderweitig benutzen kann.

P.S. ich hab immer noch keine Ahnung von Source-Forge. werd mich aber mal am WE damit befassen was hoch zu kriegen.

Die Engine ist zu viel mehr fähig als nur 2D-RPGs. Komplett 3D geht auch theoretisch schon, aber wer braucht das schon?
Ein schönes 2D-RPG ist doch viel besser als ein kantiges, hässliches 3D-Spiel.

@Deamonic: Wenn du schönere Icons haben willst, dann zeichne/mal uns doch welche. :)

@MagicMagor: Ich werde mal in Zusammenarbeit und Absprache mit tws mal schauen, wie wir das mit dem Quellcode machen können.

Zitat:

---

Zitat von niR-kun

Die Engine ist zu viel mehr fähig als nur 2D-RPGs. Komplett 3D geht auch theoretisch schon, aber wer braucht das schon?
Ein schönes 2D-RPG ist doch viel besser als ein kantiges, hässliches 3D-Spiel.

---

Wobei beides sich keineswegs ausschliesst.
Einige meiner absoluten Lieblingsspiele sind zB Final Fantasy Tactics (PS1) und Xenogears. Sie kombinierten in den Kämpfen die Flexibilität von 3d Hintergründen mit 2D animierten Characteren. Das Manko bei Xenogears war damals nur, dass die Charactere zu extrem gezoomt wurden und dadurch extrem pixelig wurden. Aber die Idee ansich ist zeitlos.
Ein Maker, der ein solches Battlesystem bieten würde, hätte bestimmt viele Anhänger. Mir jedenfalls gefällt sowas.

Leider hab ichs immer noch nicht zu einem vollwertigen Release geschafft.
Wusse nicht, dass Ein Eingabeformular so furchtbar viel Zeit in Anspruch nimmt.
Aber es läuft mehr oder weniger.

Jedenfalls stellt ich mal die Subversion-Link rein. (Ja, ich hab langsam einen Durchblick bei SF^^)

Engine:
http://svn.code.sf.net/u/thewhiteshadow/cesource/

Editor:
http://svn.code.sf.net/u/thewhitesha...editor/editor/

Eigentlich sollten es 2 unabhängige Prohjekte werden, aber um Redunanz zu vermeiden, greifen sie auf gemeinsame Ressourcen zu.

P.S. Ein KS wie FFT braucht nur ein 3D-Renderer. ICh hab keine Lust einen zu schreiben, würde aber helfen, wenn sich jemand dazu finden lässt.

mfg TWS

Hab mal eben kurz durch den Quelltext gestöbert. Mir sind ein paar Dinge aufgefallen die du (oder ihr, keine Ahnung ob du das Projekt jetzt noch alleine machst) vielleicht beherzigen solltest.

• Leg dir einheitlichere Conventions zu. Ich würde dabei zu den Standard Java Code Guidelines raten. Dann sieht dein Programm wie 99% aller anderen Java Programme aus, und wenn später mal jemand helfen möchte fällt das leichter. Aber egal welche Codeconventions du auch für dich entscheidest, vermische sie nicht. Einmal sehe ich multi_word_variable und einmal multiWordVariable. Auch sind Methodennamen wie _init() nicht gerade gängig. Der _ vor der Methode gibt mir das Gefühl die Methode sei irgendwie nur intern wichtig, aber dann ist die Methode public. Warum also der _? Mag unwichtig klingen, ist es aber nicht.
• Widerstehe dem Drang alles selber zu schreiben. Ich sehe da drin eine Klasse zum auslesen von Ini-Files. Die Properties Klassen aus Java machen genau das. Warum also neu schreiben?
• Das Userinterface sieht stark handcodiert aus. Nutz lieber einen GUI-Editor. Der spart dir enorm viel Zeit, und wenn er Databinding unterstützt umso mehr.
• Wirf Exceptions. Eine Methode wie "public abstract boolean finishEditing();" die false im Fehlerfall zurückliefert ist suboptimal. Wenn du schon keine Exceptions werfen möchtest (warum auch immer, die sind nämlich eine viel schönere Lösung zur Weitergabe von Fehlern), liefer wenigstens ein Fehlerobjekt zurück wo du Informationen über den Fehler lieferst. Es sieht ganz so aus als würdest du die Fehlerbehandlung in der finishEditing Methode selber machen müssen, und nur für den Caller den Hinweis geben, dass etwas schief gelaufen ist. Code Smell vom feinsten.
  Achja, und benutze Exceptions richtig.
  
  Code:

  ---

  try
{
        ini = new Ini(new File("editor.cfg"));
}
catch (IOException e)
{
        e.printStackTrace();
        return;
}

  ---

  In einem Konstruktur ist einfach nur scheusslicher Code. Man fängt eine Exception immer nur dort wo man sie auch richtig behandeln kann. Was du machst ist: Die Exception gleich an der erst besten Stelle zu fangen, und dann die Objektinitialisierung abbrechen. Derjenige der eine Instanz von der Klasse erstellt hat somit erstmal gar keinen Plan ob die Instanz überhaupt richtig erstellt wurde und arbeitet evtl mit einem unfertigen Objekt weiter ohne es zu wissen. Ganz übel.
• Pluginsysteme sind äußerst kompliziert zu schreiben. Greif lieber auf ein System wie das NetBeans Module system oder OSGi zurück.
• Schreib UnitTests. Die sind nicht nur ein guter Indikator für sauberen Code, sondern helfen dir auch dabei Stellen zu identifizieren wo du durch eine Änderung an existierendem Code, einen Fehler an anderen Stellen produziert hast, ohne nach jeder kleinen Änderung sämtliche Stellen manuell neu testen zu müssen.
• Verwende Ant oder Maven zum Bauen des Projektes. Damit können auch Leute wie ich, die kein Eclipse (vermute ich einmal) verwenden, dein Projekt bauen. Und du kannst CI Tools wie Jenkins verwenden.

Zitat:

---

Zitat von The_Burrito

Leg dir einheitlichere Conventions zu. Ich würde dabei zu den Standard Java Code Guidelines raten. Dann sieht dein Programm wie 99% aller anderen Java Programme aus, und wenn später mal jemand helfen möchte fällt das leichter. Aber egal welche Codeconventions du auch für dich entscheidest, vermische sie nicht. Einmal sehe ich multi_word_variable und einmal multiWordVariable. Auch sind Methodennamen wie _init() nicht gerade gängig. Der _ vor der Methode gibt mir das Gefühl die Methode sei irgendwie nur intern wichtig, aber dann ist die Methode public. Warum also der _? Mag unwichtig klingen, ist es aber nicht.

---

Das ist mir auch schon aufgefallen, allerdings ist das aber auch schon relativ alter Quellcode, der noch nicht an die festgelegte Convention angepasst wurde.

Zitat:

---

Zitat von The_Burrito

Widerstehe dem Drang alles selber zu schreiben. Ich sehe da drin eine Klasse zum auslesen von Ini-Files. Die Properties Klassen aus Java machen genau das. Warum also neu schreiben?

---

Unwissenheit, dass es so was gibt. :) Das wird zu gegebener Zeit ausgetauscht. Das ist so gewollt.

Zitat:

---

Zitat von The_Burrito

Das Userinterface sieht stark handcodiert aus. Nutz lieber einen GUI-Editor. Der spart dir enorm viel Zeit, und wenn er Databinding unterstützt umso mehr.

---

Die meisten GUI-Editoren erstellen einfach nur Spaghetti-Code. Das einzige vernünftige scheint der Swing Designer zu sein, den es erst ab Eclipse Indigo (oder war es doch Helios?) gibt.

Zitat:

---

Zitat von The_Burrito

Pluginsysteme sind äußerst kompliziert zu schreiben. Greif lieber auf ein System wie das NetBeans Module system oder OSGi zurück.

---

Von OSGi und NetBeans Module system hab ich schon mal gehört, aber beide noch nie benutzt. Auf der TODO-Liste vermerkt.

Zitat:

---

Zitat von The_Burrito

Schreib UnitTests. Die sind nicht nur ein guter Indikator für sauberen Code, sondern helfen dir auch dabei Stellen zu identifizieren wo du durch eine Änderung an existierendem Code, einen Fehler an anderen Stellen produziert hast, ohne nach jeder kleinen Änderung sämtliche Stellen manuell neu testen zu müssen.

---

Da eignet sich JUnit4 sehr gut für. Auf der TODO-Liste vermerkt.

Zitat:

---

Zitat von The_Burrito

Verwende Ant oder Maven zum Bauen des Projektes. Damit können auch Leute wie ich, die kein Eclipse (vermute ich einmal) verwenden, dein Projekt bauen. Und du kannst CI Tools wie Jenkins verwenden.

---

Die meisten nutzen ja Eclipse (oder NetBeans), weil sie nicht nur das Projekt bauen, sondern auch verändern/erweitern wollen. Vielleicht wird der Build-Process auf Ant oder Maven umgestellt, mal schauen. ;)Also jetzt gibt es ein von eclipse generiertes Ant Buildscript für jedes Projekt eins.

Ich habe gerade keine Zeit um mich um das Projekt zu kümmern. Dafür ist das Studium (besonders jetzt gegen Ende des Semesters) einfach zu zeit-fressend - in den vorlesungsfreien Zeiten und am Wochenende hab ich vor allem viel Zeit für das Projekt.
Du bist natürlich herzlichst eingeladen dich an dem Projekt zu beteiligen. ;)

EDIT:Kleines Update.

Zitat:

---

Zitat von niR-kun

Die meisten GUI-Editoren erstellen einfach nur Spaghetti-Code. Das einzige vernünftige scheint der Swing Designer zu sein, den es erst ab Eclipse Indigo (oder war es doch Helios?) gibt.

---

Versuchs mal testweise mit dem neuen XDEV 3. Es hat einen sehr guten GUI-Editor und erzeugt keinen Spaghetti-Code. Es kann nachträglich Projekte in ihrer bestehenden Struktur übernehmen.

Der GUI Designer von NetBeans erstellt in meinen Augen auch brauchbaren Code. Allerdings ist das auch nicht unendlich wichtig. Den GUI Code vom Editor greift man nachher sowieso kaum an...

Zitat:

---

Zitat von StarWolf

Versuchs mal testweise mit dem neuen XDEV 3. Es hat einen sehr guten GUI-Editor und erzeugt keinen Spaghetti-Code. Es kann nachträglich Projekte in ihrer bestehenden Struktur übernehmen.

---

Irgendwie komm ich selbst nach einer erfolgreichen Registrierung/Aktivierung eines Benutzerkontos nicht auf die Downloadseite.
Ah doch, jetzt geht es. Musste wohl nur ein paar Minuten warten.

Zitat:

---

Zitat von The_Burrito

Der _ vor der Methode gibt mir das Gefühl die Methode sei irgendwie nur intern wichtig, aber dann ist die Methode public. Warum also der _? Mag unwichtig klingen, ist es aber nicht.

---

Der ganze Aufbau dieser Klasse ist ein mehr oder weniger veraltetes Konzept der Engine. Der Umbau wird nur etwas größer und so viel zeit hab ich grade nicht.

Zitat:

---

Zitat von The_Burrito

Widerstehe dem Drang alles selber zu schreiben. Ich sehe da drin eine Klasse zum auslesen von Ini-Files. Die Properties Klassen aus Java machen genau das. Warum also neu schreiben?

---

Ich mag die Properties-Klasse einfach nicht als Ini-Adapter
Gibt zwar noch andere Gründe, aber das ist der Hauptgrund.^^

Zitat:

---

Zitat von The_Burrito

Wirf Exceptions. Eine Methode wie "public abstract boolean finishEditing();" die false im Fehlerfall zurückliefert ist suboptimal. Wenn du schon keine Exceptions werfen möchtest (warum auch immer, die sind nämlich eine viel schönere Lösung zur Weitergabe von Fehlern), liefer wenigstens ein Fehlerobjekt zurück wo du Informationen über den Fehler lieferst.

---

Könnte man machen...

Zitat:

---

Zitat von The_Burrito

Pluginsysteme sind äußerst kompliziert zu schreiben. Greif lieber auf ein System wie das NetBeans Module system oder OSGi zurück.

---

Für den Anfang reicht ein Interface, alle Implementierungen in einem Ordner suchen und verwenden.
Für später... mal sehen

Zitat:

---

Zitat von The_Burrito

In einem Konstruktur ist einfach nur scheusslicher Code. Man fängt eine Exception immer nur dort wo man sie auch richtig behandeln kann. Was du machst ist: Die Exception gleich an der erst besten Stelle zu fangen, und dann die Objektinitialisierung abbrechen. Derjenige der eine Instanz von der Klasse erstellt hat somit erstmal gar keinen Plan ob die Instanz überhaupt richtig erstellt wurde und arbeitet evtl mit einem unfertigen Objekt weiter ohne es zu wissen. Ganz übel.

---

Zum Glück ist der Konsturktor private^^
Aber sauber ist es nicht, war auch eher zur schnellen Fehlerbehandlung gedacht.
Wird demnächst korrigiert.
Ich programmier Java halt so wie ich Spiele programmier. Schönes Intro kommt zum Schluss^^

Zitat:

---

Zitat von The_Burrito

Der GUI Designer von NetBeans erstellt in meinen Augen auch brauchbaren Code. Allerdings ist das auch nicht unendlich wichtig. Den GUI Code vom Editor greift man nachher sowieso kaum an...

---

Du vielleicht nicht. Ich mach das aber immer.^^

mfg TWS

Zitat:

---

Den GUI Code vom Editor greift man nachher sowieso kaum an...

---

Uhhhh~ Das würde ich aber nicht so leichtfertig sagen ;) Bist du dir sicher dass das wirklich der Regelfall ist? Ich bin mir fast sicher es ist umgekehrt :) Ganz oft muss ich in den GUI-Code vor allem wenn ich dazu gezwungen bin einen Gui-Generator zu nutzen :/

Gui-Designerprobleme lol ^.^

-Corti.NET

Ich weiß nicht, was man am GUI Code noch großartig bearbeiten sollte. Hätte darin weder die Notwendigkeit noch den Nutzen gesehen.
Da würde mich jetzt echt mal ein paar Beispiele von euch interessieren wofür das notwendig sein sollte.

Um mal ein Beispiel aus meinem MapMaker zu nehmen: Überschreiben von paintComponent :)

Bitte den Thread nicht mit solchen Diskusionen füllen.
danke

Ein kleines Update zu Projekt.

Da wir seit einiger Zeit Memnarch als neues Mitglied zu uns gestoßen ist, ist die Motivation im Team auch wieder auf Volldampf und die Arbeiten gehen zügig vorran was die folgenden Screens auch zeigen sollen.
- Memnarch arbeitet grade am Event-Editor, der schon recht komfortabel in der Bedienung ist.
- Objekte haben nun ihren eigenen Dialog
- Textboxen unterstützen problemlos Bilder und Auswahlmöglichkeiten:
- Ein Overlay zeigt im Debugmodus optional die Kollisionsboxen an.

http://s7.directupload.net/images/12...p/uxa9xea7.png
http://s14.directupload.net/images/1...p/uqqkqyzx.png
http://s14.directupload.net/images/1...p/u42cdo4s.png
http://s14.directupload.net/images/1...p/8ej47vwo.png
http://s14.directupload.net/images/1...p/w79x4m5r.png
http://s14.directupload.net/images/1...p/t54xkp3g.png
http://s7.directupload.net/images/12...p/z7f9sdf4.png
http://s14.directupload.net/images/1...p/n58ewuh3.png
http://s1.directupload.net/images/12...p/5dcczjex.png

mfg TWS

Endlich mal wieder ein kleines Update.

Auf der Projekt-Seite gibts seit heute ein Demo-Spiel, welches zu 100% mit der Engine erstellt wurde.
Hier noch mal der Link: http://www.cuina.byethost12.com/download.php

Ich würde euch echt empfehlen, das Video zu wechseln. Es ist nämlich leider furchtbar öde zum anschauen. Nach ungefähr 20 Sekunden passiert nichts mehr was man nicht schon gesehen hätte. Außerdem zeigt es jetzt nicht unbedingt großartig her was die Engine so kann (hoffe ich zumindest). Sind nämlich nie sehr viele Objekte gleichzeitig auf dem Schirm. Muss ja nicht gleich ein Hardcore Bullet Hell werden, aber mehr wäre schon fein.
Und man sieht in dem Video auch gar nix vom Editor. Und der wird vermutlich für viele auch recht interessant sein ;)

Ich weiß, ich hab nur über das Video geredet, aber ich finde das solltet ihr ernster nehmen. Immerhin ist es Werbung für euer Tool, und ich weiß einfach nicht ob das Video jetzt großartige Jubelrufe hervorbringen wird ...

Aber man muss immerhin sagen: Respekt, das ihr es überhaupt so weit geschafft habt. Die meisten Engines von Leuten aus dieser Community, kamen nicht einmal zu so einem Status. IIRC

Hey, hab mir mal das Ganze etwas angesehen und hab wie The_Burrito-San einige Ideen bzw. Fragen

Fragen:

• wie genau bindet ihr Shader ein? GLSL ist klar. Ich frage mich nur wie ihr es macht. Dazu hier mal ein Tipp. Macht es per-Objekt oder als PostProcessing. So kann der Nutzer Easy für die gesamte Szene einen Shader implementieren (entweder per PBuffer oder Framebuffer). Wollt ihr auch Screentoning benutzen? Falls ja ich kenne den "Algorithmus" dafür und weiß sogar wie das Samplebild gezeichnet wird.
• Bin mir nicht sicher aber nutzt ihr echt Plain-arrays für vars und bools? (Auch nur die Beiden? Keine floats???). Gibt es da einen Grund? Ich finde das ehrlich gesagt nervig beim Maker. Warum keine HashMap?
• Was für eine Form des Gameloops nutzt ihr? Von Vorteil wäre imho Semi-Fixed-Timestep aber ich hab jetzt nichts gefunden was darauf hindeutet.
• Wie genau verhalten sich plug-ins? Kann ich da einen eigenen update/render-Zyklus einfügen.
• Gibt es Spritesorting und wenn ja wie sieht das aus? Ala Maker oder whut?

Das Exceptionhandling isr imho echt merkwürdig aber das ist eure Entscheidung. Codedesign ist so eine Sache :D Ansonsten könntet ihr effektiv auf direkt im OpenGL Kontext die GUI bauen. TWL ist eine super Engine die dafür gemacht wurden, zumindest sollte es möglichen Support für so was geben, ich nehme an durch Plug-ins :)

@The_Burrito
Ich bin weder der Videoexperte noch versuch ich damit ein OpenGL-Performancedemonstration zu geben.
Wir entwickeln zentral eine Engine kein einzelnes Spiel, noch dazu eins, was nicht auf den MainContent (RPG's) abziehlt.
Der Editor ist in vielen Dingen noch instabiel. Heißt das Zustände auftreten, die so nicht gewünscht sind. Es erfordert auch sehr viel Zeit die Features aus der Engine in den Editor zu übertragen.
Ganz besonders das Eventsystem für den Editor ist alles andere als funktionsfähig. Zwar kann man den Sourcecode der Events editieren, aber eine klicki-bunti-Oberfläche dafür wird noch Monate in Anspruch nehmen.

@R.D.
zu 1 und 5 erzähl ich mal den Aufbau des Renderns:
Das ganze Gragik-Konzept ist baumartig aufgebaut. Ganz oben steht der GraphicManager. Jedes Grafik-Element, was diesem übergeben wird wird gezeichnet. Man kann weitere Kontainer hinzufügen, die ebenfalls wieder Elemente enthalten. (Im maker vergleichbar mit den Viewports)
Die Reihenfolge ist abhängig von der angegebenen Tiefe der einzelen Elemente innerhalb des eigenen Kontainers.
Die Shader werden als Objekte eingebunden und einem Kontainer im Rendertree übergeben, der diesen auf alle seine Elemente anwendet. Da das System noch neu ist, muss hier noch vieles gemacht werden.
Ein eigenes Grafikelement kann ganz einfach erzeugt werden indem eine Klasse von GraphicElement erbt.

2. Die int und bool-Arrays sind an dem Maker-Konzept angelehnt und eher historisch in der Engine vorhanden. Für alle relevanten Objekte wird eine HashMap benutzt. Eigentlich sogar 3.
Eine für alle globalen Objekte, eine für jeden Spielstand und eine für jede Spielszene.

3. Ich habe auch keine Ahnung was Semi-Fixed-Timestep ist. Der Loop führt alles aus und wartet den Rest der Zeit auf den nächsten Frame, wie auch immer man dieses System nennt.^^

4. Plugins werden, wenn entsprechend angegeben direkt in die Szene geladen. Man kann Methoden für update-zyklen definieren. Redermethoden gibs so nicht, können aber wie oben beschrieben auch aus Plugins erzeugt werden.

mfg TWS

Zitat:

---

Zitat von TheWhiteShadow

Die Shader werden als Objekte eingebunden und einem Kontainer im Rendertree übergeben, der diesen auf alle seine Elemente anwendet. Da das System noch neu ist, muss hier noch vieles gemacht werden.

---

Also kein PostProcessing? Wäre auf jeden Fall etwas das ich noch einbauen würde. Es ist wie gesagt nicht wirklich schwer. Du kannst das soweit automatisieren das die Engine entweder PBuffer oder Framebuffer nutzt. Wenn beides nicht möglich ist, sind auch keine Postprocessingeffekte möglich. Und auch kein Offscreenstuff.

Zitat:

---

2. Die int und bool-Arrays sind an dem Maker-Konzept angelehnt und eher historisch in der Engine vorhanden. Für alle relevanten Objekte wird eine HashMap benutzt. Eigentlich sogar 3.
Eine für alle globalen Objekte, eine für jeden Spielstand und eine für jede Spielszene.

---

Ich kann ja mal sagen was ich machen: Ich nutze ein GameVariable Interface. Welches bools, Strings, ints, float usw. speichern kann und an alle States weitergegeben werden kann :) Klar wollt ihr an den Maker anlehnen aber vergesst dabei nicht das nicht alles was der Maker gemacht hat sonderlich gut war. Immerschön hinterfragen :D

Zitat:

---

3. Ich habe auch keine Ahnung was Semi-Fixed-Timestep ist. Der Loop führt alles aus und wartet den Rest der Zeit auf den nächsten Frame, wie auch immer man dieses System nennt.^^

---

Solange ihr euch sicher seit das die verlorene Zeit nicht genutzt werden kann :) Ein Tipp, für weiche delta werte könntet ihr einbauen das man delta auf Basis der "gesetzten" Framerate berechnet (nehme an das ist bei euch immer 60 fps). Also sprich delta = 1000 / 60 (Wenn delta Millisekunden sind). Dadurch werden spikes ganz gut ausgeglichen :)

Zitat:

---

4. Plugins werden, wenn entsprechend angegeben direkt in die Szene geladen. Man kann Methoden für update-zyklen definieren. Redermethoden gibs so nicht, können aber wie oben beschrieben auch aus Plugins erzeugt werden.

---

Das solltet ihr auf jeden Fall machen, ich persönlich würde sofort einen FontRenderer machen wollen, da ich mal nicht annehme das ihr einen dynamsichen habt (Wenn ihr euch an den Maker anlehnt schon etwas).

Zitat:

---

Zitat von TheWhiteShadow

@The_Burrito
Ich bin weder der Videoexperte noch versuch ich damit ein OpenGL-Performancedemonstration zu geben.
Wir entwickeln zentral eine Engine kein einzelnes Spiel, noch dazu eins, was nicht auf den MainContent (RPG's) abziehlt.
Der Editor ist in vielen Dingen noch instabiel. Heißt das Zustände auftreten, die so nicht gewünscht sind. Es erfordert auch sehr viel Zeit die Features aus der Engine in den Editor zu übertragen.
Ganz besonders das Eventsystem für den Editor ist alles andere als funktionsfähig. Zwar kann man den Sourcecode der Events editieren, aber eine klicki-bunti-Oberfläche dafür wird noch Monate in Anspruch nehmen.

---

Ist mir alles klar. Dennoch ist das Video in meinen Augen suboptimal. Als einziges Aushängeschild für euren Kram auf der Seite wirkt es einfach nicht sonderlich einladend für mich. Wenn euch sowas egal ist, dann ist mir das auch recht. Ich wollte jedenfalls nur nen Rat geben.

- Framebuffer werden bereits für PostProcessing benutzt. Shadereinbindung ist dort noch geplant.
- FontRenderer gibt es auch bereits.
- Delta-Werte für den Frame-Loop können bereits abgefragt werden, aber benutzt ich für die bisherigen Plugins nicht.
- Spielvariablen haben keine großen Abhängigkeiten zum Rest und lassen sich auch später noch ändern. Vermutlich wiederum als Plugin, weils doch so schön einfach ist und wers nicht mag, kanns rausschmeißen.^^ (Natürlich gilt das nur für den Entwickler. Fehlt ein benutztes Plugin beim Spiel selbt, gibt Probleme)

Was das Video angeht, wird es sicher nicht dabei bleiben.
Aber momentan ist es mir wichtiger fortschritte zu machen, als zu Viel Arbeit in demonstrative Videos zu stecken.

Ich wollte mal fragen, wie fertig eigentlich die Engine ansich ist. Ohne grafische Oberfläche, Event-Editor etc.
Wäre die, wenn man nur harten Code schreibt schon nutzbar? Gibt es Klassen, ähnlich denen in RGSS? (z.B. Bitmap, Sprite oder ähnliches, was einem das Leben erleichtert?)

Ich frage deshalb, weil ich mein Projekt im Moment gerade so weit zurück geschnitten habe, dass ich eigentlich alles nurnoch im Script-Editor (XP) code.
Und da wäre es ja schon fast sinnvoll, auf eine freie Alternative zurück zu springen, die sich evtl. auch unter Linux ohne weiteres betreiben lässt. Und da dachte ich daran, einfach mal hier nach zu fragen, bevor ich in den unendlichen Weiten des Netzes nach eventuellen Alternativen suche.

Da könntest du auch Slick2D nutzen. Das bietet direkt was du brauchst. Ist aber auch eine richtigen Engine. Die gibt dir nur Grundlagen. Gamelogik musst du selbst implementieren und es gibt keine Scripte, nur Raw Java :D

Na dann, werde ich mir mal anschauen. Danke für den Tipp ^_^

Neue Projektseite

Diese Woche hab ich mich mal dran gesetzt und die Projekt-Seite neu aufgezogen.
Noch fehlen diverse Inhalte aber das wird auch bald nachgeholt.