The Java FX Journey

JavaFX 1.2 released recently. Many of you may have seen my article relating to the performance increases, but I never went into the other benefits of this release, and why they’re important. At the time I didn’t do this because there are many good articles elaborating the features, so I thought it would be redundant. After some time though, I got to thinking that it might be useful for me to explain why I think JavaFX can make a good gaming framework/engine, and why the 1.2 release helps enable that.

A lot of people reading this will immediately think that this is foolish – JavaFX doesn’t have the power to run a true game. For a real game you need a game engine, like JMonkey or Slick2D. Perhaps there is some truth to that, as those engines have been built from the ground up to focus on making a game – that means performance, three dimensions, networking, etc… Don’t get me wrong, these game engines are good…some are really good, but there are some fundamental issues that limit their practicality – especially for smaller teams.

Let me put a little context to my discussion first though. My friend and I are starting to write a game which will end up being a Real Time Simulation game, similar in concept to Red Alert of Command and Conquer. We did a lot of evaluation, and decided that the backend of the game will be Java. With the JavaFX 1.1 release, it was a no brainer…we couldn’t use JavaFX – it was far too slow. With the 1.2 release, a lot has changed. So, it bore another looking into, and I think we’re going to try to use JavaFX for the front end of our game…and let me explain why the 1.2 release changed our viewpoint.

The language compliments the domain

This is a tricky one to explain, because some argue that you don’t need a new language, you just need a good framework. I argue that a framework is a language. But the reality is, a programming language can be quite complimentary to a domain language. Look at how Perl has blown up over the years, especially within the scripting. It is because the language compliments that domain well. JavaFX compliments the graphics domain very well.

One of the features in the 1.2 release that show this is the ‘mixin’ support. This is similar to multiple inheritance, but there are some subtle differences (although I dare you to try to find what they are). With mixin’s, we are able to splice together functionality from several ‘mixin’ definitions. For our game, this means that I can have a ‘Building’ and an ‘Offense’ unit both of which have functionality built in. Using mixins, I can combine those two to create an ‘Offensive Building’ – like a turret.

Several other language features, like Timelines and Tweening are built right into JavaFX. Many frameworks also have these concepts built in, but the languages they’re written in require a lot of boilder plate code and it starts to look ugly. With JavaFX, the code is short, sweet and makes immediate sense visually.

Rapid Results

One of the greatest strengths of JavaFX is the rapid results you get. Assuming you take the time to learn the language (look here and here) you will be able to code your ideas into a usable program in a fraction of the time it took with Swing. Just look at my ‘Blockz‘ game. I remembered a game from my childhood, couldn’t find it so I made my own version (literally) in a couple of hours. That’s ridiculous. By no means is the game perfect, but I couldn’t have had those results in any other Java based framework (unless I was an expert in it…).

JavaFX 1.2 provides you with even more tools and API’s to be more efficient. A great example of this is the Charting API that is now built in. In our upcoming game, I could easily show graphs of resource usage, land ownership, and several other attributes over the course of the game. The 1.2 release makes this easy, where as before, I wouldn’t have even considered this feature.

Quickly Evolving

The 1.2 release shows that some good thought has gone into JavaFX. Lets talk persistence. HTML5 introduces the concept of persistent data for Web browsers. HTML5 has been around as a standard for how long now??? How many browsers actually implement that? Persistence in the browsers is a long ways off (a few years, any way you cut it). JavaFX on the other hand was able to implement that in a point release.

No matter if I’m running in an Applet, Web Start, or on a mobile phone, I can now persist data from session to session of my application. What does that mean for me, as a game developer? A whole lot. When you play a Real-Time Simulation game, it can take hours. Very infrequently do you actually have time to sit down for hours to play the game…you have to save the game. JavaFX 1.2 gives me the ability to persist that save data no matter what platform I choose to run the game on. I simply need to use the Storage class to persist my data.

Its awesome that JavaFX was able to get this feature in so quickly. Its one of the benefits of having a single development team for the framework. And before you say “well, this will only work on a Sun JVM”, I’ve tried running it on J9 – it works fine.

Tools are Maturing

