jMonkeyEngine PROS and CONS survey

The 2.0 stable will be upon us this Sunday, marking the beginning of the road ahead to v2.1. In relation with this progress I would like to ask the community to partake in a 3-part survey, that aims to benefit both JME 2&3 (2nd part will only reflect on 2.0 and 3rd part will largely be 3.0 only).



The Three Parts


  1. Pros and cons of JME 2.0
  2. Feature requests for 3.0
  3. Feature rankings



    I sincerely hope we will get to see a large portion of the community partake in this three-part survey. This is a unique opportunity to be a part of the few focus points that can be afforded for 2.x development. For 3.0 you get to directly influence the priorities of the core developers, and maybe even open their eyes to a neglected golden feature.



    See the thread below for the first part in this survey.

Make a simple list of pros and cons for JME. It can be a specific aspect or a memorable experience. It's up to you whether you want to get into the technicalities, the practicalities or both.


  • Write down 2-5 one-liners detailing your favorite features or memorable positive experiences with the Java Monkey Engine.
  • Write down 2-5 one-liners detailing the exact opposite of the above.
  • Post it here!



    Technical examples:



    Pro

    "The greatest was when I implemented JOPS rendering in jME. I just did it, and it was fast as a motherf****r. Great, cause I had learned jME enough to actually make something usable and reusable for it, with great performance."



    Con

    "Every time I find myself searching for that bloody object I just put in the game and it just won’t show up. Usually I just forgot to call updateRenderStates() , we’ve all been there. Don’t deny it."



    Practical examples:



    Pro

    "It's free!"



    Con

    "Project lacks strong direction"

Hmmm, I cannot believe I am the first to reply here… Oh well, I hope I don't stand out for my ignorance  :wink:



Pros



  • Clear unified base-code (featuring Java 5 style consistently)

  • JOGL/LWJGL option for rendering and render-independent JME file formats

  • Support for Ogre3D format

  • Nice and shinny new stats display



Cons


  • Still lacking documentation and wiki pages specific to 2.0

  • Too directly based on jME 1.0 (needs new direction? 3.0?)

  • The always pervasive artwork pipeline problem. No easy way to import arbitrary models with animations

  • More features would be nice... like better shadows, or more post-processing shaders and the like



Hope this helps!  :roll:

duenez said:

Hmmm, I cannot believe I am the first to reply here...
I must admit I was surprised myself... I imagined this a welcomed opportunity for some inspired ranting in between JME waltz & wrestling sessions ;D

This sure helps duenez! I see your comments are a mix of technical and practical (i.e. administrative) which I forgot to mention is absolutely welcome.

By "Too directly based on jME 1.0" I suppose you're referring to the documentation. Anything else that still points in that old worn out direction though?

Pros:

  • its free
  • its Java
  • it works



    Cons:
  • artwork pipeline is a pain in the backside

Pros:

