Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Best way to organize Screen states in the code  (Read 1790 times)
0 Members and 1 Guest are viewing this topic.
Offline Nietzschean

Senior Newbie





« Posted 2006-12-04 14:44:12 »

Hi folks,

Most of the simplest examples of Java2D games have something like:

1  
2  
3  
4  
5  
6  
7  
public void run() {
       while (running) {
             gameUpdate();
             gameRender();
             paintScreen();
       }
}


In each method you have what you need to update, render objects and paint screen. This is very simple and nice when you are showing how to make a game and only have one screen. What about when you have more screens? (menu, Single player mode, multiplayermode, options, etc).
What is the best way to organize this so that each one of this methods knows what to do depending on which part of the game you are?

My initial thought was to create a State class. Each different part of the game would extend from state and then you would have something like this:
1  
2  
3  
4  
5  
6  
7  
public void run() {
       while (running) {
             state.gameUpdate();
             state.gameRender();
             paintScreen();
       }
}


Of course this would mean that the state variable would change inside update sometimes so this might create some problems.

What do you guys think of this? In your experience what is the best way to control the flow of these things?

Thanks

"If I find 10.000 ways something won't work, I haven't failed." - Thomas Edison
Offline Kova

Senior Member





« Reply #1 - Posted 2006-12-04 14:57:40 »

well in most games everything is actively rendered. That means menus are rendered through gameRender() also. So first example stays the same, only you would have more stuff in your gameRender() to check what to render (game or menu for example).

BUT if you are using swing for your game menu you can't active render swing without using hacky stuff which are unreliable and not tested (see my and CommanderKeith's discussion over this in java2d subforum). I use swing for game menu, and what I do is put swing menu in one panel and game animation in another. When I want to draw menu I show menu panel and hide game panel, and when I want to draw game I show game panel and hide menu panel. I've found CardLayout to be excellent for this, as you can have only one component visible at a time and you can call .show("component name") to simply display that component when you want to switch to, let's say, game menu.

If you are using OpenGL have a look at FengGUI.
Offline Nietzschean

Senior Newbie





« Reply #2 - Posted 2006-12-04 15:09:11 »

I'm using only Java2D and everything is rendered in a JPanel.

I think you didnt understood very well what I wanted. My problem here is that I don't want to have a gigantic  gameUpdate() and gameRender() methods. I want to separate each part of the logic to include only what each part of the game needs to do. That's why I talked about the State classes and have one for each part of the game, where each one would have their own gameUpdate() and gameRender() and then in my main run() method I would call the one I need at the moment.

Example:
1  
2  
3  
4  
5  
6  
public abstract class State;
public class MenuState extends State;
public class OptionsState extends State;
public class SinglePlayerState extends State;
public class HighScoreState extends State;
...


I just wanted to know if this is a good solution or if there is a better one and more traditional one.

"If I find 10.000 ways something won't work, I haven't failed." - Thomas Edison
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline kevglass

JGO Kernel


Medals: 118
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #3 - Posted 2006-12-04 15:13:28 »

Your state class idea is a good one. I use this interface (though in this case it's not Java 2D):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
24  
25  
26  
27  
28  
29  
30  
31  
32  
33  
34  
35  
36  
37  
38  
39  
40  
41  
42  
43  
44  
45  
46  
47  
48  
49  
50  
51  
52  
53  
54  
55  
56  
57  
58  
 public interface GameState extends InputListener { 
    /**
     * Get the ID of this state
     *  
     * @return The game unique ID of this state
     */

    public int getID();
     
    /**
     * Initialise the state. It should load any resources it needs at this stage
     *  
     * @param container The container holding the game
     * @param game The game holding this state
     * @throws SlickException Indicates a failure to initialise a resource for this state
     */

    public void init(GameContainer container, StateBasedGame game) throws SlickException;
     
    /**
     * Render this state to the game's graphics context
     *  
     * @param container The container holding the game
     * @param game The game holding this state
     * @param g The graphics context to render to
     * @throws SlickException Indicates a failure to render an artifact
     */

    public void render(GameContainer container, StateBasedGame game, Graphics g) throws SlickException;
     
    /**
     * Update the state's logic based on the amount of time thats passed
     *  
     * @param container The container holding the game
     * @param game The game holding this state
     * @param delta The amount of time thats passed in millisecond since last update
     * @throws SlickException Indicates an internal error that will be reported through the
     * standard framework mechanism
     */

    public void update(GameContainer container, StateBasedGame game, int delta) throws SlickException ;
     
    /**
     * Notification that we've entered this game state
     *  
     * @param container The container holding the game
     * @param game The game holding this state
     * @throws SlickException Indicates an internal error that will be reported through the
     * standard framework mechanism
     */

    public void enter(GameContainer container, StateBasedGame game) throws SlickException;
 
    /**
     * Notification that we're leaving this game state
     *  
     * @param container The container holding the game
     * @param game The game holding this state
     * @throws SlickException Indicates an internal error that will be reported through the
     * standard framework mechanism
     */

    public void leave(GameContainer container, StateBasedGame game) throws SlickException;
}


The enter and leave methods gives the state a chance to do something as we start using and stop using them as the actual game state.

Kev

Offline c_lilian

Senior Member


Projects: 1


Java games will probably rock someday...


« Reply #4 - Posted 2006-12-04 15:20:23 »

What I do in my games :

- abstracted away a 'game flow controler' (singleton) whose role is to manage game states

- each state then has s set of methods
  - init() called once
 - start() called when the game enters this state
 - update(double deltaTime) invoked many has long as no state change is required
 - end () at the end of the state
- destroy() at the end of the game, or the end of a game phase (when you are sure you will never need this state again)

changing of gamestates is just a matter of invoking 'GameFlowControler.instance().setNextState(nextState)' in the update() method at appropriate times.

It's very simple to implement and powerful enough for most games (although it doesn't support game logic multi threading).

If you add an abstraction of rendering (like a scenegraph), you can even use multiple states working with the same display (like : showing a 'game over effect' while the game gackground is still display'). which is good as it keeps your classes small and dedicated.

Lilian Smiley

Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #5 - Posted 2006-12-04 19:53:42 »

1  
2  
3  
4  
5  
6  
public abstract class State;
public class MenuState extends State;
public class OptionsState extends State;
public class SinglePlayerState extends State;
public class HighScoreState extends State;
...


that's a good idea. also, you might wanna make sure you do not mix drawing with model classes (MVC pattern).

Offline Nietzschean

Senior Newbie





« Reply #6 - Posted 2006-12-04 21:20:01 »

Thanks for the feedback guys.

"If I find 10.000 ways something won't work, I haven't failed." - Thomas Edison
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

ctomni231 (33 views)
2014-07-18 06:55:21

Zero Volt (29 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (26 views)
2014-07-16 23:30:00

Cero (41 views)
2014-07-16 00:42:17

Riven (43 views)
2014-07-14 18:02:53

OpenGLShaders (31 views)
2014-07-14 16:23:47

Riven (30 views)
2014-07-14 11:51:35

quew8 (29 views)
2014-07-13 13:57:52

SHC (65 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!