Jump to content
Unity Insider Forum

Game States - Pro / Contra - Diskussionsrunde


Ismoh

Recommended Posts

Hallo allerseits,

ich versuche gerade mein Aktivitätsdiagramm nach Game States zu gliedern, jedoch fehlt mir die Erfahrung dieser.

 

Nutzt ihr Game States ?

Wieso ?

Wie nutzt man diese am besten ?

 

Ich würde mich freuen, wenn ihr mich vollspamt mit Erfahrungen :)

 

P.S.:

Ich wollte anfangs pro "Game State" eine Scene benutzen - bin mir aber nicht sicher, ob das eher unspaßig wird.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Jedes Game benötigt (oder hat ganz einfach) Game States, zumindest in dem Sinn, wie ich sie kenne. Und sei es nur Splashscreen-Play-GameOver. Ob du das mit einzelnen Szenen machst oder mit einer UI, die du je nach State einblendest, hängt auch viel vom Spiel ab.

 

Am Anfang würde ich mir überlegen, welche Gamestates dein Spiel überhaupt hat. Bei einem Multiplayer kommt da schnell einiges zusammen. Splashscreen - Serverwahl - Lobby - Gamesetup - Playersettings - Game - Auswertung und so weiter. Dann ist so was wie ein Game-Manager nötig, der je nach GameState die Szene bereitstellt, Übergänge managed usw.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Achso. Dann habe ich Game State glaube ich falsch verstanden.

Ich dachte das sind so eine Art von Definitionen für den Level-Fortschritt.

 

Also definiere ich mittels Game State das Ende ...

Ne bin etwas verwirrt.

..

Game States definieren Ereignisse des Spiels - ist das richtig?

 

Es soll ein 2D SciFi RPG Sidescroller werden :D

Ich möchte eine Art von Videosequenzen einblenden. Dafür wären Game States angebracht, oder ?

Link zu diesem Kommentar
Auf anderen Seiten teilen

Wie kann man ohne GameState denn arbeiten bitte? :D

 

Meine GameStates identifizieren aktuelle Lage im Spiel zu verschiedenen Dingen.

 

Im Spiel selbst kann das wichtig sein.

Is GameState == prepare um zum Beispiel Timer zu anzeigen

 

Beispiel bei meinem Doodle Towerbuilder. Da gibt es diese Werte

 

public enum States {
 START,
 WAIT_FOR_DRAG,
 DRAGGING,
 WAIT_FOR_ENDING,
 END,
 SETUP_CAM,
 GAMEOVER,
}

 

States würde ich jetzt aber bei Unity nicht für die ganzen UI benutzen. Seit dem neuen kann man mit einem MenuManager einfach abfragen, welches Menü man gerade anzeigt :). Naja kommt auch natürlich darauf an wie Komplex das ganze ist. Vergleich man die oben genannten States, sieht man das ich im Spiel total viele verschieden Arten von States habe. Da kann man nicht einfach mal Fragen "Aktuelle Menü == Option" oder so. Früher wars aber anders beim GUI musste immer abgerufen werden, welches gerade "gezeichnet" werden soll.

 

Zweitens sieht alles viel übersichtlicher und schöner aus:

 

void Update() {
 switch (currentState)
 {
  case States.START:
startHandler();
  break;

  case States.WAIT_FOR_DRAG:
waitForDragHandler();
// next does other script
  break;

  case States.DRAGGING:
draggingHandler();
  break;

  case States.WAIT_FOR_ENDING:

// if timer started
if(StayStillTimer > 0) {
 StayStillTimer -= Time.deltaTime;

 // if timer ended and something is still moving, so set timer again
} else if(anyBoxIsMoving()) {
 StayStillTimer = 1f;
} else {

 // if nothing is moving and timer is ended so continue
 currentState = States.END;
}
camMoveHandler();
  break;

  case States.END:
endHandler();
  break;

  case States.SETUP_CAM:
setupCamHandler();
  break;

  default:
break;
 }

}

 

Allgemein States kann man auch für alles benutzen um Übersicht zu bekommen wo man sich aufhält. So ne Globale State sage ich mal (auch bei UIs)

Da sieht man Beispiel wo man sich gerade aufhält.

 

Bei kleinen Spielen braucht man das nicht, aber bei großen und vor allem im Multiplayer spielt das große Rolle.

Das hat Hrungdak schon geschrieben.

 

 

