Jon Thysell

Father. Engineer. Retro games. Ukuleles. Nerd.

The State of Mzinga, February 2018

Mzinga is my open-source AI for the board game, Hive, and I can’t believe that the last time I posted it was all the way back in Summer 2016.

So much has happened since then!

At the time, my focus was on the Mzinga Trainer, a tool for improving my board evaluation function, ie. if I look at a given board, how accurately can I answer: who is winning and by how much?

The Mzinga Trainer does this through a genetic evolution algorithm, whereby a population of AIs (each with their own evaluation function) endlessly battle one another, and the winners earn the right to “breed” new AIs (passing on a mix of both parents’ functions) while the losers get culled from the population.

So in July 2016, I was just getting AIs to battle one another. Fast forward to July 2017, and I had:

  • A feature-rich Trainer with dozens of options, including support for running multiple battles concurrently on different processors
  • A refactored AI, making it much easier to validate that I was implementing the algorithms properly
  • Some key performance tests to evaluate changes to the core code

I had also spent several hundreds of hours of computing time in running experiments with the Trainer. Hundreds of AIs lived and died as I tweaked parameters and followed the most successful AIs (and their children). But by July 2017 I stepped away from Mzinga and started spending my spare time on other projects.

Then around December of last year, having not touched Mzinga for months, I suddenly had the inspiration for how to fix a particular performance bug I’d had, and by the start of the new year, I was back on the Mzinga bandwagon.

Since I’d spent so much time on the Trainer, from a regular user’s perspective, Mzinga hadn’t changed much since 2016. The Viewer (where you can actually play games) had seen some minor bug fixes, and while the Engine (with the core of the game and the AI), was technically faster and stronger, I doubt it was noticeable to most players. I regularly lose to people playing for the first time, and I could still beat the Mzinga AI.

I spent most of January focused on code performance – nothing AI-specific, nothing that needed any study or research, just analyzing the code and removing every little bottleneck I could find.

Then, after nearly eight years on my venerable, dual-core laptop, I finally bit the bullet and bought a new PC. A custom, fancy, rocking, eight-core beast with horsepower to spare. And wouldn’t you know, suddenly I had an interest in hitting the old chess AI sites and researching how the best chess AIs take advantage of multiple processors.

Now Mzinga’s AI is starting to get fancy:

  • It spreads its search across multiple processors, via “Lazy SMP”
  • It searches during your turn instead of waiting, aka “Pondering”
  • When it finds the “best move”, it peeks just a little further ahead to make sure, via “Quiescence Search”
  • It keeps you updated each time it finds a better move

On top of all that, everything is all nice and asynchronous, meaning I can cancel a search when I want to. I don’t have to say, “search 2 moves deep” or “search for 5 seconds” and then sit and wait for it to stop. If I want to stop it early, I can. If I want to just let it search, I can, and stop it when I’m good and ready.

Now sometimes the AI beats me.

I’ve also started addressing the Mzinga Viewer:

  • It’s faster and more responsive
  • It’s finally got some options, so you can tweak your experience:
    • Do you like your pieces with the flat or the pointy side up?
    • Do you want pieces that can’t move to be “grayed-out”?
    • Do you want to see certain things highlighted, like your opponents last move or what the valid moves are?

Some of these features are new, but some already existed in the Viewer and were always on because I liked them. Now you can turn them off if you don’t.

These are just a taste of how much Mzinga has changed, and there’s still more to come! Check it out today if you haven’t and send your feedback my way!

Stay tuned,


Making some retro games with LÖVE

I was in the mood to make some games this past week, when I discovered the wonderfully powerful yet lightweight LÖVE game framework.

After watching some videos on YouTube highlighting games others have made*, I set to work on one of my own. Within a couple of hours I had Pong running on my phone!

I decided I’d keep exploring the APIs by building a suite of simple retro games, the source of which I’ve uploaded to a new GitHub repo named RetroLove.

So far I have decent clones of Pong and Breakout. I’m thinking maybe Asteroids next. It’s so much fun, and the framework couldn’t be easier to use.

Check it out,


*: The story on how I found LÖVE is actually a little bit longer and shows the circuitous way by which I find myself doing these kinds of projects. I was working on another project, my first Universal Windows Platform app (that is, an app that runs on all Windows 10 devices). The project itself is something I’ve had on the back-burner for years, and I was primarily using it as an excuse to practice using XAML, which is the UI framework for UWP apps. (My day-job is on the XAML team at Microsoft, so using it myself only helps me to better understand our customers.)

Anyway, my app needed an embedded scripting language, and I wanted to use Lua, but I needed something that would work within a UWP app, which, because it needs to work on lots of different kinds of devices, meant I couldn’t use the native Lua libraries easily.

