Jmonkey overhead and missing documentation

General Discussion
1

hey guys,

i recently tried a bit of jmonkey engine.

for now all runs fine, but i noticed the Docs
https://docs.jmonkeyengine.org
seem down. is there any replacement or should it be back up in a few days?

also i all found extending simpleApplication, but this class has some ridiciolus overhead. is there any reason behind it “should” be used just to remove all stuff then?

all in all its pretty interesting to use, but these 2 things make me a bit sad.

2

for documentation look either at

or if you prefer the javadoc
http://javadoc.jmonkeyengine.org/
Both are linked to in the header of the forum

3

Where did you find that link?

4

its a pretty common source if you google for some topics.

well ill prefer the javadoc. this wiki is kinda wierd(more like a half filled tutorial).

part 1 can be seen as solved then.

any oppinions on the simpleApplication extending?

5

What do you mean with overhead ?
You can use it only to bootstrap your app and put all the logic in AppStates (it’s actually the recommended way), but I admit our examples fail to demonstrate that as it’s usually convenient to put all the code in SimpleApplication for a quick test case.

There are plans to change the SimpleApplication in the future.

6

in a quick overview i saw simple application setup following things:
-exit keybinding
-a camera
-a font
-debug text
-root and gui nodes
-a listener

my first though was it is may used as a simple thing for tutoriaals to get news started, but not as a starting point for every project. (this design idea confuses me a bit tbh)

7

I haven’t been able to do much with JME yet as other programming projects are taking up my time so I may be wrong about the following but lets go over the list and see why they are setup.

First the exit key binding-> strictly spoken not needed. Until you run your game in fullscreen and don’t know about alt+f4 or have that disabled, then its nice that the engine already put its own keybinding which you can use to stop the game. Especially as it can be changed later on.

As for the camera, pretty sure that without one you can’t see anything thus you will probably want one anyway.

font → probably needed for the debug text. Not sure…

debug text → you are developing a game.You probably need some debugging to happen and turning it off during initialization probably doesn’t cost that much.

root and gui nodes. Probably as necessary as the cam. Perhaps the gui nodes a bit less, I guess those are made to support the debug text?

the listener. I guess you mean for sound? Which is something pretty much every game needs and disabling probably takes little to no time so why not have it automatically made? (Also, yes you can now clearly see how little time I spend with JME. I am planning to change that, just need more time… )

Remember that you only need to extend this class once and from that point on you can just pass the created objects to the methods that need them saving you the need to create them yourself.

8

Most of those behavior are as you said an easy way to quickly bootstrap a new project, especially when you are not familiar with the engine.
As said before we are envisioning a better design, that is not enforced today, but that is already usable.
If you look at SimpleApplication default constructor you will understand how it works.

Basically the application is injected upon construction with the default AppStates.
If you look at the second constructor

It allows you to specify what AppState you want for your application
So SimpleApplication is handy for test projects (I very often use it as is) but I recommend for a full blown game to use it like this:

public class MyGame extends SimpleApplication {
    
    public MyGame(){
         super(new MyCustomSate(), new AnotherState(), ....);
    }

    public static void main(String[] args) {
        MyGame app = new MyGame();
        app.start();
    }

}

Then have all logic implemented in AppStates and your SimpleApplication will never change much, except when you want to add a bootstrap AppState (or maybe you can have an AppState that manages AppStates…) SimpleApplication is just the list of states you are using.

In future version, all the code in SimpleApplication will be refactored in AppStates (InputHandlingSate, RenderAppState, whatever) and you will decide what you want to use. But for legacy sake we kept the code as is for now.

9

Read the wiki like a book from start to end. Things will become much clearer grasshopper.

2 Likes
10

Ill add this to my add list for the wiki.

1 Like
11

thanks for all your answers,

i dont plan doing a project right now. in office we just take some looks in different engines for evening side projects, and as the fact we do a lot java backend stuff it would be handy to stick with what we are used to.

i will quick and dirty a straped version of timple application monday and see where it leads. (so far i only took some looks into but doesnt seem to complicated.

enjoy aour weekend
bernhard