Oracle gave it the big FU, now what?

What i personally would like to have is an EditorAppState that i can easy extend to the needs of my game.

Imho it would have the advantage that it is a battletest for the engine, and everyone would have an ingame editor. Added with a oneliner in your project and a dependency.
Code where you want, edit assets ingame.

But i also know that it is a too big task.

7 Likes

just funny picture :slight_smile:

4 Likes

I think that monkey just segfaulted. :laughing:

2 Likes

As I recall it (perhaps incorrectly) this also was one of the ideas behind the SDK - to not only make lives easier for the coder but to also provide a tool for people who are only dealing with asset pipeline and level editing.

That seems to be what some people here are doing (have seen that at least twice). They make their own level editing tools inside a running jME instance. Since that is so easy with jME I almost did that too. :slight_smile:

Yes, please keep improving and providing the JME-SDK-IDE-Bundle! :heart:

I owe you a couple dozens of beers for all your effort put into it :beer:

I use quite a few different IDEs for work (non-JME Netbeans 8, Android Studio, Visual Studio, …), but as soon as I double click on that lovely monkey icon to start up the SDK in the evening I’m in a totally different creative world :chimpanzee_smile:

And to the people wanting more WYSIWYG-Editor thingies for your scenes and assets: Just code them yourself, specific to your game, old-school style like many successful devs before you (Romero, Sweeney, Blow, etc.). They will always be more efficient and powerful than any general solution in the long run and will force you to produce more stable game code, plus you will gain a lot of experience.

2 Likes

I don’t doubt about it, but in my opinion, as I already stated, it isn’t actually (having all the way experience about the first decision) the best choice to continue with (considering best, the most liked, the way more new people will get attracted by the engine, etc).

This isn’t what a visual artist want (and without them, you are very limited). When you pay someone, you can force him to work however you want, but when not (what usually happens with starting indie teams, which happens to be the big part of jme3 users), you can’t afford that, if the artist doesn’t like the tool, you lose your team.
Apart of that, I don’t think there is any problem in people doing “more WYSIWYG-Editor thingies for your scenes and assets” to share with others.
That frase you state there is just like: “And to the people wanting more WYSIWYG-Game engine thingies for your games and programs: Just code them yourself, specific to your needs, old-school style like many successful devs before you…”. But hey!, I don’t have any problem with it, but I don’t think that is the philosophy we are seeking here right now.

1 Like

Ah, yes. I’ve watched a documentation about Romero and other games pioneers. Was quite suprised that he was quite a good coder and 8 bit graphics painter before he transformed into more of a designer.

True, but why not consider multiple ways to get new people (SDK and JMB and others). I guess a good Youtube channel demonstrating JMB, SDK, several of the test projects (maybe even with some kind of moderator or “charming talking person”) might do the trick - this might get even more people into jME.

Good point - not every self-made level editor is a big attraction. :wink:
Same is for the most open-source-art-tools: Many artists don’t like Blender (too many hotkeys, too cryptic) or Gimp / Inkscape (these are really terrible for similar reasons). I as a technically versatile person with some artistic talent am one of those rare people who like these tools (but even I had to buy Microsoft Office and use PhotoImpact in order to make my board game, since LibreOffice and Inkscape/Gimp were missing key features). I guess that’s why any talented people will most likely resort to 3DS Max and the CS (Creative Suite, from Adobe).

But no reason to be sad. jME now has an asset store and support for several import formats (for tools that artists really like). Also support for five major platforms (Windows, Linux, MacOS, Android, iOS). In addition to that some of the best Java code ever seen by some of the most experienced coders. And some good products started to appear (games made with jME). Promising for the future that is… :slight_smile:

Idea that might push it even further: Write an en detail description for a solid asset pipeline + Make a fancy youtube channel that brings 2 new videos each week: 1 WIP show that shows stuff going on + 1 feature show that shows a test case in action and what that feature gives you (might be from the jme-test.jar or from the several plugins like SkyControl, CSG, and the like).

Cheers! :slight_smile:

1 Like

