GameStateManager or ScreenManager?

Started by
8 comments, last by SiCrane 12 years, 6 months ago
I'm currently thinking of creating a "larger" game.
Now first of let me define the word larger in this context!

It's a tile based game with a lot of menu's all with it's different systems and logic.
For example you got your:
  • Main menu screen
  • Option screen
  • Credit screen
  • Game Screen <-- Don't know what to call this but basically it renders the game and handles all of the games input for moving around, interacting with the environment and the like.
  • Inventory screen
  • Quest screen

And many more screens, some of these screens will just be treated as a popup screen and renders over the current screen whilst just disabling the main screens logic but still makes it draw.
All these screens have different logic and draws different images than the others.
So I'm thinking a class called "GameScreen" that all these different screens inherits from and allows overriding the two main methods "updateLogic()" and "drawScreen()" which in turns enables them to have different update and draws. And then let a ScreenManager class do all the work and handling the screens and states of the screens.

But I'v also heard many people like to have some kind of GameState instead? Like:

public void UpdateGame()
{
switch(GameState.getState())
{
case State.Initializing:
break;
case State.MainMenu:
break;
and so on.....
}
}

Or do people usually combine them and how does it look like if they do?


Advertisement
What I do is indeed create a baseclass named Screen

Abstract Draw()
Abstract Update()

Now I create the different screens
MenuScreen inherits from Screen
GameScreen inherits from Screen
Whateverscreen inherits from Screen

in my game class I have then a Screen CurentScreen property

Now all I have to is change the CurentScreen to whatever I want to display.

in Game. Update and Game.Draw, I just call CurentScreen.Update and Curentscreen.Update. No need for switch statements

The advantage of doing this is that all code for each screen is confined in a separate class.

The other thing I know people do and I think that is what you are talking about is to use of FSM (finite state machines) to trigger the transition from one screen to another. I have never done this but it would male sense if you have a lot of screens and need to switch from one screen to a lot of different screens depending on what the user wants.

What I do is indeed create a baseclass named Screen

Abstract Draw()
Abstract Update()

Now I create the different screens
MenuScreen inherits from Screen
GameScreen inherits from Screen
Whateverscreen inherits from Screen


Yeah I have an abstract base class called "Screen" that has:
protected bool isFocused, isActive
protected GameEventHandler

aswell as the abstract methods:
Draw and Update

and a method called notifyEventHandler(Event e)

Basically gives the screen to send an "Game Event" to the GameScreenManagers -> GameEventHandler class that takes and processes the events.
The isFocused and isActive is for handling the screen while an "popup" window is active aswell "Like you have obtained the sword of awesome, and a small box shows in the middle of the screen"
It allows for the game to render but not update ( so like a pause feature but still showing the background of the game )
I try to avoid manager classes. Usually I have state objects that implement an abstract state interface. The state interface uses the run and return successor pattern. So if you have a state object that doesn't have a state transition when it updates, it returns itself. If it wants to transition to a pause state, it constructs a new pause state and returns that state on the update call.

I try to avoid manager classes. Usually I have state objects that implement an abstract state interface. The state interface uses the run and return successor pattern. So if you have a state object that doesn't have a state transition when it updates, it returns itself. If it wants to transition to a pause state, it constructs a new pause state and returns that state on the update call.


I would also like to avoid using Manager classes but I have a problem stitching it all together, design and code wise that is.
At the time right now I'm still having a hard time getting the code to get together like for example:

I have the ScreenManager to hold a list ( or well stack ) of all screen objects and then also an GameEventHandler object that well handles the Event objects and processes them.
The Screen objects in the list must be able to send of events somewhere so in the ScreenManagers method "AddScreen(Screen screen)" I also call the Screen's method "setEventHandler(GameEventHandler handler)" so that the Screen objects can access the "AddEvent" method inside the GameEventHandler object.

I don't know if this is a good approach or not :( ?
You'd have to give me a concrete example for me to comment on what you're doing.
I'm making an Game ( using XNA and C# ) that is basically a small ( very small ) Rougelike game.
The map is tiled based and eventually I can place event objects with properties.

When a player enters a object or "Tile" that contains one of these events the TileMap class ( which contains the map data ) will return that player has met the event condition.
The screen "Main Game Screen" that is basically rendering and updating the main games logic as moving around, interacting with different stuff and such, will then get that event and send it of to the EventHandler that then process the event.

It also enables other screens to use it like for buttons pressed and choices selected and can fire that event off to the handler and be processed.
So It's not JUST for the Main Game Screen.

Something like that :o?
I'm still not seeing why you want or need an event manager class.

I'm still not seeing why you want or need an event manager class.


Basically you are asking my why I'm just not triggering them on the spot instead of flinging them away in a queue?

EDIT:
That is a good question! Hmm, I'll try to avoid having the "Manager/Handler" .
I'v always thought you should use them 1. For containing and handling objects in one place 2. Cleaner code
Is there a reason I should not use them :o?
I'm just trying to figure out why you want this class around. If creating an object simplifies your code, then that's a good thing. However, it sounds like your event manager doesn't actually simplify anything; it's just adding a layer of complexity without any returns.

This topic is closed to new replies.

Advertisement