= JEmpire =

JEmpire ist ein Projekt, bei dem Mitglieder der Lug Krefeld, (insbesondere bisher ThomasBayen und KaiEhlers) versuchen, eine gemeinsame Basis für von Ihnen geplante Strategie- und Wirtschaftsspiele in Java zu erstellen. Das Projekt ist bisher noch in einem recht frühen Stadium und eigentlich mehr ein Test von Technologien.

== Website und Wikiseiten zum Thema ==

Das Projekt hat eine eigene Website unter http://jempire.javaproject.de bekommen. Dort gibt es auch eine per JavaWebStart zu startende Demo-Version sowie die API-Dokumentation und einen Blick in die Quelltexte, wenn man will.

Anfänglich wurden hier im Wiki einige grundsätzliche Überlegungen zum Thema 3D-Grafik auf der Seite JavaGrafik (sowie OpenGL) angestellt. Dann wurde eine Seite SpielProjekte erstellt, die eher allgemein gehalten ist. Diese Seite hier soll nun speziell das Projekt '''JEmpire''' beschreiben.

== Feedback von Testern (bitte ergänzen!) ==

* läuft unter XP (32-Bit) auf Anhieb, ich finde die Handhabung und das Design ansprechend. Mal sehen was daraus wird. \\
Macht es Sinn, http://jempire.javaproject.de unter http://javaproject.de zu verlinken? --MarkusMonderkamp am 07.02.2007
* Unter Win2k im Büro lief es, aber man konnte die Spielfläche nur von oben betrachten - das Drehen ging gar nicht. --StefanGaffga
** Wenn es einmal zeichnet, gibt es IMO keinen Grund, warum es gedreht nicht auch zeichnen sollte. :-( Wie genau äußert sich das? Tauchen die Schieberegler auf? Kann man sie bedienen? Was passiert, wenn man das Fenster hinter ein anderes und wieder nach vorne klickt? -- ThomasBayen
* Unter meinem 64Bit Ubuntu 6.10 startete der JavaWebStart-Download, dann stürzte die VM ab. Habe JEmpire aus SVN ausgecheckt und eine Exception aufgrund eines falschen ELF-Binarys gefunden (32 statt 64Bit). Habe nur die jogl.jar ausgetauscht - dann gings (*grübel...wunder...*) --StefanGaffga
** Bei Webstart stecken die native Libs in der von Sun signierten Webstart-Extension. Hab da mal reingelinst und es gibt eigene Versionen für 64Bit. Funktionieren denn die Webstart-Demos von der JOGL-Webseite?
*** Die klappen auch nicht - aber das lag an einer falschen Java-Version die ich hatte. Hab nun die richtige drauf (1.6 64bit) - aber in dieser Version ist kein Webstart enthalten (bei der 32bit war es das) :( *grrrrr* Nun kann ich gar nichts testen :(
** Beim Auschecken ist das evtl. anders, weil mein Projekt selber nur Linux32-Binaries enthält (die Exception ist also wohl meine Schuld). Obwohl ein Austausch nur der jogl.jar keinen Unterschied machen dürfte. Es müsste um die native Libs gehen. Kannst Du das näher erklären? -- ThomasBayen
<<*** Nein, leider nicht - es liegt irgendwie an der "gluegen-rt" - anscheinend braucht meine Version der jogl.jar diese nicht.
* Für Webstart wirst du vermutlich eine getrennte Version für 64Bit-Systeme bereitstellen müssen. --StefanGaffga

== Überlegungen zu unserem Projekt ==

Die Überlegungen auf dieser Seite fingen an, als KaiEhlers und ThomasBayen merkten, daß sie gerne Spiele schreiben würden, die ähnliche Grafikprobleme beinhalten. Ich notiere hier mal unseren gemeinsamen Nenner (vorerst aus meiner Sicht), um vielleicht eine ergiebige Diskussion anzuregen. :-)

Uns geht es beiden um eine "Weltkarte", auf der Figuren herumlaufen. Diese Welt hat verschiedene Geländeformationen (Wälder, Flüsse, Meer, etc.) und unterschiedliche Höhenstufen. Das Ganze soll somit ungefähr aussehen wie Siedler, Populous, o.ä. Die Grafik soll in einer schrägen Ansicht von oben dargestellt werden, so daß die Höhenunterschiede auch sichtbar sind. Folgende Überlegungen sind uns dazu bereits eingefallen:

* Eine Frage ist, ob das überhaupt ein '''3D-Problem''' ist. Die alten Siedler-Versionen z.B. auf dem Amiga haben das bestimmt nicht mit OpenGL gemacht. Eine echte 3D-Ansicht hat hingegen den großen Vorteil, daß man die Ansicht auch variieren kann (Kamerafahrten, etc.). Evtl. brauchen wir beides: 2D für das schnelle und detailreiche Spiel und 3D für Übersichten, Drehungen und Kamerafahrten. Dann ist die Frage, ob es sinnvoll ist, 2D extra zu programmieren oder ob OpenGL in 2D genauso schnell ist wie die 2D-APIs und ob diese auch hardwarebeschleunigt sind. -- ThomasBayen
* Es gab verschiedene Meinungen zur '''Grundform''', die ein einzelnes Feld hat:
** '''Vierecke''' wollte eigentlich keiner haben. Obwohl sie natürlich am besten auf den Bildschirm abzubilden sind, gilt dieses Argument bei 3D-Ansichten, wo sowieso alle Linien durch die Perspektive verzerrt werden, nicht mehr. Man muss sich entscheiden, ob man 4 oder 8 Bewegungsrichtungen zulassen will. Nimmt man vier, werden Bewegungen zu Zielen, die diagonal liegen, unverhältnismäßig teuer, nimmt man 8, sind diagonale Bewegungen eigentlich zu billig, weil man ja eine um wurzel(2) längere Strecke zurücklegt. -- ThomasBayen
** '''gleichseitige Dreiecke''' waren Kais Favoriten. Dreiecke sind die Grundform jedes Polygons und jeder OpenGL-Engine. Damit keine teureren oder billigeren Bewegungen entstehen, müsste man gleichseitige Dreiecke nehmen. Es gibt nur drei Bewegungsrichtungen - das könnte evtl. irgendwie kompensiert werden, z.B. indem man die Position unabhängig von den Kacheln bestimmt (man also nicht immer genau auf einem Feld steht) oder indem man auch "diagonale" Richtungen erlaubt (was sechs Richtungen ergäbe, aber evtl. ähnliche Probleme ergibt wie Vierecke mit 8 Richtungen). Gleichseitige Dreiecke ergeben keine geraden Kanten, also keine geraden Meeresküsten oder Waldränder Das kann hübsch wirken, kann aber auch lästig sein. -- ThomasBayen
** '''rechtwinklige Dreiecke''' haben einige Vor- und Nachteile mit den gleichseitigen Dreiecken und einige mit den Vierecken gemein. Sie ergeben gerade Kanten. Dafür ist eine "gerechte" Bewegung generell unmöglich, außer man koppelt die Positionen der Figuren von den Feldern komplett ab. -- ThomasBayen
** '''Sechsecke''' sind Thomas' Favoriten. Ich habe bereits ein Spiel mit Sechsecken geschrieben und habe gute Erfahrungen. Man hat sechs Bewegungsrichtungen, was ausreicht. Felder, die außerhalb der direkten 6 Richtungen liegen, werden nicht zu sehr benachteiligt. Da Sechsecke ja eigentlich aus sechs gleichseitigen Dreiecken bestehen, müssen sich Sechsecke und Dreiecke nicht grundsätzlich ausschließen. Sechsecke ergeben keine geraden Kanten. Tests auf meinem Thin Client haben ergeben, daß das Zeichen eines Sechsecks ca. 2,5 mal so lange dauert wie das Zeichnen eines Dreiecks, aber das kann bei entsprechender Hardware bis auf Faktor 1 zurückgehen. -- ThomasBayen
** Eine '''Zwischenform''', die mir eingefallen ist, ergibt sich, wenn man sich Sechsecke als aus jeweils sechs gleichseitigen Dreiecken bestehend denkt. Die Figuren stehen nicht auf einem Feld, sondern auf den Schnittpunkten der Feldränder. Es gibt sechs Bewegungsrichtungen, man kann dreieckige Geländetypen vergeben. Unschön finde ich es, wenn Figuren immer auf dem Rand eines Geländetypen stehen. Das hängt davon ab, ob man den Rand wirklich durch den Rand des Feldes führt (s.u.); eine solche Lösung wäre aber auf jeden Fall aufwendiger (vielleicht auch nicht, wenn eine "Bewegung" immer über zwei Schnittpunkte geht, womit man dem Benutzer gegenüber wieder näher an Sechsecken wäre). -- ThomasBayen
** Natürlich wäre es auch möglich, Gebiete als beliebige Polygone zu definieren, die dann aneinanderpassen. Dort könnte man dann eine gekachelte Textur auftragen und fertig. Die Position von Spielfiguren wäre dann frei wählbar. Zu so einer Lösung habe ich mir selber bisher noch nicht viele Gedanken gemacht. -- ThomasBayen
* Die Felder brauchen eine vom Geländetyp abhängige '''Textur'''. Dies sieht IMHO viel besser aus, wenn die Texturen von Nachbarfeldern sauber ineinander übergehen. So bekommt ein "Ebene"-Feld, das an ein "Meer"-Feld grenzt, einen schmalen Strand verpasst. (Damit kann man evtl. sogar wieder "gerade Kanten" bekommen?!?) Nun muss man aber für jedes Nachbarfeld den entsprechenden Rand anpassen. Das heisst bei einem Sechseck, das man bei z.B. 4 Geländetypen 5 hoch 6 = 15625 verschiedene Texturen benötigt... Also muss man stattdessen das Sechseck in sechs Teile zerlegen (die obige "Zwischenform" ruft gerade laut Hallo!), was die Texturen auf 4*4 = 16 reduzieren würde. Die nächste Frage ist, ob, wenn man sechs Dreiecke zusammensetzt, in der Mitte (wo ja eigentlich der wichtigste Teil der Textur, z.B. ein Baum sitzt) noch ein sauberes Bild herauskommt oder ob man eine siebte Textur für das Zentrum des Sechsecks benötigt. Alternativ lässt man alle diese Überlegungen weg, verkleinert die Felder und lässt den Kartendesigner entsprechend "Strand" u.ä. einfügen, wo Geländegrenzen sind. Dann würde ein "Schritt" für den Spieler natürlich auch über mehrere Felder (incl. Zwischenfelder) gehen. Von der Grafikausgabe her ergibt sich da jedoch eigentlich kein Unterschied. -- ThomasBayen
* Für mein Spiel ist es wichtig, daß die Welt keinen '''Rand''' hat. Bisher habe ich dazu den linken und rechten und den oberen und unteren Rand jeweils verbunden. Das ergibt im Ergebnis eine "torusförmige" Welt. Das ist für mich eine Voraussetzung, ergibt aber keine wirklich schöne Lösung für eine "Gesamtübersicht". Noch schöner wäre es allerdings, wenn man es schaffen würde, eine '''kugelförmige Welt''' zu bauen. Das Gesicht eines Spielers, wenn eine Kamerafahrt sein "Reich" aus der Satellitenperspektive auf einem Planeten zeigt, wäre den Versuch wert... Deren Projektion hat allerdings schon die Autoren von Atlanten seit Jahrhunderten in die Verzweiflung getrieben. Vieles von dem, was ich oben über Feldformen gesagt habe, wäre dann wohl obsolet. Außerdem ginge es dann endgültig nicht mehr ohne 3D-Projektion. Eine Idee hätte ich, dazu müsste man es jedoch schaffen, ein Sechseck (oder zum Anfang ein Viereck) passgenau auf eine Halbkugel zu projizieren. Wie geht das? -- ThomasBayen
* Erste Tests lassen in mir die Erkenntnis reifen, daß eine Live-Erzeugung der Welt mit vielen Feldern und Texturen sehr lange dauern würde. Wir brauchen also definitiv eine '''Cache-Strategie''', um die Weltansicht irgendwie zu cachen (und dann nur die beweglichen Teile wie Figuren neu zu zeichnen) bzw. für schnelle Kamerafahrten die Qualität harabzusetzen. Da die Fähigkeiten von Hardware sehr unterschiedlich sein können, brauchen wir auch eine '''Detail-Strategie''', um den Rechenaufwand (dynamisch) der Hardware anzupassen. Bewegungen auf den Grundfeldern (z.B. wippende Baumwipfel oder schäumendes Meer) sind wünschenswert, sollten aber wohl nur sporadisch und nicht bei allen Feldern des Typs erscheinen und könnten daher auch auf die gecachte Version "aufgesetzt" werden wie die Spielfiguren. -- ThomasBayen
* Für mein Spiel ist es wichtig, daß die Karte schwarze Flecken (also unerforschte Gebiete) haben kann. Dies sollte man irgendwie darstellen können. Ob dabei über die Randtextur oder eine Geländeneigung ein Hinweis auf das nächste schwarze Feld gegeben wird oder nicht sollte in der Grafik-Engine variabel sein. -- ThomasBayen

----
;Kategorien:KategorieJava