Here is my problem:
I want to try to make a (simple) game with jME and physics. With only jME, I was able to create classes that represent stuff in my virtual world, like a 'Car', which would extend Node and attach everything needed. (Correct me, if this was a faulty approach to start with).
Anyway, all the tutorials and examples I come across have everything stuffed into a single file/class. But how do you structure a bigger world?
I was thinking of having a Level class, that would load a level and all static objects in it. I would also want to create dynamic objects, like a player, cars, birds and what not. But can I simple extend a class from DynamicPhysicsNode?
What would be the best approach to encapsulate model behaviour properly?
All comments are very welcome. Thanks!
In physics fun i created some basic physic objects which extend Node.
The ‘level’ could be a GameState. In the constructor you assembly the level by adding your physic nodes to the scene.
like rootNode.attachChild(new Car());
A other way is to have a base class like Entity (theres one such class in jme) where all your scene elements are derived from.
This class has a getNode() Method, so your Car which is derived from Entity can be added to the scene like
rootNode.attachChild(car.getNode());
I think both are valid methods, but with the latter you are more flexible if your game gets a bit more complex.
In Stardust for example my Entity class has additionally a health/damage field and a doCollision(entity) Method.
There are a lot of ways to structure a game i guess and there is no ‘correct’ way do do something just different ones.
I would generally discourage from extending Node. In jME Physics you cannot extend the physics nodes. In jME you should not (not with entities, at least). I would always favor the other approach Core-dump mentioned: having independent entity objects (without a superclass from jME btw) which link to scenegraph objects. And this is due to flexibility. But I won't extend this here - modeling software is a very complex topic and most things require experience, so… simply try both 
Thanks for all your replies.
I've looked in to Core-Dump's Stardust project. It's really nice, and it got me a better view on how it's possible to structure a game. Thanks for that Core-Dump!
My next step will be figuring out how to load levels and all that. But, all in good time.
Thanks!
i'm glad you find it useful
but many things in it are still a mess and not very nicely structured.
i'm improving things as i learn more about game programming (and OOP cough)
irrisor said:
I would generally discourage from extending Node. In jME Physics you cannot extend the physics nodes. In jME you should not (not with entities, at least). I would always favor the other approach Core-dump mentioned: having independent entity objects (without a superclass from jME btw) which link to scenegraph objects. And this is due to flexibility. But I won't extend this here - modeling software is a very complex topic and most things require experience, so... simply try both :)
Yes extending from a base class can be problematic in Java, since you only get to extend one of them. Choose wisely. That is especially true for a base class that's part of a library. It's generally considered "bad" practice to introduce external library classes into your core inheritance hierarchy. Not that you'd want to switch away from jme, but keeping your libraries at arm's length helps keep you flexible and more tolerant to change (for instance, jme 1.0 to jme 2.0). Mediators, Facades, Adapters and Bridges are good for that sort of thing, if you are ready for them.
If you're a beginner to OO, I have found that a good approach is to try creating your classes independently. When you find yourself cutting and pasting code between classes, that means it's time to merge the common stuff into a superclass (or some sort of delegate or composition). It's somewhat analagous to refactoring a giant method into several method calls.
<soapbox>
One trap that even veteran developers fall into is overanalysis and design up front. You want to think about how you are putting it together first, but don't go overboard. You aren't going to think of everything. That's where agile methods come in. Some of those kinds of design issues have a tendency to work themselves out over time. I try to only sweat the big implementation details up front, and then let my design evolve as the code progresses. That's especially true for a personal or open source project. You don't have to worry about possibly having to "sell" a big refactor to management.
</soapbox>
Some folks are anal about it to the point that they strictly enforce a "no cut n paste" policy in their code.
bwarren: thanks for the advice. I've extensive knowlegde of OO programming and concepts, but I'm just starting out using Java. I tried it back in the day that Java was slow and cumbersome. But with 1.5, I noticed that the speed is really good and that the things you can do with Java have evolved quite a bit.
I'm currently a full-time Ruby on Rails developer, so I do have quite a bit development knowledge, I'm just new to Java and game programming in general, so it's always nice to hear the opinions of more experienced developers in that area. (Any of you guys want to learn Rails? 
)
Anyway, I'm just getting started and I'm now on a learning project. I want to rebuild an old game. I don't remember its name, but you had a level (viewed from the top) where you had to push around boxes into the right positions in order to get to the next level.
Well, I'm trying to write a 3Dish version of that. I just got a custom Blender model imported an showing, but I'm still messing around with the textures and the lighting. Core-Dump's startdust project has been a great help. Maybe not finished in some area's, but certainly good inspiration for a blind man in the world of java game development.
This is a complete threadjack, but have you seen the YouTube videos with Ruby vs. Java? They’re quite humorous, even for Java people.
http://uk.youtube.com/watch?v=PQbuyKUaKFo
I’ve got 10 years of Java but I’m a jme noob. It’s nice to get an idea of other peoples’ skillsets on here.
Oh and if you liked JDK 1.5, you’ll love 1.6 if you haven’t tried it already.
Hehe… I know the one. there are a lot more of those, especially the ruby vs. php was nice.
Before I was always using a complidated web of factories and providers…then I found Spring IOC…
As soon as I found Guice, Spring IOC went out the window…So if you like to have very nice and clean code, use Guice…it will change ur world 