Just buy AgentFX I’ll solve all your problems ;D … or try the PLE.
// Tomas 
On the prototype thing and experienced programmers this is a technique documented in software engineering books and the way it is use has little to do with the way it is used in other areas. Still it is recommended in complex tasks. A plugin architecture is also recomended when the application is complex and modular in nature and will get benefit from many upgrades.
Since i never made any game engine i’ll go by the books on software engineering made by experienced programmers who have recognized work. When facing a complex problem what an experience programmer shouldn’t do is to think that he is good enough for anything.
If you guys think you are good enough for anything then i can give you a design doc for a reasonably complex game. I can give you maps, dialogs, detailed huds and interfaces, even game logic details and then we will see how you will do when things start geting hard. This is not a scroller or a simple platform game, its a fully 3d game with douzens of pages of dialogs and intrincate rpg style gameplay. So if you can take this then you could say you can take anything.
" Zingbat, have you thought about using Xith3D? That’s already nicely abstracted out into user, scenegraph, and render code. Why not write yourself a software renderer to test the Pure Java codepath, and reimplement the scenegraph packages in C++ to test the Native Scenegraph codepath?"
Yes. I also looked into the monkey engine. In fact we could consider many of the interfaces as given a subset of the benefits of a plugin architecture without the complexity. I need a complete plugin architecture however and thats the why i have stay away from those apis.
A reasonably good plugin architecture (don’t mention Photoshop plugins or any of that sort) means that plugins can be loaded without having to reinitialize the game. It also means that plugins can be initialized and loaded any time in the execution of your app.
Another advantage of using plugins is that you can make manage and automate tests a lot better.
Yet another advantage is that you can copyright your plugins plugins with the GNU copyright while profiting from other plugins. For instance you could copyright your core engine under the GNU license and take your profit from selling the content and the specific game plugins. The users are allways free to choose if they want to run a plugin or not without messing with the code.
So in short a plugin is not just a programming feature like an interface with a dynamic behavior. It also has to do with testing, copyrights and the freedom of the user to choose what plugins he wants to run the game with.
Um, but how is this related to the Open Scene Graph, and more to the point, how is this news?
I’m not trying to be arrogant or ignorant, just I’m trying to work out what point you’re trying to make?
Kev
[quote]Um, but how is this related to the Open Scene Graph, and more to the point, how is this news?
[/quote]
Fully agreed.
What has all this talk to do with the Open Scene Graph?
The screenshots of the various games/projects using the OSG look very impressive. Also there’s a long list of importers/exporters for various 3d formats including Lightwave. Looks very professional indeed!
So somebody using OSG with the Java binding could share his experiences please. Or his ones with the Java binding which has been done by Noodle-heaven (a funny name and yes I like noodles).
Please stick to the topic, guys. 
I was just being polite by providing an answer to the previous posts.
As for Open Scene Graph my point is with an heavly customizable engine by using modules and plugins we have the choice to choose whatever we want to use and whener we want to use with our engine. Besides we can benchmark (not micro-benchmarks) our plugins and modules simply by switching to a different plugin and running the same tests in the exactly same environment we are building our game.
That’s the reason why i pointed out Open Scene Graph. I would also point out the SDL binding or a binding to the Irrlicht engine. Even if people don’t wish to use C++ code and prefer to do everything with jogl or lwjgl (which is a reasonable atitude) you can allways use one of external C++ apis i mentioned, which are proven high quality, to do high-level benchmarks to thecode and comparing the performance of those apis. It’s also possible to do useful prototypes, not just prototypes to measure complexity and then throw away.
But of course that to do an high-level benchmark you will also need a game. It could be anything for the purposes of testing that will have the same performance demands and quality requirements of any other commercial game competing on the market today. So my proposition for giving you guys a design doc already game for a complex 3d game is still up.
Look people talking is nice and we could be here forvever debating all kinds of stuf but i have an interest in developing games in java like the ones i mentioned before. So if anyone wants to implement a plugin architecture in Xith3d or the monkey engine that will allow us to dynamically swap modules at runtime without reseting the game i have a couple of ongoing projects i can contribute to the java gaming community (gnu license): like a software rendering engine im doing for tests and compatibilty purposes and i can also start developing the game i mentioned before (in case no one else has the balls ;D ) for which i already have a complete design doc. I could have done the plugin architecture myself but i won’t get any free time for another project in the near future.
[quote]So if anyone wants to implement a plugin architecture in Xith3d or the monkey engine that will allow us to dynamically swap modules at runtime without reseting the game i have a couple of ongoing projects i can contribute to the java gaming community (gnu license):
[/quote]
It’s already there - the java ClassLoader, that has little to do with actually loading classes. All you need to do is make a new one and kill the old one, basically (gross over simplification, but the API’s reasonably well documented. Probably cause a lot of headscratching if you’ve never used it before…)
IIRC JOGL is already using multiple classloaders (?) to some extent somewhere, I recall seeing stuff about it in the games.java.net CVS repository…
Making your engine render to Xith should be next to trivial, assuming you wisely already based it on an SG and you didn’t have a really strange SG. You should be able to do it in one lazy Sunday. I would guess most java game devs could actually do it in 4 hours or so. At least, that’s my personal experience from faffing about converting old scanline java renderers to Xith (just toy examples, but the amount of wrapping needed was very little - mainly the effort was in fact in cleaning up and refactoring/improving my existing code, and fixing naughty design shortcuts I shouldn’t have used in the first place :))
I presume that a jME conversion is similarly quick…
I don’t have such an experience on working with software rendering engines so it will a little longer, probably a lot longer. ;D
The plugin archhitecture i need is more complex than that. It requires a simple process for the end user to be able to disable/enable, install/uninstall plugins at will. The end user may be a player who knows nothing of programming but can, at least, edit a text file and copy files with the explorer. Alternatively the end user could be a developer that is building a game for a new version of his renderer that is almost 100% content compatible with the previous version but since the new version is still in development (and thus unstable) the artists can start working with the old renderer right away.
It also has to be completely transparent. That is you get the renderer interface with a factory method and you are not required to explicitly destroy the class and create a new one. That renderer just delegates its call to the real renderer that is invisible to the game code. The user can be switching renderers at any time but the game code is allways working with the same delegator class while the switching process happens transparently, maybe with a slight pause depending on the circunstancies. Alternatively the engine code can force a list of choices for renderer plugins and deny others.
This is probably too complex to go on without a UML diagram and a precise defenition. Anyway i was hoping someone already made something similar.