have you tried it? Have you actually gone out and built something in Java using the latest in available JVMs and libraries and done user experience testing on the result?

Of course you haven't. Your preconception of what would happen is all the proof you think you need.
Of course your lack of experience with Java also means you'd be unable to create that Java application to be optimised for performance, which is another problem for a new tool to gain acceptance in an established industry.

But why? I actually have tried to do it, Java worked OK for this 3D game; comparable with C++ on the same machine; most of the speed problems were introduced via naive coding style. There aren't any show-stopping technical disadvantages to using Java; if releasing for the PC. Reasoning? The CPU intensive task that most games want to do is transform/lighting/texturing/etc - this is usually written in very low level code, and always accessed via some level of abstraction whatever platform is used. If you have low-level libs for physics aswell; the rest of the code in a game is usually 'light', event-based, quite dynamic; so, in a way, it doesn't matter what language you use for that part.

I didn't finish the game because I didn't finish the engine because it got stagnant and over-engineered. I'll happily write games in any language - some of the high level frameworks provide so many useful tools/libs, even runtimes these days. But.. if I was writing a tool, lib, or runtime; 'an engine'; I would want to do it in C++. In the games world C++ is more cross-platform-compatible than Java, it's got a proven track record; you rarely need to work at a lower level, but it is quite easily understandable, useable and well documented; a new language standard is going to be released soon, I don't see C++ stopping being de-facto.

The only time I'd want to use Java for any part of a game client, is if there was some platform-based reason for which Java HAD to be used; i.e. if the game had to be deployed through a browser, on a mobile phone, etc. If I had a choice between writing a game using an existing Java engine, using an existing C++ engine, or using an engine that compiles or interprets ECMAScript ( or similar ); assuming no constraints, and the same functionality and comparable speed from each engine; I would chose in the order ECMAScript, C++, Java.

Why? ECMAScript = multi-paradigm and highly unstructured, C++ = multi-paradigm, Java = rigidly OO. After core math-intensive graphics, physics/movement-feedback system, and general structural stuff is done; the only important thing is being able to make 'the game' - and this is often laughably high-level and inherently non-intensive code.. working with person not person.submodels[0,1..n].vertices[0,1...n].. As long as the ( context -independant ) engine is fast, well put-together, and appropriate; it actually doesn't matter so much what language you use to do the work that comprises a given game. I'd pick flexibility every time; I see C++ as more flexible than Java. Personal choice.

For writing an engine, or a one-off game; if the domain is fullscreen graphically intensive games, targeted for the PC and perhaps eventually consoles; there aren't any domain-relevant advantages to using Java; but there are domain-relevant disadvantages - there's no compatibity on the consoles, an arguably higher level of abstraction from the graphics subsystem, ethereal memory management, and everything, for better or worse, is a 'platform-independant standard'. If the domain is browser-launched thin-clients for some physics-light multiplayer game ( i.e. RPGS, they don't have 'physics' like FPS do ); Java wins for the same reasons in reverse.

jwenting, you can't argue non-experience or non-ability because very few people want to spend the time using Java for a certain purpose - Java rarely gets chosen for writing the core of 'high-end' games/engines because it's never been pushed as a platform for developing the core of 'high-end' games. I don't need to know from personal experience that a drill isn't the best tool for hammering nails.. I do - and it kinda works; perhaps it damages the drill in the long term; but that's besides the point, and deviating into irrelevance.

bnastic, you can't blanket-rule 'games' as some singular - there's many types of games, and usually some development constraint on each game, Java MIGHT be the right tool for a given job, client side or server-side. Depends on the job.

he actual plot etc... is not a part of the engine. e.g one game engine (for example, the unreal engine) powers about 50 different games.

Dont use java though. 99% of game engines are C++

For writing an engine, or a one-off game; if the domain is fullscreen graphically intensive games, targeted for the PC and perhaps eventually consoles; there aren't any domain-relevant advantages to using Java; but there are domain-relevant disadvantages - there's no compatibity on the consoles, an arguably higher level of abstraction from the graphics subsystem, ethereal memory management, and everything, for better or worse, is a 'platform-independant standard'. If the domain is browser-launched thin-clients for some physics-light multiplayer game ( i.e. RPGS, they don't have 'physics' like FPS do ); Java wins for the same reasons in reverse.

>>i.e. RPGS, they don't have 'physics' like FPS do

most RPGs these days have advanced physics, as MMORPGs are the big thing (world of warcraft/guild wars)

Why did you repost exactly what I said, mohanrobin? :p use quote tags and only if you have something to say about what i had to say.

jbennet.. physics in most RPGs isn't as heavy as physics in most FPS; only because it's not as integral to the game experience. By that statement I meant, RPGs don't need to have, and don't tend to have, the same complex physics simulation as FPS; not that RPGs don't have any kind of physics and FPS do.

'Advanced physics' implies soft body/fluid dynamics and realistic destructable/multipart objects in this day and age =P.. First-person shooter/adventure engines are starting to have them, based on ( certainly approximate ) solvers that take alot of variables into account; those MMORPGs you listed might fake this on a certain level ( i.e., breaking and fluids based on pre-written animation ), and have some degree of rigid body simulation; but.. that's not advanced anymore. I hold by my statement, that RPGs don't ( generally ) have physics like FPS. Correct me if I'm wrong; I've only played WoW once at a trade fair.

yeah, i was just thinking of the arrows, catapaults, spell clouds etc

the physics in any FPS I've played go no further than you sinking when you get into water.
The very best may see bullets of long range weapons drift with gravity and wind, but that's as far as it generally goes.

In some FPS games of a few years ago; physics simulation is a part of gameplay.. Think Halflife 2; you throw things ( boxes, cars, etc ) around, they affect other things; in Red Faction, which is really quite old now; you can blow holes in walls. In other FPS games that I've played briefly, but not enough to remember specifics, you can hurt people by hitting them with shrapnel from exploded objects, take cover from explosions by ducking behind short walls, etc.. That isn't so advanced anymore, but; I would imagine, based only on the history of games so far, that the 'advanced' physics in any time period will be more prevalent in FPS than RPGs. For modern, look at anything that uses Ageia's PhysX SDK ( i.e. Unreal Engine 3 ), or Crytek's CryEngine2.. CryEngine has support for realistic ( and massive ) explosions and interaction with the environment, PhysX SDK potentially supports realtime soft body, cloth and fluid simulation.. There is more to physics in games than paths of bullets and the like... what's the last FPS you played?

Any RPGs I've played don't really have even single object, rigid-body physics; the map is usually non-modifiable, and when you destroy an object it just disapears. That's not to say it'd be unreasonable to put good physics in RPGs... just that it doesn't seem to get done.

Decent gameplay-altering physics in a massively online game of any genre would be hard to do; since it'd have to be calculated or syncronized exactly at both the server and the client(s). Not impossible, but perhaps unnecesary; unless physics really is integral to the gameplay.

> I hold by my statement, that RPGs don't ( generally ) have physics like FPS. Correct me if
> I'm wrong
Agreed. The amount of physics in 'sports' games is also worth taking into consideration. RPG's as such don't rely much on physics as FPS and Sports games do since the focus is never on fast paced game-play or real time physics.