Advancing JME

[Jedimace1]

Yes. This has been said hundreds of times. Everybody wants their features implemented.



I'm not suggesting all these features even in JME3, and they could be even longer term then that. There is one thing I'll mention that I would want in JME3. I'm basically going to list some things I think should be in JME in the future, and then I'll probably go ahead and start messing with the JME source to get used to using it. Hopefully after that we can talk about starting to implement these features.



1- Game object classes. A code example would be the simplest to show in this case. It should be this simple.

//Physics game object
PhysicsGameObject crate = new PhysicsGameObject();
crate.AddCubePhysics();
//rendering
root.Attach(crate);

//Player physics
Player mainPlayer = new Player();
root.Attach(Player);

2- Advanced Game. This will make it easier to get a game running quickly. It allows for you to have the features of JME in Advanced Game like shadows, blur, etc. that can be enabled or disabled through some simple functions. It is similar to simple game but is good for commercial projects without having to retype code like the shadow pass and stuff.

These two previously mentioned features can be packed into a JAR file, so if people would rather do this stuff from scratch, they still can, just like before.

3- Deffered Rendering. This allows for much more complex lighting systems with hundreds of lights. It's speedy and definitely is good for post processing effects. It renders lighting as a post processing event.

4- Advanced Rendering- People want their game to run fast. One way or another. Things like VBOs and such should be implemented in rendering much deeper, you shouldn't have to activate it. Dynamic VBOs would be nice if possible, otherwise it can be a setting that can be changed. Most things other than animations are going to need VBOs, so make it the default.

5- Advanced Effects- SSAO, Motion Blur, DOF, Volumetric Lighting, Radiosity, Bloom, an HDR. What more is there to say?

Maybe these last three features can be in an advanced rendering, so, yet again, if someone doesn't need rendering this advanced, they can use the old JME renderer.

All these features are an attempt to do what I talk about in my blog a lot, simplicity.

[Core_Dump]

I guess implementing such advanced features in a generic way, so that every one can just plug it into his game, is very hard.

Behind simplicity is a lot of complexity. 

[Jedimace1]

Yes, definitely very hard to make simplicity. It's surely worth it in the end though. I'd spend 50 hours making something simple, so that I only have to spend 5 hours for every project instead of 50. So, after you make 10 games EDIT: scratch that, 2, you'll have made up all that time you lost. I'm trying to get my blog link to work, I do mention that in some of my posts.

[Starnick]

The idea behind #1,2 is very similar to the idea of game states that are currently in the jme source.



While I like the idea of using updatable/renderable components to separate data out instead of some humongous monolithic class that does everything. I think game states could be improved.



Has anyone used Microsoft's XNA? They have an interesting system called GameComponents and GameServices which resemble GameStates, but not quite. GameComponents essentially are GameStates, and follows the way StandardGame uses them. But GameServices puts an interesting spin on how to handle services in a game and allow for communication. A service is nothing more than a GameComponent that implements some sort of service interface.



E.g. SceneGraphComponent implements SceneGraphService or MyFighterShip implements PlayerService



So lets say I have a class that tracks projectiles, and does intersection checks on the scenegraph and if I get hit, it must tell the player I just died. Normally you'd either use singletons or have to keep the player, and the scene referenced by this tracker. With a game service, it acts like a singleton, but it's not. The tracker would ask for the reference to the player from a static method in your game object or have it as its own singleton manager, and request MyFighterShip based on the PlayerService interface. This reduces the coupling between these classes very nicely.



The beauty of using interfaces is, in a different project, you may use the projectile tracker, but you need to make different implementation of how the player works (movement, what the game should show when you die, etc). But you don't have to touch the tracker, obviously because it takes in a PlayerService interface - doesn't matter what else the player does. Everything is nicely modularized (which helps if you have users exchanging code too). Lots of potential for re-use and good organization. Of course if you don't bother to register services, and try to run the tracker, bad things will happen…but you'd think your game would have a player



In my own stuff, I'm working on such a thing (marriage of XNA GameComponent/Services with GameState), and I gotta say, it's a real nice way to organize a game.

[Momoko_Fan]

I think I'll take this as a wish-list for jME3 since some of these are exactly what it is trying to address. 

Jedimace1 said:

