jME: Professional contributions

As most of you know, my day job as of early this year is working on game technology over at NCsoft Austin. In terms of jMonkeyEngine contributions from me, this is good and bad. The upswing is that I no longer have to split my time between a boring job in financial software and my true passion. jME is also getting a whole lot of experience in a professional environment and subsequently a good deal of polish.

On the down side, my employment at a professional game company means I am developing and working with a lot of cool stuff that - for competitive reasons - may never get contributed to jME. That is fine and makes a lot of sense to me from many angles... Some technology is very game specific and does not really belong in the jME core. Other technology is company goal specific and is essentially the trade secrets that allow a company to achieve specific goals ahead of other people. I'm all for that because it provides incentive for a company to risk the large amounts of money required these days to produce a top quality game.

All that said, I do have a certain philosophy regarding contributions from commercial companies - including the one I work for. It is my belief that with the Java Game Engine market currently in its infant stages, it is beneficial to everyone involved to cooperate on core java engine technology. There are still a good deal of features that are common to other professional game engines that jME lacks. These features are not trade secrets or necessarily advanced, and by developing and contributing these features a company can get many benefits in return.

First off, jME is a very active and - in most cases ;) - intelligent community. Donated features are always being freely bug tested and improved upon by community members. Secondly, donating a new feature gives a company the ability to set a direction or a standard in the community. Assuming the donated code is high enough quality and is accepted into the core, the donated code is now the "jME way" of doing things and improvements will likely spawn from that base. Finally, companies donating code reap good will from the community and influence others to consider contributing code as well.

At work I've personally stuck my neck out several times to push this strategy. We are a very small team and I believe the benefits I mentioned above could offload some bugfixing and polishing while also just being "a good thing." In the next week or two you should see the results of my pushing with the contribution of a Collada importer and a Bones/Skin system. Other companies using or considering using jME, I invite you to likewise participate. You'll be glad you did.

I'll definitely look back at this in a future blog post, so stay tuned.

Work: Play Tabula Rasa

We've been play testing NCsoft's upcoming MMORPG Tabula Rasa at work lately and I've got to say, it's a winner. It's visually impressive (I hope you have a nice computer) and the gameplay is fast-paced, unique and solid. I'm not sure how much I can say about it, so let me just say it feels like a cross between WOW and UT with a definite Garriot touch.

Keep your eye on this one.

jME: Threading, Future and Callable

As I've posted before, OpenGL is a state machine and as such, instruction order matters. In my opinion that is why only single threaded OpenGL usage is guaranteed to work. Unfortunately, there's many times when constraining yourself to a single thread is difficult or impossible. So what's a guy supposed to do when he needs to access OpenGL from another thread?

Up until this past weekend, the solution was a custom jME interface called RenderThreadExecutable and a queue called RenderThreadActionQueue. These classes simply allowed you to implement functionality and save it to be run later by the thread holding the OpenGL context. This worked fine, but as pointed out by another jme'r by the name of darkfrog, it duplicates functionality already in Java 1.5 and above.

Make way for Java's Callable and Future interfaces. The Callable interface is not unlike Runnable or even RenderThreadExecutable (which was basically the same as Runnable, come to think of it) but with the added ability to return a generic result and throw an exception.

The Future interface combines with this to allow you to monitor if a given Callable task has been run or cancelled yet and gives you the ability to cancel and receive a result (or exception) from that task.

Here's a sample bit of code:

Callable<?> exe = new Callable() {
public Object call() {
if (renderer != null)
renderer.reinit(width, height);
return null;
}
};

You can then stick your Callable into a queue to be run later via jME's GameTaskQueueManager. The manager has RENDER and UPDATE queues for running your Callable during those game logic loops, or you can define your own. When you add your Callable, you'll get back a class that implements Future called GameTask.

Future<?> task = GameTaskQueueManager.getManager()
.getQueue(GameTaskQueue.RENDER).enqueue(exe);

Then you could do something like wait (assuming you are in a different thread) until the task .isDone() or you could decide to try to .cancel() it, etc.

All in all, I think this solution gives us more flexibility and control over our tasks. Look for it in jME .11 when it's released or in CVS if you want to play sooner.