JMonkey october 2016 share experience please

@Antonystar Fun metaphor about Rome and Sparta :clap: and it looks like it is true.
But for me the game creation is a challenge by itself, no need to make it more complicated.
If u want build ur IT muscles it is just another task. U have to make 3D game without engine, just with JavaSE or JavaFX and ur gonna look like game developer Hulk :wink:

Heh, I am not saying about becoming IT Hulk as the main goal. I tried to say that you get experienced quite fast and that becomes a benefit.

Imho it all depends on what kind of features you have in your game.
As soon as you use non standard core features you cant use the sdk anyways.
It is nice to quickly place a few objects in your scene but there are tight limits.

So the benefits are, shader node editor and the material editor which are super nice and hard to integrate in your own toolset.

Convertig assets and stuff like that are 10liners. Even possible to do it during the build process from gradle.

I personally go the route of creating my own editor, mainly because i use custom solutions all over the place.

For my real game I am using blender as my scene editor. And wrote a post-loader utility class to auto load my scene in JME and did all my conventions there (ex: model loader based on place holders from blender, LOD loader , Navigation Mesh loader for path finding , Cinematic Motion Path loader , Bone Attachment loader and so on). I create my scene in blender and links models to scene (using blender proxy) and when i export scene i just export Place Holder of models in scene (PlaceHolder is just an empty node with the name of model and it’s location and rotation) so my whole scene size after export is lest than KB. And in JME i load scene and read all Place Holders then add corresponding model based on it’s place holder using my conventional post-loader .
Using this way i could simulate SDK’s scene composer model linking.
And for exporting from blender to JME i am using Xbuf exporter.

This is a demo of all i explained above

1 Like

@Ali_RS Looks like u made some kind of subsystem of SDK system. Greate job i have to say and now we r all know how jme can be used in dat unstandart way.

EDIT: Can u answer are SDK features like terrain generator, apply controls and AppStates to preview scene dynamically isn’t needed for u? U just happy with ur subsystem?

No , I create it in code
see this example

I am doing these also in code. Managing Appstates and Controls in code is easier and faster in my opinion. (and now by switching my game design to Entity Component System Design (using great Zay-ES framework) i do not need to use controls in my game and every thing is done in AppStates)

It is really not that kind to call it a sub system :stuck_out_tongue_winking_eye: and still is a WIP that i extend it as new need comes.
And yes i am happy with this. JME puts your hands open to do as you wish.

Actually before i want to start working on my real game, i put lots of time to study all wiki tutorials and JME beginner guide book and cook book and most of jme example codes. And before all of these it takes me about 3 monthes to learn blender and yet i find new things about it every day. And now i really really love it and use it as my scene creator.

I also created some video tutorials for using blender with jme you may like to watch them.

In my opinion JME is a decent game engine. Its flexibility and fact that its opensource makes it worth to use despite the several weakness. In general, it is quite hard to start a good looking project, JME requires at least a fair knowledge of Java at the begining and the ability to understand shaders. What you can be done with JME? Look at @MoffKalast’s Lightspeed Frontier and my Skullstone.

Personally I don’t like SDK, I use Eclipse for coding so SDK is only a tool for importing models.
Nifty is an nightmare for me, I use it only in one place, made an entryfield using it, I was too lazy to do it from scratch in my own GUI engine.
After few months of making Skullstone (and learning JME at the same time) I was able to do my own rendering pipeline based on deferred shading, with live shadows, many light sources etc. It was not a hard thing to do, thanks to JME’s flexibility.
With JME you write a CODE. Not a script, not any blueprint, there are no ‘creators’ or ‘wizards’. Treat JME as a huge library, use what you want, ignore what you don’t want to use.
Incomplete documentation is not a problem imo - you have source code, you can read it.

1 Like

Thanks for the compliment, but he should really rather look at Spoxel or some recent creations of @thetoucher which are way better looking in terms of graphics. I’m still on basic forward phong rendering.

You’re not the only one. High five? :raised_hand:

That’s where you’re wrong, there are wizards.

The ones sitting in front of their pc writing code. :wink:

1 Like

What’s wrong with Phong? I’m using it too, it’s just the formula for lighting the objects.

Well PBR seems to be all the rage these days.

1 Like

The truth is that we would never achieve the visual quality of AAA games, its just a matter of workhours. And imagine a player who say ‘your game don’t have PBR so I will not play it’.
Ingame graphic should be NICE. That’s all. Indie games are not something strange for players these days, their requirements are reduced.

Even the larger companies often fall back to “comic look” in order to let players on older or cheaper computers play 3D games. For many indie games it’s a great step to use 3D at all - as the creation of proper assets may take way longer than pixel graphics or flat colored polygons.

Something to add to the OT PBR discuss:

IMHO PBR is a totally overused term. The only good thing about it is that it has created some sort of a standard pipeline for assets. It really is just a formula, and the main difference is that it is energy conserving.
The big thing is global illumination, and nehon did a great job in that direction. Even phong would look pretty good if you add some global illumination…

1 Like

I did this a few years ago to practice modelling + the blender to jME pipeline. It uses no lighting , so phong vs pbr debate is mute, no shadows and nothing baked out ( lighting, ao, normal maps … that would be cheating).

Thought it might be interesting to include in this current conversation.

1 Like

I kept waiting for them to fight… disappointed. :slight_smile:

To paraphrase so many imgur threads:
Step 1: be talented

Step 2: Be talented

Step 3: You think that’s air you’re breathing?

1 Like

I keep reading tutorials this days too, watching videos and e.g. Learn is smth we can’t avoid while developing game, it is how it should be. But someone of us thinks solving SDK’s entire problems or any other tool’s problems is just ok too. Rarely it is, but most of time it is NOT! When u switch from making game (while learning engine) to solving many stomping bugs it is bad for developing process and annoying. Don’t u agree?
I saw ur project, looks like u invested much time to making assets, cause models looks greate. Spoxel look cool too to be honest, have it’s own style :slight_smile:
Seems now not many ppl using SDK for real full developing cycle. It matters much to me. Thx for responces guys.

P.S.: Have to try to be talented :slight_smile:, but i beleive i am not, i am just typical newb game developer :confounded:

@zzuegg as i can see maybe this fuature is what differs most popular engines from jme. Maybe PBR gives unexpirienced developers opportunity to not think much about scene creations, it still looks nice. Is this what r u talking about, right?

No, even with pbr you need good assets, and make use of the image based lighting. The upside os that nehon did lot of the tricky work for you.