Two comments…
Don't expect this to compile agains JME 2.0… 2.0 is a completely NEW engine and probably no game or framework made with 1.0 will compile over it… I'll port Gcore to 2.0 (when released and integrated with Jmephysics)
About GameStateFactory… I don't want to expose the game state creation to the game developer in Gcore… Although I can actually code a factory method, That would make the object compositions dependent on the game state being intantiated by the factory… And that's EXACTELY what I want the game developer NOT TO THINK of… (how do I code this stuff, etc?)
I prefer to have one well equiped game state (camera, physics, adio, etc…) and you don't care about it anymore when coding components, all the infrastructure is present… BUT, if you're worried about the useless objects present, I plan to create singletons for Audio and PhysicSpaces, so all gamestates share the same refernce…
About documentation.
Yes, I have some UML and an article explaining much more of the architecture. I'll post it when I receive clearance from the conference, probably in one-two weeks from now.
This goes to Yunspace:
I think all those example game states from the JME source tree are an example of how not to compose a game… They use inheritance to create different kinds of game states. If I'd expose a way of how to create different infrastructure game states (apart from how to attach game objects) I'd use the same composition approach I used to the game objects…
Code one generic game state, with a collection of InfraStructureComponent (Abstract class)… I'd create subclasses of this abstract class such as AudioManager, PhysicsManager, CameraManager, etc etc… Each one having it's update method…
So my GameState will be designed like this:
AbstractComponent ----<> GameObject ----<> CompositionGameState <>---- InfraStructureComponent
But that I think will be overngineering, since I DON'T think we need more infrastructure than:
- A Master node
- RenderPassManager (for special visual components, such as terrain splatting)
- Camera
- Audio
- Physics…
BUT, it's possible that I end up with this composition structure for gamestates indeed, to enable some flexibility… But remember that most of the built-in components are dependent on the infrastructure components (but I can automaticaly check this - more details in the article to come)…
One thing I know I WON'T enable is GameState INHERITANCE…
Composition…OK
Did you get what I meant? Open to suggestions
sounds good perick. My curiosity about the classes isn't so much to understand how to use it (that is straightforward I think), but mainly just to understand the concept in general, which is pretty interesting.
I think I kinda get what you mean… will definitely ask more questions further down the implementation path.
Hmmm maybe we should all go and post in the original "Data-driven game engine" thread instead?
http://www.jmonkeyengine.com/jmeforum/index.php?topic=6980.0
Yes, that
Peric: Thanks for the answer and thank you all for the following discussion I didn't reply back because at first I couldn't give any useful feedback and then I got busy afterwards. This seems very interesting and I'm going to keep an eye on this, then try it out soon (gotta get a hand on the jME basics first ).