5 Replies - 6718 Views - Last Post: 14 June 2014 - 02:59 PM Rate Topic: -----

#1 Waylander  Icon User is offline

  • New D.I.C Head

Reputation: 2
  • View blog
  • Posts: 3
  • Joined: 31-May 14

Game screens versus game states in game code organization

Post icon  Posted 31 May 2014 - 03:24 PM

First post so please bear with me :). I've tried searching for answers but terminology (see below) problems have stifled those attempts.

I've been teaching myself programming for a while now and have slowly but surely been getting better and better. I've been getting my head wrapped around game screens and game states and as I've tried tackling projects that are getting more and more ambitious, I'm really starting to see how game screens and game states can be very useful. But the problem lies in trying to figure out what differences there are, if any, between game screens and game states.

So what I'm after here is some clarification about screens and states and if they are not the same thing, how they work together. From what I've read, here is my understanding so far:

Game screens are used for different "screens" in a game. For example, in a simple game you may have a splash screen, a menu screen, a gameplay screen, and a credits screen.

Game states are used for different modes in a game. On a basic level it can be what "state" a character is in. For example, a character can be walking, running, crouching, dying, etc. On a larger level, a "state" can be different levels within the gameplay "screen."

And this is where part of my confusion comes in. If my above explanation is correct, I am still unsure how to get the various screens, states, and managers to work together. I've been working with XNA and have been working with various managers (including screen managers) and while I have an idea on how I can have various screens and states work together, it feels incredibly unwieldy and inefficient. So I'm looking for a way to set up a game via screens, states, and managers. To date I haven't found any information that addresses this specifically and any tutorials I've found just show basic information and no implementation.

So in the spirit of learning to set something like this up, I figure I'll start small and ask for some feedback on creating a simple game along the lines of the old NES game "Lifeforce." Here's my thoughts so far:

A game screen manager that has a stack of screens and only updates the one at the top. In XNA, each screen would be a drawable game component. The screens could be splash, menu, gameplay, and credits.

The gameplay screen would contain the "states" that would determine which level would be drawn/updated. This screen would contain any managers for gameplay (player(s), enemies, terrain, etc. I'm thinking a switch could be used to determine how the managers update and when.

This is where it gets fuzzy for me. I'm not quite sure that having all of this in the gameplay screen is the best way to go. But if it is, can anyone give any advice on how to work with the managers in here? Should there be a separate set of managers for each level? For example, for level 1, a certain enemy manager would be created and run and for level 2, the first enemy manager would be destroyed and another one created for that level?

Like I said, that seems pretty unwieldy for one gameplay screen but that also may be my ignorance since I'm still learning and venturing into unfamiliar territory here. I'd appreciate any advice or comments :).

Is This A Good Question/Topic? 2
  • +

Replies To: Game screens versus game states in game code organization

#2 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 571
  • View blog
  • Posts: 1,272
  • Joined: 24-April 12

Re: Game screens versus game states in game code organization

Posted 01 June 2014 - 03:40 PM

I'll start out by saying I'm no expert at this and have really only begun to explore the issue myself.

But last year when we were doing the Pong Challenge in the XNA forum we discussed this problem.

The way you are describing it the difference between states and screens is that a state is probably an enumeration and a screen is probably a class. Really, there are a lot of ways to do this and no truly "correct" way. It would be nice to know how major game studios handle this but I don't hear any of them talking.

