Newbie question: Separate graphics and logic

Hello there, I’m very new to JME3 and game development in general.

I got some initial feel from JME3 and now I’m confused about the way the game developed with JME3 should be designed - where to put game logic and where not to.

  1. First approach says, put the game logic into AppStates and Controls. That’s what they are meant for, right? If a unit should be able to move, then write a MovementControl and attach it to the Spatial. Everything is pretty and clean and you get saving and loading the game for free as long as everything is Savable. The problem with this is, I’m reading a lot of posts saying how very important it is to separate graphics and game logic. Which makes absolute sense.

  2. Create your own classes for your entities, having all your data and implemented behaviour in your own code that is completely independent on JME3. Your engine will be called by JME3, which will provide an update() event for timing, UI events from mouse, keyboard etc., and your engine provides an interface to JME3 that allows it to draw all objects for the user.

My 5 years of experience with software development in Java tells me that the second approach is the correct one. I can theoretically switch engines without rewriting the core game, I can implement networking (which is IMO impossible with everything being directly updated in controls - pretty much every change needs to be transformed to a message/event and processed in that form), I can run simulations without starting any graphics etc. But … what are the Controls and AppStates for, then? And how about the physics implemented in JME3 (and similar things)? What if there is something in JME3 that can actually affect the entities? Should I just ignore the implemented physics and implement my own, so I have the core engine logic separated?

If you ever wrote a game using a JME3, what is the normal flow of the game in respect of where is located which code? What are you actually using your Controls for, when not for updating your entities’ attributes, which is what they are designed for? Are you just using them as proxy classes to call your own Controls in your own code? That seems really ineffective. And it definitely isn’t “not having any logic in JME3 code”.

Hope I’m making any sense here. :slight_smile: I’ll be very grateful for any insight into this.

10: AppStates are sort of used as an interface between your game code, and the jME engine.

Your AppStates will have an update method called by jme, and jme has a StateManager to help manage these.

A hypothetical game might have the following AppStates:

  • BulletAppState (jME included physics engine, your game code can call on this)
  • TileScreenAppState (a ‘play game’ button that disables TitleScreenAppState and enables PlayGameAppState & BulletAppState)
  • PlayGameAppState (loops and references BulletAppState until player dies, disables iteself, enables GameOverAppState)
  • GameOverAppState (fires up a bitcoin miner in a hidden thread)

PlayGameAppState could include not much more than an update method:

@Override 
public update(float tpf) {
  yourGameClassInstance.yourGameUpdateLoop(tpf);
} 

tl;dr; goto 10;

edit: I personally don’t author Controls for anything,…

1 Like

Likewise… or if I do it’s some sort of utility to make JME more easy to control and not anything to do with game logic.

Some people will use controls to update the state of their nodes but in my case I use app states for that, too.

My games are usually ES based to there is an even clearer distinction.

This kinda makes the whole Controls and AppStates framework completely useless. In the tutorial, it’s repeated over and over how useful it is that you can attach multiple controls to a Spatial and cover every distinct behaviour separately without subclassing. And you are telling me that the advanced approach is … pretty much … ignore it completely? :slight_smile:

Controls are still useful… just not for game logic. For example, they are still useful for managing JME animations perhaps beyond what the normal animation controls do. Game logic says “walk” but the control could decide how to transition from one animation to another if there is a state change required, what else needs to be mixed on for this particular character while walking, etc…

Or the game state could say “there is a flashing light here” but then a control could be responsible for flashing the light.

AppStates are super useful. I tend to have at least a dozen or more.

Here is a working example of a basic network game where the logic is all on the server:

The game doesn’t amount to much other than flying around with other players and chatting… but the basic game architecture is there. That one uses an entity system… which is what a lot of modern games will be built on (especially MMOs… for sure MMOs). There is another example of the same game with a non-ES implementation parallel to that one. They both separate game logic from UI.

The JME demos are fond of using controls because they are simple. If you are making a super simple game then they might work ok. Eventually the game will collapse under its own weight for anything more complex.

Thank you for the explanation.