Confused about appstates

breakspirit · July 17, 2013, 12:27am

I read the tutorial on app states and I am left with many questions. Can someone please enlighten me?

Appstates should be more about data whereas Controls are more about behaviors, yes? The tutorial makes it sound like you should have the appstate do a lot of actions for your in-game objects and I’m unsure what the difference is between when I should use an appstate and when I should use a control.
Should the Player be an appstate? A control? Both?
Should NPCs be an appstate and/or control?
Should scenes be appstates? For example, if I’ve got a town scene, should that be its own appstate? Then, when the player moves to another scene, simply swap out the town appstate for something else? Is that right?

Thanks for any guidance you can give.

pspeed · July 17, 2013, 1:07am

App states are for global things or things you’d otherwise extend application to add. Controls are for things you’d extend node to add.

ie: AppStates are a way of adding functionality to the application and controls are a way to add functionality to a node. And in both cases, they can be swapped in and out as needed.

Technically, a “player” is neither. It is a game object. The same goes for NPCs. The tutorials tend to encourage you to make visualization objects into game objects but this is a bad practice in the long run.

Scenes can be app states… then you can just swap the state to load a new scene. You could also have one SceneAppState that loads different scenes as you need them (that’s probably what I’d do personally). A lot largely depends on whether each scene will have custom logic that makes sense to have in an app state.

Some of it is personal preference.

SirFizX · July 17, 2013, 1:20am

@breakspirit
Think of OpenGL as an analogy. OpenGL is a “state machine library” where each state evokes a particular output/behavior for a given set of state values/data.

The diagram below shows part of the OpenGL State Machine. Notice how the Color Pointer and Draw Arrays values are each elements of the discrete data set which evokes a particular output from the Vertex Array Control. Similarly the EvalCoord and Map data help determine the Map Evaluation value which in turn partly determines the output/behavior of the Evaluator Control.

Essentially, the AppStates are discrete data sets with game variable elements whose values collectively correspond/map to particular output/behaviors/Controls. So the AppStates may have names such as OpeningState, PlayerEditorState, GamePlayState, EndCreditsState, etc. whereas your controls may be RigidBodyControls, NiftyScreenControllers, EffectsControllers, etc. whose parameters are determined by the current AppState(s).

Appstates should be more about data whereas Controls are more about behaviors, yes?
Yes
The tutorial makes it sound like you should have the appstate do a lot of actions for your in-game objects and I’m unsure what the difference is between when I should use an appstate and when I should use a control.
A particular AppState may require changes to the parameters of several separate Controls.
Should the Player be an appstate? A control? Both?
A player should have controls whose parameters hinge on the current AppState(s).
Should NPCs be an appstate and/or control?
NPCs should have controls whose parameters hinge on the current AppState(s).
Should scenes be appstates? For example, if I’ve got a town scene, should that be its own appstate? Then, when the player moves to another scene, simply swap out the town appstate for something else? Is that right?
Scenes may have environmental Controls, LOD Controls, etc. whose parameters hinge on the current AppState(s).

breakspirit · July 17, 2013, 1:33am

Thanks a lot for the detailed responses, guys. Definitely gave me a lot to think about. The tutorials show adding controls directly to Spatials in the SDK. Would you agree that that is not the best way to add a control to the Player? I.e., the Player should not be treated as just a Spatial with Controls?

A good followup question, then, is what is the best way to “associate” a Player class (which has Controls attached to it) with a Spatial?

Or, if a Control SHOULD be attached directly to a Spatial representing the Player, how should I “associate” the Player class with the Spatial/Control pair? In my mind, the Player class includes things like HP, run speed, etc.

pspeed · July 17, 2013, 3:34am

I personally favor a more MVC approach where the game objects are the model and most of the “game” could function without a user interface. Then the scene graph, etc. is strapped on as the View/Controller of that.

In that case you might have one or more app states that manage the “game logic” and then the controls would be given or would look up the appropriate game object… but now we start to get towards “Entity systems” which is a whole other mind-altering topic.

breakspirit · July 17, 2013, 3:38am

That’s actually exactly what I had in mind. I design web site backends at work and so that’s how I naturally wanted to think about the problem. I just couldn’t see how the models would fit into the whole node/geometry/control paradigm

pspeed · July 17, 2013, 3:42am

Controls are kind of like… the… controller in MVC.

They coordinate updating the model from UI interactions and updating the UI from model changes. So if your game objects has moved then the control can move the spatial to the right place, etc…

breakspirit · July 17, 2013, 3:56am

When I think about MVC, I think about it like this:

The controller then has no direct access to the view. That way of thinking seems to me to be in conflict with the jme idea of a control being a behavior that you tie to spatials(views).
It seems like it takes away all the benefits of using a Custom Control and being able to use them as modular behaviors that you tie to spatials.

pspeed · July 17, 2013, 4:04am

