hi all!
First, sorry abount my bad Engilsh!
I have a general question abount JME.
Put the case, that I (and of course my team) want to develop a complex mmorpg, we have a full design, art, etc.
Is it possible to develop a complex mmorpg game with JME? I know, we need to use many of thirdparty lib for physic, networking and other. know that is a very big work, lots of money…
I have a 10 years experience in Java programming. (business programming daily) But not in game programming.
So, i dont know that, with jme+other java tool, is possible to create this?
Or we need to use some C++ engine? I hope not, because i can't program in C++ , like in Java!
sorry if my question isn't clear. i try to write it more clear if need.
Thanks!
First of all, I moved your question into a new thread, because it had no relation to the thread you posted it in.
Second: Welcome to jME! Unfortunately there is no short answer to your question, because it is not very specific.
Of course you can build a MMO with jME, you could even do so without jME just using AWT/Swing, or a text console.
It all depends on your standards. If you need next-gen graphics and tens or even hundreds of highly detailed characters on screen at the same time, jME isn't for you, and neither is any other java 3d engine I know of.
But if you are willing to compromise, jME can be right what you need. Depending on your team's capabilities of learning 3d graphics concepts and techniques, you might be able to pull off something "better looking" than runescape. But even if you compromise, you will need time, and LOTS of time! You'll be pushing jME to it's limits and beyond, and that means you'll have to do a lot of 3d engine coding yourself.
Hi hevee!
Thank you for moving my question here.
So, if we want very detailed graphics, we will run into jme's limits? In that case we need and other engine (implemented in c/c++) or we just can't use engine, we need to code it by hand?
WOW is definately dooable in JME, you just need to learn the tricks and illusions …
Hi Boci! (funny meaning for a name in my language, no offence)
I'd like to share what i have learned about MMO game making.
- If you want, make a small graphical demo (possibly multiplayer, but not massively) under any engine, just as a proof of concept, that your team can produce something complete.
- If you still haven't changed your mind, when you finished the demo, and mean on making the MMO, don't start with the client, models and all the visual stuff, that part can wait.
- Start with the server code. Make a MUD (textual MMO) first, and make a prototype networking to client. Make a dumbed-down client for visualising the things happening on the server.
- Make, test the actions, rules and the event flows that are in your world. This is much like business software programming, boring, transactional, and not a bit like programming a game.
- Adapt the world, so that it can be handled by the engine. How many, how complex models can be visible at one time? At what rate can your server handle the actions? Replace the actions one by one on the client with actual animated actions instead of just textual logging.
- Prototype. It takes lot of learning to get everything right, and for prototyping you can use any engine you want.
- Make tools. World editor, script editor, test client, all these should bring together your MMO software ecosystem. Document the workflows. The way of building the world, the model import pipeline, etc. The modelling procedures should be described in documentation, and not left to each of the modellers to decide on.
- As Hevee said, lots of time.
1 Like
Thanks for share you experience it was very instructive!
I know, that making an mmorpg is lots of time, work. I don't want to make mmorpg my first game, it impossible i think.
I'am only want to know, if my team have the neccessary knowleadge (programming and grapics, and others) and we want to use JME for mmorpg, it is possible? As i see, it is.
Otherwise, for my first game i developing a tank-driving game. I download some free blender models for terrain, and the tank. It's a thirdparty view game. Now i can move it (basically), play some sound when tank move, and tring to load varied terrain, etc…
Can you tell me what 'boci' meaning in your language? Just for fun. In my, it means Cow like the animal 
boci said:
Can you tell me what 'boci' meaning in your language? Just for fun. In my, it means Cow like the animal :)
Yes, it seems you are a fellow Hungarian. Welcome to jME, and when you have further questions, feel free to ask.
I'm currently working on my second large scale MMO. My last one was begun almost 14 years ago, and while being 2D and mostly text based still enjoys a significant following today.
I began evaluating the jME over a year ago and have to say that I really don't see any limitations when it comes to creating a commercial-scale 3D MMO equivalent to WoW or even AoC. As mentioned above, you will need to learn the "illusions and tricks" used by other MMO's as well as getting to know the intimate details of the jME itself. The JVM is your largest overhead in terms of performance, but in my opinion this is a hugely insignificant factor when you consider the benefits of platform independence.
And when it comes to performance, I've been fairly floored so far by the amount of flexibility and tools provided by the engine in regards to this aspect. The jME provides features such as imposter nodes, CLOD meshes, and a variety of other performance enhancing tools as well as the ability to query the featureset of the hardware. This provides you with everything you need to develop an engine that can adjust its own featureset and framerate to specifically suit the machine it's running on.
I also believe that the issues inherent to developing MMO's and jME performance are mutually exclusive. MMO's are about networking and service architecture; if you can make a stand-alone game in jME then you can certainly develop an MMO.
-Prime
The JVM is your largest overhead in terms of performance, but in my opinion this is a hugely insignificant factor when you consider the benefits of platform independence.
I don't really think that's the case.. If you know how to write decent java code then your main problem would be 3D rendering. All profiling I did for jME games I was making, I found the 3D rendering to be the largest performance bottleneck. Three things that could alleviate this concern by about 3-4 times is Scene optimizations, VBO and precompressed/mipmapped textures (DDS). Support for the former two is rather shady in jME which makes using the optimizations difficult. CLOD does changes to the mesh which is preferable to avoid in modern cards (instead you should use Index LOD). Beside that, imposter nodes each create a TextureRenderer which is a memory waste (should be shared).
1 Like
The JVM is your largest overhead in terms of performance
Sorry, I guess I meant that more in terms of java programming in general (I've enountered the performance impact of the JVM in other applications quite often). As for the jME, I've been extremely impressed with its performance thus far and as of yet see no reason why it wouldn't be capable of delivering games on par with many commercial releases.
Thanks for the info on CLODs and imposter nodes.
-Prime
My team and I decided to drop our MMO in jME solely because we didn't have enough 3D artists. Aside from that, jME performed very well in testing stages.
One of your biggest battles will be with Terrain. Take a look at the code that Llama posted (jME Terra) and the code I posted in the User Code section and you'll be able to skip that phase.
Momoko_Fan said:
Three things that could alleviate this concern by about 3-4 times is Scene optimizations, VBO and precompressed/mipmapped textures (DDS). Support for the former two is rather shady in jME which makes using the optimizations difficult. CLOD does changes to the mesh which is preferable to avoid in modern cards (instead you should use Index LOD). Beside that, imposter nodes each create a TextureRenderer which is a memory waste (should be shared).
Those are the areas i hope will be improved in jME 3. The solutions are given, just need to be integrated into the rest of jME. Mapped buffers should improve performance of CLOD meshes.
I had two bottlenecks: the JVM (small objects, recursive calls) in regards to physics, and fragment shader because GLSL is still not as performant as a fragment program (especially on ATI). Getting CG support into the engine might be the solution, since as i read, CG uses the same shader compiler as Direct3D, which is better than the GLSL compiler. But this belongs to some other discussion.