1- Game object classes. A code example would be the simplest to show in this case. It should be this simple.

//Physics game object
PhysicsGameObject crate = new PhysicsGameObject();
crate.AddCubePhysics();
//rendering
root.Attach(crate);

//Player physics
Player mainPlayer = new Player();
root.Attach(Player);

The crate object is okay, but the new Player() part is a bit ambiguous. What is player? The kind of physics used is different if player is a spaceship, car, elephant, or human. This is the kind of abstraction the game itself should provide in its API.
I guess the goal is to get as much simplicity as possible by addressing the most common aspects used in game entities. You want physics, animation etc to be combined in one class so you don't have to use many of the engine's APIs.

Jedimace1 said:

2- Advanced Game. This will make it easier to get a game running quickly. It allows for you to have the features of JME in Advanced Game like shadows, blur, etc. that can be enabled or disabled through some simple functions. It is similar to simple game but is good for commercial projects without having to retype code like the shadow pass and stuff.

The main problem with this in jME2 is that the render passes couldn't be combined effectively, if you wanted to have motion blur + bloom + stencil shadow passes on your entire scene you would have to use PassNodes or combine the shaders in the passes, etc.
In jME3, there would be a post processing system so effects like these would combine seamlessly. Shadows are already integrated in the core of the engine and their rendering handled by an interface and its implementations.

Jedimace1 said:

3- Deffered Rendering. This allows for much more complex lighting systems with hundreds of lights. It's speedy and definitely is good for post processing effects. It renders lighting as a post processing event.

Deferred rendering is only useful in (very) specific situations. You incur a constant performance loss just by using it because several offscreen frame buffers must be written to and processed by each light, plus there are several limitations, like no blending and no FSAA. Only a small amount of games use high number of dynamic lights so implementing deferred rendering is not a priority right now.

Jedimace1 said:

4- Advanced Rendering- People want their game to run fast. One way or another. Things like VBOs and such should be implemented in rendering much deeper, you shouldn't have to activate it. Dynamic VBOs would be nice if possible, otherwise it can be a setting that can be changed. Most things other than animations are going to need VBOs, so make it the default.

This is already default in jME3 and dynamic/animated VBOs are implemented as well. For implementations that do not support VBO, vertex arrays are used instead.

Jedimace1 said:

5- Advanced Effects- SSAO, Motion Blur, DOF, Volumetric Lighting, Radiosity, Bloom, an HDR. What more is there to say?

Almost all of these are post processing effects, so consequently they should be implemented with the post processing framework in jME3.

[IR_Radek]

I think JME2 is good engine with many good thing implemented already. Some things need to be reimplemented and revisioned (jme audio for example) .I have started to implement deferred shading for JME2 I have some results now but it is still unfinished.

[Jedimace1]

"Player" represents a character controller with attached models and animations, and would probably be more accurately referred to as that. Most of the other solutions you mentioned seem to be acceptable. What I'm saying is, you refer to JMonkeyEngine as a game engine, however, it could use some game specific features. What I see now is terrain, rendering, physics, input, and a few other wrappers, however, there are no classes to help you integrate them into a game. That is what I am proposing. To make a character, I first have to create a model with animation, physics, add input to him.

Another thing that would do this engine well is a screen or state machine manager. I've not seen a game engine include something like this yet, and I think that is really helpful. It's also pretty easy to make. However, users shouldn't have to create that themselves. I know it's easy, but a whole bunch of small things like that add up to a huge amount of work.

Also, easier support for 64 bit would be nice(have to go download and compile LWJGL!), as well as an integrated level editor. What I mean by an integrated level editor is that you create the levels in a separate application, and in JME you can load in that level and parse it automatically. Then you should be able to access objects and attach behaviors or something to them. Unity 3D is a good example of that, but imagine the coding being in LWJGL.

We've been examining things to do as a team and I think this would be great if we could work on that. I don't think I'll actually start using this engine yet, but I want to help make it better so that later I can. I need to port some APIs from C++ to Java first, but after that I want to be able to use this engine effectively.

[MrCoder]

Jedimace1: I promised I'd be back, but I just don't want to use JME anymore. I want to move onto bigger things. I have already invested in commercial engines. I said I'd come back, but I don't want to stay. I need to move on with this, and JME just isn't for me anymore. Forgiveness, Vardamir? I hate to leave, but, I don't think I could stay. I really hate to break a promise, but IDK.

