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:

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:

Status Update

I did all my initial development a couple of weeks ago, then got heavily involved in a project at my real job that prevented me from touching Chess Juice since. So far I have the basic board rendering at any resolution up to 800x800, which should be plenty big for computers and tablets. I've got the PGN engine done that can parse and replay a PGN game on the board as well. The server side will be storing all the games as just vanilla PGN files with ancillary data (like timestamp of last move) in a database. Next up for the board code is to allow making/validating the next move.

I'm still working out how I want the communication with the server to work. I'll likely just send up the PGN text - that's the easy part. How to send a move back to the server is the part I'm wrestling with. Sending the move in straight PGN/algebraic notation is obvious enough, but should I protect this with some sort of encrypted data to keep anyone from trying to hack a game? Seems like a reasonable thing to do.

Here is a screenshot of the board pre-loaded with a sample PGN file (don't pay much attention to the look of this page yet, just the board):