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 ).

Oops, my turn to forget my name. Arch@on you''re not alone with this

Yeah, that's what I meant: "collections" Okay, so you want JDK-cross compatability, right? If the amount of dependencies of these collections classes is minimal (i.e. helper classes, inner classes, etc...), than it should be easy to just include those classes in your distribution, allowing you to use what has already been made. But say that the extra dependency classes will make the distribution too large. Then I guess I'd understand the need to redo the wheel.

BTW I am still interested in the project ('course I don't want to spend too much time on it either )

JoeG

Edited by - joeG on 2/17/00 1:55:35 PM

The incompatibilities I am referring to deal more with classes that expect certain threading behavior to be present. If you were to remove that threading behavior I can imagine all kinds of chaos ensuing. You might have to make modifications to your single threaded implementations to take into account the expectations of the other classes. Future changes in the JDK classes might require more changes to compensate for the threading behavior expectations of those classes. But then again it might not be as involved as all that… I admit I am a pessimist about these things : )

I did have the wrong perception of your goal with GameFrame. I did not realize you anticipated it being a ‘black box’ technology. I was looking more from the perspective of GameFrame being an application framework or toolkit. Games would be constructed through sub-classing of default implementations.


Edited by - Jerry Lynn on 2/17/00 5:54:12 PM

Hey JavaNerd, I am just a newbie, but I like the sounds of your project. I don''t know if there really is anything I can do but if I can help you I''d be glad to.



-The beatings will continue until morale improves!

Just e-mail me if you are going to do this project.

BTW I already have some Java data structure classes based on the publisher Bailey's Java book. Can't think of its name right now. Vector, Queue, Stack, Binary Tree. They are all structured together very nicely. I think the best part of the project will be figuring out how all these 'different' classes will work together: i.e. some generic interfaces and classes.

Keep all of us informed,

JoeG

Edited by - joeG on 2/18/00 1:11:48 PM

Great! It''s good to know there are some interested persons out there. I''ll have to delay the startup to next weekend, but I''ll inform you then (via eMail).

quote: Original post by Jerry Lynn
The incompatibilities I am referring to deal more with classes that expect certain threading behavior to be present. If you were to remove that threading behavior I can imagine all kinds of chaos ensuing. You might have to make modifications to your single threaded implementations to take into account the expectations of the other classes. Future changes in the JDK classes might require more changes to compensate for the threading behavior expectations of those classes. But then again it might not be as involved as all that… I admit I am a pessimist about these things : )

I did have the wrong perception of your goal with GameFrame. I did not realize you anticipated it being a ‘black box’ technology. I was looking more from the perspective of GameFrame being an application framework or toolkit. Games would be constructed through sub-classing of default implementations.


Edited by - Jerry Lynn on 2/17/00 5:54:12 PM

Yep, you definitely sound a "bit" pessimistic but then again I''m often a "bit" too optimistic.

But I''ve just got to say that many of the classes I''m talking about are not interdependent. E.g. Vector and Properties are quite stand alone classes. Vector uses arrays internally which in my opinion might not be the fastest choise (because array access is so slow under Java). Properties has changed inbetween JDK versions annoingly. These are just two classes, but they are good examples of what is has gone wrong IMHO with Java. It has grown to be a Jack Of All Trades and thus many of it''s classes aren''t that usable for game programming or aren''t usable for multi JDK (1.1 - 1.2 - 1.3) programming.

I chose the "black box" approach as it really is the only way to approach making of several implementations of the same thing. So my game programming library doesn''t allow the user to subclass the concrete implementations. Heck, the user doesn''t even know which implementation the application is going to use at runtime. But that is just the beauty of it, you can have several (even native) implementations specific to different platforms and get the benefits of increased speed or fullscreen graphics etc.

The original reason why I started with all these different implementations was that I just wanted to have fullscreen graphics and ended up doing an Asteroids emulator that used different sound & graphics engines under JavaSoft JDK 1.1 and Microsoft Java 3.0. Then Java 2 came around and I noticed that the sound API had been changed (from the application point of view) and I had to implement a sound engine for that also. And so I noticed that maybe I should do all this stuff in some generic way and publish it as a simple 2D game programming library for the masses.