Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder ein alternativer Browser verwenden.
hab mich mittlerweile etwas eingelesen was das Thema "isometric tile game" angeht.
"Killer Game Programming in Java" von Andre Davison war/ist da recht hilfreich. Doch einfaches 2D im klassichen Sinne ist zu "altbacken" und 3D ist für nicht begabte 3D MOdeller doch etwas "overkill".
Der Weg "dazwischen" scheint vom Anspruch her "okay" zu sein, und das Ergebnis könnte sich unter Umständen sehen lassen. Also eine Mischung aus 2D und "optischem 3D".
Nun suche ich nach einen Anhaltspunkt zu folgender Art von Karte/Map:
Man sieht dass die Karte auf 3-, bzw. 8-Ecken basiert. Aber ich hab noch keinen Schimmer wie sich sowas im Fachjargon nennt und wie man sowas technisch abbilden würde. Echtes "3D" ist das ja nicht.
Nach was müsste ich suchen um mich dazu einzulesen? Oder kann mir jmd. ergänzend ein Buch nennen, welches sich mit sowas (ähnlich zu "Killer Game Programming in Java") beschäftigt?
Isometrisch ist klar. 6-Eckig ist auch klar (sorry, hatte doch tatsächlich 8-Eckig geschrieben ... z z z z ).
In dem Screenshot sind ja nur "kleine Erhebungen" zu sehen, so dass offensichtlich der Eindruck erweckt wird, das ist einfach ein statisches 6-eck das "optisch" nach einer Erhebung aussieht. Ist vllt. etwas "doof" gewählt. Hab mal nen anderen, besseren Screenshot angehängt:
Die Grafik ist auf "Die Siedler" von BlueByte von 1994. Das ganze wurde in Assembler gecodet.
Man sieht deutlich dass die Map zwar aus 6-ecken besteht, aber die "Höhe" sich stark unterscheidet. Hinzu kommt, dass dadurch die 6-ecke nicht mehr gleichförmig sind, was den Kantenverlauf von "niederem Punkt" zu "höherem Punkt" verdeutlicht.
Diese Art von Technik/Map muss doch eine Bezeichung haben. Wenn ich nach "isometric map" suche, komme ich immer bei sowas raus:
Und das ist nicht das was ich haben will...
Verstehst du jetzt den Unterschied? Ersteres will ich haben, weiß aber nicht nach was ich suchen soll ...
Das sind fertige Tiles die die Ränder so gemacht haben. So kenn ich das zu mindestens. Vermutlich sind das insgesamt 10 - 15 verschiedene Kombinationsmöglichkeiten (aus möglicherweise 40 - 50 Tiles), die, richtig angeordnet, aber eben einen tollen Effekt haben.
Ehrlich gesagt sieht das für mich nach einer 2D-Map aus, wo tatsächlich die einzelnen Vertices nach oben/unten verschoben sind. Genau sagen könnte man das nur, wenn man das Spiel sieht und ggf. die Ansicht drehen kann. Aber sonst wüßte ich nicht, wie z.B. die unregelmäßig aussehende Umwandung des Schlosses entstehen sollte (d.h. ich glaube, wenn man das wirklich senkrecht von oben sehen würde, würde es nach einer normalen 6eck-Map aussehen, und die Umrandung wäre ggf. auch ein 6eck...)
hmm ich glaube das sind einfach hextiles (6 ecken) bei denen der "3D Effekt" einfach nur durch die aufgemalten schatten auf den einzelnen tiles zustande kommt...
Kann ich nicht ganz glauben. Das hätte sehr viel aufwand ergeben. Denn die Spielfiguren können nicht nur an den Kanten der Tiles entlang laufen, sondern auch quer drüber. Und dabei wird die "Höhe" berücksichtigt.
@Marco13
Von oben sind das vermutlich wirklich perfekte 6-ecke.
So wie ich das sehe haben die Vertices wirklich unterschiedliche Höhen.
Die Ansicht drehen kann man nicht. Das wäre für 1994 und Assembler als Basisprache wohl zu viel des guten gewesen.
Aber in späteren Versionen (btw: es handelt sich hier um "Die Siedler" Reihe, angefangen bei Siedler 1 von 1994, bis Siedler <keine Ahnung> das erst vor kurzem auf den Markt kam) als dann auch 3D mit ins Boot kam konnte man die Ansicht drehen.
Hatte gestern Abend noch etwas gegoogelt. In irgend nem Entwickler-Forum kam eine Ähnliche Frage auf, jedoch gab es passende Antwort dazu. Einzig die Info, dass BlueByte (die habens damals "verbrochen") da eine geschickte Rendering-Engine für gehabt haben muss.
Die Frage ist nur:
Wie bildet man hextiles, deren Vertices unterschiedliche Höhen haben können, technisch gesehen am geschicktesten ab? Und das ohne JOGL, JMonkeyEngine und Co. zu benutzen ...
Wenn man dafür ne Engine bauen würde, könnte man auch noch mit 2D schicke Spiele basteln ...
Aber daraus ergeben sich immer noch das eine oder andere Problem:
1) Wenn man technisch mehr dazu erfahren will: Wie nennt man sowas? Nach was muss man suchen?
2) Wenn es wirklich so selten ist, dass es im 2D Umfeld keiner/kaum einer macht: Wie bildet man sowas programmatisch ab? Stichwort: Datenmodell/-container.
3) Zeichnen ist dann an sich wohl auch noch ein kleines Problem. Schließlich hat man bei 2D nur 2 Koordinaten. Man müsste wohl eine Art künstliches 3D abbilden. Als Drahtgitter ist das vllt. noch nicht allzu schwer. Aber was ist mit den Flächen? Normale "Tiles" passen da ja nicht mehr rein und das Zeichnen von nicht rechteckigen Shapes ist ja auch nicht gerade ressourcenschonend. Bei normalen isometrischen Maps ist das weniger ein Problem. Da haben alle die gleiche Form und das was nicht gezeichnet werden soll hat transparente Pixel.
- Alex
[update]
Hab ein Siedler-ähnliches OpenSource Projekt namens "Widelands" gefunden. Die haben die gleiche Map-Technik.
Im Splash-Screen des Map-Editors ist das Gittermodell der Map zu sehen:
Mal schauen wie die das gemacht haben. Vllt. findet man da was raus.
Standard 2D Zeugs und die dritte virtuelle Ebene kannst du durch rein- und rauszoomen der Sprites erreichen welche auf Basis der Polygone berechnet werden.
Die Polygone setzt du halt aus mehreren Punkten zusammen, und jeder Punkt ist durch X, Y, Z definiert. Damit kannst du dann später die Steigungen und auch den Zoomfaktor berechnen.
edit: Bei denen sieht das so aus (widelands) als ob die alles komplett aus Polygonen gebaut haben.
edit2: ok seh es grad im zweiten Link (haben sie) *gg*
Die Widelands Map Geometry basiert auf Polygonen. Prima. Verstanden. In Java2D gibts ja auch Polygone. In dem Fall hätte das Polygon drei X/Y Koordinaten, deren Anordnung eben ein 3-Eck ergibt. Verschiebt man ein Vertice auf der Y-Koordinate, so würde das Auswirkungen auf "die Höhe" haben.
Heisst das im Klartext und vereinfacht ausgedrückt dass pro 3-eck ein Polygon-Objekt von nöten wäre, welches dann von der paint/paintComponent Methode gezeichnet werden muss?
Des weiteren ist gleich am Anfang der Beschreibung die rede vom Abbilden der Map in einem Graphen. Kann mich da mal jemand erleuchten? Stehe total auf dem Schlauch. Vllt. am besten anhand eines kleinen Beispiels mit sagen wir sechs solcher Polygone, damit wir wieder ein 6-eck haben.
Ein Dreieck ist ein Polygon. Zu jeder der 3 Polygonecken kommen auf 3 Polygone dann ein Vertex (ein X/Y Punkt). Wenn du ein Vertex verschiebst (X/Y) entsteht der Eindruck einer Verzerrung und damit Tiefeneindruck (wie ihn isometrisch ja ehh schon hat).
Soweit ist mit das klar. 3-Eck (Polygon) wo jeder Eckpunkt (Vertice) eine X/Y Koordinate hat. Verschiebt man die Y-Koordinate entsteht der Höhen/Tiefeneindruck.
Um so eine Map darzustellen brauch ich aber viele Polygone. Ich greif jetzt einfach mal ne Zahl aus der Luft: 200 Stück
Die müssen ja irgendwie "zusammenhängen". In der Doku bei Widelands steht was von einem Graphen:
"It shows that the map is composed of triangles. It is useful to see the map as a graph, especially when making searches on it."
Wie mach ich so nen Graphen? Eine LinkedList reicht da ja nicht aus...
Da dies die eigentliche Standardart ist, wie 3D Grafik erzeugt wird Polygone (mitlerweile mit Subdevision Surfaces), kannst du dir einfach 3D Graphen anschauen und einfach die dritte Dimension auslassen.
Die Wideland Geometrie ist auf jeden Fall sehr interessant. Das einzige was mir persönlich noch etwas unklar ist, wie sie das mit den Schatten bzw. Beleuchtungen machen.
Ich meine die haben doch auch nur eine Sprite wahrscheinlich für jeden Untergrund und legen einen Schatten irgendwie drauf. Hat jemand Erfahrungen wie die das machen? Das würde mich interessieren.
Das Thema schreit förmlich nach einer Umsetzung.
Steht doch in der Dokumentation mit drin. Anhand der Verzerrung wird eine Abwendung von der Sonne berechnet und mit dem eigentlichen Pixel interpoliert.
Oh so tief hab ich gar nicht gelesen. Ich glaub ein kleinen Prototyp werde ich mal basteln mit der Methode. Mal schauen wie schwierig das ist. Tolles Thema =)
Wenn ich Zeit finde häng ich mich gerne mal mit rein, nur Grafikprogrammierung unter Java ist nicht meine Welt. Aber ähnliche Dinge hast du halt auch in Zonensystem auf Gameservern
Gut gut. Na dann versuch ich das mal ausseinander zu nehmen:
Representation
The map is basically an array of vertices. A vertex is a record consisting basically of a number representing the height property and a 2 triangles called r (right) and d (down). Which those triangles are is seen in this image:
A vertex is also responsible for storing 3 edges, but edges do not yet have any properties to store. If they had, each vertex would be responsible for storing the 3 edges shown in this image:
Eine Karte besteht also aus Vertices. Ein Vertice (der rote Knubbel) hat im Prinzip 3 Koordinaten: X, Y und Z (die Höhe). Da wir uns aber erstmal im 2D Raum befinden, haben wir nur X und Y. Wenn wir also die Höhe komplett weglassen würden, würde unser Gitter so gleichmäßig sein wie's die beiden gezeigten Grafiken darstellen.
Die Höhe, bzw. Z ist eher "virtuell". D.h. man muss die Höhe in den Y Wert mit einrechnen. Aber dazu später mehr. Bleiben wir deshalb erstmal bei X und Y, wobei Y die Höhe schon beinhaltet.
In dem Text steht, dass die Karte aus einem Array von Vertices besteht.
In Java dann also sowas (stark vereinfacht):
Java:
public class Vertice {
public int x;
public int y;
}
So, es steht da aber auch noch weiter, dass jeder Vertice 3 Kanten (Edges) hat. Diese 3 Kanten definieren, zusammen mit weiteren Vertices, das darunter liegende Polygon, und das rechts daneben liegende.
Gut gut. Damit man da jetzt einen Graph machen kann, über den man iterieren etc. kann, muss man ja jetzt die Vertices miteinander verknüpfen. Ich nenne die 3 Edges mal "d" (das ist der erste der nach unten links schaut), "dr" (das ist der der nach unten rechts schaut) und "r" (der der nach rechts schaut). Die eingebaut in die einfache Vertices Klasse, würde dann so aussehen:
Java:
public class Vertice {
public int x;
public int y;
public Vertice d;
public Vertice dr;
public Vertice r;
}
---------------------
Vertice first= Vertice();
first.x = 0;
first.y = 0;
first.d = new Vertice();
first.d.x = 0;
first.d.y = 1;
first.dr = new Vertice();
first.dr.x = 1;
first.dr.y = 1;
first.r = new Vertice();
first.r.x = 2;
first.r.y = 1;
first.d.d = new ....
...
So irgendwie in der Art ...
Allein mit dieser Objektstruktur müsste ich doch schon eine Map abbilden können, oder? D.h. ich hätte meinen "Graphen", bzw den Container zum speichern einer Map gefunden, oder hab ich was übersehen?
Klar, im ersten Moment ist das ein wenig witzlos: Wenn ich genau weiß in welchem festen Winkel und mit welchem festen Abstand der nächste Vertice kommt, wozu brauch ich dann noch diese "Vernetzung"?
Nun, zum einen denke ich wegen einem später benötigten Wegfindungsalgo, und zum anderen weil man ja auch noch die Höhe haben will.
Im Klartext heisst das:
Java:
public class Vertice {
public int x;
public int y;
public int z; // <--- die virtuelle höhe
public Vertice d;
public Vertice dr;
public Vertice r;
}
Ist die Variable z=0, dann wird einfach das vorhandene X und Y zum positionieren genommen. Ist Z jedoch !=0, so wird Z genutzt um von der Y-Koordinate entsprechend abzuweichen und die Höhe darzustellen. Idealerweise sollte Z wenn dann positiv sein, und Y demnach nur nach oben korrigieren können. Dann wäre z=0 der niedrigste Punkt auf der Karte.
Klar, man könnte Z gleich von vornherein in Y mit einrechnen und würde sich somit die Z Variable ganz sparen. Aber ich bin mir noch nicht sicher ob man sich damit nicht eine später noch benötigte Information, nämlich "wie hoch ist es hier jetzt eigentlich?", "killt".
Ideen? Gegenvorschläge?
- Alex
[update]
Ich denke X und Y Werte könnte man sich in der Klasse Vertice ganz sparen: Denn: Wo sich ein Vertice befindet wird schließlich durch die Vernetzung zu den anderen Vertices definiert. Allerdings fehlt noch die Verbindung eines "d" Vertice zu seinem "Parent": Mit der aktuellen Implementeirung könnte man nur von oben links nach unten und rechts durchnavigieren/iterieren, aber nicht umgekehrt ...
Denkst du X und Y sind wirklich notwendig? Oder reicht es wenn sich die aus der Relation der einzelnen Vertices untereinander ergeben?
ich mein: Letztenendes muss X und Y eh auf die Bildschirmauflösung und den entsprechenden "Zoom" umgerechnet werden.
Klar, aber wozu? Ich mein: Wenn man die Karte von oben betrachtet (und somit die höhe keine Rolle mehr spielt), folgt alles einem symetrischen Raster. D.h. alle Vertices sind auf der X und Y Achse immer gleich weit ausseinander.
Von daher ergibt sich die exakte X und Y Position immer aus der Relation zwischen den einzelnen Vertices. Einzig und allein die Y Koordinate wird später von der Höhe beeinflusst.
Erstmal vorneweg: Einer heißt "Vertex", merhere heißen "Vertices".
Ansonsten würde es IMHO schon Sinn machen, X, Y und Z zu speichern. Du solltest dir aber genau überlegen, was X und Y sind. Sind das die Koordinaten oder die Gitterpositionen? Man kann beides ineinander umrechnen - wenn man nur Methoden für's getten anbietet, ist es egal, aber eine von beiden Informationen wird man wohl brauchen.
Und die Sache mit den "Edges" hast du ja selbst schon erwähnt. Eigentlich braucht man die Edges (bzw. in deinem Fall die Verweise auf die Nachbarknoten) nicht explizit zu speichern: Man kann sich die Nachbarn ja aus den (Gitter!)koordinaten jedes einzelnen Vertex berechnen. Aber WENN man Kanten speichert, dann würde ich das als echte Edge-Klasse machen, die selbst wieder 2 Vertices enthält - und auch in jedem Vertex alle 6 Kanten speichern. Ansonsten kommt man bei Graphenalgorithmen aus dem Gemurkse nicht mehr raus: Jede Wegesuche o.ä. ist darauf aufgebaut, dass man von einem Knoten schnell und einfach ALLE Nachbarknoten bestimmen kann. (In den Kanten könnten dann z.B. noch Bewegungskosten Gespeichert sein - Sumpf hat höhere Kosten als Straße usw...)
Sorry, bring die Bezeichnungen immer wieder durcheinander ...
Die Idee mit der Edge-Klasse hat was... Aber wäre das nicht irgendwie redundante Datenhaltung? Die Anzahl der Objekte würde sich damit ja auch drastisch erhöhen.
Oder ist der Gewinn, den ich aus der zusätzlich gekapselten Information mit den Edge-Objekten gewinne größer zu bewerten als der mögliche Speicher/Performance-Verlust durch die große Anzahl an Objekten?
Ich habe das mal schnell versucht umzusetzen. Ich speichere einfach alle 6-Nachbar-Vertices mit dem eigentlichen Vertex. So kann ich schnell einen Wegfindungsalgorithmus drüberlaufen lassen (die Kosten für A-Stern kann ich einfach aus der Differenz der z-Koordinate nehmen).
Das Problem was ich nun habe ist immer noch die Beleuchtung. Ich habe die Theorie (glaube ich) verstanden, aber ich überlege grad wie ich das am besten umsetze. Ich erstelle mir ein Polygon, das bekommt eine bestimmt Farbe. Jetzt müsste ich aber nochmal mit einem anderen Farbwert drübermalen. Aber wie genau (neben der Berechnung die auf der Site erklärt ist)... das will sich mir noch nicht so richtig erschliessen. Hat jemand eine einfache Idee?
Die Idee mit der Edge-Klasse hat was... Aber wäre das nicht irgendwie redundante Datenhaltung? Die Anzahl der Objekte würde sich damit ja auch drastisch erhöhen.
Ja. Und wenn du eine Map mit 1000x1000 Feldern hast (also für jeden Pixel des Bildschirms einen), braucht das dann locker mal 100 MB oder so ... Also - der Speicher dürfte da eine eher untergeordnete Rolle spielen. Mein Tipp wäre, das ganze so schön und so einfach verwendbar wie möglich zu machen. Das andere extrem wäre, die ganze Karte als einen dicken int[]-Array zu speichern, da alles mit Bit-Masken reinzucodieren, und beim Zeichnen alles "on the fly" zu berechnen...
@Apo: Ganz klassisch: Man berechnet die Normalen der Dreiecke, definiert eine Beleuchtungsrichtung, und wählt die Helligkeit der Dreiecke abhängig vom Winkel zwischen Normale und Beleuchtungsrichtung....
Sorry hab es zu spät erst gesehen. Wenn jemand den Code haben möchte, bitte bei mri melden.
Ansonsten versuche ich mich grad an der Beleuchtung. Ich möchte die Dreiecke nicht komplett fabrlich verändern, sondern lieber einen Layer darüber legen damit ich das Punktuell machen kann. So wie die bei Widelands. Aber so richtig perfekt ist es noch nicht. Wenn jemand eine Lösung hat, würde ich mich sehr freuen wenn er sie postet =)
Hab mich auch eben am Flat Shading probiert. Aber ich bin irgendwie nicht so das Vectorrechnung-Genie ;( Es kam zwar "irgendwas" bei raus, aber für vernünftiges Flatshading hat's nicht ausgesehen.
Gourad Shading ... Da muss man ja jeden Pixel "anfassen", bzw. seine Helligkeit bestimmen. Zumindest hab ich das so verstanden. Ich denke das könnte ohne Einsatz von OpenGL&Co. schnell problematisch werden. Oder?
Naja kommt drauf an.
Wenn es nur eine Blickrichtung gibt und die Kamera nicht gezoomt bzw gedreht werden darf, dann könnte man den Umweg nehmen, ein Bild mit den Shadinginformationen zu erstellen und das dann einfach über das Polygon zu packen. Das reicht dann locker aus, weil theoretisch könnte darauf aufbauend einfach ein Bild erstellt werden mit dem Untergrund und den Schatten. Dann muss man nur das Hintergrundbild malen ...
Wenn man aber natürlich einen Tag-Nacht-Wechsel im Spiel haben möchte oder die drehende Kamera ... dann muss man es doch immer neu zeichnen.
Ich persönlich würde mich mit der ersteren Variante zufrieden geben. Nur muss ich das mal ordentlich hinbekommen =)
Hmm, stimmt. Wenn man kein drehen und zoomen braucht, dann ist das ganze ziemlich statisch. Also 1x rechenaufwand und fertig.
Auch wenn ich drehen nicht unbedingt bräuchte/haben wollte: Zoomen ist gerade bei großen Karten doch von Vorteil.
Denke ich schau mir mal an wie man eine 3D Lib mit 2D Elementen kombiniert. Da hat man dann drehen und zoomen "schon drin". Müsste man nur noch die Sprites entsprechend reinzeichnen.
Wobei ... Da geht drehen dann auch nur in bestimmten Winkelschritten. Zoomen wäre wohl egal.
Naja. Ich denke nicht dass man auf Serverseite sich mit dem Shading beschäftigen muss. Da reicht es ja wenn man ausrechnen kann ob eine bestimmte Koordinate (X/Y/Z) über oder unter der Map ist, bzw. wenn man den Boden der Karte eines jeden Pixels bestimmen kann.
Der Wegfindungsalgo ist davon ebenso unabhängig. Gleiches gilt für's drehen und zoomen.
Für deine Zwecke ist es glaub ich völlig wurscht welchen Ansatz man nimmt. Hauptsache das zugrundeliegdnde Datenmodell ist gut designed.
Gourad Shading ... Da muss man ja jeden Pixel "anfassen", bzw. seine Helligkeit bestimmen. Zumindest hab ich das so verstanden. Ich denke das könnte ohne Einsatz von OpenGL&Co. schnell problematisch werden. Oder?
Wenn mich nicht alles täuscht könnte man ein "halbes" Gouraud shading relativ einfach machen: Es wird in jedem Dreieck nur zwischen den Farbwerten der Eckpunkte interpoliert. Eigentlich bilinear und pi pa po, aber ... es könnte gut sein, dass man schon schöne Effekte hinkriegt, wenn man da ein GradientPaint geeignet reinlegt... :reflect:
Das mit dem GradientPaint hatte ich mir auch überlegt. Aber habe noch keine passende Lösung gefunden das ordentlich anzuwenden. Das Dreieck hat ja drei Punkte. Man müsste überlegne das Polygon entweder nochmal zu zerlegen oder aber mit 3 unterschiedlichen Farbverläufen von jeder Ecke arbeiten (also Grundfarbe bleibt und dann nur das Shading von jeder Ecke mit Farbverlauf malen ...). Aber so richtig zufrieden bin ich damit noch nicht.
Derzeit sieht Projekt X so aus (natürlich sind die Farbveränderungen durch die Höhe noch etwas extrem ... ist ja für Testzwecke =) ):
Das erinnert mich iwie an Landscapes aus den guten alten Amiga-Zeiten. Eine Tilemap (viereckige Tiles, 2D) werden auf eine Trianglemap (das eigentliche Landscape, 3D) projeziert. Dazu teilt man ein Viereck in zwei Dreiecke... Sollte nicht das Problem sein.
Das Problem ist nun, wie projeziere ich das 3D-Landscape wieder auf eine 2D-Fläche (ohne 3D-Hardware natürlich... so etwas gabs erst in der Amiga-Endzeit). Schlüssel dazu nennt sich 3D projection - Wikipedia, the free encyclopedia. Hatte da auch mal ein Wenig Javacode für, müsste ich suchen... Zumindest existiert im JDK eine Demo (Wireframe) wo das zum Einatz kommt. Allerdings nur ohne Texturen.
@Edit: Noch ein Suchbegriff für Google: Fraktale Landschaften, Voxel Space Engine
