jMonkeyEngine 3.1 alpha 4 released

You can still use SimpleApplication and you’ll be able to during a long time. You can even implement your own application if that floats your boat.
We are not forcing you to use AppStates, we are recommending you to.
Also you have absolute control on the order of AppStates running, because that’s the order you add them to the stateManager…

It’s not pspeed telling you to how to make your game, AppState are the preferred way of composing your game since the beginning of JME3. The only mistake we made was to not make the examples with them.
And on a side note, even if it was, IMO and in my experience “Pspeed way of doing things” is definitely not the worst path to consider.

1 Like

Well what about AppStates that must be attached and detached to work (example: VideoRecorderAppState) (example: a complex finite state automaton of AppStates). The order can quickly change.

The problem with the Pspeed way is that he’s an expert already. And new users or intermediate users aren’t.

That app state needs a rewrite. Generally you only attach and detach app states rarely if at all. For example, starting a single player game, attach a bunch of app states. Exit single player game, remove them again. Else they should always be there.

App states are run in the order you add them but it does bug my that there is no way to declare dependencies. I will be adding something like that for 3.2.

Apropos dependencies: I use that when defining commands for the ingame console. A command is a little class extending ConsoleCommand - in the c’tor you provide a clazz for the kind of game (or appstate) you need for that command in order to work. The console will only allow to add those commands that the game (or appstates) really support - so you will never have the VolcanoExplodeCommand if there is no GameWithVolcano (interface) or VolcanoAppState (appstate) - so it will not appear when typing in “help” [ENTER] - which lists the available commands only.

I think the order of AppStates might still be a topic. One might be interested in creating new AppStates on demand and having control over their order.

Important to know what @nehon wrote - that we still can make our own apps. I’ve used SimpleApplication for my OGF (Open Game Framework) and would create an app class like that when making my framework fit for the future. I hope that my framework will become some kind of standard (or at least one school of thinking about how to make jME games).

Also note: part and parcel with a base application rewrite will be a rewrite of all the tests/examples. Many of them do some strange things even within the older default approaches of magic protected fields. Those and a couple of the existing app states deserve a good once over.

Plus, things like camera controls will probably be morphed into app states which is more appropriate for an input handling thing.

Well… I have a few appstates which have the only purpose to MANAGE OTHER APPSTATES (attach/detatch/enable/disable)

Yeah, I also have a composite app state that can attach/detach its children and selectively enable/disable them with itself as well.

I wish to make certain I understand this correctly as in my case I had already implemented this, it seemed the natural thing to do.

  1. In the future we will extend BaseApplication rather than SimpleApplication.

  2. Updating our existing game is as simple as changing SimpleApplication to BaseApplication in our main class.

  3. Headless server, from an implementer perspective, will not be any different.

Edit: Didn’t realize the age of the thread, it just showed up for me, thought it was recent.

Eventually…

Presuming you don’t use any of SimpleApplication’s protected fields, don’t override simpleInitApp() or simpleUpdate() with anything important, etc… then yes. SimpleApplication will be around for some time as it will take time for folks to migrate that stuff.

Very nice design.