Javalobby is hosting an article series on creating *real* games in Java. The series runs the gamut of topics of creating a truly professional quality game in the Java Programming Language using the LWJGL (Lightweight Java Game Library) API which includes a native binding to OpenGL, OpenAL, FMOD, and native input routines. The goal of this series is to provide users with everything they need to make Java games that can stand up to their C/C++ counterparts.

http://www.javalobby.org/articles/game-programming/

Having dealt with all of the APIs and worked on a good bit of them off and on over time, LWJGL is hands down the easiest low level API to deal with. It lack of a modular API structure makes it easy to get up and running with minimal crap.

At the high end things somewhat spread out. I like jME a lot, but its scene graph is currently 'non standard' though that's changing. Xith3D isn't as feature rich as jME but if you're familiar with Open Inventor or any of the other professional scene graph APIs its far easier to get into.

I would be interested in seeing how this is done in jme.




Interesting because I just expected them to be scene graph objects so I'll be greatly interested when they change. Is this in CVS now? If so I'll do a cvs update and play around with that



Now you're just teasing me Whats the estimated time for the next release?





Cool. Would be interested in chatting with you as well. if you're open to some chatting, please PM communication options or just contact me. I think mine are public.

Is there a mechanism that does simple Rotation behaviors like Java3D? If on each frame I want an object to rotate on its Y axis by a specified amount, how do I do that? SpatialTransformer, suggested in another thread, seems more complicated than I would think necessary for a replacement to RotationBehavior.

I'm looking at SpatialTransformer and I have some basic questions about why it works the way it does. If I have geometry attached to a node, I would want to attach a SpatialTransformer to it. Not sure why I have to tell it the number of objects it would be transforming - it would be all of the nodes that are the children of the node that the Transformer is attached to.

Root Node
|_ Transformer
|_ Node
        |_ Planet
        |_ Node
              |_ Moon

By Attaching the transformer to the 'root node' I expect I should be transforming everything underneath.

Similarly, why would I be attaching objects to the transformer? setObject just seems awkward in this sense. I have to attach the transformer to the rootNode (which IS my pivot point) and then attach all of its children to the Transformer as well?

The other sets (position, rotation, scale) make sense to me. But I should be able to set a rotation based off a Vector3f as well (0,1,0) -> rotate along the y axis.

I guess what I'm saying here is that this use case is very complex when it really should be obvious and simple but in this case appears to be neither and will be harder to learn.

Rotation with the SpatialTransformer is far from simple unfortunately and I'm actually trying to get my head around the pivots and Quaternions of that example to make sense of them. If you want a simple "Rotate around your parent at this rate using this rotation matrix" there isn't anything simple.

Great thanks. Was surprised to not see a "classic" hierarchical animation example in the docs.

I'm writing a presentation comparing jME and Xith3D and while I could gather information about Xith3D with regards to putting together a related hierarchical scene structure I haven't been able to find similar for jME.

So here's the question. The scenario is drawing a simple:

sun->planet->moons

scenario. So I create a Node and attach a sphere for the sun. I create a Node and attach a sphere for the planet. I create a set of Node(s) and attach a sphere for each of the moons. I then parent them up properly to maintain the hierarcy. The question I have then is how do I specify position relative to the respective parent Node for the planet and the moons?

The sun is sitting in the middle of the graph. The planet is going to be offset from the center and I set a Vector3f() for its position when creating the sphere, but what coordinate system is that relative to?

Oh yeah, I know what Todd said. I also know where they are with the various consoles which is why I found it 'interesting' that someone would have said that they were currently developing for all the consoles simultaneously. I think people are inferring a LOT from some of the comments that are being made, but that's the status quo I guess.

Thanks. I would be interested in knowing 'who' said that.

The devs said they were developing for PS3 and Xbox2 and PC simultaneously?

I've talked to a few people interested in where you read this.



If this is the quote you're using - you (and gspy) may be reading a bit into things.

Yes you can very much run JOGL from SWT, though the mechanics of it is a little 'interesting'.

Can't help you with gl4java. All I can say is try jogl for a simple point drawing application and if it doesn't work post here and someone will be able to give you an answer.

If you're already using gl4java, you will likely find a port to JOGL pretty straightforward. Just give it a go and ask questions if you get stuck.

I've been conversing with their devs off and on because some of them are still friends of mine since I left the shop. I've raised my own personal concern that I hope that the game is close to the license and I've received many assurances that while they have no intention of remaking Fallout 1 or 2 in terms of playstyle, it should be a worthy successor to Fallout 2.

The team working on Fallout 3 is not the same team working on Morrowind, so some of the "Morrowind with guns" views of the game are unfounded - though they are VERY VERY early in their design process.

I remain hopeful that the game is something that is cool, although I have heard some things (from their press) that make me want to cringe

Tomas I'm having some issue just trying to get the framework to actually do something meaningful. Have you installed the framework and actually gotten it to work?

