quote:Original post by Jerry Lynn
I can see the justification for writing replacement classes if one was doing so as part of the development for some proprietary engine. Say for example, if you were going to use a Java based engine for several commercial products within a particular game development company.
But if your target is to provide an open source game development tool for the masses I think you would want to stick to the standard Java technology as much as possible.
Your game toolkit will probably need to be flexible to allow developers to integrate it with other Java technologies, such as sound API’s, Java 3D, Java 2D, Input Device related API’s… Attempting to ensure compatibility between your replacement classes and the large number of other Java class sets would be a major undertaking. With a proprietary engine you would know exactly what technologies you need to support to build your products. With a toolkit aimed at a mass distribution you risk making the toolkit unusable to a lot of developers if you place limits on which Java class sets you can integrate with.
Your replacements may have compatibility problems as soon as the JDK was upgraded. You might be putting yourself in the situation of trying to keep the replacement classes compatible with the most recent releases and java extensions. This wouldn''t leave a lot of your time for the development of game related functions.
Just my humble opinion.
Hmm, your message really gives me something to think about.
But if you look at the way the Java VM has changed during the last five years, it really hasn''t. SUN has kept it their goal to NOT change the VM if it isn''t mandatory. The bytecode is still the same, just some class file flags have been added, but even then backwards compatibility is preserved. So if I wrote my own set of classes from the ground up I think I could rest assured that they''d work on the future Java VM''s.
The idea of these replacement classes would be to make the game programmer free of the runtime JDK version problems. Of course that would mean settling to some subset of the JDK classes, but that is to be expected. What this would mean is that the programmer wouldn''t have to worry about the tiny (and oh so annoying) differences between the JDK classes.
The idea behind GameFrame (as it is provided) is to offer easy access to game programming and to enhance the experience under some runtimes. That means I''m targetting the hobbyists, beginners and the like that don''t want to spend half a year just making some graphics engine to work. And believe me as a hobbyist myself, half a year is quite a short time for this kind of thing and you need one more half-a-year to make sound work both under JDK 1.1 and JDK 1.2. Many of my own projects have ended prematurely just because I got fed up with making the low level things to work. The only reason GameFrame exists is that I haven''t been aiming at making a game, but a library and I''ve had my previous source codes to draw upon. Trying to reach both targets (game+engine) is too heavy requirement for many. Doing a game is difficult task in itself (idea development, planning, graphics, sounds, logic etc.).
If someone wants to use GameFrame with e.g. Magician or Java 3D they can do that if they just get inside the source code, but that really requires a whole different level of knowledge. As is required by the aforementioned APIs anyhow. It would be next to impossible to implement as flexible game library that one could use it with everything under the sun (no pun intended
).
)
