In the summer of 2020, I discovered the Pico-8, what I consider to be a very neat piece of software. Its a small virtual game console, and comes inbuilt with code, sprite, map, and music editors, allowing anybody to create a simple game inside of it. After playing games others made on the Pico-8 for a couple of days, I decided I wanted to make something myself on it. Having recently been brought into it by a friend, I decided I was going to make chess.

Part 1: Preparation

The goals and guidelines I laid out for myself were simple:

Implement all modern FIDE rules of chess
Draw my own sprites and make my own music
Do all of the above myself, i.e. I wasn’t going to look at others work

I created simple goals since Pico-8 was new to me, and I this project was mean as a small, fun learning experience, rather than some grand creative ambition. To this end, I also spent a lot of time getting familiarized with the Pico-8, reading the online manual, referencing the wiki, and just messing around with the code of the demos included in the initial install. After a good week of learning, I decided it was time to start coding.

Part 2: Just do it

My philosophy to start was to just code, figuring out what I would do as I went along. This worked initially, and I got quite far coming up with ideas off the cuff. The way I handled the logic initially was I had two data structures, the game board, which was an 8x8 2D array, and a piece list, which was a growing and shrinking list. (Technically both game board and piece list were tables, which are associative arrays and the only data structure mechanism in Lua) Every type of chess piece - pawn, knight, bishop, rook, queen, king, had its own constructor, and stored data about what color it was, what moves it could make, and what position it had. Using this logic, I implemented every piece, their movement, a turn system, and even basic capturing. I was feeling confident, I had made progress! There were pieces on the board, capturing each other! This was going to be easy! Sure, there were some issues, but I would fix them soon! Seeing my progress, I figured I would leave it at that, and continue working on the project after midterms (most of the time I spent on this project was during fall quarter 2020).

The first major version of my Pico-8 chess. Very buggy! If the iframe isn’t working, you can also play here

Controls: Arrow keys to move selector, Z to select a piece, X to deselect

Part 3: It all comes tumbling down

After midterms ended I came back, excited to continue on my little pet project. I was able to fix most of the initial bugs. Then, I got started implementing additional chess rules. First up, the pawn’s diagonal capture. Since the pawn doesn’t capture like other pieces, it didn’t fit in the existing infrastructure I had set up, where captures were determined by where each piece could move. So, I ended up having to create a special move for each pawn, where it checked its diagonal neighbor. This special rule ended up being cumbersome and not very elegant, and I was beginning to see some of the flaws in my initial design. However, sunk cost fallacy was in full effect, and I decided to continue. Next was castling, and this is when I hit a metaphorical wall. No matter what I tried, I could never seem to get castling working without dozens of bugs. Castling is complex, it requires neither the king nor the rook to have been moved, the space between them to be empty, and the king to not move through or end up in check. These complexities just were not compatible with the existing logic I had. Growing frustrated, I decided to take a break and ended up making sprites. After doing that, I realized that what I had wasn’t going to work and that I need to refactor. But, not having the energy to do so, I told myself I would come back to the project later.

Pico-8 chess after making sprites. Still very buggy! If the iframe isn’t working, you can also play here

Part 4: Rebuilding

I ended up not touching the pico-8 chess project for a month, unwilling to put in the effort to overhaul everything. I was unmotivated, and no longer had that initial rush of excitement when I started. Eventually, I realized it had to be done at some point, and got to work. I decided to be more deliberate in my thinking and planning, not only considering what would work well for castling, but also future things I needed to do, such as en passant and checkmates. I ended up rewriting about a third of what I had previously had, streamlining my logic to allow for cleaner implementation. It took about the same amount of time I had already spent working on the project in total, but as soon as I was done refactoring, I was off to the races. I was able to quickly add castling, en passant, checkmates and pawn promotion. At that point, I had a properly working, bug free version of chess, and I considered myself done.

Final version of Pico-8 chess! If the iframe isn’t working, you can also play here

Part 5: Retrospective

For me, the Pico-8 chess project was a good lesson in planning and not rushing ahead. I got too excited to work on a project and started coding without thinking about how the foundations I laid would affect the future code I would have to write. It was also a good learning experience in terms of programming in general. Not being able to look at anybody else’s work meant that I had to be original when designing my implementation. I was also unfamiliar with the Pico-8 and so had to do a lot of documentation reading to get acquainted. I feel that I improved quite a lot as a coder from doing this project. One thing I will note is that I didn’t actually accomplish all of my goals for this project, the final version does not have music and the FIDE rules for drawn positions/draw by three-fold repetition are not implemented.