JavaFX: Looking even better

I was surprised to get a quick response to my forum post, on a Sunday afternoon yet. The response contained a solution for my unresponsive-objects problem (see below), and almost completely fixed it. I've seen the symptom recur now just once or twice in a 90-minute session, and it never persisted for more than a minute. I suspect that these remaining minor glitches have a different cause, and quite possibly are just due to my system being busy doing something else for a moment.

My virtual gameboard is now actually usable, and I played a complete game of Hammer and Spike with it in just 90 minutes. I am very pleased.

I still have more work to do: adding features, cleaning up minor bugs, and finishing the documentation. But one of these days, hopefully soon, I will make it available for others to use.

JavaFX: Looking better, but...

I took vacation last week, and spent some of it working on my JavaFX virtual gameboard app (still inadequately named "Placer"). I've resolved some of the problems that were worrying me at the time of my last post: the exceptions are gone, the design and code are cleaner, the feature set and UI of the app itself have improved. I've figured out how it can be deployed, too, although unhappily it must use Java Web Start and requires the user to have a fast Internet connection (at every launch! Why won't Sun give us a better option?).

But my biggest problem remains unsolved. Sometimes, some of the objects in the window (cubes, banks, other clickable or draggable things) simply stop responding to mouse clicks for a while. This is mystifying because of the apparent inconsistency of the behavior. For example other objects in the same window remain perfectly responsive and well-behaved while the frozen ones continue to ignore the mouse. And a frozen object will often spontaneously unfreeze later on; but the period during which it remains frozen can be anywhere from a few seconds to many minutes. I have circumstantial evidence suggesting that a frozen object is more likely to unfreeze soon if I drag some other (and obviously more responsive) object over the frozen one; but this certainly does not always work, so it may be coincidence.

Until this issue is cleared up, the app is not viable. When objects freeze up like that, the app becomes effectively unusable. (It's okay if objects freeze up when you don't want to manipulate them. But you only notice that they're frozen when you do want to manipulate them, which means that your game is stopped until you can unfreeze the things you need to move.)

I've joined Sun's developer network, and posted in their JavaFX forum about my problem. And now I have yet another thing to wait for. I'm spending a lot of time sitting by my virtual phone these days, waiting to hear from game publishers, CD makers, and now helpful JavaFX gurus. It's getting old.

JavaFX FTW?

JavaFX is yet-another-scripting-language. It promises that you can quickly create Java applets and applications with fancy visual effects by writing simple little scripts instead of miserably complex Java code. Does it deliver?

I was sic'ed onto JavaFX at my day job, charged with whipping up some cool new UI mockups. I quickly became fascinated. You can accomplish a lot with a little, using JavaFX. But that's not enough; I need to find out whether it can create industrial-strength applications, and if so, whether the code is readable and maintainable, and whether the UI it produces runs quickly and is responsive to the user.

I won't go into my day-job's proprietary stuff here. But (just in order to learn, you understand) one of the first things I did was start building a virtual gameboard. It went so well and so quickly that I've kept working on the project at home on my own time.

What is a virtual gameboard? I wanted a tool to quickly prototype a new game idea on the computer, without having to spend time and money assembling physical pieces. I wanted to be able to play the game (by myself, as I always do with new game ideas), change the rules and pieces, then play again, with rapid turn-around time on the changes. I also wanted play to go at least as quick as it would with real materials. I called the tool "Placer" because it will let me place things on a virtual gameboard. (A lame name, but it doesn't need a better one at the moment.)

Placer lets you specify an image file for the gameboard, which it displays in a window. A tool-palette area is automatically provided to the left of the board. In the palette are templates: If you see a red cube in the palette, for example, you can click-and-drag on it. It will produce a copy of itself (another red cube) that gets dragged away under your mouse. You drop the copy (called a "token") anywhere you like on the board. The template stays put, in the palette, and can be used again and again to make more tokens. A template is therefore a sort of virtual, limitless pile of its particular kind of token.

Placer is configured from a text file, in which you can specify a wide variety of templates for the palette: squares and rectangles, circles and ovals, cubes, disks, and more. Each one can be given a color, so you can have (say) four templates for the cube supply of four different players: one template each in red, yellow, green, and blue.

Tokens on the board can be moved around as much as you like. They can also be rotated, and each has a little popup menu that lets you delete the token or get a little information about it.

There are a couple of fancier kinds of tokens. One is the Bank, which displays an amount of money. Click on it to make a withdrawal: a small text box appears, you type in the amount to withdraw, and the Bank creates a new Cash token under your mouse. The Cash token displays the amount of money that you withdrew, and you can drag the Cash off to wherever you want it to go. The Bank stays behind, now displaying the balance that remains after your withdrawal. If a game uses money, you can create a master bank for the game, and then give each player a bank of their own. When you drop a Cash token onto a Bank, the Cash disappears and its value is added to the Bank's balance, making it easy to transfer money among the players. (The image shows a $13 bill ready to be dropped onto the Red player's bank, which currently contains $42.)

So has it been all kittens and rainbows? Nope, it hasn't. As is always the case with Java or anything Java-related, layout (that is, getting everything to be in the right place) is a major pain. JavaFX features coordinate-system manipulations that you must use to get anything significant done; no doubt they are very powerful and carefully thought out, but it gets very difficult to keep it all straight in your head (and your code) when you're writing something complex. Event handling is a bit tricky, and seems not always to work as advertised: sometimes my tokens simply ignore clicks and drags, with no clue as to why. (I suspect the garbage collector, at the moment.) And then sometimes JavaFX just throws a huge exception, stopping my app cold. It seems to be because I've coded something wrong, but I don't (yet) understand why I can play half a game of Hammer and Spike before it suddenly decides it doesn't like me.

Another issue is deployment. Suppose I finish up Placer, and want you to use it: how do I give it to you, and how do you install it? JavaFX isn't really designed for building stand-alone apps. You're supposed to access JavaFX programs via the Internet: as browser applets, or mobile device apps. It does provide a way to use WebStart files to deliver a desktop app, but these may have Java sandbox problems, which would be a killer for Placer: it has to be able to read your config file and board art.

But we'll see. I'm not done playing with it yet!