didnt work out with the commercial engines? 

[erlend_sh]

First off:

Jedimace1 said:

Yes. This has been said hundreds of times. Everybody wants their features implemented.

Not at all to such a degree that it has become a nuisance. For JME3 we would like nothing more right now than having a bunch of people screaming for their dream features at the top of their throat (not saying that's how i interpreted your approach...). It can be a lot more motivating to work on certain features when you know there's a bunch of people cheering you on for it and are waiting at the finish line for the final praise ;D Really. So big thanks go out to you, Starnick, and everyone else who have requested their share of features, past of future.

@jedimace1: Do you have some hands-on experience with Unity? If so it'd be great if you could share more of your experiences with such a top-notch engine. One thing that is a big priority for me when it comes to JME3 is a drastically improved art pipeline. From what I hear, Unity scores very high in this respect. Any thoughts on that? Do you know how exactly they approach the matter? Torque's art pipeline ain't too bad either, but from what I gather all they've really done is implement excellent support for Collada, and that's it. Unity's different, so I would love to hear about it.

Jedimace1 said:
I'm not suggesting all these features even in JME3, and they could be even longer term then that. There is one thing I'll mention that I would want in JME3. I'm basically going to list some things I think should be in JME in the future, and then I'll probably go ahead and start messing with the JME source to get used to using it. Hopefully after that we can talk about starting to implement these features.

But ultimately you are talking chiefly about JME3 here right? You plan to mess with the source of JME3 and get used to it? You want to start talking about implementing features for JME3, and possibly have a hand in it?

Just keeping it crystal clear :)

Jedimace1 said:

>1- [simple] Game object classes (...)
2- Advanced Game. This will make it easier to get a game running quickly(...)

These two previously mentioned features can be packed into a JAR file, so if people would rather do this stuff from scratch, they still can, just like before.

As an aspiring game designer, I love these features suggestions; that is if I get them right. A game engine needs to become a bigger part of the game process if it wants to be more than just another rendering engine, period. With these type of features in, I can see editors the likes of UnrealEd eventually (like, in years from now) seeing the light of day, and designers like me, of average technical insight, could make a whole new game just with a lot of 'GUI scripting', if you get me.

Is this one of the possible avenues you had in mind for these features?

@Jedimace1 & Starnick: I believe a lot of the features you have talked about here are what was once in-the-making by this guy. Am I on the right path here? I liked where he was going with this and I've also seen from his blogs that he knows a whole lot (lots of hands-on experience included) about game design, not just programming, so I am planning to get in touch with him.

Jedimace1 said:

All these features are an attempt to do what I talk about in my blog a lot, simplicity.
(...)
Yes, definitely very hard to make simplicity. It's surely worth it in the end though. I'd spend 50 hours making something simple, so that I only have to spend 5 hours for every project instead of 50.

With you all the way on simplicity, all challenges and extra development time considered. While we're already relying on LWJGL to make stuff, we might as well take them up on their principles as well.

MrCoder said:
didnt work out with the commercial engines?

Ha ha, love what you're implying!

[erlend_sh]

Jedimace1 said:
[would be nice to have] an integrated level editor. What I mean by an integrated level editor is that you create the levels in a separate application, and in JME you can load in that level and parse it automatically. Then you should be able to access objects and attach behaviors or something to them. Unity 3D is a good example of that, but imagine the coding being in LWJGL.

Level editing, and the art pipeline more generally, is a major subject for JME3. The problem with integrated level editing is that there are so many different approaches to consider. Along with innovative ideas and implementations found in the community, we also have to consider the industry standards of today, as we want this engine to appeal to first-rate game developers, and they will have set expectations for what this level editor should do for them. As independent developers it is almost considered our duty to innovate on and re-define these standards, but we still have to abide to certain boundaries if we want our work to be acknowledged in the first place.

Jedimace1 wrote:

We've been examining things to do as a team and I think this would be great if we could work on that.

For sure. Way I see it, best way to make this happen would be to organize a game project for JME, same way Blender's Yo Frankie! left a plethora of enhancements to Blender's game framework in its path, as was intended. I assume you've had the same idea seeing as you recently showed intent to revive the 'JME Game'. I'm all in for this and would be willing to set time aside to be part of this as a dedicated designer. We might want to just rethink the scope and concept from scratch though. Anyways, that's not for this thread :)