My Pong prototype that I worked on to iron out some basic concepts had a ridiculously capable (er... over complicated) screen manager. (Hopefully, this is the full project for the actual working Pong 2D game since I also have another project from earlier that doesn't actually work. I put that zip file out there for everyone last year.) That was one of the reasons I wrote a prototype instead of writing the actual game; I wanted to get the screen manager ironed out before attempting any serious work as well as some other minor things. That's all XNA code for your viewing pleasure and you can see how I did it.


However, earlier in the thread I posted my code for a simplified screen manager that had most all the elements but was just a sample rather than a game. I was intending to work in 3 stages: Develop a Screen Manager and Test it, Use the Screen Manager to build a basic classic Pong game, and then finally use it to build 3D Pong, which I never got around to due to family issues that took me away from the Challenge during the final month when I was planning on doing the actual game.

Anyway, I forgot what I did because it was about 8 or 9 months ago and I haven't looked at it since December. But the simplified example code I posted directly in the thread illustrates the concept while keeping it simple and the Pong code actually uses it in a simple game.

I got the foundation for my game state manager from an XNA book as I mentioned in that thread. But by the time it got to code my code barely resembled the code I got it from in the book. Really, my simple example is probably more clear in understanding it than what was in the book because I really worked to clarify and simplify it for that code. You can copy and paste that code.

You may also want to take a look at the pinned thread by lordofduct on his entity framework idea. It is similar to the approach Unity takes to game design and dove tails nicely with XNA.

In Unity, you have like a separate Scene saved for every "screen".

I can't really remember how I handled it in my code. It's just been too long and I'd have to reverse engineer it at this point. But I did come away from that experience with the belief that I had over complicated it and maybe just keeping it as simple as possible might be the best approach next time.

Oh. I should probably mention that I'm using the terms state and screen interchangeably when discussing my code in the thread.

This post has been edited by BBeck: 01 June 2014 - 03:56 PM

Was This Post Helpful? 2
  • +
  • -

#3 Waylander  Icon User is offline

  • New D.I.C Head

Reputation: 2
  • View blog
  • Posts: 3
  • Joined: 31-May 14

Re: Game screens versus game states in game code organization

Posted 02 June 2014 - 03:33 PM

Thanks for the reply! You hit the nail on the head when you said, "It would be nice to know how major game studios handle this but I don't hear any of them talking." That is exactly what I'd like to see. I know that there is no "correct" way but I'm thinking about some of the industry's "best practices" that are out there and it sure would be nice to see how various things are tackled so I can study them.

I'll look into your program as well as the links you posted :).

I had an idea after I made the original post to create another screen manager INSIDE my gameplay screen and I've been slowly getting it hammered out. I figure that the gameplay screen can keep anything that needs to be updated updated throughout the game (for example, in my Lifeforce clone idea, the player manager in the gameplay screen will remain active and the player can keep whatever powerups they've collected from level to level) while at the same time having its own screen manager that can manage a stack of screens that are the levels themselves. So when the time comes, the old level can be popped and the new one pushed on all within the original gameplay screen.

That's the plan anyway :). So far it seems to be working but I haven't gotten to the point where I can transition from level one to level two. Need to work a few more things out first. But at any rate, how does that idea sound? And can't wait to check out your Pong game :).
Was This Post Helpful? 0
  • +
  • -

#4 stayscrisp  Icon User is offline

  • フカユ
  • member icon

Reputation: 998
  • View blog
  • Posts: 4,175
  • Joined: 14-February 08

Re: Game screens versus game states in game code organization

Posted 03 June 2014 - 05:33 AM

This book may be a good buy for you http://www.amazon.co...y/dp/1133776574
Was This Post Helpful? 1
  • +
  • -

#5 Waylander  Icon User is offline

  • New D.I.C Head

Reputation: 2
  • View blog
  • Posts: 3
  • Joined: 31-May 14

Re: Game screens versus game states in game code organization

Posted 13 June 2014 - 08:26 PM

I've been studying your Pong code. Not as much as I'd like (have had to put it on the backburner a bit) but I think I'm understanding what you were after.

stayscrisp, I took your advice and got a copy of that book. Started reading it today and after getting about 50 pages or so in, it looks like this could be exactly what I needed! Thank you! Can't wait to get more into it.
Was This Post Helpful? 0
  • +
  • -

#6 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 571
  • View blog
  • Posts: 1,272
  • Joined: 24-April 12

Re: Game screens versus game states in game code organization

Posted 14 June 2014 - 02:59 PM

Glad you're getting some use out of it. :rockon:
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1