Why it'll take time for good Java games to appear

[gregorypierce]

That's all completely true Gregory, but you're only looking at one small expensive end of a very big market (the high-risk end). Go to http://www.dexterity.com or http://www.garagegames.com for a look at another segment of the market, and that's the segment I'm most interested in because I have the greatest chance of making a living and enjoying myself at it.

Oh I didn't mean to belittle your position, only stating that there are other people out there who, from a business perspective, are trying to address the issue a different way. From their perspective there is money to be made if clear compelling content can be provided and viable tools can be produced to help more novice programmers build games.
 

If you get anything serious going wrt. LWJGL game development, there's a programmer and artist for hire here

I will let them know. Unfortunately I don't yet control the future of that particular endeavor I just know people who knew people who had a plan that could use LWJGL. I'd talked to you about it before... they were already working on something similar but they were still at the 'planning' phases of the rendering pipeline and what I had given them basically wrapped the AWT component paint (and I'm sure they've already created their own rendering component that does the same) so they could build their own tools.

[nlmueng]

I saw http://roboforge.com/ at the store boxed this past weekend.  It is a pure java/java3D game.  It has been out for some time, 2 years I think.  First time I have seen it at the store though. It has pretty good graphics.  Never ran real well on my computer though.

nathan

[jbanes]

Sorry to continue hashing this thread, but a big factor that hasn't been discussed yet is *presentation*. How could you get people to download the virtual machine? Simple, bundle it with an "online game launcher". You make a small program (probably 30K in size since it could pull images and descriptions off the server) that is bundled with the JRE/Webstart. When users install this, they get a desktop icon that says "Play Games NOW!!!". This icon launches a program which displays a cool looking list of games. (By "cool looking" I mean, smooth scroll game icons in a left to right fashion and slide out a description panel when they click on one.)

When the user selects a game for gameplay, the Java Web Start URL is launched, and the game downloads. The user gets all excited and jumpy waiting for the game to download, so they sit there and watch the download bar (anyone ever sit and watch the Windows Defrag?). Since the JRE is already downloaded, the game will easily be only 4-10 megs. Even better, the webstart programs could share libraries (such as Java3D and LWJGL) so that the user will be downloading mainly game code (small) and media (somewhat large).  

Done right, users will happily download ten to twenty megs of data just to run their first game! If you don't believe me, just ask BMW. Their filmplayer was a great success. Now if only their films were as great as the idea...

Games published by our own members! Check 'em out!

[nickdotjava]

What's LGWLJWL?

And I do believe Java will be the future of games.  Eventually, comps will be powerful enough that it won't matter if you write it in ML (but please, don't).  Anything where you'd see a significant difference between C and Java would probably have too much going on to be playable.

[kevglass]

Hear that argument alot, "eventually computers will be more powerful". Computers have been evolving a while now, when more power is available we don't do things in more abstract ways, we invent new and more complex things to do.

Java will get more and more able to do games of today, but by the time it is, games of tommrow will be more complex.

Thats not to say I think Java doesn't have a hope in the gaming market. Just that it needs to pick its mark more carefully.

Kev

[princec]

(Agh! Thread resurrection!)

Well, we'll see about that, Kev! Right now the only thing holding us back is the lack of structs, as we can do everything else just fine.

nickdotjava - you can find LWJGL here. It's for writing games in Java using OpenGL as its rendering API. It's not quite ready yet but it's close. Documentation leaves a little to be desired so we support it on these boards.

Cas

[swpalmer]

Right now the only thing holding us back is the lack of structs, as we can do everything else just fine.

I disagree,  I think the biggest thing holding back Java gaming is the garbage collection issues.  It's bad enough in Quake when you get fragged due to network lag... If it is your own machine pausing to collect garbage when you are in the middle of a fight that's an even bigger issue

I know that some people have been successful in eliminating most garbage collection pauses by not allocating objects in the main game loop.. but that is very restrictive and leads to poor program structure, less object oriented coding methods.. making the coding process more difficult than it needs to be etc.  (basically taking away many of the advantages of Java).

If we get some new features like limiting the time spent garbage collecting to a few ms every frame, etc. that would be the feature that I hope for first.   Not having structs makes things a little slower (for coding and execution time), but current garbage collection algorithms make things unpredictable.  I find that to be a greater evil, requiring more complex workarounds than the struct issue.

[princec]

Don't you worry, I think GC is under control now. With -Xincgc and -Xconcgc we're now talking about dropping just a frame or two here and there if you don't go mad with object creation, and then, only every couple of minutes at most. There's no need to be non-object-oriented in order to wisely use the new() operator. Decompile Alien Flux and have a look - new() gets used where new() is needed. It's not absolutely perfect but it's not the hassle it used to be. (FWIW, Jet has exactly the feature you've described, and escape analysis). I'm looking forward to escape analysis further eliminating garbage collection.

What's more, if your huge rendering structures like quadtrees and BSPs are stashed nicely in Buffers instead in hundreds of thousands of Objects there's a lot less thinking for the GC to do.

Cas

[swpalmer]

Hmm.. how is Java3D for garbage generation?  I only experimented VERY briefly with it and found that my simple bolb of code to bounce a ball would glitch annoyingly due to what I assumed was GC issues.  Maybe I got that all wrong or was doing something stupid..

[princec]

Java3D is fairly inefficient it seems. Look at the memory profile of the running app and watch it. I think even the most trivial j3d application needs heavy GC tuning work to run smoothly. Even then it's not the fastest dog in the race because it does do a lot of creation and collection which could simply be avoided by knowing a few other parameters in advance. But that's not how j3d is meant to work.

I don't think j3d should be pushed as a games solution at all. It's a brilliant general purpose 3d solution though by the sounds of things which should take off in industry.

Cas

Games published by our own members! Check 'em out!

[Orangy Tang]

Done right, it seems that j3d will produce almost no garbage itself, so any GC glitches are down to the use of it. Unfortunatly it seems that using any of the non-trivial features incorrectly will kill you with garbage.. and documentation on the 'proper' way of doing things is slim to none

[blahblahblahh]

Hmm.. how is Java3D for garbage generation?  I only experimented VERY briefly with it and found that my simple bolb of code to bounce a ball would glitch annoyingly due to what I assumed was GC issues.  Maybe I got that all wrong or was doing something stupid..

Not pointing at you in particular, but there seems to be a vogue these days to blame the garbage collector every time any program stutters. In most cases (> 90% perhaps) I'd hazard it's actually poor programming. Almost none of those who complain of GC problems appear to have actually *checked* whether it was a GC pause. A more likely culprit is often a poor scheduler, or a use of threads that is confusing the scheduler (I'm having problems with that in an app at the moment, and not sure yet whether it's my fault for doing something stupid with my threading, or the scheduler's for being unable to schedule a mere 4 native pthreads properly!).

As Cas mentioned, GC these days uses pretty good implementations (although I'm still eagerly awaiting a multi-threaded incremental GC from Sun as standard ). Admittedly, Sun did make a big mistake with their early GC algorithms, which anyone could have predicted were going to be a major PITA - they were using algos that people just hadn't been using for years, because they were known to be so poor. Reading hotspot's "optimizations in the GC" in the release notes for some of the 1.2.x releases was a real eye-opener.