In your picture, how did the user interact with the controller? Generally: through the view.

And anyway, the distinction between view and controller is often a fuzzy one.

I don’t see why controls can’t be general, though… but I still think in terms of an ES these days. My scene graph objects and controls are pretty thin, actually.

toolforger · July 17, 2013, 9:03am

I’d say an AppState is something that can be globally activated or deactivated. (The name derives from “application state” for a reason.)

In my designs, usually the AppState is responsible for creating/enabling various activities.
E.g. game modes (load screen, pre-game screens such as what game to load and save, normal in-game, paused state, etc.)

One can put more into AppStates, such as activating a bunch of NPCs as the player goes near. AppStates aren’t hierarchical though, you’d have to manually wire up interdependencies between AppStats so that if you deactivate the In-Game state, it needs to also deactivate all NPC states (and reactivate the NPC states as well). Most games do not use AppStates for in-game stuff AFAIK.

pspeed · July 17, 2013, 9:31am

@toolforger said: Most games do not use AppStates for in-game stuff AFAIK.

For various definitions of “in game stuff”, I think that’s true.

I have many app states “during” my game but half stem from camera-related stuff and the other half stem from HUD/control related stuff.

For example, I have a PlayerState that is responsible for translating real game world coordinates into local scene graph coordinates for use by other states and controls. It is also responsible for turning mouse and keyboard events into player movement and facing.

I have a GameCameraState which manages the fov, camera offset relative to local origin, etc… It uses stuff produced by PlayerState to resolve this.

I have two terrain related states for hi-res and low-res terrain. Both use the current world tile position to page in portions of the terrain. While these could have been controls on a node, I like the app state full life cycle for these a little better and it made it easy to enable/disable them. Also, they manage thread pools and stuff… just feels weird having these be subordinate to a node.

I have some AppStates to manage HUD layers and game-specific app states to manage different areas of the HUD. The ItemState manages the UI showing what the player is holding and translates key and mouse events into tool/item interactions.

Some of my app states are modular… like the one that manages debug info in the HUD and the debug keys. Some like the ItemState are extremely specific to game elements.

But it’s important to note that all of these are basically bridging that gap between the player and the game world. They translate player-centric game world state into view stuff and translate controller input stuff into game world state.

Any of my other game object to scene graph adapting is done with controls.

zarch · July 17, 2013, 4:49pm

HeroDex using AppStates for in game stuff. For example when in a match there is a Match AppState active, when moving a Hero around the world there is a Hero AppState active, etc.

The classic MVC architecture had the controller being the “glue” that stuck the model and the view together.

atomix · July 17, 2013, 7:32pm

@breakspirit
Good question!

I’ve also had thoughts about the design of a 3D graph scene + game architecture in term of MVC paradigm.

First, MVC paradigms can show up here and there, mostly in GUI, but layered , mixed together, even unclear in one design, especially for games. Because not every game have clear separation of Presentation, Data and Logic parts! (keep that in mind or messed up quickly as you trying to separate the MVC problems as much as you can, cause at the end you can’t and don’t have to)

Talking about MVC in general is a big and over-complicated topic, let’s zoom in a little bit. I saw your another post about RPG.
Currently professional studios do games more or less data-driven, some of them (including me) do software modeling and then creating game like this?

A lot of 3d assets: models, effects…
A lot of configs : as scripts, text
Description of entities
Description of gameplay as States! More sophisticated actions descripted in code / scripts
Controller / Script attach to specific Model’s instance (Spatial) in the scene graph will control its behavior: movement, AI, …etc
… [more] but out of topic

This somehow a haft-ass solution toward an “famous” entity framework - composition over inheritance!

Now talking about MVC embed in this approach and the same thing in JME architecture

Here M-V-C pattern nearly seen as C-V ( I say almost as Control View paradigm)… because common simple game just having Data as representation of Game objects and data stick directly to game object! Note: Spatial is a mixed term, you can see it as Entity, which is Data/ Model (M), also has embedded descriptions for Repesentation, then be updated, renderedl by the Renderer / AppStates as Control © …

So i’m telling you JME architecture are good as a base for various kind of game and also very trendy! (To find a Universal Game Architecture are clueless)

My personal advice: Now ask your self how Data-driven your game is? Then do you want to really have a full-blown clear software design or just want to make a game and save your efforts… I read your comments and see that you have quite knowledge about software designing to notice the confusion but you don’t have to, and dont let it slow you down… That said, even if you can pass through the design phase with bullet proof OOP solution, or washed out all with an Entity framework. You will facing confusion more or less eventually…!

However, @SirFizX did metioned some best practices that actually HELP in making a game. Let’s start with it at first and come through the process step by step!

Cheers,

P/s: All this stuff should be somewhere in the wiki, to reduce the repeated questions about how JME handle Logic… I’ve seen like 3-4 topic about it already !!