Which SceneGraph is optimal to begin with for small game programming?

Question

I am a Java web application developer (mostly server side) since 7 years who recently got interested in game development (i dont know why, maybe i am bored). Today I was looking for frameworks. I read about a few scene graphs and took a look at jMonkeyEngine. It was recommended here and here.

My first goal was to create a simple plane and a sphere which could be moved around using the keyboard. Well, as I mentioned I am a web developer and never programmed anything else so I started with the tutorials of jMonkey. But I wasn't able to get them working. I took a look at the wiki but I noticed that the documentation seems to be very poor, at least compared to what I am used to. I then took a look at a few other scene graph's (also for C++) but they also seem to have an outdated, incomplete poor documentation.

Can someone recommend me a scene graph which is well documented with working samples? Or is there something like the "ultimate guide" to get into this topic? Do I first need to know how to develop my own scene graph to get it working or is it possible to just understand the abstract principles and use it from a higher point of view?

Somehow I have the feeling I need to understand the deep insides of a scene graph to use it well (like it's the case for ORM tools in web dev, you can't use them well if you don't understand databases)

I'm sorry if this question is too 'noobish', but I just want to get on my feet and do my first steps.

Answer 1

A scene graph is a tool. It's not really a suitable tool for when you're just starting out in game development.

I think what you are after is not a scene graph but just a framework of some kind.

Normally I'd recommend XNA because it's really good (powerful, modern, well documented, beginner-friendly). But it is C# and I can see you are a Java man. If you'd prefer to stick with Java, perhaps a good place to start would be the Java ports of the old NeHe OpenGL Tutorials (this is not a framework - but it is a set of tutorials for how to do (at a low level) the kind of things a framework does for you - load and render models, load textures, etc).

In the first few lessons you will learn about transformation matrices, which is basically what scene graphs are all about (in the common case).

To describe a scene graph briefly: Say you have a windmill model - it is defined in its own space. You translate it to where you want it to appear in your world space. That windmill would have a child object for its rotating blades - so you you would apply a rotation transformation to the blades, and it would also inherit its parent's translation to place the blades correctly in the world.

When you're starting out, making small games, you don't need to worry so much about having this big complicated data structure. Usually you'll just have a couple of models that you'll apply transformation matrices to directly.

(Scene graphs are also used for performance-related things like sorting by material, culling, etc - all unnecessary for the beginner and for most small games.)

Answer 2

Scene graph have slightly lost their spot as a must-have. Mostly because a scene-graph centric engine is so tied up in the idea of a scenegraph that it confuses itself. Fact is that various parts of an engine need a different view of the world, whereas a scenegraph centric engine tends to want to impose the same view on all parts of the engine.
The scenegraph as it's traditionally viewed, a hierarchy of parent objects and child objects is nice for transforms, but might be totally inappropriate for rendering, where you are more interested in what materials are used (well okay, location counts too, but there are different ways to deal with that and parent-child doesn't guarantee they're close together, we just tend to see it that way).
In many games you'll find that you have a scene-root with a lot of children, but those children rarely have children of their own. The few that have children you might as well update yourself and skip the scenegraph as it adds unnecessary complexity and performance loss (every transform checking if it's parent is dirty whereas only a few actually have a parent that will get dirty ever (the world root rarely moves).

Answer 3

Why not use a game engine like Unity3d? It is very well known for being easy to use and with great documentation. I tried it out briefly myself and was impressed by how well documented everything was the API and a number of good tutorials. I had problems with my arm and some stage and had to get help from my wife. She has no clue about programming but thought Unity3D was really cool. You can accomplish a lot from just drag and drop. You can use several script languages with the engine. It support JavaScript among other things, which I guess given you background should be attractive. You can get a free version with all the features a beginning game developer would need.

If you don't need 3D, then GameMaker is a great alternative. It is really easy to get into and make games. I used it at University and made a couple of games with it. Great fun. It lets you really concentrate on making the game and you don't have to think so much about technology. You can put together a game entirely with just point and click. But as you progress and understand how it all works you start writing your own scripts.

In my opinion it works a lot better than say GameSalad which has no script language. As soon as you start doing more complicated stuff, it gets really annoying with only point and click I think.

Answer 4

I completely agree with Kaj. For more insights on this subject, see gamearchitect (by the way, if you're interested in game developpement, just read the whole site, especially the old one)