I think it''s bad that noone, never, ever notices servlets, those little things that we never see or "use", perhaps this Msg board couldn''t be done without them, I think they are so called "killer apps" for Java... What comes to libraries, It''s not our or users fault that burgerplayer can''t play/install our games, Let''s take expample DirectX, could be compared to JDK (their main ideas aren''t same, not even close), but JDK tries to bring everything in one set, but DirectX is just interface. If Microsoft would distribute "Pure" VM as part of Windows I''d bet that Java Games would be more easilly installed. If I wanted to program games seriously I would choose C++(I used to program with that and I was almost good), but I want to learn Java as much as I can, because it''s new crossplatform technology.

Oh sorry last post was from me...

The company I work for, Jellyvision, uses Java for commercial game development. Our engine currently is used in two shipping products (one PC-only, one a Mac/PC hybrid).

We use a hybrid C++/Java engine. All hardcore things like playing sounds, playing animations, network code, etc. are done in C++ code using DirectX on the PC and gamesprockets on the Mac. This C++ code is accessible to Java via JNI.

The game logic is implemented in Java. Our games tend to be fairly linear and script-driven. We basically use Java as a supercharged script language. There are some Java components to the engine, but they are mainly related to abstracting native events and organizing thing. So we use Java as a scripting language and as a glue language.

We do this for various reasons:

1) We can whip out gameplay code much faster in Java. There are less syntactic hurdles and less busywork, and changes can be implemented more rapidly - this is necessary because design changes can be fast and furious while tweaking gameplay.
2) Our engine is cross-platform (currently Mac and PC). At the Java level, there is no platform-specific code.

Performance is generally not an issue, because the Java code doesn''t do that much in terms of hardcore processing. Most of the CPU time is spent in the native layer. All memory given to large media assets (sound effects, animations) is managed by our engine and not by the Java garbage collector.

The only setbacks have been the fact that JDK 1.1 is the latest version of JAva supported on all platforms. This prevents us from using some of the features in Java2 (the biggest one we want to use is the new collection classes in java.util).

The only packages we use are java.lang, java.util, java.io, and java.net. We do not use AWT or Swing for anything except some debugging windows that do not ship with the final product.

I would reccommend this approach for other types of games. Java is a more flexible language with a simpler object model and greater runtime flexibility (reflection, for example, can be used to cut down a lot of boilerplate code that would be needed in a C++ implementation). It is easier to train new developers to become proficient in Java than in C++, and Java is much more portable (given the subset we use) than C++.



-vince

Vince, do you mind if I refer to your company''s efforts in the article that I want to write?

I think you hit the nail on the head there by either using a hybrid engine doing the production solely in a java application the fact that java runs the same(almost) on every platform means alot to people like me who would like to distribute a game that runs on all platforms, for the fact that I don''t know or hehe to be honest take an interest in learning how to write things for a mac... The fact that applets can be accessed by virtually anyone now, just about everyone has a java capable browser unless they are living in the stone age, also means that more people can see your work with very little overhead by the designer.

The hybrid system sounds good.

I was wondering how easy it would be to change the interface to the external system though. If you have a JAVA applet access a C++ engine via ActiveX or whatever then how would you interface to say a linux or other platform which doesnt support ActiveX ? Could you JAVA code be completly independant of the particular platform engine being used ?

Thanks

Though it would definitely be possible to use a Java applet with a C++ engine through either ActiveX or Corba, the hybrid engine we are discussing would run as a Java application on the desktop with the C++ engine. Since the C++ portion is responsible for sound and graphics rendering, it would have to be local.

It might be possible to load the C++ component locally and then have the applet use the installed component for graphics, but I think any model that required the users to add C++ components to their desktop that were specific to one game would fail. Many users would have security concerns and the security policies of the local JVM would have to be modified to allow the applet to access the installed C++ component (something that would be too difficult and technical for a casual gamer to bother with). If the Java applet relied on some ‘standard’ local component, that might be feasible (i.e. WildTangent, Superscape, etc…)

Back to the hybrid engine:

I would think that the Java portion of the engine would access the C++ portion through native methods rather than through ActiveX, since ActiveX is still predominately a Windows technology and I believe the ActiveX interface would have more overhead than native methods would (please correct me if I am wrong). Even if COM for Unix and Linux made more headway native methods would still probably be preferable because of the performance advantage.

On the issue of platform independence: If you standardized the interface to the C++ portion of the engine, then I believe that you could make the Java portion of the engine ALMOST completely cross-platform. You would just have to swap out the appropriate C++ component for the platform. There may be some issues that would make this slightly less than ‘plug and play’, such as implementation differences in JVMs, but I think for the most part it would work.


Edited by - Jerry Lynn on 2/8/00 11:55:33 AM

We don''t use applets, we use Java applications. We distribute on CD-ROMs, so we just install the JRE in a subdirectory of our game''s dir. We use JNI.

There was an interesting article in Game Developer (I know, a rare occasion) about Java. There were two main courses of action (A) C++ program with a Java VM built in, and (B) a Java program with outsourced Direct X native support. One company used the latter with much success. Unfortunately, the project got canceled, but they became Gearbox and ended up making Half-Life: Opposing Forces.

Anyway, to answer the question, I think Java will bring back the days of garage game development. There isn''t a big chance some kid is going to come out with Quake 4, but he can still make games worth playing. The barrier of entry on Direct X and Windows programming is amazing. Just Windows alone will keep you up at night trying to figure out which non-english #define you wanted to use. Hungarian notaion is evil.

But Java is amazingly easy to get into. It is a great environment for a beginner programmer to get into. It is well structured, which is extremely important. Most importantly, it is perfect for small games. Can''t do Quake 3, but you could do Legend of Zelda. And the fact that Applets can be played online, convincing someone to download your program is easy.

For more advanced programmers, Java isn''t going to offer anything in its own environment that will help too much. It is a little more structured, and easier to understand and program, but by no means does it do anything that can''t be done anywhere else. Making graphical tools is actually a little quicker, I think. Java may, I think, provide enough structure that more complicated games could be more complicated with less bugs. Ultimately, that is up to the programmers.

I''ve had a peek at the Java3D docs, and it looks amazingly easy to use, and extremely powerful. It isn''t made for game programming, but it is at a level of abstraction which could lend itself well to games. I don''t know any 3D programming, though I''ve looked into Direct X, OpenGL, and Java 3D. They all look pretty good, but Java 3D is the most abstract. Good stuff.

Finally, Java isn''t about performance. You can''t make wow graphics games. Particle systems are going to be out of reach. Scrolling will only take place in small windows. But, in situations where the majority of the game takes place in the logic, Java will work out just fine. I think RPGs and Strategy games almost lend themselves to Java. You could probably make a neat platform game...but you''d be limited in the size of your graphics, and probably would have to withdraw any parallax scrolling ideas you have.

I think single screen, non-scrolling, games could be fast enough for a dozen moving onscreen objects. I''d wager that you could recreate (for example) the gameboy Legend of Zelda, or Puyo Puyo.

There are particle systems and behavioral modeling in java. I''ve never seen them in an actual game, but that''s probably because i''ve never actually seen a game in java (that wasn''t go or connect 4)