More screenshots

Here are a couple of screenshots of the progress so far. The top one shows a landscape mode screenshot from Chrome, the bottom a portrait mode screenshot from Android. To avoid accidental actions, I'm putting the game actions (resign, draw, confirm, cancel) into a dropdown so that you have to select the option then hit OK to perform it. Other actions will also be in this dropdown (like player stats) to conserve screen space.

Chrome Screenshot:

Android Screenshot

Notice in this screenshot that the board isn't quite the whole width of the screen. I'm not sure what is causing this yet, and it only seem to happen at random on the first page load - if I hit refresh then it fixes itself and takes the whole screen width. Must be a timing issue somewhere, but the load is all done in the jQuery ready method, so I'm not sure what it is exactly related to. I thought it might be related to the fact that the images may not be fully loaded when I go through the computations, but I would hope that the browser would show the images at the size I assign at runtime even if they were not fully loaded. I might try not generating the board until after the images have loaded to see if that makes a difference.

Android screenshot

Here is a quick screenshot of the play screen so far, as seen on an Android device:

GZip compression broken on Safari, Android?

I just tried testing the board page layout on devices other than Chrome on my Macbook, and had some surprising results. I use Tomcat for my app server for my java war file, and in my war file I have configured a GZip stream compressor I wrote years ago. Unknown to a lot of web users, browsers tell the servers if they support GZip compression for content, then the server can send the data back compressed for faster downloads. I just enabled this compression on the server side for .js and .css files, since the jQuery 7 .js file is over 100k. On Chrome this works fine, but on Safari on my Macbook and on the default browser on my Android phone the whole page broke. The reason seemed to be that those browsers were telling my server they supported GZip compression for those resources, but wasn't decompressing the data I sent down! I turned on the compression on my server for .js and .css files and, sure enough, the page started working again. Very weird, I'll have to report that to Google and Apple.

Server side data storage and access

One of the biggest issues Chess Buddies has is performances - far too often the app just gives up waiting on the server to respond to a request. As a user, this is frustrating to say the least. So if Chess Juice is going to be a better mousetrap, it has to perform really well. Toward that end, I'll be using a split data storage approach on the server. For games in progress, where performance is a premium, all storage will be done using Lucene instead of a traditional sql-based server like MySQL. Lucene is very fast for look-ups, which is critical for checking on new moves for example.

For archival storage, I'll use MySQL for all completed games, keyed by game number and indexed on player name. This should allow for reasonably fast look-ups even after the archive gets larger. A simple User table will hold the game number keys for all games that user has played.

So that's what I'm working on right now on the server side. Should have the core done by the end of this weekend, that's my goal anyway.

Status update - making a chess move

I was sort of dreading implementing the move validation because it's a bit tedious. But then I had an idea - since the javascript I'm using to validate a PGN file already validates individual moves, I should be able to just hook into that somehow. I need to mention that my PGN validator, jChess 1.0, was written by Ben Marini - thank you, Ben, wherever you are, you saved me so much work! I didn't have to reorganize much in Ben's code, and I now have a new move validator. All my code had to do was generate a new move in algebraic notation format, pass it in to the jChess PGN move validator, and catch any exception. Ben's code doesn't actually trap bad moves, it just chokes on them - so I just catch the resulting exception to know that the move is no good. Could hardly have been easier - whew!

Next up - server coding!

Chess pieces

The first thing I like to do when I start an app, particularly a game like Chess Juice,  is to create my core graphics. For Chess Juice, this mean the chess pieces. I am a horrible artist, and I cannot possibly stress horrible enough. So creating pieces from scratch was right out.

Next I searched for chess fonts, thinking I could use HTML5's web font facility to load the font to the page and then just use the font for the pieces since I could have the browser scale them to any size I wanted. Yeah, I actually thought using fonts for this was going to work. Now to realize why that was such a horrible idea if you didn't lol right away, you have to know that fonts make their little images by just specifying which dot is foreground color and which isn't. And by isn't I mean background color. But of course I need to put a white chess piece (which in a font is just a black outline and not filled in) on top of a chess board, so the color of the square just shows through. Ahem.

But I really, really liked the chess font I found, Chess Alpha 2. So I decided on an arbitrary maximum board size - 800x800 seemed like a good size - which makes the square size 100x100. I created the pieces at a size of just under 100x100 in Gimp, then filled in all the transparent areas with white. At runtime I then compute a real size for the piece based on the device the page is running within, and let the browser do all the scaling for me. Like magic, I get pretty nice looking pieces with very little work:

Development Environment

I'm a long-time Eclipse user for my java/web development. But if you look closely at the screenshots I've posted, you'll see I'm using Netbeans for developing Chess Juice. Now I'm not trying to start an IDE holy war here, but what made me use Netbeans for this project? Basically it's Netbean's context-sensitive support for CSS3, HTML5, and javascript - from my experience, it just blows Eclipse away in these areas. I prefer a lot of Eclipse's other features over Netbeans, however, and I use Eclipse at my real job so I won't be completely switching to Netbeans anytime soon. Still, Chess Juice is a lot of HTML5, CSS3, and javascript development, so right now for this project I'm really enjoying Netbeans a lot.