Hi Leute,

Ich habe gerade erst mit OpenGL angefangen. Da mein Plan war, ein Iso-game zu erstellen, 3D aber vorteile hat, habe ich beschlossen ein 3D- Iso Mix zu programmieren, also eine 3D Welt auf "Fliesenbasis"

Hier meine ersten Gehversuche (siehe Anhang).


ich habe mir folgendes überlegt:

Ich erstelle verschiedene IDs für die jeweiligen Textur/Bebauung der "Fliesen" in einem zweidimensionalen Integer - Array.



ist das ein Sinnvoller ansatz? Wenn nicht, bitte Verbesserungstipps.


EDIT:

Screenshot mit Texturen^^

_________________
FinnO

Damit ich dich richtig verstehe:
Du möchtest also eine Flache Karte erstellen, wobei jedes Feld einen bestimmten Untergrund haben darf.
Du willst zwischen den Feldern keine Übergänge.

Nunja... du könntest auch gleich die TexturID in dem Feld speichern. Schließlich ist das auch nur ne Zahl. Wenn du aber noch andere Auswertungen machen willst ist der Code vielleicht gar nicht so schlecht.

Es kommt auch ganz drauf an, was du mit den Feldern machen willst. Wenn die einen Inhalt haben sollen (z.B. Ressourcen, Truppen, Gebäude etc.) dann wäre es besser die Felder als Klasse darzustellen. Am besten im MVC (Model-View-Controller) Pattern.

Die Ausgabe ist nur ein Teil einer Anwendung. Wenn die Art wie du deine Daten darstellen willst (z.B. OpenGL) die Struktur deines Programms beeinflusst, dann läuft irgendwas falsch. Wenn du alles schön von einander kapselst, sollte es z.B. möglich sein, zwischen einer GL Ausgabe und einer z.B. Canvas ausgabe zu wechseln.
Auch wenn du das im Moment nicht vorhast, wäre der Ansatz einer solchen Trennung sicherlich nicht die dümmste Idee.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ja, du verstehst mich ^^

naja jedes Feld ist bei mir ja EINDEUTIG definiert durch dieses Array. Das einzige, was OpenGl benutzt ist die Map-Zeichen Prozedur, und ich kann mir auch nicht vorstellen, dass da weg zu lassen Und ich habe gedacht das ich jedem Feld so auch objekte zuordnen kann, quasi, dass Gebäude auch eine ID haben. Die Truppen sollen wie in jedem normalen RTS nicht an dieses Fliesung gebunden sein.

_________________
FinnO

So hätte ich das vor 5 Jahren auch gemacht. Aber ObjektOrientierte Programmierung bietet dir hier eine bessere Möglichkeit. Jedes Feld ist ein Objekt. Und dieses Feld besteht einerseits aus den Zeichendaten (also z.B. TexturID, Postion, was immer du noch willst) und den Spieldaten (was steht dort, Ressourcen, etc.). Außerdem noch regeln für den Umgang mit dem Feld. z.B. Wer kann etwas bauen, wer kann es betreten, wer kann Infos abfragen in welchem umfang etc.

Das sind die 3 Teile Model (=Spieldaten), View (=Zeichendaten) und Controller (=Spiellogik).

Am Ende hast du eine Karte die einen Zeichenbefehl hat. Diese Karte wiederum ruft für jedes Feld den Zeichenbefehl des Viewobjektes des Feldes auf und dieser Aufruf produziert die Ausgabe.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das hab ich mir mal als Tipp vom profi^^ zu Herzen genommen und nocheinmal neu angefangen mit einer Feldklasse und einer Mapklasse. Danke für den Tipp! Bisher läufts ganz gut, ich hab nur noch ein Problem mit den Texturen, aber das schaff ich auch noch^^

OPENGL macht SPAAAAAß^^

_________________
FinnO

Wenn du dir dazu mal die reine Theorie durchlesen willst dann kann ich dir die Softwareentwicklungstutorials im Wiki empfehlen.
Schau die dir mal an. Du wirst das ncht komplett durchziehen (müssen), aber es gibt dir einen Einblick.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

würdest du dir meinen Krams vielleicht mal anschauen?

(Die TCamera Class kann man sich momentan getrost schenken, aber soweit der Rest sollte klappen^^)

Dazu ist vielleicht zu sagen:

Pfeiltasten : Karte Bewegen
".","," : Karte Drehen

_________________
FinnO

