JMonkey geometries and your object model

[ags1]

I am investigating JMonkey and I notice that the early tutorials suggest placing game data in a hashmap on the geometry objects. Sure that is bad idea - reducing your entire data model to a bunch of hashmaps? Also, your game will be tightly bound to JMonkey - it would be really hard to swap in a new framework.

Am I missing something? Obviously the jmonkey approach keeps the class hierarchy flat - perhaps that has some performance benefit that I don't understand.

[sproingie]

Tutorials are there to teach you the engine and its capabilities, not necessarily best practices.  The less extra structure a tutorial has to involve, the more it can focus on the engine itself.

[gouessej]

Hi

I used lots of 3D engines and I tried to support both JMonkeyEngine 3 and Ardor3D some months ago, I finally decided to focus only on Ardor3D. You can avoid tightly bounding your game to a given engine but it is quite difficult and it might increase the memory footprint of your game. I advise you to keep a copy of all models in a format that does not depend on a modeler or an engine, for example Collada, MD2, MD3, MD5, MDL or even OBJ + MTL for static objects.

If I were you, I would spend some weeks or months to choose an engine and stick to it instead of using 4 or 5 different engines during almost 6 years   Don't spend your whole time in writing abstraction layers above high level APIs.