proggen.org

Hiho, ich bastel derzeit an einer isometrischen Game Engine (2D, basierend auf SDL). Irgendwie habe ich das Gefühl, dass etwas konzeptionell wichtiges fehlt

Also bisher besteht sie aus folgenden Komponenten:

• State Machine: Für verschiedene Zustände des Spiels (Hauptmenü, Untermenü, eigentliches Spiel) werden Zustände (States) verwendet. Von einem Zustand kann in den nächsten gewechselt werden. Dabei enthält ein State sowohl Daten als auch Funktionalität zu deren Präsentation, sowie die Programmlogik dazwischen (vgl. Model-View-Controller).
• Application-Klasse: Das Herzstück der "Engine", basierend auf der State Machine. Sie besitzt Methoden zum Laden von Grafiken (aus Dateien, diese werden in einer map<string, SDL_Surface*> zwischengespeichert, damit man nicht immer wieder alles neu laden muss). Dazu kommen Methoden zum Laden von Sounds (werden analog "gecacht") und zum Rendern von UTF-16 Strings (basic_string auf Basis von Uint16) zu SDL_Surface*
• Sprite- bzw. Animation-Klasse: In diesem Kontext wahrscheinlich klar, was das ist Sprites erhalten im Konstruktor den Pointer auf die Application (und damit auf die Surface, die den Bildschirm repräsentiert). Somit kann sich der Sprite "selber malen" (z.B. durch Aufruf der draw()-Methode)
• Input Handling: Erfasst, welche Tasten (oder Mausbuttons) gedrückt wurden, so dass über die StateMachine dann abgefragt werden kann, ob in diesem logischen Durchlauf z.B. die linke Maustaste gedrückt wurde.
• Network-Stuff: Für TCP-Kommunikation habe ich da eine Connection-Klasse, die Daten via Socket schreibt und liest. Damit es "schön" verwendbar ist, ist das ganze noch mit einem generischen Hauch versehen ^^ (z.B. int i = conn->read<int>();) Ausstehend ist hier noch das UDP-Pendant.
• IsometricView: Quasi die Grundstufe der isometrischen Darstellung (vgl. View in MVC). Beschreibt die grafische Darstellung einer isometrischen Karte, bewegt Objekte (optisch) auf ihr hin und her. Dabei verhält sich die View wie ein Sprite (ich meine damit sie kennt die Bildschirm-Surface und kann sich - und ihre einzelnen Kacheln und Objekte - malen).
• TiledModel: Quasi die Grundstufe der gekachelten Karte aus Datensicht (vgl. model in MVC). Beschreibt den Zustand der Objekte (eigentliche "Ingame-Position") auf der Karte, bewegt Objekte (intern) auf ihr hin und her, prüft Kollisionen und solche Späße.
• Widget: Für Buttons, Eingabefelder, Checkboxen und Listenfelder habe ich (basierend auf der Sprite-Klasse) Widget-Klassen geschrieben. In der State-logic werden ihre Zustände (zb ob ein Button geklickt wurde oder was in einem Listenfeld ausgewählt wurde) ausgewertet.

Ich hoffe ich habe nix vergessen Erscheint euch das soweit erstmal sinnvoll?

LG Glocke

Glocke hat geschrieben:Hiho, ich bastel derzeit an einer isometrischen Game Engine (2D, basierend auf SDL). Irgendwie habe ich das Gefühl, dass etwas konzeptionell wichtiges fehlt

Also bisher besteht sie aus folgenden Komponenten:

• State Machine: Für verschiedene Zustände des Spiels (Hauptmenü, Untermenü, eigentliches Spiel) werden Zustände (States) verwendet. Von einem Zustand kann in den nächsten gewechselt werden. Dabei enthält ein State sowohl Daten als auch Funktionalität zu deren Präsentation, sowie die Programmlogik dazwischen (vgl. Model-View-Controller).

Die States verwaltet doch normalerweise die Software nicht die Engine?

Glocke hat geschrieben:[*] IsometricView: Quasi die Grundstufe der isometrischen Darstellung (vgl. View in MVC). Beschreibt die grafische Darstellung einer isometrischen Karte, bewegt Objekte (optisch) auf ihr hin und her. Dabei verhält sich die View wie ein Sprite (ich meine damit sie kennt die Bildschirm-Surface und kann sich - und ihre einzelnen Kacheln und Objekte - malen).

