Du bist nicht angemeldet.

Werbeanzeige

1

16.08.2010, 16:57

Gamestate - Design probleme

Hallo,

ich habe in den letzten Tagen versucht Gamestates zu porgrammieren, das klappt auch alles wunderbar, aber jedes State muss
auf die Game Klasse zugreifen können um auch die States zu wechseln. Das klingt nach keinem Problem ist es aber wenn man
die State Klasse im Game Header inkludieren muss UND die Game Klasse im State Header.

Hier mal ein wenig Code als Beispiel

--> Game.hpp

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
#include"State.hpp"

class Game
{
public:
    //Funktionen

private:
    State* mState; //Der aktuelle gamestate
};


--> State.hpp

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
#include"Game.hpp"

class State
{
public:
    //Funktionen

private:
    Game* mTheGame; //Das spiel
};


Eine vorwärts deklaration klappt nicht, da die Funktionen der Game Klasse klappen müssen.
Aus diesem Problem komme ich nicht mehr raus :(

FalkT

Treue Seele

Beiträge: 125

Wohnort: AC

  • Private Nachricht senden

2

16.08.2010, 17:05

aber wenn man die State Klasse im Game Header inkludieren muss UND die Game Klasse im State Header.
Warum mußt du das tun ?
Warum reicht keine Forward Declaration ?

NachoMan

Community-Fossil

Beiträge: 3 905

Wohnort: Berlin

Beruf: (Nachhilfe)Lehrer (Mathematik, C++, Java, C#)

  • Private Nachricht senden

3

16.08.2010, 17:08

könntest aber auch mit rückgabewerten arbeiten^^
"Der erste Trunk aus dem Becher der Erkenntnis macht einem zum Atheist, doch auf dem Grund des Bechers wartet Gott." - Werner Heisenberg
Biete Privatunterricht in Berlin und Online.
Kommt jemand mit Nach oMan?

4

16.08.2010, 17:09

Eine vorwärts deklaration klappt nicht, da die Funktionen der Game Klasse klappen müssen.


Steht da doch ^^

Denn VC++2010 zeigt folgenden Fehler:

C-/C++-Quelltext

1
2
3
4
1>c:\c++projekte\platformer\platformer\stategame.cpp(6): error C2027: use of undefined type 'Game'
1>          c:\c++projekte\platformer\platformer\state.hpp(7) : see declaration of 'Game'
1>c:\c++projekte\platformer\platformer\stategame.cpp(6): error C2227: left of '->Do' must point to class/struct/union/generic type
1>c:\c++projekte\platformer\platformer\stategame.cpp(6): fatal error C1903: unable to recover from previous error(s); stopping compilation


@Nachoman
Ja für die ChangeState Funktion schon, aber in der Game Klasse sind sämtliche andere wichtige Objecte, die für Grafik, Sound etc. wichtig sind.

5

16.08.2010, 17:19

du tust ne forward declaration in die state.hpp, und inkludierst dann in der state.cpp eben beide header

6

17.08.2010, 11:03

Empfehle dir folgende 2 Samples:
http://www.ogre3d.org/tikiwiki/Game+Stat…ucture=Cookbook
http://www.ogre3d.org/tikiwiki/Managing+…ucture=Cookbook

boost hat auch ne state machine
http://www.boost.org/doc/libs/1_44_0/lib…HTML/index.html

alles schöne beispiele für uml2 standard. In erster Linie empfehle ich natürlich boost, allerdings ist dies meines Erachtens nicht gerade schön zu lesen.
Man sollte das Rad nicht immer wieder neu erfinden, sonst wird man nie fertig :thumbup:

Gruß
Markus

Beiträge: 775

Beruf: Student

  • Private Nachricht senden

7

17.08.2010, 19:14

Ich find ein starres Gamestate-System für die meisten Fälle ohnehin nicht sonderlich angebracht.
Letztlich ist es doch so, dass man viele Datenbestände über das ganze Spiel hinweg braucht. Zum Beispiel hat man doch permanent eine GUI. Oft lässt sich ein Spiel außerdem gar nicht mal so zerstückeln, dass man immer ganze Teile lädt und zerstört.
Ich arbeite mittlerweile lieber mit flexibleren, verteilteren Statusangaben.
Ein Gamestate-System wär in CuBrush zB. praktisch unmöglich gewesen, weil man ja immer die Spielwelt da hat - klar die Spielwelt hat nicht immer den Status "Spiel läuft" und ergo auch nicht immer Spieler. Aber deswegen entlad ich nich nicht das halbe Programm.

Außerdem sollte man sich mal überlegen in wie weit man in wirklich unabhängige Gamestates unterteilen kann. Meistens kommt dann raus Credits - Hauptmenu - Spiel, wobei Spiel vllt noch ein paar mal unterteilt ist. Letztlich braucht man überraschend viele Daten möglichst Griffbereit.
Unterteilungen kann man da machen, wo beispielsweise eine Spielwelt geladen wird.
So gibt es auch in der Architektur von Xrodon II keine Spielzustände. Das ganze Spiel ist von oben betrachtet eine Klasse die eine GUI-Klasse verwaltet die permanent besteht und eine Game Klasse die besteht, wenn ein Spiel läuft. Die Gameklasse selbst kümmert sich wieder um unterzustände die teilweise bestimmte Objekte (andere Klassen halt ;)) bedingen. Diese haben natürlich auch wieder verschiedenste Zustände - und die müssen dann nichtmal ein stures Enum sein.

Summa summarum ist das Game State Prinzip meiner Meinung nach ein Schema das sich in Reinform nur in sehr wenigen Fällen anweden lässt und einen oft viele Steine in den weg stellt. Hat man ein kleines Projekt lohnt sich eine Abrieglung oft gar nicht, weil man gleich direkt ins Spiel einsteigen will. Hat man ein großes Projekt verwehren einen die Abriegelungen den Zugriff auf wichtige durchgehende Resourcen (oke das gilt beim kleinen erst Recht :D)

Werbeanzeige