The 1.2 version marks the release of a decent Eclipse plug-in. I’m not going to say its as good as the NetBeans support, but its light years ahead of where it started. The Eclipse plug-in has drag-and-drop support, templates, built-in documentation, and auto-completion. Its still missing some things like a visual application developer, source code formatting, and ‘good’ inline support (there is still some quirkyness).

I would personally like some better ant support right out of the box, like NetBeans, but that was an easy fix. I am personally a big proponent of Eclipse support because I write all my applications in it. All my tools are built around it, I am familiar with it, and I just like it more. Now I can re-use my previous tooling when working with JavaFX – which is a huge bonus for me.

Speaking of NetBeans, there is a really cool feature, although I don’t know whether or not it is new. There is a ‘JavaFX Preview’ that will show you the results of the JavaFX application or node. To use it, go to Window -> Other -> JavaFX Preview. It will open up a window like the following, showing you a visual representation of what the node will look like. This is really cool for node development, because it updates in real time and shows you instant results of your code. This is nice because then you don’t have to build and run the application just to see how things look.

Better Integration with Java

Sequences are a great feature, but when they get big…they get slow. Often times, you want to use an array instead of a Sequence. Well, with JavaFX 1.2, you can access arrays natively (although this feature may have been there before, and I just stumbled on it). This gives you the speed and predictability of native arrays, and you get better interoperability with you core Java classes. Since our business logic for the game will be in Java, this helps tremendously.

Skinnable Controls

One area where most game libraries fall short is in their support for user interfaces. Typically, the engine is really strong with sprites, interactions, and some other things…but simple things such as text boxes and toggle buttons and that sort all usually need to be made by hand. Its something that really frustrates me. The behavior of the control rarely varies, yet I need to make a whole array of custom widgets to make a UI? Sure there are Open Source libraries out there to help, but a lot of them look bad and the support isn’t great.

JavaFX 1.2 introduces a wide array of new input widgets – and the best thing is that they’re skinnable.

This means that during the prototype phase of my game, I can quickly throw together the UIs. Later, when I want to make these controls look better, I just need to make a new skin. I get to keep all the logic but get to put a new face on it. This means that I don’t need to throw away as much code as I normally would. Equally important, I can focus my time on the architecture of the game, rather than coding the UI for it.

It has a community

All of the game engines I have used have a very small, but very dedicated community working towards it. There is no financial benefit (usually), but rather a pure dedication and desire to make a stellar product. They usually succeed, but over time interest wanes and the original proponents leave. With JavaFX, you have a very large, dedicated, paid team working on it – and that’s a very good thing.

JavaFX has a strong and growing community. Right out of the door, it had a stronger community than most (at least Java based) game engines could ever hope to have. Its amazing what a little corporate sponsorship can do.

On top of that, most game libraries have….well….terrible documentation. The forums are usually a good source of information, but its a real pain to look through the forums, dig into the code, and try to figure out something that you think should be simple. JavaFX on the other hand has great documentation. The API is well documented, there are plenty of tutorials, and (if this is your thing) an active forum. This is a really strong aspect that makes JavaFX really stand out from a lot of other engines. There is a clear drive to want to succeed, good support and a growing (and supportive) community.

All in all though…

I tend to be pretty supportive of JavaFX – after all, I’ve been blogging about it for 6 months. But let me not stray you unfairly. JavaFX has a lot of room to grow. Performance needs to be increased, platform support needs to be enhanced (although they now support OpenSolaris and Ubuntu), and more tools need to be created to support it. It is an amazing toolset, and I would advise you to evaluate it. Don’t let anyone fool you into thinking it is so great it will take out the dog and make your bed.

What it will do is provide you with an interesting new perspective on rich user interface development. We’re past the 90’s…text boxes, combo boxes and lists are old. We see them far too often today. But lets be honest, the future of good interfaces is in widgets, fluidity, and maximizing the users productivity. JavaFX gives you the tools to create a truly unique experience, and will let you re-use your existing Java code. To me, that is a pretty easy sell.

As far as the game goes, I have to at least try JavaFX. It doesn’t make sense not to. At this point my only fear is the performance. But, I know that will get better as time goes on – I’ve already witnessed a 300% performance increase. Worst case, I switch to Slick2D. Best case, JavaFX provides rapid development and deployment of the game and allows me to focus on what matters – the game.

This entry was posted on Tuesday, June 16th, 2009 at 7:55 pm and is filed under Java FX. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.