Dev Diaries - July 21, 2018
This is a short update about all of the hobby projects I have in flight. I’m mostly writing this as a way for me to keep track of what’s next on each of them, so I can decide what to work on next. 😀
Glish
The core language is working well enough that I’m ready to start working on my first real Glish application to help design the other language features. The first application is a board game engine, where Glish is the repository of game rules and a web application is responsible for collecting the actions from the players and showing everything.
Since I’m not totally sure what a “board game engine” looks like, I want to code a basic implementation in JavaScript, just to help me figure out what the primtives are. I am building a command-line Mancala program as an initial trial, and then plan to add some other simple game built on the JS version of the engine to “kick the tires” of the model I’ve designed. Then I’ll implement that model in Glish, and finally build a graphical frontend.
The last step is a bit tricky for me. It turns out I’m really only good at building web applications of the traditional “application” kind, like with buttons and forms and stuff. I haven’t done any work with any modern tools to handle things like animations, physics, etc. So I had to take a pretty big detour here to learn about these. I compared a few and settled on Phaser, a JavaScript library designed to make 2D games. After doing a tutorial, I think I have a good enough grasp of Phaser to start building the front end. I wanted to do this before I got too far into building a particular implementation in case there were any unforeseen difficulties.
Next steps on this project:
- Finish building the command-line version of the engine and make sure the designed model makes sense.
- Build a command-line version of the engine in Glish.
- Build the graphical frontend.
Chess 2
I’ve been working on a Chess 2 game for several years now. There’s an official Steam game, but it doesn’t offer mobile play and the AI that comes included with the game is woefully bad (it appears to be a stock Chess AI dropped in to the rules of Chess 2). My goal from the start has been to build a better Chess 2 AI and learn about machine learning in the process.
I started this project by building a Python implementation of the Chess 2 engine. In doing this I discovered many difficult edge cases in the rules of Chess 2 and built an engine that could handle all of these. I chose Python because I was planning on developing the AI using TensorFlow, for which Python is the preferred language.
After I did that I built an online app to play games. It’s built with React, GraphQL, AWS Lambda, and AWS DynamoDB. The biggest thing I learned in doing this is that my entire API should have been a single Lambda function. I used a different Lambda function for each endpoint which means that deploys are more difficult and the app takes longer to “boot up”. The web app frontend isn’t very good, and I haven’t touched it in probably about a year.
In order to train an AI, you typically need a huge data set. One doesn’t exist for Chess2 games, so I looked for “tabula rasa” training methods. The widely-known AlphaGo Zero was one implementation, and Giraffe was another targetting Chess. I was very excited when the AlphaZero paper was published and was confident I’d be able to get decent results if I followed the same methodology.
Unfortunately, the problem facing me now is purely technical. My Chess2 engine is slow. On my computer, I’m only able to list valid moves at a rate of about 27 boards per second, and this doesn’t include doing any actual evaluation on those boards (i.e. no “AI”). I estimate that at this speed I would need around 100 days of 24x7 training to achieve similar results to the AlphaZero paper (300k self-play games). And if there was a bug then I’d have to start over.
I think I need to make move generation at least 1,000x faster in order to have a real chance. Building the engine in Python seems to have been a pretty big failure here due to the speed issues. cPython might be faster, but isn’t supported by TensorFlow. Multithreading isn’t possible in Python, and multiprocess has too high of an overhead to enable the 1,000x speedup I’m looking for (the algorithm is very sensitive to latency).
Next steps on this project:
- Think more about neuroevolution, which may enable a multiprocess solution to work.
- Rewrite the engine in C++, then figure out how to build a paralellizable MCTS. This might require writing the neural network in C++ as well.
- Make the Chess 2 Online app better.
HTerminal
I haven’t touched HTerminal in over 2 years, but I’ve started to think more about it recently. I stopped working on the project because I lost confidence that the approach I was taking was going to meaningfully enhance the terminal experience.
The current status of HTerminal is “generally working”. It supports a few neat features and generally works as a standard console, although nowhere near as good as iTerm 2. The features that it adds aren’t game-changing, though. I can show icons in ls, or put a “commit” button in the output of git status, but none of these things really make me materially more productive.
I have some ideas about how to improve HTerminal, which I’d like to write about soon. I think the core ideals of HTerminal are valid, like not replacing the shell and working over SSH; but I think the improvements that it brings to the table are lackluster presently. I’d like to incorporate some of the ideas from UpTerm into the project, but without compromising the ideals HTerminal has about backwards compatibility.
Next steps on this project:
- Think more about specific features that would improve my own productivity.
- Build them into HTerminal.