(I agree with dhdd)

  • free
  • open source
  • written in Java
  • quite reliable (but it could be better)
  • lots of interesting features
  • faster than the other 3D engines
  • hardware acceleration



    Cons:
  • there is a real lack of optimisation for GPU-limited computers
  • the JOGL renderer (:() is not as reliable as it should
  • it is still not possible to use it with Android (if I take only the standard stable version)
  • there is not yet any fallback on JavaSound whereas unfortunately OpenAL works badly on a few machines (but 3D sound system should solve this problem)
  • no commercial support
  • not enough documentation
  • the wiki is not up-to-date
  • no official example using JOGL
  • it uses JOGL 1.1.1 whereas JOGL 2.0 is available
  • it would be fine to have a RAD tool, something like Shiva
  • there is no way of converting the source code of a game using JME into C#/XNA source code (to target XBox 360)
  • it is very difficult (but not impossible) to buid a collision system without JME Physics whereas some games do not need a so complicated physic engine

I suspect the thread title might be causing some confusion, at a glance on the front page I assumed it was a thread about monochrome rendering  :expressionless:



Disclaimer: Hopefully this is a constructive list for the betterment of JME. I base it on my experience working with jME and what I think would be ideal or some app that does something well. Not necessarily Java or even a game engine (examples Unity, GROME, DAZ). ie the criticism isn't relative to something else - obviously, jME is good :slight_smile:



Pros


  • For a Java coder, JME makes it quick to start working with 3D and using many advanced features. Saves a huge amount of time compared to using lower level libraries directly.

  • Able to produce very nice games, demos and apps with good graphics and performance. No showstoppers.

  • Fairly straightforward to add features. Few limits to what you can do if you are prepared to implement some algorithms yourself.

  • Doesn't dictate how you code. Design, structure and code your app in your preferred way using any Java methods and API's.

  • The API is generally easy to work with.

  • The community is generally friendly and helpful for the competent beginner to intermedate developer. The forum history forms a pretty good set of documentation for many common problems.

  • Source code is generally easy to understand and modify.

  • Decent performance, ability to implement your own case-specific optimisations (albeit because JME doesn't



Cons

  • Lack of emphasis on the engine's ability to help you produce finished, polished games or apps.

  • Resource management is very poor.

  • Critical features left below par and/or out of date and/or outside the core (sound, gui, physics, animation, splatting etc etc.)

  • Lacks game engine features, such as spatial partitioning, scripting, terrain handling, foliage.

  • Lacks tools support.

  • Lacks advanced graphical effects, poor shader support (presume JME 3 to remedy this).

  • Things (features, tools) too often don't get into the core project, and miss the benefits of open source software as a consequence.

  • Lack if stuff to show off the engine that will really impress. Most of what there is developed in isolation and often screenshots or video only. Reflects the engine itself as per the above.



Feature requests

  • Much improved resource and memory management (textures, sounds in particular). Threaded loading.

  • Redo the soud system or integrate another one.

  • Integrate key tools into the core like the particle editor is. Examples, a scene editor, model/entity/character importer/editor.

  • Make very common effects such as texture splatting and bump mapping, very easy to add with only core code.

  • Won't just rewrite my cons list!

Pros:

  • its free/opensource/Java
  • it is supported by a great community
  • the questions in the forums often receive interesting/helpful answers from both jme developers and users
  • has good support for model loading
  • delivers very good performance
  • meets common 3D gaming needs



    Cons:
  • no context sharing support (i.e. initializing JME from an existing GL context)
  • too much static references around (Display,DisplaySystem)
  • has JOGL support, but who really needs it ? LWJGL is exactly what we need for JME, so let's save time…
  • there's always the need to update() the scenegraph/states in order to apply changes.
  • render to texture api could be better (i.e. tr = new TextureRenderer(node) , tr.asTexture(), tr. update())



    Cheers,



    Mik
MikOfClassX said:

Pros:
- its free/opensource/Java
- it is supported by a great community
- the questions in the forums often receive interesting/helpful answers from both jme developers and users
- has good support for model loading
- delivers very good performance
- meets common 3D gaming needs

Cons:
- no context sharing support (i.e. initializing JME from an existing GL context)
- too much static references around (Display,DisplaySystem)
- has JOGL support, but who really needs it ? LWJGL is exactly what we need for JME, so let's save time..
- there's always the need to update() the scenegraph/states in order to apply changes.
- render to texture api could be better (i.e. tr = new TextureRenderer(node) , tr.asTexture(), tr. update())

Cheers,

Mik


now why did u have to go and that...................no really................hopefully he'll just ignore it
mcbeth said:

now why did u have to go and that
He is entitled to his own opinion. Seeing as that is what this thread is all about, and not actually argument for or against any bullet points mentioned at this time, I hope everyone will respect this and merely use others' comments as reference and comparison; not to start any arguments.

I'm not going to flame about JOGL support (and by NO means I want to insult someone, it's just my opinion, ok ?).



My opinion about JOGL is far from being bad. The existence of JOGL itself is really important for the java community.



Coming back to JME, yes, we have a choice, but which is the GL backend developers are using now if they want to ship a reliable application ? LWJGL.



I think that maintaining (developing/testing/supporting) 2 different backends is not a joke, that's why I would first concentrate the development resources to other important things: features, stabilty, documentation.

MikOfClassX said:

- has JOGL support, but who really needs it ? LWJGL is exactly what we need for JME, so let's save time..

It is really an insult, I'm fed up! It is too late! JOGL is inside JMonkeyEngine, it cannot be abandoned. If nobody needed it, it would not be supported by JME 2. I'm really angry, I've spent a lot of time (and money) in trying to drive the JOGL renderer more reliable. You're happy with LWJGL like lots of JME 2 users, that is fine, but some people including me need JOGL. I won't turn this thread into JOGL versus LWJGL debate.

PRO's

  • Open Source & Java
  • The Wiki + Forum serve as a kind of master handbook.  A ton of questions have been asked, a ton have been answered.
  • Very helpful community for beginners and veterans alike.
  • Active development is back in swing.



    CON's
  • A lot of these side projects for terrain, morphing, animation support, etc are close to prime time for putting into the engine.  We need to make sure that they find their way into the dev branch if the authors are open to it.
  • For all that the forums and wiki have, documentation is still lackluster for some parts.  This is usually as it pertains to integrating third party code extensions.  Having them integrated as I mentioned would certainly help this point.
  • As lawnmower mentioned, needs artists to produce sharp looking 'marketing' materials.
  • Simplified art pipeline so more time is spent on making well-built games.  Good looking should be left to the artists :wink:
erlend_sh said:

mcbeth said:

now why did u have to go and that
He is entitled to his own opinion. Seeing as that is what this thread is all about, and not actually argument for or against any bullet points mentioned at this time, I hope everyone will respect this and merely use others' comments as reference and comparison; not to start any arguments.


yes but in the context of thread it seemed an unneccessary nitpickthan an actual con............ the right to ones opinion not withstanding, especially given the angered nature of one of the posts that came after

People, please… let's keep it civilized. I am willing to give MikOfClassX the benefit of the doubt that he was really trying to be playful by saying that nobody needs JOGL because he doesn't use it, and knows of nobody who does. I think that is why I would take macbeth's reply as a simple continuation on the playfulness.



@gouessej I remember back a while ago I went on vacation for a summer, and stayed out of touch with jME for a while, and then I returned to see there was JOGL support. I think even if people don't activley use JOGL, it helps developers think of how to abstract and decouple better the rendering engine, which is always good to do IMHO.



edit: fixed typo

So beside your "discussion" I will simply answer to the first post of this thread.

I'll start with the



negatives:

-there are many game-engine related features not in the core, like scripting, or basic physics.

-and there is no spatial sorting system implemented (we, goussej and me are working on one though)

-many projects (wich often looks nice) are too often not put into the core or even near to it. they are somewhere in the depth of this forum. ( I think there should be something like a plug-in portal or so integrated to googlecode, so everyone could commit it into a SVN and work on it. Don't know if there's somthing similiar now.)



positives:

-BEST community ever seen

-several good ways to start

-threading is very easy with standardGame and Gamestates

-several ways to make a GUI. (though it's not always easy to integrate)

… It's just easier to nail down a lot of cons if you put your mind to finding deficits…



Pros


  • I've been moderate to very actively involved in close to a hundred online communities. JME is no doubt the most self-sufficient community I have ever dealt with.
  • The degree of support at hand, both in availability and expertise, is close up to professional standards.
  • JMonkeyEngine is one of those open source projects that actually do work as OSS both in theory and practicality. So long as Java continues to be a bigger part of game development, JME will follow suit as will serious developers.
  • Being written in Java, JME serves as a viable alternative with significant differences to other competing engines, as opposed to merely saturating the 'market'.
  • Albeit slowly becoming outdated, there are some truly excellent tutorials and docs around that seem to have helped a lot of users immensely.





    Cons


  • Missing a well integrated website; we need more consistency in our web structure, both in regards to general organization of data and design, as well as a singular user database.
  • We need more commercial projects to get JME into the spotlight as a fully viable high-end game engine.
  • IMHO quite a few entities are not giving back as much as they easily could. We keep seeing students showing off their student projects done with JME, but we never heard a word from the educators themselves.
  • Widely spread assets; there are sooo many different projects closely related to JME, most of them open source. These could be made a whole lot more accessible by establishing a dedicated "project forge" to keep all project listings in one place.
  • Lack of professional documentation; although we have a lot of promising material, it is not structured nor maintained properly, nor are there any guidelines or standards to support such.
  • Lacking establishment in the OSS sector; we need to spread our wings more and once again be part of events such as JavaOne and go even further with new goals such as GSoC participation.


  • Although the art pipeline is going through a lot of exciting improvements, it is all over the place and supported features varies widely from one solution to another. Any where I turn for input from industry professionals and otherwise, Unity seems to be the greatest example of 'art pipeline done right' these days.
  • Without integrated physics JME is still far away from being a full featured game engine.
  • Personally I’m missing more designer-friendly tools that do not require in-depth technical insight. A basic game framework with a scripting (eventually GUI) interface would be a great place to begin.







    Next survey up: Feature Requests for 3.0



    Before that though, I got a couple of important tasks to carry out. First of all, I am going to make up a list of proposed milestones for JME 2.1. They will be based off of this list as well as concurrent promising projects, such as JBullet integration, Scene Managers and Cells & Portals. I will keep it very realistic though, and there might not be any feature in there at all that is currently not being worked on already.



    I believe that is the way we have to do things with 2.x, considering new features appear on a per-need basis of the individual user, not as a result of great demand. It seems however that a lot of what is being worked on fills in a lot of the holes pointed out in this survey.



    Seconly, it’s time to introduce the team as a whole, and give a brief idea of what is currently being worked on for JME3.



    Big thanks go out to all who participated! I believe this sort of active participation in development is something that needs to be leveraged a whole lot more in OSS dev, and I can assure you I will do my best to make that happen in this particular project. As far as I’m concerned, the first part of this survey was a success. I hope we do as well with the next one.



    It’s not too late to drop your pros and cons in here though. Even if it comes in too late to be used for milestone reference, this type of feedback is still very valuable .

Pro

Easy to get into (Java + tutorials). The tutorial classes (with source) are great, and the wiki tutes are quire accessable

Fast (but what isn't when compared to java3D)… but Fast & Java. Java is no longer slow, but its great to see java doing real graphics.

Good basic physics support. Slots right in. But there is no point keeping it seperate any more. Keep up with the times… no inbuilt physics, no go.

Bundled natives. w00t!!!

Helpful people. That is the community. At least you tend to get answers.

ACTIVE PROJECT… how many projects are there that look like the next thing… and then die of a lack of interest.



Note that all the 'pros' are at a simple level only. Once customisation continues past a certain point, it is no longer generic. I don't want to make another FPS. Go figure. I guess this is 'easy to customise', and still does enough. It can't do everything people.



Con

multithreading isn't brilliant. Its easy to write a 'mostly good' wrapper, but the support just isn't there deep down. And I don't just mean 1 thread each for GL, physics, updates, sound, etc, but even towards multi GL threads (and multi cpu threads)

Too static. OK, a lot is thread based, but ALOT ISN'T!!! Why all this annoying static latching? Display System's create should ALWAYS return a new one… And GameTaskQueue… whats wrong with game.getTaskQueue? Just keep a reference. It looks like the static/GL-thread model has ballooned out to where it shouldn't have. This isn't a design pattern/OOP complaint… I keep on having to remove static methods so that I can add my functionality the way that I use it.

too many game types, but no actual game interface… would be nice, I've gone and done it, it makes it nice and easy to switch threading strategies into an existing game. That is, a GAME interface - start(), stop(), getLock(), getGameTaskQueueManager(), getDisplaySystem(), etc. don't need an initGame(), its not part of the interface… though it fits with the standard jme way or initialisation, and should stay abstract (or stubbed). And it would let me use my classes, and swap in a basic game class without having to to a cut & paste job to get the same code.



Feature Requests

Fix the cons. ESPECIALLY the one about having too many static methods. That one bugs me. Lots. No, really, LOTS.

Libraries & class loading. OK, this isn't really jme's fault, but having to set up so many library dependencies is kind of annoying, especially when I develop under XP & OSX… to say nothing of (hopefully) releasing a simple multi platform demo. For the most part, even the natvies are there. I do have a classloader & framework that auto fills dependencies (in a workspace… would need to package natives or write out temp files for jar deployments, as loadLibrary requires a FILE name). I know some people might consider it too much 'automagic'… having had to set up the same classpaths, code the same glue and parse mountains of the same xml static config files, auto is… NICE. Except that now JOGL is a jsr release, its in a protected namespace. damn.





There we go, a short reply of pros and cons, from a technical standpoint. I have yet to play with sound, and my art isn't even grade 3 fridgeworthy. But I stand by what I said (typed?), and if I can help, I will. Even though I'm a little sporadic when it comes to jme.





And jme NEEDS LWJGL and JOGL, if only to keep the display system isolated from the rest of the system… same as multiple physics implementations.

I am not a professional by any means, but from my experience as a total beginner to programming, to where I am not, I will list some pro's and con's of things I have experienced along the way.



pros:

once understood, the engine is very easy to work with.



cons:

a revamp of the wiki/tutorials is something I feel really needs to be done. In some cases I have to look through various tutorials, and then even search the forum to understand some things, also, there are alot of empty spots of "To Do" that dont even seem to get done. (i understand its open source and there is alot of work already going into it, i dont see this as people being lazy, just something i think should be worked on)



while alot of the outside projects which work with JME (like GBUI, JGN, JME Physics) are really really awesome, I wish that they had their code integrated into the JME 2.0 download itself. For me, setting up all of those projects, building them, and getting them all to work properly took me so much time, and was the longest set of problems I faced with JME. For myself and my friends, getting JME 2.0 to work in eclipse was confusing enough, and every week or 2 as I got another side project like GBUI or JGN under my belt, I had to go through the whole process to help my friends get it installed and working as well.



Well, those are just some of my thoughts off the top of my head. JME is really awesome and I am excited to see it progress into the future.  :smiley:

A valid point, I say we make a thread on possible ways to make jme more idiot friendly