Application States and Update Loop


I’m new to jMonkey and got some general questions that i asked myself during development.

The game I’m currently developing got a player class, where I instantiate the player and attach controls to it and also a Monster(NPC) class, where I instantiate the monsters and attach their controls. Both classes extends AbstractAppState. I just wanted to wrap up blocks of code which belong together and put them in a different class, so that not all instantiations are handled in one class. It’s not necessary to enable and disable one of those app states, It’s just for wrapping up code blocks and still got acess to the app. But is this the right design decision, or should I do it in a different way?

I read in the doc, that you only can acess other AppStates in the update loops. But the player interacts with he monsters all the time. So for example when I click with the mouse(a PlayerInteraction control which is added in the Player app State to the player) on one of the monsters(which are instantiated in the other app State), I call specific methods on a control attached to them. But the check if the mouse button was clicked happens in an actionListener and not in the update method. Does that mean the game can get out of sync? Do I always need to set a boolean when something was clicked, respond to it in the update method and set it back to false? Thats not a great way of doing it, I think. Or is the actionListener a “part” of the update loop?

If the actionListeners are called out of order with the update loop, how it is possible that in the “Hello Input” tutorial the player gets rotated in the analogListener class and not in the update Loop, even it is the same Application State it should cause problems I think.

So, how is the general design pattern and am I doing something wrong here? Do I use different application States in this case our how would you solve it? Or is it just not added to the doc of AppStates(“You can only access other AppStates (read from and write to them) from certain places: From a Control’s update() method, from an AppState’s update() method, and from the SimpleApplication’s simpleUpdate() loop.”) that it is not a problem when you call them from a action/analog Listener? In my case I don’t call the appStated directly, but controls which are attached to a Spatial created in the appState. Does that make a difference?

Thank you for your help .

Action listeners and all other InputManager related stuff are all called as part of the update loop.

Thanks :slight_smile:

So is it the right design decision to use different application states in this case?

sure why not, do what ever is easiest for you/makes most sense

Sounds fair :slight_smile:

Thanks for the quick answer

@futuragon said:
Thanks :)
So is it the right design decision to use different application states in this case?

To do or not to do is sort of up to you.

However, if all your app state is doing is some stuff in initialize() then there probably isn't much point to making it an app state. You could just call that stuff directly.

App states are nice when you need to do stuff on update() or handle being initialized/cleanedup, enabled/disabled.