This is what a game engine SDK should be! Netbeans REALLY doesn’t cut it, at all. Not going to start a flamewar over what IDE is best.
I’d be interested in helping too. Could you migrate this project to github so people can contribute?
@fabsterpal said: This is what a game engine SDK should be! Netbeans REALLY doesn't cut it, at all. Not going to start a flamewar over what IDE is best.Really? how can I edit java code in this editor? can I refactor classes? can I manage to what platforms I'm gonna deploy my game to? Does it have a gradle support? Maven? ant? Android? Can I have a C++ support if I want to make a JNI bridge? Can I profile my code? does it have a shader editor? Can I connect to an SCM? ......
Are you guys gonna implement all this features? Do you guys really believe you can do something as complete as Netbean in your spare time? At least use another platform like eclipse or intelliJ but from scratch??
I mean the features for this editor look great, but when I read this it just feel like wasted effort to me. Probably not for the OP as he’s gonna use what he did of course, but I really doubt this could end in something as advanced as the SDK.
I know netbean’s API can be daunting, but in the end you always manage to get things done. Those features would have been very welcome in the SDK…too bad.
@nehon said: Really? how can I edit java code in this editor? can I refactor classes? can I manage to what platforms I'm gonna deploy my game to? Does it have a gradle support? Maven? ant? Android? Can I have a C++ support if I want to make a JNI bridge? Can I profile my code? does it have a shader editor? Can I connect to an SCM? ......Are you guys gonna implement all this features? Do you guys really believe you can do something as complete as Netbean in your spare time? At least use another platform like eclipse or intelliJ but from scratch??
I mean the features for this editor look great, but when I read this it just feel like wasted effort to me. Probably not for the OP as he’s gonna use what he did of course, but I really doubt this could end in something as advanced as the SDK.
I know netbean’s API can be daunting, but in the end you always manage to get things done. Those features would have been very welcome in the SDK…too bad.
I think these features should be separeted.
WorldEditor - create world, place models, add scripts to NPC, etc.
SDK - all you mentioned in the quote.
WorldEditor certainly should be separeted from SDK.
@mifth said: I think these features should be separeted. WorldEditor - create world, place models, add scripts to NPC, etc. SDK - all you mentioned in the quote.WorldEditor certainly should be separeted from SDK.
But the post Remy quoted clearly hinted at replacing the SDK. Or rather at replacing NetBeans, which is the base for the SDK. This would mean replacing all functionality we get through the SDK such as deployment, build handling and code handling. That is remys point afaics.
It happens often that people misunderstand the current SDK as a “world editor” but a world editor like this one here would be an additional plugin for the SDK. When we add game type templates for example, we will have to add logic elements to describe things like “levels”, “players”, “spawn points” and things like this. We’ll make a plugin and it will probably do similar things as this framework does. Right now the SDK just has editors to edit features that actually exist in the engine as none of the mentioned things conceptually exist in the engine. So as remy said, this could be considered a failed chance to implement this. But still, OP has done what he wanted so gg 
@normen said: But the post Remy quoted clearly hinted at replacing the SDK. Or rather at replacing NetBeans, which is the base for the SDK. This would mean replacing all functionality we get through the SDK such as deployment, build handling and code handling. That is remys point afaics.It happens often that people misunderstand the current SDK as a “world editor” but a world editor like this one here would be an additional plugin for the SDK. When we add game type templates for example, we will have to add logic elements to describe things like “levels”, “players”, “spawn points” and things like this. We’ll make a plugin and it will probably do similar things as this framework does. Right now the SDK just has editors to edit features that actually exist in the engine as none of the mentioned things conceptually exist in the engine. So as remy said, this could be considered a failed chance to implement this. But still, OP has done what he wanted so gg
well yeah…
But i dunno think he wants to replace the whole SDK. His main idea is the editor i guess.
So that people can choose their own IDE… Netbeans, Eclipse, Idea etc for other features.
EDIT: Posted below.
@fabsterpal asked me by skype to post this because he is locked to post on this thread somehow.
@normen said: But the post Remy quoted clearly hinted at replacing the SDK. Or rather at replacing NetBeans, which is the base for the SDK. This would mean replacing all functionality we get through the SDK such as deployment, build handling and code handling. That is remys point afaics.It happens often that people misunderstand the current SDK as a “world editor” but a world editor like this one here would be an additional plugin for the SDK. When we add game type templates for example, we will have to add logic elements to describe things like “levels”, “players”, “spawn points” and things like this. We’ll make a plugin and it will probably do similar things as this framework does. Right now the SDK just has editors to edit features that actually exist in the engine as none of the mentioned things conceptually exist in the engine. So as remy said, this could be considered a failed chance to implement this. But still, OP has done what he wanted so gg
I’ve tried submitting this message 4 times now, hopefully fourth times the charm…
What I was saying is that the SDK is 99% netbeans, 1% jmonkeyengine. The features included to edit JMonkeyEngine itself are so thin spread that it’s underwhelming. They’re pretty much tools or utilities.
As much as you guys hate being compared, let’s look at Unreal and Unity (industry standard engines):
Both of them focus on editing your project and distribution of the project. The SDK’s are concentrated on editing the engines features, and so it has the complete feel about it. When you go to open a C++ / C# / JS file on these, they open the file up in (Visual Studio / XCode / MonoDevelop) - actively developed IDEs, with all the features Nehon mentioned.
There’s +/- to this:
Plus:
People can choose their own IDE just by adding the libraries, and still use the tools dedicated to the editor easily.
You don’t have to waste time working around the restrictions of the IDE, e.g. netbeans API.
You can create a more interactive experience than using an IDE.
Minus:
It’s separated over 2 tools.
It’s all about structure. The JMonkeyEngine SDK in my opinion is extremely underwhelming for what is actually an extremely capable engine. When I saw the SDK at first, I walked away, because I personally hate netbeans and felt it was being forced on me. It was only when somebody pointed out that you can get the libraries separately (NBM also isn’t the funnest format to extract, it’s a pack200 inside a pack200) that I decided to use it.
I can appreciate that all of you core developers have put endless hours into the SDK, and understand why you’re getting defensive over it, but I think something which provides the tools to edit the engine AND allows the users to easily use their own IDE is far more preferable than one which forces usage of one which is probably the 3rd or 4th most popular IDE for thin-spread tools.
Really? how can I edit java code in this editor? can I refactor classes? can I manage to what platforms I'm gonna deploy my game to? Does it have a gradle support? Maven? ant? Android? Can I have a C++ support if I want to make a JNI bridge? Can I profile my code? does it have a shader editor? Can I connect to an SCM? .....
No. Neither it should have. The editor is meant for content creation - a tool for designers, not for coders.
I know netbean's API can be daunting, but in the end you always manage to get things done.
Yeah, eventually you can get things done by using any tool, but that is not the point, is it? Having the editor part of the SDK is what I wanted to do initially. However after some atempts it became clear that NetBeans is good IDE but a bad content creation environment. The NetBeans platform being constantly broken doesn’t help either.
On one hand I understand why the SDK is built the way it is. On the other hand I don’t believe this creates the most efficient workflow.
@yezu said: No. Neither it should have. The editor is meant for content creation - a tool for designers, not for coders.My point exactly, it will never replace the SDK, and that's what I was answering to.
So we have people who don’t like the NetBeans platform and we have people who want an extended framework on top of the engine, specialized for the “typical” game editors, which is fine. All other reasons mentioned aren’t really valid. The NB platform is neither broken nor does having the ability to edit code directly in the SDK/Editor take away anything from what you could do in a SDK plugin or keep you from using your favorite IDE for coding (see for example the codeless project feature).
Kudos @OP for doing an editor the way you imagine it, lol @all who just whine about the existing tools. The SDK has almost as many lines of code as the whole engine, idk if you can say thats just 1% of what the SDK is, maybe you didn’t find or use all features, maybe you just expected different ones. But at any instance, using this thread as a platform to bash what we put out for free when you didn’t even write an editor yourself and this editor is in no way comparable to the SDK (as I explained) is pretty silly. So lets just leave out that part from the discussion, shall we?
Obviously you can trigger responses from the core developers with such mindless statements, obviously we use an open platform for the SDK in the hope for synergy effects. There were more editors of this type for jME2 than there are for jME3, all of them were created by and died with the interest of one person and never experienced any serious synergy effects. At least theres one thing we learned about this fact by trying to make a global platform for that, it has to do with programming styles and the learning curve of the global editor APIs 
As I know many people interpret my words in the most negative way possible I’ll add that theres no hard feelings here, especially @OP, the comments of the core developers weren’t really triggered by any of your actions or words and my posting here is just to explain my viewpoint on various raised issues 
@normen said: So we have people who don't like the NetBeans platform and we have people who want an extended framework on top of the engine, specialized for the "typical" game editors, which is fine. All other reasons mentioned aren't really valid. The NB platform is neither broken nor does having the ability to edit code directly in the SDK/Editor take away anything from what you could do in a SDK plugin or about using your favorite IDE for coding (see for example the codeless project feature).Kudos @OP for doing an editor the way you imagine it, lol @all who just whine about the existing tools. The SDK has almost as many lines of code as the whole engine, idk if you can say thats just 1% of what the SDK is, maybe you didn’t find or use all features, maybe you just expected different ones. But at any instance, using this thread as a platform to bash what we put out for free when you didn’t even write an editor yourself and this editor is in no way comparable to the SDK (as I explained) is pretty silly. So lets just leave out that part from the discussion, shall we?
Obviously you can trigger responses from the core developers with such mindless statements, obviously we use an open platform for the SDK in the hope for synergy effects. There were more editors of this type for jME2 than there are for jME3, all of them were created by and died with the interest of one person and never experienced any serious synergy effects. At least theres one thing we learned about this fact by trying to make a global platform for that, it has to do with programming styles and the learning curve of the global editor APIs
As I know many people interpret my words in the most negative way possible I’ll add that theres no hard feelings here, especially @OP, the comments of the core developers weren’t really triggered by any of your actions or words and my posting here is just to explain my viewpoint on various raised issues
You’re missing my point entirely, but I’m not going to bother wasting more time trying to explain it.
@fabsterpal said: You're missing my point entirely, but I'm not going to bother wasting more time trying to explain it.
This is what I mean, your posting here has no real point, as you say yourself, you don’t even bother to explain it. The only real point you made that was no rant against the NB platform is that you want an editor like this. I elaborated on that point by saying that an editor like this is an intended future feature of the SDK for us as well.
@normen said: This is what I mean, your posting here has no real point, as you say yourself, you don't even bother to explain it. The only real point you made that was no rant against the NB platform is that you want an editor like this. I elaborated on that point by saying that an editor like this is an intended *future* feature of the SDK for us as well.
Actually, I was meaning to put the word “again” at the end. I dislike NB, I know. That wasn’t what I was saying however.
Another point is that everybody has their preference. A SDK shouldn’t force one IDE on a user, infact the IDE should be totally unrelated (something such as generating a gradle or ant buildfile to import the code into other IDE’s would be a good idea also).
@fabsterpal said: You're missing my point entirely, but I'm not going to bother wasting more time trying to explain it.
And additionally, if you really want to make your dislike of the NB API a point… I don’t see how a windowing API that we or somebody else creates would get around the fact that there will always be people who don’t like it / want to learn it and rather do their own thing? I mean effectively you are putting an API you don’t even know yet against a Oracle/Sun supported windowing API as the base of your argument. I bet the API of the OP is very elegant and I bet your hate for the NB platform is deep enough to prefer anything above it but isn’t that a bit of a shot in the dark in terms of an argument really? 
@normen said: And additionally, if you really want to make your dislike of the NB API a point.. I don't see how a windowing API that we or somebody else creates would get around the fact that there will always be people who don't like it / want to learn it and rather do their own thing? I mean effectively you are putting an API you don't even know yet against a Oracle/Sun supported windowing API as the base of your argument. I bet the API of the OP is very elegant and I bet your hate for the NB platform is deep enough to prefer anything above it but isn't that a bit of a shot in the dark in terms of an argument really? :)
The base of my argument isn’t even with the API. It’s with the concept of standardizing the use of one specific platform / IDE when there’s no special coding requirements (e.g. a custom language) that need to be catered for. I’m not attacking netbeans at all. In fact, whilst most of the time I use eclipse, for projects which require a chain of projects depending on other projects, I use IDEA.
You’re getting it confused with when I said about how the time between features is being increased because of the API. That was solely based on what Nehon said at the end of his post.
@fabsterpal said: Actually, I was meaning to put the word "again" at the end. I dislike NB, I know. That wasn't what I was saying however. Another point is that everybody has their preference. A SDK shouldn't force one IDE on a user, infact the IDE should be totally unrelated (something such as generating a gradle or ant buildfile to import the code into other IDE's would be a good idea also).
Again, the SDK doesn’t force you to use it as a code editor. You can use it as a simple asset editor and use your own IDE and project type with it. You can also choose to use the project setup and deployment features of the SDK and use the created project as a normal ANT project (which all java IDEs support) in your own IDE. So theres absolutely no forcing to use the IDE for coding.
However, your preference for this kind of editor will also inevitably lead to a situation where the external IDE in question will have to be set up in a special way (database connection, used libraries, how the code is parsed, where the script stuff is injected/compiled etc.). Why not simply use the existing infrastructure in the NB platform? It allows us to compile things, access and run the code and many other things that are very helpful and will have to be implemented or re-implemented one or the other way for a “unity type” editor anyway. If we wrote APIs for all of that, in the end it would probably not be more intuitive or pretty than the NB APIs for these things, plus we would have to write docs and answer posts about it here on top of all the work for implementing it
And yes, I still think its simply unfair to compare us with Unity and UDK, think about the fact that if you even compare us on the editor and highlevel framework level, that means you compare us at pretty much every other level as well. This is a handful of people coding in their free time (and wasting time explaining or defending their decisions after doing that) against a multi-million dollar company… 
As an example: Yes, we have comparable deployment features, even for different platforms, no we would not have them yet if we went “top down” and implemented the editor first without something like the NetBeans platform.
And: No we don’t have highlevel APIs for NPCs, AI or anything like this yet in the engine so we can’t make an editor for such things, yes we do want to add stuff like this in the future.
Edit:
@fabsterpal said: The base of my argument isn't even with the API. It's with the concept of standardizing the use of one specific platform / IDE when there's no special coding requirements (e.g. a custom language) that need to be catered for. I'm not attacking netbeans at all. In fact, whilst most of the time I use eclipse, for projects which require a chain of projects depending on other projects, I use IDEA.You’re getting it confused with when I said about how the time between features is being increased because of the API. That was solely based on what Nehon said at the end of his post.
Saw this after my post but it kind of contains the answer(s). How is our own API or the one of this editor here not something that effectively causes the same issue? And as said, you can use any IDE for the code (see above). Finally, the core engine is completely independent from the SDK anyway.