[Starnick]

@erlend_sh



That link you gave is more or less what I'm talking about. In fact the use of XML or some sort of script is something I'm doing in regards to specific entities in my project - e.g. A basic starship entity class and instead of subclasses, having XML files for each of the specific types like fighters, capital ships, corvettes, and so on.



Anyways, I'm not necessarily requesting features here. I'm not sure this should even be in the core of jMonkey but maybe an optional package. Not every project is a game. Although, this level of organization could probably be used in any 3D application anyways. I was just sharing my two cents since I'm doing my own thing in extension to jmonkey

[ncomp]

in my humble opinion what jme 2 is lacking at the moment are the following features;

1. spatial partitioning extension package
   

• covering grids, quad trees, octtrees, bsp, kd trees etc…
  
• seems like everyone ends up having to code their own and as far as i'm concerned this is fundamental game architecture…
  
  
  

2. a java based physics layer
   

• seems we all agree on that
  
  
  

3. a compositing system
   

• jme3 has the right idea in this regards but at the moment texture rendering with passes etc, i don't know if this is the most effecient way of doing things…
  
• i.e. if you want to render the scene in a number of different ways then wouldn't your scene just be a blend of all the texture renderers and not a typical scene graph hierarchy?
  
• we could wait til jme3 is up and running but that could be a while yet.
  
  
  

4. 1 uniform animation system that is robust, up to date and feature complete
   

• how many different attempts have people made at animation in the engine?
  
• if all that work went into improving and extending an existing system then it wouldn't feel like all the animations systems are currently in alpha and dependant on customised exporters…
  
  
  

5. 1 streamed based infinite terrain system that is the only terrain system in the engine
   

• make it customisable so it can be used for either infinite of finite terrains, mapspinner would look like a real candidate here…
  
  
  
  i think most of us have probably had a go at writing one or all these systems at one stage…
  
  would be nice if we didn't always have to 

[clwillingham]

thats interesting, i developed a GameObject class (extending Node) a long time ago. it did not have any physics, and it was only a convenience class, but that class was the bases of most of our program. i defined a GameObject as anything that appeared in the game. all it really did was make it easy to load models and stuff. later on i also added the ActiveObject extending GameObject.



i thaught about implimenting physics into the GameObject by adding two other classes extending it: DynamicObject and StaticObject. unfortunetly when i tried to implement these, i discovered that dynamic and static nodes are abstract. i found myself with about 20 abstract methods and no idea of how to use them.

eventually i found out that what you really need to do is extend the Physic impl  classes. although i haven't had much success with those either.



as for the Player class, i added that to. this however was more specific to the game i am developing with a friend.



i think the advanced game idea is a very good idea. i've been trying to make a render pass gameState, and it works but it always seems a bit slower than when i use simple pass game. it would be nice to have a simple implimentation of these effects. currently i am using no effects in the game i am helping to develop because we decided to add the special effects last.

[blemmeDev0]

I think, if we want such features implemented, we need to split it out of the jME-Core API,

in fact, i got a GameObject class, too



if you want physics, you shouldn't extend a PhysicsNode class, but have a Node containing a PhysicsNode…

[clwillingham]

thanks for the tip on the physics.



i was curious though, how could we contribute code to JME3 if we want to help impliment these features?

i can certanly think of several ways to implement them. but i don't know how to contribute to JME without just writing my own addon. is anyone allowed to contribute to the JME repository? or do you send your code to a specific person?

[Momoko_Fan]

clwillingham said:

i was curious though, how could we contribute code to JME3 if we want to help impliment these features?
i can certanly think of several ways to implement them. but i don't know how to contribute to JME without just writing my own addon. is anyone allowed to contribute to the JME repository? or do you send your code to a specific person?

You can contribute to jME3 in a similar way you contribute to jME2. Post on the jME3 contrib forum a patch. If I and other people don't object, it may undergo some modifications, and then go in.
I also ask that you be familiar with jME3 before you submit anything, jME3 is not like jME1/2 at all. What works for jME1/2 might not work for jME3 in terms of design or purpose.