Cuina Projekt

**Kelven** · 27.11.2011, 15:17

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

**Whiz-zarD** · 27.11.2011, 16:00

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.

**MagicMagor** · 02.12.2011, 11:43

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.

**TheWhiteShadow** · 03.12.2011, 14:36

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.

**niR-kun** · 04.12.2011, 03:02

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.

**[KoA-Angel]** · 04.12.2011, 13:20

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.

**TheWhiteShadow** · 26.12.2011, 20:10

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

**The_Burrito** · 02.01.2012, 18:59

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.

**niR-kun** · 03.01.2012, 20:29

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

**StarWolf** · 04.01.2012, 10:12

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.

**The_Burrito** · 04.01.2012, 11:36

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

**TheWhiteShadow** · 06.01.2012, 22:56

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

**R.D.** · 06.01.2012, 23:23

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

**Corti** · 06.01.2012, 23:34

Gui-Designerprobleme lol

-Corti.NET

**The_Burrito** · 07.01.2012, 09:23

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.

**R.D.** · 07.01.2012, 16:41

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

**TheWhiteShadow** · 07.01.2012, 16:57

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

**TheWhiteShadow** · 26.02.2012, 17:42

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.

mfg TWS

**TheWhiteShadow** · 03.06.2012, 20:37

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

**The_Burrito** · 03.06.2012, 22:15

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

Thema: Cuina Projekt

Themen-Optionen

Anzeige

Stichworte

Berechtigungen