The headline kind of wraps it up. Starting in the discussion in this thread I was thinking myself about how much game functionality should be built into jme3. EmpirePhoenix made the point that mutiple separate projects that make it a game engine in the end is not really the way to go.
Also, when I look at all the external projects, to me it seems that most users want something more like that. Sceneworker, jmephysics, even MonkeyWorld3D are all attempts in making jme2 something more of a game engine than just a scenegraph.
I have to agree that combining all these efforts would be better for jme3 than hoping that the side projects come together in a way that can replace current jme2 functionality (including externals).
Edit:
Mad idea: combining all that in a customized NetBeans with modules etc. for everything 8)
Well i definitely think that jME 3 should be a tightly integrated game engine.
One of my main problems when I first came to the community was that though their were good implementations they were not a part of the engine source code and since none were really linked to the site i found myself researching and writing code for implementations that were already created. Some such as scene worker or jME Terra which are directly related to the engine are found in separate svns however other solutions such as simple physics or the original bsp tree loader were simply pieces of code found hidden deep within the forums archives.
Though the wiki makes excellent work of listing all of the extra side projects I think it a bit irritating to have the workspace cluttered with several projects and different dependencies some not even linked to the jME2 lib.
If at most jME3 should have different packages within the engine to handle each impl instead of spreading the different parts around the engines packages to help organize imports and allow users to find all of the code in a single package.
Besides this take for future releases I think that the java Monkey Engine 3 is an awesome engine and will be the bases of future projects within the community.
I agree with normen it would be cool to create customized eclipse 
project that users could download and would automatically link and update the code from the SVN.
Bonechilla said:
agree with normen it would be cool to create customized eclipse :P project that users could download and would automatically link and update the code from the SVN.
Whatever platform, I did not mean just a project template, but a complete GDE (game development environment) based on the IDE, with sceneworker built in via the IDE's api, managing of physics properties, game entities etc. via pop-up windows in the IDE.. stuff like that.
normen said:
Whatever platform, I did not mean just a project template, but a complete GDE (game development environment) based on the IDE, with sceneworker built in via the IDE's api, managing of physics properties, game entities etc. via pop-up windows in the IDE.. stuff like that.
If someone is actually willing to do this, it would cool if during compile time for EclipseNetbeans content was automatically converted to binary, into a J3P file or what have you.
SomethingNew said:
If someone is actually willing to do this, it would cool if during compile time for EclipseNetbeans content was automatically converted to binary, into a J3P file or what have you.
The way I imagine it the IDE/system would directly implement the model importers, the contents of the game (in the form of jme binaries) would be managed by the system.
maybe we could also slightly modify and optimize blender to create and deploy models making it obj exporting it as obj if static or ogre.xml if animated automatically
Bonechilla said:
maybe we could also slightly modify and optimize blender to create and deploy models making it obj exporting it as obj if static or ogre.xml if animated automatically
I think specialized importers for the results of the current ogreXML->Blender exporter are the better solution. Something like this. You can add properties in blender and then further modify it in the sceneworker..
normen said:
I think specialized importers for the results of the current ogreXML->Blender exporter are the better solution. Something like this. You can add properties in blender and then further modify it in the sceneworker..
lol you see I knew nothing about that lol
Well since I already kind of started this discussion, what about a Networkcode?
I think one of the important point for a engie would be to have a reliable networksupport as that really lowers the initial problems with creating multiplayer games.
If you all agree I would really like to build a low level network system for JME3
I alredy have a half finished for JME2, working on a low binary level. Like a message containg one float is 2bytes classid + 4 bytes the float. Currently it is based on UDP, and also supports Reliable transfer, the only larger thing issing is to add is a interface for the Messages that allows in order transmission.
I think its no use talking about the single features when there is no roadmap on how to put it together, just to get the topic back on track 
But as it seems, for most people its no question it should be done somehow like this 
Edit:
sorry, I did not want to play down what you said, a dedicated developer for a network part in jme3 would surely be great
Empire Phoenix said:
Well since I already kind of started this discussion, what about a Networkcode?
I think one of the important point for a engie would be to have a reliable networksupport as that really lowers the initial problems with creating multiplayer games.
If you all agree I would really like to build a low level network system for JME3
I alredy have a half finished for JME2, working on a low binary level. Like a message containg one float is 2bytes classid + 4 bytes the float. Currently it is based on UDP, and also supports Reliable transfer, the only larger thing issing is to add is a interface for the Messages that allows in order transmission.
I actually am interested in momoko's take on this because it seems as though any time I run to begin to write a feature momoko already has it begun in some way shape or form just not updated to the SVN yet :wink:
but back on track if a IDE specifically for jME3 is created it would probably have to be made in the distant future or a separate team would have to begin it as to not stagger the production of the source code lol though it seems very comparable to jME2 already =p
I would take the time in starting a set of Netbeans plugins for jme3…
It sounds like a massive effort. Even the Unreal SDK is far from being everything you need to create a game from scratch.
It would be unbelievably cool to develop but you'll need at least a couple of managers and a team of designers (and programmers, testers, artists… all volunteers).
well thats what the forums are for besides asking why doesn't my model show (updateRenderstate() epidemic of 2008-??)
some kind of plugin system would be nice think, but i don't know if its reasonable,just a thought.
the problem with different project is, that api changes break those other projects.
If all the functionality is in the same project/source tree, its easier to manage i think.
Core-Dump said:
some kind of plugin system would be nice think, but i don't know if its reasonable,just a thought.
the problem with different project is, that api changes break those other projects.
If all the functionality is in the same project/source tree, its easier to manage i think.
it would probably be more unethical to create an actual IDE from scratch but it would probably work better than using plugins IMHO (lol or create an IDE for plugins =p)
it should be that way it would be easier to see what breaks and prevent code previous code from not working
NetBeans has a plugin system and it is a plugin development environment… That is why I suggested using that framework, you have all the features of a compiler/ide and you have a plugin/windowing system. So it would not be needed to implement that from scratch.
And about the "overhead" in development resources… Its not more complicated to develop a scenemonitor as a netbeans plugin than making an application, actually its less because the core IDE plugins allow reusing of functions…
When I first joined in to help with management of jMonkey Engine as momoko introduced the jME3 engine (an obvious side-goal of that being to 'lift' the community), one of the first things we made a serious attempt at was rounding up a small, compact team of programmers for dedicated jME3 development. Back then there wasn't enough interest for it, but I am very happy to see that now might be the time to try another push for it.
Normen, we should talk Unfortunately I'm without an internet connection these days so we'll have to set a later date if you're interested in meeting up. Meanwhile I'll keep checking up on the forum and this thread whenever I have the chance. Both in software and project architecture, I find content management systems (Wordpress, Drupal, Joomla!) to be a major inspiration. I will elaborate on that in public after some more internal talks.
To answer the question raised in the topic title: JME3 is definitely intended to be more than just a scenegraph engine; in fact, being a complete game engine is meant to be one of its main selling points when compared to JME2 and Ardor3D. Being a low-tech game designer (in education) I aspire towards a JME with user friendlyness on par with Unity3D, but there is no way that can be made a priority just yet.
To answer the main question, jME3 is intended to be a game engine. In other words, it provides all the things necessary to construct a game.
So far what I've been doing is trying to add a tool-suite. Right now there's a model viewer (PreviewTool) and a deployment utility (DeployTool). Perhaps when the engine is finished there will be many tools that you could use to create your game. I am not sure, but perhaps combining these tools to create a sort of a development-environment might be better? It certainly would require a lot more work though, I think.
I definitely think that an integrated solution would be the best solution for jme3 as an open source game engine. Also, as said I think lots of the burdens of such a system can be taken off by using an existing framework. I am very willing to invest time into jme3 but we surely have to talk a bit more direct before, seems like I only catch some of you because I like to code in the night