[Proposal] Making JME more artist friendly

Ok, first off I want to say that this is not a comparison of JME to any other engine. I just feel that JME could use some improvements for artists and non programmers like myself but also the learning curve for JME for artists / Non programmers is high.

What can we do to fix this?

Make tools for artists -

A prime example would be a Visual Logic editor similar to Unreal Engine blueprints toolset. This would allow artists and non programmers to make game logic for games in a visual way opposed to using a IDE such as Netbeans. But this could be a starting point for that.

When Artists start to use these hypothetical Visual logic tools they are learning java and how JMonkey Engine works. This is how Unreal Blueprints work If you know blueprints you know the API behind Unreal Engine.

Overall I think this would benefit everyone. We get more artists using JME and programmers get better tools to help speed up game development for programmers. Later on Artists start to learn to code using J Monkey Engine bringing in more tools and more contributions to JMonkey Engine.

Thoughts? Concerns? Criticism?

Please I would like to hear it all.

  • HeadClot
2 Likes

The thing is you’re talking about high-level concepts that simply don’t exist in jME as code. There is no “player” or “NPC” or “start point” defined in jME, you can define these things as you want in your game. Consequently there cannot be any visual tools to edit these things.

Unreal is basically expecting you to write a FPS game and has code concepts for players, navigation and things like that and while you can deviate from that and change the code to do something else these tools then won’t work for your game anymore.

So to do what you suggest there would have to be some kind of plugin that brings both these concepts as code plus the editors for it and while the core team definitely has an interest in eventually creating things like that for FPS, RPG, RTS games etc. we’re still far from that. One logical next step for that could be integrating Zay-ES into the core engine and building from that towards things like FPS etc. templates and then in the end creating editors for that but as you see theres still a lot to do to get there and we do want these things to be done right if they ever get integrated in the engine. But obviously we did bundle the SDK and engine to ultimately be able to support such frameworks.

This is also why so many of the editors etc. that have been done for jME by others are eventually doomed because their creators think from the top down (like you do) and basically want a button to place a spawn point, creating their editor from that perspective and later realising they only restrict the possibilities of the user. Then they either have to extend the options for their framework, basically creating a mess (as its not planned from bottom to top) or end up with an editor that can only create one type of game basically.

I don’t want to sound dismissive as I totally get what you want to say but I hope what I said makes clear why it simply isn’t so and why it can’t be approached from that angle.

4 Likes

It’s a complicated topic IMHO. In one side we have artists, which are unable to spend much time on coding, but they do on external tools, like PS, Blender, Gimp, etc. And on the other side, we have the coders, which spends a lot of time coding, but don’t do so on external tools.

I think it’s impossible to satisfy both sides and have a good engine. I see Unity as very good for Artists, because with you can create games with minimum code, but for developers, it isn’t that good, because as @normen said, you got restricted by some laws. But JME3, as discussed on others topic, give you more flexibility and do less trivial checks (they trust on us!) but for artists, this isn’t good, because they need to dive deep into code if they want a good game.

As a developer, I hope JME3 never became so friendly for non-coders, because to achieve that, they have to implement many restrictions and lose some performance which trivial checks.

1 Like

I’m sure I’d be frustrated if I was an artist, but as a programmer I would run like hell if JME was like that. I love how I can code what I want how I want without having all this other stuff thrown at me.

1 Like

I would also like to (respectfully) point out that “wanting a thing” gets you exactly 0 steps closer to having a thing. Like dropping by a friends house and seeing their empty back yard “Dude, wouldn’t it be great to have a forest here… with a little path and a pond full of goldfish?!? Why don’t you do that?” Well, a proper forest would take decades and time + money.

This wish list is not that far off of “why don’t you create a forest here?”. We don’t have paid staff to create and support such a tool. And it’s a HUGE effort. You don’t even guess how much of an effort it is. Think of all of the money, time, and people Unity has poured into their tools.

I have created visual scripting tools before… it’s hard, it’s a pain, and the users are pretty horrible, really. I mean, the coding problems don’t get that much easier, you just avoid the syntax. So all of the fundamental understanding issues are still there but now you also have to deal with something visual. Even when paid to do it, that was pretty terrible work.