Depends entirely on the 'scale' of your server. If all you really need is a single box (and to be honest that's rare except for the smallest projects) then it doesn't REALLY matter what you choose. A MMOG rarely runs on just one box, it runs on a cluster of boxes with the application distributed in zones across those boxes and other boxes in there for fault tolerance. Once you start talking about all of this - Linux, BSD, and the other Unices like Solaris and AIX start making a LOT of sense.

Does Linux already have support? If so you just need to dynamic load the requisite libraries in the OSX GL core and it will work.

You are right in that it doesn't work. The surfaces do not get restored properly for reasons that I never really spent a lot of time investigating because I found it easier to in my window listener destry and recreate the context.

I used to have this a while back and patched this in my local version when I used to use JOGL. The problem is that the applet is trying to paint before the OpenGL context is actually ready to paint - its a semantic problem between Windows and OSX that can be solved by not trying to pack, size, etc. the drawing area until it is visible.

If you've got a sample of that you should send it to the developers. We haven't had any issue with the evaluation of rules taking different amount of times outside of the first run when janino is compiling our java semantic code into bytecode. After that, performance is constant if we send the same data through over and over and over agaain.



That's already done in the CVS head as best I can tell. Are you using the version from CVS or the beta-17 binary distro?

Most new development projects are done in subversion and that use is accelerating.

The one thing that we generally hate about it is having to create the extra trunk, tag, etc. directories.

Apple is still behind on this front as well. Its 'coming' but current support is very incomplete.

I unfortunately can't talk much about our particular uses of it, but when we went shopping for an engine - we pretty much knew that we weren't going to use  a custom engine for a variety of reason, much of which goes in line with supporting it versus people in that space who actually care.

I'm surprised you didn't like Drools. It took less than an hour to understand exactly what Drools was trying to do. There is so little XML in the system and even it is a bagillion times more intuitive than anything in Clips derivative Jess (there was a long debate, which is somewhat still going on, about the Jess/Drools decision). Drools is just an excellent architecture with its pluggable semantics. You could write your own AI language, plug it into Drools and Drools would function just fine. We liked our rules in Java, however, since we have lots of people who understand Java/C/Pascal/etc and that language syntax. It takes no time for someone completely unfamiliar with our system to be able to read our .drl files and understand what its doing and write new rules. That by itself was a major selling point. But then again our end product will have more 'regular programmers' writing declarative rules for our product. Your mileage may vary based on your use cases.

To be honest I'm actually amazed to hear anyone find Drools syntax to be difficult.



If you have a special case use for a rules engine, it is extremely easy to optimize for those cases - but they will have side effects that are bad for a more general purpose engine. Drools is a more general purpose engine, though I've been impressed with its performance. Drool's java semantics and its groovy semantic use janino.net's open source compiler to turn their AI rules into byte code so it will run pretty fast. When I talk about speed I'm talking about relative to a specialized engine for particular tasks. Most people will likely find Drools to be of acceptable performance - though its not the type of thing you'd call every frame

My architecture has the notion of a Planner which also holds WorkingMemory. While the game is taking place the planner's working memory is updated periodically for high level decisions and this causes the rules to fire and decisions to be made. The actions from these decisions is usually not defined in the rules - they usually just set a state that determines what an entities goals are. While I liked the idea of Drools giving me the functionality to put actual java code in the consequences and acutally giving me the ability to drive the game right from the rules - that isn't an ideal seperation.



Our use cases are the same though we didn't find it reasonable to put all game logic in the rules engine. Some things just work well that far seperated from the engine core. While we're weaving our rule engine in using Aspects (something its unfortunate that Sun doesn't seem to understand or use), moving stuff in and out of working memory, updating objects in the working store, and some light synchronizing of data makes doing everything in the rules engine somewhat impractical. Now maybe your use cases will point to something different, but for us after we tried and tried to make that the use case - performance dictated that putting everything in the rules impractical.

Let me give you a dump on using rules engine for games. We evaluated several engines including Mandarax, JESS, Drools, JRules. Drools and Mandarax are the only 2 open source ones that were really alive and showed some sign of what could be considered 'great architecture'. Mandarax is a backwards chaining rules engine, and that may not matter to you if you don't have a large number of rules (something that RETE is designed to handle well). Drools is a straightforward RETE implementation. Its semantic layer is excellent, allowing you to use Groovy, Java, etc. as the language for rule logic. JESS is 'interesting'. The syntax of JESS is just nasty, especially if you don't have a background in lisp like languages. I personally wouldn't want to touch JESS with a 10 foot pole, but that's not my decision. JRules is straightforward and has a lot more syntactic goodness than Drools. One thing that Drools does do , however, is compile the rules into bytecode using janino - which gives it excellent performance. In fact, its one of the faster engines we tested both open source and commercially. Drools is still somewhat young though, and its documentation needs some help. It has a fairly simply view of rules engines at the syntax level. However, Drools is certainly a very active project and the users list has maybe a 24-48 hour turn around on questions to the list.

Using a rule engine did bring about some very interesting questions which some people here may have already solved. Even with salience its sometimes difficult to get rules to fire in the order you wanted them to, and have the side effects make sense. In addition - rule engines are NOT the fastest things in the world. You can write custom code that will outperform any of the ones on the market right now... .but it will be a very custom solution.

I wouldn't really spend a lot of time screwing with JSR-94. Its an 'interesting' JSR, but when the rubber hits the road you will find it extremely limiting.

Jess is very very far from free. Get ready to spit out 10s of thousands.

Cg has not made it to OSX.

If you need to reach the board - send email to board@games-admin.dev.java.net.

If you guys need to reach me - you can AIM me at digitalsedition.

Hey blah - lemme dig up some information for you. I've been busy with some stuff and haven't even been looking at the board for the past 2.5 weeks.

That is correct. The only time that you can actually draw in JOGL is when the drawable is valid - and that's only in a small window during the display. Outside of that your calls will go to the JOGL equivalent of /dev/null.