Games, Physics, JavaFX #devoxx

Games, Physics, JavaFX #devoxx

We just finished our talk here at Devoxx called “Gaming JavaFX”. The talk was scheduled for Friday morning and we wanted to do something really fun and a bit lighthearted, but also really practical. Earlier this week James Gosling had a talk about the Java Store, and we wanted to provide some momentum to the idea that you can write really fun and interesting games in JavaFX and then load these up into the store.

Jasper posted a preview teaser earlier in the week of our Dude with a bomb. You’ll appreciate watching the talk at Parley’s when they have it posted (or you can pay Parley’s a few quid and see the talk even earlier).

Dueling Sketch

The game we wrote is called “Dueling Dudes”. Its a non-scrolling side shooter, not unlike some other popular games like Scorched Earth or iShoot. Except we decided to replace the tanks and earth with dudes and boxes. We placed it in a warehouse and gave each box & barrel physical properties, and gave our dudes weapons and the ability to bash the terrain around. It was tremendous fun. I once read that every programmer should write a game at least once a year just for fun and to keep that youthful exuberance. I couldn’t agree more.

Technically it was a very pleasant and fun thing to work on as well. Integrating the physics engine was not very much work, and using a scenegraph to model things was very natural. We drove things mostly from the engine and a few well placed binds and a single Timeline which drove the world. Jasper pretty well wrote the whole thing over 3 days. Here was our secret equation for success:

Equation For Success

We’ve hosted the game here at FXExperience, hope you enjoy playing it (and if you have troubles on your machine configuration we’d like to know that too!).

DuelingDudes

Click To Play

Enterprising JavaFX @ #devoxx

Enterprising JavaFX @ #devoxx

In a couple hours Jasper and I will be presenting a talk titled “Enterprising JavaFX” at Devoxx. The main purpose of the talk is to describe how to use JavaFX for writing enterprise application content. Here’s a quick teaser screenshot of one of the apps we’re going to describe:

Jira Dashboard Application

Jira Dashboard Application

We’ll be writing some additional blog posts over the next few weeks describing various tips n’ tricks as to how we used web services in this app, how we wrote the custom list cells, and so forth.

Come see cool stuff at “Gaming JavaFX” @ #devoxx

Come see cool stuff at “Gaming JavaFX” @ #devoxx

bombdudeCome see a cool new game we have written on the current JavaFX release and learn how we wrote it. We’ll even post a link to play it online, though I might have to save that till the end otherwise all I will hear in the room are explosions coming from every laptop.

Gaming JavaFX
with Jasper Potts & Richard Bair
Firday 20th Nov  9:30am
at Devoxx

For those unlucky few who are not attending Devoxx this year, you will be missing many great things. We will post the game and some blogs about it over the next couple weeks and the recorded talk will be available early next year online as a video.

Hope to see you there 🙂

Function delegation

Just a quick post here. Found another example in Popup code that can be cleaned up and wanted to share. Here is the original code:

[jfx]
FX.deferAction(function() { doAutoHide(); });
[/jfx]

This line of code is going to use the FX.deferAction function which takes as a parameter a function with no arguments and no return. (FX.deferAction is essentially like SwingUtilities.invokeLater(Runnable)). However, since the doAutoHide() function already has this method signature, I can avoid creating the anonymous function and instead simply do:

[jfx]
FX.deferAction(doAutoHide);
[/jfx]

Much nicer.

Node Lookup

The Node class has a lookup function which is used for finding a node in the scenegraph based on an id. Every node has a String id, similar to HTML. In theory it should be unique within the scenegraph though in practice this isn’t necessarily the case.

This lookup function currently only operates over the “public” or “logical” scenegraph, not the physical one. For example, a Button is a Control which delegates its visuals to its Skin. The Skin has a sub-scenegraph. But since we typically want to encapsulate all that, we hide it from the programmer such that most things don’t find this part of the scenegraph. Seems like a reasonable thing to do (Swing went the other way and all the gory details were public which led to issues sometimes where people would dig around and rely on internal details — the horror! — and this made it incredibly difficult to fix bugs later in Swing).

CustomNode was our level of encapsulation. Any CustomNode’s children was explicitly not part of the public API. However, a number of people have complained, likely because they aren’t using CustomNode for encapsulation but rather for modularization of their source code (ie: break a huge file into several files where each piece extended from CustomNode).

So it seems like this partitioning of “logical” and “physical” scenegraphs is quite confusing at times. So the question is, should the lookup function operate on the physical scenegraph? Vote!

[poll id=”2″]