How to organise a gamestate well?

Troubleshooting General Help
1

I’m not a English speaker…so maybe the problem isn’t expressed well. I would be very grateful if you understand and notify me to correct.

The point of my question is that I think sometimes a gamestate is not totally player-controlled. For example, a gamestate probably consists of a fade-in effect, a 2 seconds’ pause, an object’s move(maybe a book is opened), the main part, another 2 second’s pause and a fade-out effect. Apart from the main part, all other phases take place automatically and in order.

However, if I write all these stages into that gamestate’s update method, it would seem too crowded and unreadable. Yet, if I divide the gamestate into several pieces of smaller gamestate, there would be too many of them.

I know I can use Control classes to encapsulate, for example, the fade-in effect, but I still need relatively complex codes to put several stages in order. (something like creating a class variable to represent which stage is now)

I’m not a very experienced programmer and the jmonkeyengine is something new to me. I don’t know if there’s better way to organise and manage a gamestate. Any ideas on my questions would be highly appreciated.

2

If your game is mainly a large state machine, you might want to look at the strategy pattern, or some similar logic, and then make each state a actual class, implementing a simple shared interface. Then you main game only needs to be coded against that interface, and handle state transisition, everything else is done by the states.

1 Like
3
@Empire Phoenix said: If your game is mainly a large state machine, you might want to look at the strategy pattern, or some similar logic, and then make each state a actual class, implementing a simple shared interface. Then you main game only needs to be coded against that interface, and handle state transisition, everything else is done by the states.

Thank you Empire Phoenix! I’ve seen the state pattern description on wiki that you mentioned, and I think that’s really useful, thanks!

However, what I want to ask is, I think, a little different from that. Well, consider a game scene which is made of 5 stages —the fade-in effect, one animation, the main part (controlled by the player), another animation, the fade-out effect.

Logically, these 5 stages should belong to one gamestate, yet if all stages were written in one update method, there would be too many if-else statements. But dividing 5 stages into 5 gamestates is either a good idea, I think.

For example, if let me solve this problem, I would write something like this:

[java]

//…

int stage = 1;

void fadeIn() {
//…
if (isFadeInOver())
stage = 2;
}

void firstAnim() {
//…
if (isFirstAnimOver())
stage = 3;
}

void mainPart() {
//…
if (isMainPartOver())
stage = 4;
}

void secondAnim() {
//…
if (isSecondAnimOver())
stage = 5;
}

void fadeOut() {
//…
if (isFadeOutOver()) {
// switch to a new gamestate
}
}

public void update(float tpf) {
switch (stage) {
case 1: fadeIn();
case 2: firstAnim();
case 3: mainPart();
case 4: secondAnim();
case 5: fadeOut();
}

// …

[/java]

What I wrote seems a bit stupid… I believe this can be improved. I’m not very experienced, so any slight idea in your eyes is highly likely to be very helpful to me. Thanks again.

4

Yep similar to this, then I suggest the use of an enum for the internal state to improve readability. + a setNewState()
the pro, you can easily add logging/sysouts in the setNewState, to debug if something does not work as expected

5

I would go at it this way:

Attach the intro… once that has run it’s course, have it detach itself and attach the playing app state. When playing ends, have it detach itself and attach the outtro app state.

6
@loopies said: I would go at it this way:

Attach the intro… once that has run it’s course, have it detach itself and attach the playing app state. When playing ends, have it detach itself and attach the outtro app state.

Thanks for answering!

About your idea, wouldn’t it seem to be so many gamestates? This is just a small example, but what if there are tens of gamestates like that? If all gamestates are divided into several sub-gamestates, would it cause a bit mess?

I’m not sure if it’s appropriate for a big game project to create many many gamestates for every fade-in and fade-out states (because sometimes fade-in/out effects are different and cannot be reused)

Thanks again!

7
@Empire Phoenix said: Yep similar to this, then I suggest the use of an enum for the internal state to improve readability. + a setNewState() the pro, you can easily add logging/sysouts in the setNewState, to debug if something does not work as expected

Thanks very much, but what you said about ‘logging/sysouts’ seems new to me. Could you please explain a bit more?

By the way, I think maybe looking at how a relatively big project solved this problem would be helpful for me. Do you know where to fine such a proper open-source game project?

Thank you very much.

8

Well I would design with debugging in mind, so it is suefull to change your state = x to setState(x) then you can if sometzhing does not work as expected add to the setState somethings like

setState(EState x){
System.out.println("Changing from " +currenstate + " to " + x);
currentstate = x;
}

This greatly helps when you have many states later, and something does not work as excpected.

9
@Empire Phoenix said: Well I would design with debugging in mind, so it is suefull to change your state = x to setState(x) then you can if sometzhing does not work as expected add to the setState somethings like

setState(EState x){
System.out.println("Changing from " +currenstate + " to " + x);
currentstate = x;
}

This greatly helps when you have many states later, and something does not work as excpected.

Thanks very much, I’ve understand what you mean.

10

Hi,

I see you don’t really familiar with JME system so i will go from the basic first:

  1. You can use state to represent a GUI screen : a duration of activities that not obviously look like changed to another form/ appreance. But state also mean internally they are different (what they containing, what children related to them, what functions they provide). Because state are first class citizen in jme3, you can use it to direct almost every aspect of the application. Changing the ui and screen are only small part of those. How many game state are up to you. The split of them are depend on the design and also take a look of criteria above (differencies in contain, relate, functions etc…)

  2. Transistion are the progress of moving from one state to another: it often involve an interpolator, which take all the meaningful and similar (same type, same meaning) values from stateA and calculate current values until it reach stateB values. It often look like :
    val1 = stateA.val1 * (1-t) + stateB.val1 * t;

fadein and fadeout are too application of this.
3) Monitoring states is not hard but the current implementation of StateManager not support many features.

