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.

Neuigkeiten #

Die neue API, die ThomasBayen und KaiEhlers im Limericks besprochen haben, hat zu einer ganz neuen Pakethierarchie geführt. Wen es interessiert: Die Webstart-Demo erlaubt jetzt den Start der alten sowie einer neuen, Java2D-gestützten Demo. Das revolutionäre daran ist allerdings weniger die 2D-Grafik, als die darunterliegende Klassenhierarchie. Schaut mal in die Javadoc API, wenn ihr wollt. -- ThomasBayen am 13.03.07

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
    • Ich habe die Schieberegler hier und kann sie auch bedienen - es verändert sich die Anzeige leicht wenn ich Gitternetz und flache Elemente an/aus klicke. Aber egal was ich an den Reglern drehe oder das Fenster nach vorne, hinten, groß und klein mache - es dreht sich nichts. (Was ich mir aber auch nicht erklären kann - denn ich kenne ja den Source und der sieht okay aus)
• Ich habe es auch unter Win2k ausprobiert und bis auf flache Felder läuft alles bestens. -- KaiEhlers
• 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
    • Mit gleichseitigen Dreiecken kann man sehr wohl wunderschöne gerade Linien herstellen. Eigentlich gilt das für jede gewählte Dreiecksform, es muss nur immer die gleiche Form genommen werden, die dann abwechselnd "seitenverkehrt" gezeichnet wird! -- KaiEhlers
  • 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
  • Ich bin auf meiner Suche auf dies gestossen: http://mathworld.wolfram.com/ArchimedeanSolid.html , nur sehe ich bei den meisten diesen Kugeln schwarz dort mit Hexfeldern zu arbeiten. Damit man immer eine gleiche Anzahl an Ecken hat, machen dort die 4, die 8, und die 11 nur Sinn, da sich alles leicht und nicht zu unsymetrisch in Dreiecke zerlegen lässt, und man ja Dreiecke wieder in 3 Dreiecke unterteilen kann. Das einzige was für viele Sechsecke Sorgen könnte währe das "truncated icosahedron" (11), und dann hab ich noch das hier gefunden, was wohl eine erweiterung der 11 ist, welches nur viel mehr Sechsecke und nicht mehr Fünfecke hat: http://www.freewebtown.com/adrian/geom/830_woven_polys/geo_2_3_pr_Lrg.jpg.13.html (das Muster der lilafarbenen Linien betrachten, und _nicht_ die orangenen Punkte innerhalb der weissen Sechsecke) oder hier das obere der beiden animierten gifs : http://en.wikipedia.org/wiki/Geodesic_dome#Chord_factors -- JanReitz
• 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
• Anmerkung zur Game-Engine
  Zur Technik, die hinter einer Mehrbenutzer-Game-Engine steckt, fand ich die Perl-XS-Assimilation des Uralt-Klassikers Crossfire (Bj. 1992) bemerkenswert: Vortrag zu Crossfire+ auf dem Perl-Workshop 2007 und Homepage Crossfire+ -- MarkusMonderkamp