This led me to the very cool MoonSharp project, which is a Lua interpreter implemented entirely in C#. After I got that up and running, the app also needed a kind of visual editor, so I needed to do some 2D graphics work. It was then that I discovered the Win2D project, which makes it easier to do GPU-powered 2D graphics within XAML.

Then an idea hit me: what if I had a 2D game engine designed similar to retro consoles? Where the engine would be responsible for maintaining backgrounds, sprites, and drawing to the screen, and the game developer would provide the game in the form of a package of Lua code and game assets? I could make a UWP app that used MoonSharp to interpret the Lua and used Win2D to draw to the screen.

It had been some 15 years since the last time I’d made a game engine. In college I made a decent Mario-style platformer in Java; it had realistic physics, collision detection, music, sprite animations, scrolling, power-ups and enemies. I only ended up making one tech-demo of a level, but in the process I learned a ton about game engine design. (Though looking at that old code now… yikes.)

I spent a weekend trying to implement my idea for a sprite-based 2D game engine for Windows 10. It took me the two days to realize the true scope of such a project, and unfortunately I couldn’t get MoonSharp and Win2D to cooperate. Knowing that my idea probably wasn’t a unique one, I started searching online for other Lua-powered 2D game engines.

That’s how I found the free and open-source LÖVE. After seeing the size of its community, and how mature it was, I quickly abandoned my own broken code and started work on Pong.

SegaController v1.3.0 now available

I’ve released an updated version of the SegaController Arduino library. If you don’t know, SegaController enables your Arduino sketches to read Sega Genesis (Mega Drive) and now Master System (Mark III) controllers.

What’s new in v1.3.0?

  • Now supports Sega Master System (Mark III) controllers
  • Optimized code to reduce compiled binary size
  • Reduced read latency
  • Fixed issue with errant button reads when inserting/removing controller
  • Temporarily disables interrupts while reading to prevent misreads
  • Added DB9 pinout diagram to readme and examples

So if you’re interested in reading Sega controllers in your Arduino projects, check out  SegaController Arduino library on GitHub.

I’ve also updated How To Read Sega Controllers with information on reading Master System (Mark III) controllers.

Enjoy and happy hacking!


Introducing the AtariController Arduino library

After releasing my Arduino library to read Sega Controllers, I decided it might be fun to create a suite of such libraries for reading other retro controllers.

So today I’m introducing my new AtariController Arduino library on GitHub. This initial release only supports the classic Atari 2600 joystick, but I hope to add other controllers in the future.

The code is provided as a proper Arduino library, making it easy for Arduino enthusiasts to use in their own sketches. As with SegaController, I also include two examples, one which reports the button states via the serial port (good for testing) and one which sends Keyboard key presses (good for driving other software).

And of course, I’ve created some documentation of my own in the AtariController wiki at How To Read Atari Controllers.

Enjoy and happy hacking!


Introducing the SegaController Arduino library

A couple years ago I tried my hand at building an interface for reading Sega Genesis / Mega Drive controllers with an Arduino. I documented my first attempt with Reading Sega Genesis controllers with Arduino, and my updated version with Sega Genesis controllers and Arduino revisited.

That was three years ago, and I’ve gotten a lot of feedback about those projects. While they worked well enough for me, many people had problems getting my code to work. My research had led me to an implementation that relied heavily on having correct timing delays, and others found they had to constantly tweak those timings.

Of course, as any decent programmer will tell you, if your code relies on a bunch of seemingly random sleeps to work properly, you’re probably doing it wrong. And it turns out I was.

I recently found the Six Button Controller page on SegaRetro, where I gleaned some new vital pieces of information:

  1. The controller must be cycled through 8 different states.
  2. Reading the controller involves knowing the current state.
  3. If the state isn’t changed for 1.5 ms, the controller resets.

Using this information, I decided to take another crack at my Arduino code. And with a little bit of work (not all of the information on the SegaRetro page was accurate) I created a much more deterministic, stable, delay-free program. Taking it a step further, I refactored the code into a proper Arduino library, both to learn how to do that, and to make it much easier for Arduino enthusiasts to use in their own sketches.

So if you’re interested in reading Sega controllers in your Arduino projects, check out my new SegaController Arduino library on GitHub. Replacing the original sketches are two new examples, one which reports the button states via the serial port (good for testing) and one which sends Keyboard key presses (good for driving other software).

Also, since my research into how the controllers worked led me to mixed results (no one’s documentation had it 100% right) I’ve created some documentation on my own in the SegaController wiki at How To Read Sega Controllers.

Enjoy and happy hacking!