30 Nov 2014

Chess42

written by hunter | Tags: , , , ,

I couldn’t find a simple online multiplayer Chess game that (1) didn’t require registration, (2) worked on all devices, Mac to PC to mobile, and (3) wasn’t blocked at school for being a “game.” So I made one myself. Check it out.

A quick project. Probably 3-4 hours of work. Still not 100% complete but I’d call it finished enough for now. I might revisit it when I have more time, but what counts is that it’s functional and shouldn’t break. Moving on, let’s see the basics.
Name: Chess42 (pronounced “Chess for two”)
Language: HTML/CSS interface. Javascript (w/ AJAX) client-side. PHP w/ MySQL back-end.
Source: Here
License: MIT
Tools/Libraries: Cloud9 IDE. jQuery. chessboard.js for visuals. chess.js for move validation.
 
Then, the meat. Again, this was a quick project, so it’s a bit hacky, but I’ll still try to overview it all as neatly as I can. As far as functionality goes, it’s pretty basic while still being rather versatile. The key design goal was simplicity here, so you start on a landing page (no registration required) wherein you can choose to configure your game, or just hit start and go with the default settings. There’s really no need for configuration, but I just wanted to throw in the option of having the “host” (even though the back-end doesn’t differentiate between clients) be Black or White, alongside a couple toggles for the display (i.e. show PGN or hide it, and allow/disallow undos). While I was at it, I threw in a toggle for “sandbox mode” which basically shuts off all the rules and isolates the game from chess.js. This lets players make whatever moves they want, ignoring whether or not it’d be valid. Finally, a quick textarea for a starting position in case players want to pick up a game from somewhere else. It takes a PGN as input.
Moving on, you hit start and you’re transferred to a temporary page that you never see where all the loading takes place. This triggers the MySQL database to create an entry with a unique ID and all of the settings you configured. Then it pushes you to /play.php with some GET variables to indicate the state of the game. In particular, I pass the page the ID of the game, so it knows what game is being played, alongside the side (Black or White) that this client is playing as, so it knows how to orient the board. Beyond that, it’s all rather basic (and easy to hack client-side) database manipulation. Every time you move (the client restricts you to moving only your pieces, but a little playing around in the javascript console could, technically, bypass this) the game uses AJAX to POST the move (along with the ID of the game) up to the server. The server accepts whatever it receives, trusts that the players are playing fair, and updates the database entry for the game with that ID, replacing the previous position with whatever new position was sent up. The position variable is a string, and it can be formatted as either a PGN or a FEN string (since both chess libraries I used accepted those natively). For actual games, it sends up PGNs since that keeps the whole history, and we know the PGNs will be valid since the clients (should be) validating the game as they play. For sandbox games, it uses FENs since the board positions might not be valid, and all that matters is the position of the pieces.
While data is being sent, there’s a flag that causes the client to stop receiving data from the server, but after the data is confirmed received, that toggles back. Then, every 3 seconds, the client will GET the current board position from the server. That’ll be sent back, and the board will be updated as needed. Play then continues until both players quit. The game can be picked up later, so long as the URL with the proper game ID is saved by one of the players.
The only other particularly technical piece involves some @media tags in the CSS for a semi-responsive design. Essentially, if the screen becomes small enough that it’s conceivably a mobile device, all of the elements re-position and resize to better fit the smaller screen. With this method, I was able to play a full game on my iPhone very easily.
Overall, simple and straightforward. It accomplishes my purposes perfectly, and I expect to get some use out of it in the near future. That said, there are a couple of shortcomings. Some are easy fixes. For example, I don’t properly detect the newest move sent by the server, and, as a result, I don’t properly highlight moves made by the opponent (which sometimes means you need to look at the PGN below the board to figure out what the last move made was). Also, in the name of saving my poor, old webserver from crashing, updates are currently limited to once every three seconds. Even then, I’m not sure how many games I’d be able to run concurrently before the whole thing crashes. This results in a bit of delay after each move is made.
There’s one major shortcoming that would require a rewrite to fix, but it’s not enough of a problem (for my purposes) to merit reworking the whole logic of the game. Because the simplest library for move validation I could find was in Javascript, and because I wasn’t going to write a whole node.js server just to run this game, I do all of the validation on the clients. As long as players are honest, this isn’t a problem. But, especially considering I have a sandbox mode built in, all it takes is a very, very simple toggle in the console of most modern web-browsers to enable sandbox mode and allow ANY move to be made. Thus, if players are being dishonest, it is very easy to cheat. Again, however, I’m not particularly worried about this flaw, since I knew it was an issue from the beginning, but didn’t see it as a problem since I expect users of the system to be mostly noncheating players. And, if they do cheat, it’s not a problem, since it only affects them.
Overall, a successful 3 hour project.