Frameworks, on the other hand, kind of reach an effort-to-benefit sweet spot. Example: add in a wrapper for OpenGL then you get ALL of OpenGL. Spend a little time creating support for a basic scene graph structure and suddenly you can make pretty much any scene you want. The pay-off relative to effort is pretty huge for these things.

With visual scripting, at best you break even on effort to pay-off… and in the end you gain a mountain of support issues.

5 Likes

I think the friendliness of unreal/unity is the main reason of why many of the games built with them is bad.
Making a videogame is not only about sterile programming,you must understand how a game works to make it performable and stable.

If you want to program a game,learn programming,don’t look for easier paths because they’ll not bring you to anything good.

I moved a post to an existing topic: What level of knowledge do i need to make a bloxel engine?

Wrong topic? :laughing:

Sorry for the late reply - I am just getting back on the JME forums - I could not access them yesterday for some reason.

So wait - JME does not have any pre-defined classes that save time or am I mis-understanding here?

I want to correct you on this - With Unreal Engine 4 can make pretty much any game I want it too. This was the case with UDK / Unreal 3. But not Unreal Engine 4. I just want to clarify that.

Yeah I understand :smile:

You are right. I guess I should look into actually doing opposed to wanting.

It was just a suggestion on teaching artists a way to learn Java but visually and when they are ready they can jump into the Text based IDE.

Many of the games are bad because the developers rush the game out the door, don’t take time to learn the tool sets, and / or Just give up half way through. It has nothing to do with user friendliness. If anything that would make a better game by allowing the developer to just focus on the development of the game, simulation, or whatever.

I can agree with you on this to a certain point. For larger games (Open World, etc.) You will most certainly need to learn programming without a doubt for tools and game play. But for a smaller game like a FPS or a Third person shooter you could use visual script and get away with it.

Mind showing some examples? I am curious of some of the visual scripting tools that you have made.

2 Likes

for a smaller game like a FPS or a Third person shooter you could use visual script and get away with it.

Can you point up any good game made only by scripting from non dev / artists only team ?
To build an good game, you need artists and developers, they have knowledge of complete different things, they are diferent, artists are good with art, developers with logic.
The thing with games is that you need both, and you cant mix it up, if you put an artist to learn java you will just louse time and money and will not get good results. The same paradox for devs.
I do agree with tools that make smoth for the artists to load models, test the performance on the engine, etc, Jm3 have some tools with some bugs, could be more, but it has some. But I dont agree on making scripts and stuff to try to make it easy for artists to make logic, I never saw it work and I dont think it works.

Yeah sure

Into the Stars by Fugitive games is a notable example. Keep in mind that these guys had no programmers on their team. They ran a successful Kick starter and Released an Early access build of the game as you can see they update frequently.

There are also plenty of examples on the unreal engine forums.

Give a man a fish and he will eat for a day but teach a man to fish and you will feed him for a lifetime.

The idea is not to give artists and non programmers an easy out so to speak but to teach them how to use Java and JME3. That said - I really think that this feature will increase adoption rate of JME among the Java game development scene.

1 Like

Well, I dont agree with you, I guess its just an diferent opinion on how the human brain works.
Anyway, I think you will find dificult to get support for this idea in this engine thought.
Its just that the objective of Jm3 is to supply tools for advanced developers to make games, and just that.
I mean, even for developers, if they dont have some good knologe of java they will get lost, we see it everytime in the forum.
Like this guy I repply today that thought you need to change the material and texture of the object to make it bouncing more :

Actually, I’d be thrilled if we had that kind of editor. Really.
But we’d also need someone(s) to actually create it and maintain it.
We barely can cope with maintaining and making enhancements to the engine and the SDK as it stands, so unless more people step up and contribute with a will to stick around for several years, I don’t see that happening.

7 Likes

From a more novice java programmer’s perspective, I have used unity and udk and i like how comfortable they feel and just how fluent and productive the tools are. JME can just be overwhelming for a beginner java developer (believe me I know). I think it would be cool for JME to have as powerful editors and sdk tools but im not adapt to help with that. It’s better to invest time in learning java and writing other applications before jumping into JME. Im talking from experience :smile:

The main problem here on this topic isn’t that JME3 can’t have advanced editor for Artists or can’t be friendly for non-programmers, would be nice if it was (without changing its raison d’etre), but since the Core Developer team is small (they work on it by their own, since there is no profit for doing it), there are a lot of priority improvements to do in engine, that they can’t stop and create (or maintain) an editor.

As I stated on another topic, the visual editor for Shaders and the ShaderNode design is unbelievably amazing!!! It show the skill and knowledge of our lovely core developers, so the problem isn’t knowledge. It’s a matter of time and space.

If anyone wants to create editors or tools for SDK, I have sure it’ll be welcome by community, but actually, the JME3 Core Team can’t handle doing it.

It’s simple as it is (I think).

4 Likes

Visual scripting tools are among the scariest double edge swords I have seen in my years of game development and multiple engines. To me they should only be used for prototyping purposes only, so a game idea can be tested in a few days rather than a few weeks. It should not be used to do 100% game development without many sacrifices. Besides, there is no visual tool for code that is as flexible as the code that supports it and many designers and artist that do not have experience in code don’t know this or refuse to know it because it will require to then to actually learn code.

1 Like

Hi,

Just to share what our team have done to improve JME SDK to be more artist-friendly as you said but this is good-n-bad…

For project in the past, our pipeline and production require use to outsource level design, texture painting and facial performance, voices… for example. So we need a way to organize all the stuffs we will bring to the SDK before we code any line. Another anoying thing is even programmers are used to different tools (insert Unity or UDK wannabe) and they asked for it. Also our company base in an Asian country and we are bad at English, that’s why we even localizate the whole SDK to fit “our language” and “concept” of thing… For summary, PIPELINE, PRODUCTION, SKILL, EXPERIENCE, LANGUAGE and more thing need to be customized, and it take a lot of effort before we can actually write any game and make money…That’s our scenario.

So you can forget the whole thing and just jump into writing games. Or you can continue reading :smile: …

We have run a long path in improving the tool (JME SDK to be specific). I’ve started first like 3 years ago to make a cinematic and facial tool. At the time I’ve use Unity and UDK for a while so I want to mimic them (UIs, workflow…). Later, other games are planned. Designer need MapEditor, CharacterEditor… Artists need Component, Scripting, NodeBaseLogic, TexturePacker, GuiEditor… Progammer need CodeCompletion to link all the stuffs together. So I have to learn Netbean SDK, later Groovy to integrate it as Scripting language. In the meantime, other developers are too tired of waiting for the tool I’m making and their wrap some python scripts and let Blender to all the jobs… After all the struggle, our company had two tools and two pipeline are relatively do the same thing, have some glitchs and thank god can worked together. In the start of this year, we decide to make better tools for upcoming projects to make Java game. At the time, UDK and Unity also announce as Opened. It’s an very attractive temptation you know… We’ve planned to use JME3 projects that require open-source license, for education or for public-free purpose for example. And use other tools that more fit for other money related jobs. This is the choice we should make acordingly to what we been through.

Hope this helpful,

4 Likes

You know, the only tool I would really love to see is something that would allow me to use something else then ogre for animations… This format is pretty much dead right now and really this is something that keep JME down. A game with no animations ain’t really a game, and an engine that doesn’t support any living format ain’t really healthy either.

Don’t get me wrong, I love JME, but adding new format compatibility would really help little people like me to put some assets in their game without a budget. I know its not that easy whit the license and code complexity, but a man can dream x)

Well the blend importer is actually already quite useable, but yeah getting animations in any way into jme is a pain in the ass.

If you knew how many times I had format error with that blender importer xD Or texture not showing, or deformed, or broken animation. Maybe am doing something wrong, maybe there would be a way to make it work, but I don’t really have the talent nor the patience for that x) plus an engine should make your life easier, and even if I must say it’s very refreshing to code a game whit Java, damn is it complicated to get the stuff inside…