Yes. I give this lecture a lot so others referred to it without stating this directly, I guess. (reading back)
Think MVC… JME is the V.
Model your game objects as you like. (I prefer entity component systems but that’s another learning curve.) Then couple the visualization to your game objects to just to give a display to the user… which is very likely just a small subset of “space” in this case.
what do you think of the following approach? This is my current understanding of the solution proposed by @pspeed
Preliminary requirements:
An AppState shall be responsible for generating the Space instance as well as for loading and saving the game state.
The Space object shall contain and manage SpaceObjects. It shall be possible to add and remove SpaceObjects.
The Space object shall be independent from jme3 context in such a way that it can be run outside jme3 (e.g. with text output).
The Space object shall attach and detach jme3 spatials.
The Player represents the user and shall be linked with the SpaceObject he belongs to.
The Space object shall consider the players transformation in for rootNode update.
The Space object shall accept controllers which apply distinct behavior to the spaceObject.
The Space object update method shall be called during Space updateSceneAndCamera method. Data shall be pushed to the SpaceObjectScene jme3 node.
The controllers update method shall be called during Space Object update similar to jme3 spatial-> control. Data shall be pushed to the SpaceObjectScne jme3 node.
SpaceObject shall use a solver object for position and velocity calculation (e.g. Analytical solver, RK4 integrator, Euler etc…) Calculation shall be d^2x/dt^2 = sumF/m + aGrav
What do you think? Just would like to know wether I understood the point correctly.
Please feel free to comment maybe there are still some traps/missing items which require additional attention.
Personally, I would have “Space” that contains the “SpaceObjects” be its own thing that manages the physics, objects, etc… think of this as a back-end ‘server’ if you like.
There would then be some app state that, for the local player’s view, queries “space” to see what they can see, what range it’s in, etc. and constructs the local scene graph from that.
This is exactly how all of my entity system examples work… except “Space” is “EntityData” and “SpaceObjects” are Entities with certain sets of components. Entity systems are a completely different way of thinking about design and the learning curve is initially pretty steep… but all that being said, it is sometimes mind blowing how much crap it can cut through.
Now I understood the role of the appstate here right now. It is something like a client object of the space server object. But some questions still remain (For discussion I try to answer the questions).
What will be the role of spatial controls in this context?
possible answer: Control and update graphical representation of spatials using server data: While the server of appstate is the Space object the server of controls will be the SpaceObject object.
Which data shall be stored in spatials or spatial controls and which operations can be performed there?
Data which is necessary for graphical representation.
How can I do advanced operations where I used jme3 scene before like collision checks, coordinate transformations etc…?
For Fp128 positions I’ll have to implement my own transformations for this. Collision checks: No idea! Need ray-geometry intersections and geometry-geometry collisions
Note that in regards to #3 there’s nothing stopping you from adapting jME’s stock bounding volumes and rays for this purpose. You just need to refactor them to support your custom math classes and manage the bounding volumes yourself instead of the engine doing it for you (as it would in the scene graph).
