I’ve been making slow progress on refactoring my code to play checkers in parallel. In fact, it’s not merely to play in parallel, but in fact, more like simultaneously. Parallel implies that games going on simultaneously have nothing to do with one another. That is specifically not the case. Instead, all X games make the first move essentially in unison so that the forward prop of the model can generate predictions for that first move with one matrix. Then the second move occurs in unison so the model can do the same for the prediction of the second move. And so on.

There was a point a day or two ago where I had a major pivot in my approach. I had been trying to keep as much of the overall architecture as possible, meaning that I was trying to change as few methods as possible in my various classes, (Checkers, Game, Player, Board, Model, Piece). This was in the naive hope that I wouldn’t have to revisit how all those methods worked, and could instead focus on putting some sort of a layer on top of it all. That has proven untenable, and in fact more difficult than the alternative.

So instead, I’m getting my hands dirty and breaking up and changing the methods in those classes to more closely align with an architecture that needs to fundamentally change to play games simultaneously. It’s somewhat tedious at times, but I’m glad I’m doing it. I’m commenting the crap out of this code, and in the process, thinking through the architecture in a way that I really couldn’t the first time through when I was still just figuring things out.