Die Trennung in MVC ist sicherlich lobenswert. Sicher, dass Du sie brauchst? Sicher, dass sie bei Dir nützlich ist? Die Trennung von C und V ist nur sinnvoll, wenn es den Bedarf für mehr als ein V gibt.

Glocke hat geschrieben:Ich hoffe ich habe nix vergessen Erscheint euch das soweit erstmal sinnvoll?

Schwer zu beurteilen... die Frage ist schlussendlich, was Du damit schreiben möchtest und wieviel Kontrolle des Spiels Du in die Engine übergeben möchtest (das Spiel also eine Karte für die Engine ist) oder ob es sich um ein Framework handelt, dass Dein Programm fragt, wie das Spiel eigentlich ablaufen soll.

Xin hat geschrieben:Die States verwaltet doch normalerweise die Software nicht die Engine?

Keine Ahnung, ich würde das der Engine zuschreiben, die sich um die gesamte Anwendung kümmern soll. Der Wechsel (von A zu B) wird aber schon über die Software ausgelöst (nur von der Engine quasi durchgeführt).

Glocke hat geschrieben:Die Trennung in MVC ist sicherlich lobenswert. Sicher, dass Du sie brauchst? Sicher, dass sie bei Dir nützlich ist? Die Trennung von C und V ist nur sinnvoll, wenn es den Bedarf für mehr als ein V gibt.

Naja da ich eine Server-Client-Anwendung daraus machen will (und ich das Model einzigst auf dem Server haben möchte, damit die Clients es schwieriger haben zu cheaten), habe ich das als zwingend getrennt konzipiert. Aus meiner Sicht ist das schon erforderlich

Glocke hat geschrieben:Schwer zu beurteilen... die Frage ist schlussendlich, was Du damit schreiben möchtest und wieviel Kontrolle des Spiels Du in die Engine übergeben möchtest (das Spiel also eine Karte für die Engine ist) oder ob es sich um ein Framework handelt, dass Dein Programm fragt, wie das Spiel eigentlich ablaufen soll.

Naja das Spiel besteht (für die Engine) aus mehreren Karten. Auf dem Server hatte ich überlegt für jede Karte (aus Model-Sicht) eine Instanz im Speicher zu behalten (z.B. wegen mehrere Spieler auf unterschiedlichen Maps). Am Client befindet sich ja hauptsächlich die View, die mit dem Server und damit dem zugehörigen Model kommuniziert.
Die Server-Client-Geschichte würde ich noch zur Engine zählen, d.h. durch die Engine kommunizieren View (im Client) und Model (im Server) miteinander (über den Controller, welcher wieder zur Engine gehört). So richtig im Klaren über das "Ende" der Zuständigkeit der Engine bin ich mir noch nicht ganz

LG Glocke

Glocke hat geschrieben:So richtig im Klaren über das "Ende" der Zuständigkeit der Engine bin ich mir noch nicht ganz

Welche Aufgabe hat die Game-Engine überhaupt? Also wie sieht das Spiel aus?

Naja sie soll das Darstellen der Spielinhalte (durch Verwendung von Sprites, davon abgeleiteten Animationen und der IsometricView-Klasse) und der Netzwerkkommunikation vereinfachen.

Wahrscheinlich ist da eher der Begriff des Frameworks passender

Glocke hat geschrieben:Naja sie soll das Darstellen der Spielinhalte (durch Verwendung von Sprites, davon abgeleiteten Animationen und der IsometricView-Klasse) und der Netzwerkkommunikation vereinfachen.

Naja, Du schriebst 2D und sprachst von Level. Ein PacMan-Level sieht aber anders aus als ein Level in einem Jump'n'Run Spiel oder eines Strategiespiels wie Age Of Empires.
Da Du was über's Netzwerk planst, wird es wohl eher was strategisches!?

Eingangs habe ich von "isometrischer Darstellung" gesprochen. Das umfasst imho Age of Empires, als auch Diablo (jeweils 1/2). Prinzipiell bin ich mir noch nicht ganz sicher in welche der beiden Richtung es gehen soll. Der Idealfall wäre, wenn die Engine beides ermöglicht. Dafür wären wahrscheinlich zwei Engines (die ggf. auf dem gleichen "Framework" basieren, das isometrische Darstellung bietet aufbauen) sinnvoller.

Level ist aber im Bezug auf Karte (Dungeon im RPG oder Map im Strategiespiel) gemacht.