I purposely try really hard not to mention Lemur in Nifty threads because it is unhelpful to the person just trying to get nifty to work. The rare times I will mention it is when someone else brings it up and may misrepresent Lemur slightly or if it’s a case where Lemur can be used along side of Nifty without issue to solve the person’s problem.

What I don’t do… is hop into every thread even remotely related…
OP: “I’m trying to model a toilet but the water doesn’t swirl right…”
Me: “Hey, I once coded lemur while using the bathroom, you should totally use it…”

Others are more heavily evangelical for their own tools than I am, though… so that happens all the time.

6 Likes

Change lemur to SS editor and it becomes oh so familiar :smile:

1 Like

These quotes are the jest of this thread ^^^.

I don’t understand the hostility towards @javasabr project since his approach seems visionary to me.

I don’t know what it would take to adapt it to make it qualify as a NetBeans plugin or eclipse plugin but this just makes sense. His efforts are entirely directed at adding features to JMB which equates to less time spent debugging and customizing the editor. Lot smaller footprint to.

The SDK is awesome, but if a plugin can be and has been developed that does the same thing, regardless of the editor, maybe its worth thinking about.

There’s also something else at play here and this reply from a post about git I read kinda sums it up, even though the SDK is a good tool, the general idea of why people resist change applies.

Steveko (and a few more people here) are very reasonable in their expectations that in the year 2016 we deserve to have tools with smart, rather than cryptic, user interface. And smart error and warning messages, that respect the user. But the Linux community was always opposite from that. Why?

Well, they’ve spent half of their life learning to use cryptic commands, and now they don’t want them simplified. But why? Here’s why:

1. Now that they have learned everything by heart, it seems easy. They’ve forget their own pain and now don’t understand how others can find it hard to learn. Why wouldn’t you spend a few months on this tool, a few years on that tool, another few years on another tool. After all we know that an average human being lives for 800 years, out of which the youth lasts for the first 750. Right?

2. Now that they’ve learned the tool, they don’t want user interface to change. Because that would mean they would have to learn it again. And feel that pain again… hmmmm, maybe that’s exactly what they deserve.

3. Now that they know how to use the tool, why would newbies have it any easier than they had? Let them go through the same hell. Let everyone forever use crappy UI just because they had to use it. Let in the 24th century Capt. Picard of the Enterprise be blown away by Klingons because the ‘git am’ patch didn’t apply the new photon torpedo launch procedure.

3 Likes

Very funny text you quoted. I witnessed a Linux CLI fan guy once who couldn’t even use a simple file browser and select multiple files with a mouse. Was kind of interesting to watch this … since he was a real guru in that other world… :slight_smile: The difference between SDK and JMB doesn’t seem that drastic at the moment, but I still have that on my agenda, just didn’t have time yet to test JMB. I have that jME “cook book” from Rickard and it heavily uses the SDK to explain things, which was a good idea back then, to promote the jME SDK. I’m more a book person, but videos showing JMB are nice too, just didn’t have time in my previous 750 years of existence… :wink: No offense meant, just find that quote funny. People and their psychology are sometimes ridiculous, so it’s absolutely true! :slight_smile:

Some good ideas right there. Hmmm, could it be the time to undust my youtube channel…?

2 Likes

if we will give up on JMonkey sdk i think that our best solution will be an app that initialize the project (create folders gradle files and necessary classes) and an external jme files editor like @javasabr 's JMB , seriously i don’t think that plugins are something we could manage easily cause we will need to make at lest 3 of them (for intellij netbeens and eclipse)

3 Likes

still need some work but it’s nice for now. @NemesisMate thanks by the way i didn’t know that someone already though of it at least in JMonkey community .

Why not IntelliJ IDEA Community?

@e_v_genius cause every developer like a different IDE look at this pool:
Which IDE do you use for developing game with JMonkey?

RTFM???

Do you always get this mad when someone criticizes a software you use?

Sorry,
Old school (aka real school) here what is triggered???

Does that mean drawing goofy…Meme’s I believe they are termed???
Geez must have time on your hands to make a drawing then REPLY instantly…

So I don’t know what “triggered” is in mod jargon but geez you were the one attacking or didn’t you see it that with your 2000 quote…mirrors my friend are VERY useful.

1 Like