Nebenbei doodle towerbuilder kannst hier spielen. Dann siehst du warum gamestates Vorteile bringen: http://bit.ly/1PVUkj9

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das Ganze kann man noch weiterspinnen. GameSates können auch so aussehen:

 

public abstract class GameSate : ScriptableObject
{
public bool IsActive = false;
public abstract void OnStart();
public abstract void OnUpdate();
public abstract void OnDisable();
}
public class GameStateAB : GameSate{
public override void OnStart(){IsActive = true; Debug.Log("Start GameStateAB");}
public override void OnUpdate(){ Debug.Log("Update GameStateAB"); }
public override void OnDisable(){Debug.Log("Disable GameStateAB");}
}
public class GameStateXY : GameSate{
public override void OnStart(){IsActive = true; Debug.Log("Start GameStateXY");}
public override void OnUpdate(){ Debug.Log("Update GameStateXY"); }
public override void OnDisable(){Debug.Log("Disable GameStateXY");}
}
public class StateManager : MonoBehaviour{

public GameState CurrentState;
public GameSate State1; // <-- GameStateAB
public GameSate State2; // <-- GameStateXY

IEnumerator Start()
{
 SwitchGameState(State1);
 yield return new WaitForSeconds(3);
 SwitchGameState(State2);
}

public void Update(){
 if(CurrentState.IsActive)
  CurrentState.OnUpdate();
}

public void SwitchGameState(GameSate gameState){
 if(CurrentState){
  CurrentState.IsActive = false;
  CurrentState.OnDisable();
 }
 CurrentState = gameState;
 CurrentState.OnStart();
}
}

 

Warum mal wieder ScriptableObjects? ...du kannst damit die States an verschiedene Objekte packen ;)

Ich seh gerade, ich habe das nur in NotePad++ runtergeschrieben...die kleinen Fehlerchen sind ja schnell zu korrigieren und ich deklariere das aufgrund dieser Tatsache als "PseudoCode" ;)

Link zu diesem Kommentar
Auf anderen Seiten teilen

Das Ganze kann man noch weiterspinnen. GameSates können auch so aussehen:

 

public abstract GameSate : ScriptableObject
{
public bool IsActive = false;
public abstract void OnStart();
public abstract void OnUpdate();
public abstract void OnDisable();
}
public GameStateAB : GameSate{
public override void OnStart(){IsActive = true; Debug.Log("Start GameStateAB");}
public override void OnUpdate(){ Debug.Log("Update GameStateAB"); }
public override void OnDisable(){Debug.Log("Disable GameStateAB");}
}
public GameStateXY : GameSate{
public override void OnStart(){IsActive = true; Debug.Log("Start GameStateXY");}
public override void OnUpdate(){ Debug.Log("Update GameStateXY"); }
public override void OnDisable(){Debug.Log("Disable GameStateXY");}
}
public StateManager : MonoBehaviour{

public GameState CurrentState;
public GameSate State1; // <-- GameStateAB
public GameSate State2; // <-- GameStateXY

IEnumerator Start()
{
 SwitchGameState(State1);
 yield return mew WaitForSeconds(3);
 SwitchGameState(State2);
}

public void Update(){
 if(CurrentState.IsActive)
  CurrentState.OnUpdate();
}

public void SwitchGameState(GameSate gameState){
 if(CurrentState){
  CurrentState.IsActive = false;
  CurrentState.OnDisable();
 }
 CurrentState = gameState;
 CurrentState.OnStart();
}
}

 

Warum mal wieder ScriptableObjects? ...du kannst damit die States an verschiedene Objekte packen ;)

Genial :D.

Nutze ich diese States, dann mit ScriptableObject.Instantiate() ?

Eig nicht, oder ?

Muss ich mir die Tage mal in Ruhe anschauen.

Link zu diesem Kommentar
Auf anderen Seiten teilen

Ich würde die so ranhängen...aber eigentlich ist es egal, du willst an denen ja nichts modifizieren, eher auch mal zur Laufzeit laden...

Stimmt.

Finde die OnX-Methoden mega geil :D

Da kann ich dann ScriptableObjects instanzieren und GameObjects.

Oder welche destroyen.

Eig mag ich das nicht, wenn man leute so feiert, aber bei dir mach ich mal ne ausnahme :D

Geiler Affe dieser Typ

Link zu diesem Kommentar
Auf anderen Seiten teilen

Archiviert

Dieses Thema ist jetzt archiviert und für weitere Antworten gesperrt.

×
×
  • Neu erstellen...