[Sorry self advertisment] In my Atom framework I leverage them alot by adding annotations such as @Monitor, @Transistion, @Stateful, @Depend

@Monitor mark a State to be monitored by the GameStateManager’s Monitor: all the workload and performance cost of its init and update, its Stateful values are monitored.
@Transistion mark declare next State of a State and Transistion time need, just as what the animation framework did
@Depend instanstiate the new State by its Depend via dependency injection.
All variable that is Stateful and Transistional are transfer automaticly to the nextstate by invoke the appropriate method.

That’s just some ideas of how to “well” States can be organize and monitored!

Best regards,

11
@atomix said: Hi,

I see you don’t really familiar with JME system so i will go from the basic first:

  1. You can use state to represent a GUI screen : a duration of activities that not obviously look like changed to another form/ appreance. But state also mean internally they are different (what they containing, what children related to them, what functions they provide). Because state are first class citizen in jme3, you can use it to direct almost every aspect of the application. Changing the ui and screen are only small part of those. How many game state are up to you. The split of them are depend on the design and also take a look of criteria above (differencies in contain, relate, functions etc…)

  2. Transistion are the progress of moving from one state to another: it often involve an interpolator, which take all the meaningful and similar (same type, same meaning) values from stateA and calculate current values until it reach stateB values. It often look like :
    val1 = stateA.val1 * (1-t) + stateB.val1 * t;

fadein and fadeout are too application of this.
3) Monitoring states is not hard but the current implementation of StateManager not support many features.

[Sorry self advertisment] In my Atom framework I leverage them alot by adding annotations such as @Monitor, @Transistion, @Stateful, @Depend

@Monitor mark a State to be monitored by the GameStateManager’s Monitor: all the workload and performance cost of its init and update, its Stateful values are monitored.
@Transistion mark declare next State of a State and Transistion time need, just as what the animation framework did
@Depend instanstiate the new State by its Depend via dependency injection.
All variable that is Stateful and Transistional are transfer automaticly to the nextstate by invoke the appropriate method.

That’s just some ideas of how to “well” States can be organize and monitored!

Best regards,

Thank you very much for such a detailed answer! I should apologise that I didn’t reply you in time…

I’ve read your reply through and I’m really grateful that you recommended your framework to me. However, I think it might be a little too advanced to me, so currently I think I don’t have enough capablity to apply your framework.

So, could you please teach me some techniques base on jme3, to apply fade-in/out effects on not only scene transition but also 3d objects and 2d images or texts? (sorry if i’m too greedy :))

Thanks again!