A horrific chess project

This is one of the many projects I made for my post-graduate game development course. It was designed to wrap two assignments in one project:
- Develop a multiplayer game
- Develop a web-based game
The goal of this article is to actually explain the motivation and technologies used and also serve as a simple documentation of the development process and conclusion. As a matter of fact, I didn’t even finish. I quit the game development because of reasons and I definetely plan to “finish” it when I have the time, but for now I’ll just explain what it does have. I hope what I have to offer below soften my teacher’s heart into accepting it.
ChessProject
Back in the days, when I was gathering ideas for the development of this assignment, I was really into chess. I was practicing it daily on this awesome platform and I decided I would try to write my own version of the game and see how that works out. Not only that but I was also getting acquainted with the Algebraic Notation format, used to describe the movements on a chess board and I decided to incorporate that into the gameplay as well.
With that added together I quickly got the concept for which I would aim. I wanted to develop a chess game that would be even harder to play digitally! Drag and drop would not be allowed. Instead, I would take a command-based approach and use the Algebraic notation as the method of input for playing.

The replay above illustrates the concept of the notation. Each movement is mapped to a textual representation on the right side. I will give some more examples so that this concept becomes clearer.
Simple movements:

Capturing a piece:

Desambiguating conflicts (two pieces can move to the same destination square):

It can get a little bit complex too:

and so on…
But anyway, with the concept of the game out of the way and taking into consideration that I have no idea how to structure this piece of work, especially given the unexpected time constraint, I decided to just enqueue topics of my interest. Let’s begin…
FEN (Forsyth–Edwards Notation)
Since chess has been around for quite a while, there have already been the need to serialize a given chess board configuration. FEN is actually a standard and its goal is to able to restart a game of chess from a particular position.
Below is an example for the starting position:

The FEN is an important concept that I will come back to later.
TDD (Test Driven Development)
Right from the start I decided I would try my best to actually implement this game using TDD. One of the things that I noted is that it is really difficult to actually implement isolated, truly unit, tests. Pretty quickly, I saw myself testing really instrinsic behaviors that required the colaboration of multiple classes. One time, I actually had a bug that failed one of these big, convoluted tests and after solving it, it got pretty clear that the unit tests were not that unityish. You see, one of the things that these tests are for, is that when something fails, it should be pretty explicit where the failure happened and why. Besides that, I think it gave me some experience and a clearer vision of TDD, for which I am really greateful. I was also able to integrate my project with Travis-CI and Coverall which resulted in a really nice badge for my project (I love those):

Backtracking Syntax Analysis
After that really brief introduction, you got to see that PGN is actually a very simple domain language. There is a hierarchical placement for each of the components that build to a command. That led me to try to solve these kind of problems
ex8=+
This construct is clearly wrong. The absence of a chesspiece in the beginning means that this is a pawn. The ‘x’ denotes a capture, 8 is the target rank and finally ‘=’ is the promotion sign that should be immediatelly followed by a chess piece, namely… Well, the plus sign is not a chess piece nor will it ever be.
So, what I aimed for was to make a simple syntatical analysis that would avoid errors like these by exiting early, so to speak. My solution was to implement a backtracking algorithm that would traverse a FSM consuming tokens from a stack. Each class (state) points to valid continuations and if the algorithm can’t reach an end state with an empty stack then the command is invalid.

Below is the algorithm responsible for finding the lexical match against an input, say: “exd6”. For each successor, I try to consume the tokens from the stack and if I am able to do so, I recurse to evaluate the next one. If it fails, I take care to restore the state and let the for run once again to get another successor. Pretty simple, actually!

Data Oriented Pieces
Another point that I cared about was the modelling of the behavior (read movements) of the pieces as data. This is done on purpose so that I could actually create other pieces to place in the game if I so desired with similar or made up movements. It is not hard to imagine the snippet below to be loaded from a xml configuration file:

Everything was modeled against MoveVectors, conditional repetition and movement prerequisites.
Phaser
Phaser is the 2D graphics game library that I used to actually render the pieces and chessboard onto the html. I didn’t actually play with it that much, only enough to make it do what I wanted. But it seems like a beast of a game’s library!

AWS Lambda
AWS Lambda is the service AWS provides for running code in the cloud. I used this service to encapsulate the logic for translating a given chessboard configuration and chess command to a new chessboard configuration or the error message that caused the command to fail. Given its low coupling, you can see that in action without any other tool.
Below is a screenshot from the JSON input. In this example I am testing my lambda with the fenBoard for the initial configuration in chess and the most first played command by white:

Here are the results of the execution:

Remember what I said about FEN being important? You just stepped on it. Lambdas are stateless by definition, so the guarantee that I can have a snapshot of the game in the FEN format and react to it accordingly (moving the pawn two squares ahead in this example) really play its role here.
API Gateway, DynamoDB, CloudFront
I’m not gonna go into details here.
- API Gateway: Used to route the HTTP requets to Lambdas
- DynamoDB: Used to store login information, match history and etc.
- CloudFront: Used to statically host the website along with S3 bucket(demo below)
Node.js, Express and JWT
JWT + Express was what made the backend work, basically ensuring that no unauthenticated user would be able to go through without login. Basically, I wrote an Express middleware responsible for authenticating users using a token. Node was the language of choice because I’m hearing more and more about it and I wanted to see for myself what all that fuss was about. It is indeed an incredible and powerful platform to get work done.
The END, I swear
If you got here, I think you deserve the chance to see for yourself why I named the article that way. This is one of the last prototypes I made:

If you are wondering what technologies I used there:
- <h1>, <h2>, …, <hn-1>, <hn>
- <input>s
- That’s it
After thoughts
I really struggled with all the concepts I learned, but looking back I feel like It was definetely worth it. There is a lot to be shown still especially because the demo doesn’t contain all of the features. Login, Match history persistence are some of the functionality that were left out. Mainly because I abruptly stopped the development. Sigh!
Here are the links for the ChessProject (Lambda) and ChessProjectFront. The last one has more backend, I really made a mess here.
Cheers,
Luís Copetti