Sorry, ich hab nur ein altes Delphi und das wirft mir einen compilierfehler. Außerdem hab ich seit Jahren kein Delphi mehr programmiert.

Aber so wie ich das sehe vermischt du die 3 Schichten wieder.

Versuch mal analytisch ran zu gehen. Nimm dir mal die Fragen und schreib dir alles dazu auf.

Welche Sachen gibt es in deinem Spiel? (z.B. Karte, Felder, Gebäude, Einheiten, Ressourcen/Waffen...)
-> Das sind Sachen für die du ein Entity Objekt brauchst. Also das Model.

Welche Sachen sind im Spiel selbst zu sehen? (z.B. siehen oben, außer Ressourcen/Waffen)
-> Das sind Sachen für die du eine Ausgabe brauchst. Also die View.

Was können die einzelnen Entitys machen? (z.B. Truppen bewegen, Gebäude bauen, RendereObjekt etc.)
-> Das sind jeweils UseCases für die du einen Controller definierst. Controller bilden die Logik in deinem Spiel. Sie nehmen die Entity Objekte und manipulieren deren Daten.

Die ganze Sache ist nicht so einfach - wenn man es gleich richtig machen will.

Eventuell kann Sascha da mal was zu sagen. Er hat einen direkteren Ansatz und ein ziemlich gutes Bauchgefühl. Nebenbei ist sein Projekt W ja quasi das, was du machen willst (in groß).
Nebenbei... Hast du dir mal seine Bomberman Tutorials durchgelesen? Die könnten dir weiterhelfen.

Ich als Javaprogrammierer würde da viel mit Interfaces arbeiten, um die Schichten zu trennen. Kennst du Interfaces (gibts auch in Delphi). Alternativ ist "learning by doing" sicherlich keine schlechte Sache. Aber dazu ist das was du vorhast zu groß, denn der Code den du mit LbD erstellst ist zwangsläufig ein Wegwerfprodukt.

Leg dein Spielkonzept doch vielleicht erstmal zur Seite und versuch die Verschiedenen Komponenten die dein Spiel später einmal benötigt in ein oder mehreren Demoprojekten zu erproben.
z.B.:
- Menüs (Wichtig! Schreib kein neues Menüsystem sondern probier einmal die der anderen DGL mitglieder aus. Da gibts einige interessante Kandidaten.)
- Textausgabe (Lossy eX hat eine hervorragende Lib dafür geschrieben)
- Schau dir mal an was Callbacks sind. Damit kannst du viel Spass machen.
- Versuch ein Gerippe zu bauen, wo du alle Bestandteile zusammen bringen kannst.

Es gibt verdammt viel zu lernen, aber es lohnt sich.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

hi, wenn du tatächlich isometrie in 3d haben möchtest, dann kann ich dir folgenden thread ans herz legen (natürlich von mir^^)
viewtopic.php?t=7638&highlight=isometrie

dort zeige ich wie man die Kamera perspektive so umstellt, dass man tatsächlich eine perspektive wie in alten iso-games bekommt, nur dass man alle features aus der 3d behält.
zum Beispiel, kann man die szene auch frei rotieren mit den gl typischen funktionen.

für eine Kameraklasse sind hier im Wiki schon 3 Beiträge verfasst, diese sind sehr umfangreich und vermischen teilweise die Eingabeinformationen mit der eigentlichen Kamera, was meiner Meinung nach nicht von Vorteil ist, da man die Tastatur,Maus etc. von allem trennen sollte um sie seperat zuverarbeiten.

_________________
Klar Soweit?

es geht mir ja letztendlich nur um dieses Fliesensystem

_________________
FinnO

achso! dann, schau doch nach "tilebased games" da findste alles was dich glücklich macht. auf Gamedev gibts dazu viele tutorials die erklären wie diese typischen kachelsysteme aufgebaut werden und was man alles damit anstellen kann. Iso ist normalerweise die beschreibug der perspektive, deshalb dachte ich, dass du auch so eine perspektivmatrix brauchst um die kacheln auch wie in solchen spielen darzustellen.
Sehr interesannt bei den tutorials, dass auf die Datenformate für Karten und einzelen kacheln eingegangen wird und wie man effiziente Levelsysteme kreieren kann. Meistens passt da zwar nicht ideal auf die eigene Idee, aber die grundlagen die darin enthalten sind machen trotzdem schon richtig gut was her.

In dem Sinne viel Spaß (ich bin übrigens auch bei dem versuch ein solches system zu bauen)

_________________
Klar Soweit?