"Besides lobbying for Java, the game division will pitch game publishers on servers, software and other infrastructure needed to run online games. IBM last year helped launch Butterfly.net, a project to apply grid supercomputing techniques to running online games, and a number of specialists have formed companies to address online gaming mechanics. "

Phenomenal! 2003, the Year of Games indeed! The title is finally appropiate.

There seems to be a big focus on multi-channel access to MMO games, which is something we all know Java will excel at. Is there going to be a large push for getting Java technology on the client end as well? It seems to be added as an afterthought in those two articles that AAA games and consoles might play a part.

Is this a flat out push for a percentage of the games market as a whole, or is the policy to focus on a few areas and utterly control them first?

Also, just to say again, that this announcement has been made possible due to the efforts of several people, like Jeff Kesselman and Doug Twilleager, and of course, the java game development community. Nothing great is built alone and I am confidant that we have the right people in place that will make Java technology a focal point for the game development community.

Thank you all for your continued support. It gets REAL interesting starting.......now.

Way to go guys!!! I'm glad that you've managed to convince your employers that the next Java frontier is games. I was starting to get annoyed with YAWTDSC (Yet Another Way To Do Server Code). So, do we refer to you now as "The GTG Guys"? I suppose it has a ring to it. At least the the group wasn't called "Game Advertising Group of Engineers"!

Okay. So, a lot of what this new group is about is listening to game developers and getting things moving in the right direction for them. We have a lot of ideas about what needs fixing, but we would like to see our list validated and updated with input from all of you.

So, what do you want to see fixed? (With a new #2 pencil sharpened in hand)

> So, what do you want to see fixed? (With a new #2 pencil > sharpened in hand)

1.4.2 Beta brought some much needed performance improvements. It is now feasable to do 2D at resolutions higher than 640x480. So I guess I'd say, keep that working, make improvements to what is hardware accelerated by Graphics2D (i.e. primitives like boxes should be accelerated), MAKE FULL SCREEN WORK FOR X11!!!, and fix JavaSound. JavaSound I think is a bit embarassing. Here you have an API that's capable of awesome sound manipulation, it's based on HeadSpace which has support for everything from wav to MOD XM/S3M files, yet the volume control doesn't even work!

1) Combine the server and client VMs so we get faster startup followed by even faster running.

2) Provide a CDC J2ME profile based on this hybrid VM. Chuck out everything that's not necessary to make a VM execute bytecodes. Add everything else as optional packages. Adjust license to suit this arrangement.

3) Fold in those VM startup improvements that Apple have sorted out.

4) Don't be providing any APIs as "standard" like ImageIO or JavaSound. Let the community come up with APIs to solve problems instead of choking them off with a bloated alternative.

5) Add special feature that gives me Â£100 every time someone creates a new Thread and then complains when their animation runs weirdly.

I'd like to see lightweight objects in Java. And by this, I don't mean the structs proposal on the bug parade. I just want to get rid of the cost associated with temporary objects. I'm tired of making my code ugly to avoid doing news. Even if the GC ever gets fast enough that doing news of temporaries is a non-issue (it isn't there now), you still have the problem that following references is cache-unfriendly. For example, if I have

class A {float v1;float v2;float v3;}

I know that once I reference v1, v2 and v3 will also be loaded in the cache so accessing them will be fast. However, if I have

class A {Vector3f v1;Vector3f v2;Vector3f v3;}

I'll be jumping all over memory accessing v1, v2, and v3. I want v1, v2, and v3 to be inlined in memory just like primitives are. I want to not have an 8-byte per object overhead, just like primitives don't have. I don't want to be able to extend v1, v2, and v3, just like I can't extend primitives. I don't even want operator overloading. I want lightweight objects.

Improve the native code already used in the JRE. For example the JPEG decompressor and software blitting with alpha mask can all be accelerated significantly with SIMD instructions.

Reduce garbage generation inside the JRE, or the need to make temproary objects or copies to work with the existing APIs.. e.g. sometimes data from a Direct Byte Buffer must be copied to an array so that it can be passed to other APIs (e.g. JMF, ImageIO)

Improve JMF. It doesn't work that great or get much support from Sun.. but has great potential. It could be used to send voice chats to other players in a networked game, play cutscene animations, etc.

I think I disagree with Cas' #4.. The rich set of APIs is part of what attacted me to Java. If they aren't part of Java they won't get ported (because it won't be 'required').. if they don't get ported, there goes WORA. But I agree that there needs to be provisions to include only parts of the JRE, particularily if you are installing it only as a private JRE for your application, and not a system wide JRE. Extend WebStart to handle automatic installation of JRE subcomponents to the JREs that it is aware of. That way my WebStartable game can specify what APIs it needs and if the user doesn't have a full JRE they will only get what is required by my program.. the next program may use a different API and WebStart will only need to download that small subcomponent before the program can run...

Finish the support for hardware accelerated 32-bit sprites.

As above Improve JavaSound (all of JMF actually)

Make a place to register codecs with java.sun.com for JavaSound, JMF, ImageIO.. make sure there is a link from the JavaDocs to those registered lists. (e.g. someone reading about Java Sound should easily find a link to the Ogg Vorbis codec)

The worst problems in my last, quite comprehensive, Java3D project had to do with the JMF, Java Sound and Java3D sound integration, as well as integration between JMF and Java3D rendering. A robust sound implementation that works well with all the other media APIs would be a great improvement.

Another problem that came up on the horizon but never really affect my project in a serious way was again the lack of extensability in Java3D (specificly, the lack of shaders), but we all seem to be painfully aware about that one.

Better tool integration to support the graphics content pipeline would be nice, but the Xj3D folks seem to be doing a great job in that area and now it is mainly up to the 3D-modeller companies to start supporting X3D in a serious way.

I would hate to see Sun drop the productivity focus for Java and stop supporting libraries though, even if the libraries that are provided should be made more open and extensible. My most recent project is a great testament to Java and Java3D's productivity. I modelled a virtual world in Maya, built a new physical interface, scripted and recorded cutscenes and dialogue, wrote a 3D-engine etc. in just nine weeks, much thanks to all the APIs provided by Sun and the Xj3D group.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org