Jon Thysell

Father. Engineer. Retro games. Ukuleles. Nerd.

RetroLove v1.0.0 now available on Windows and Android!

Last year I was in the mood to write a game, and in exploring the LÖVE game framework, I wrote a few old-school retro games under a project I named RetroLove.

Recently I picked up the project again and consolidated the three games I’d written (Pong, Breakout, and Asteroids), into a single game with a selection menu. I also started exploring how to release the game, even going so far as to figuring out how to get the Android port of LÖVE building on Windows.

Today I’m announcing the v1.0.0 release of RetroLove for both Windows and Android.

Both the Windows zip release and the side-loadable Android apk can be downloaded from RetroLove Releases on GitHub.

Additionally, you can get RetroLove for Android on Google Play. This marks the first time I’ve released an app on a mobile platform!

Check it out and tell me what you think,

/jon

P.S. While RetroLove itself is not the most mind-blowing game, the exercise has gotten me both my first mobile app (only 8 years in the making!) and gotten me well set up to building and releasing more games with LÖVE.

Introducing the RomSort utility

 

About a year ago I wrote a little command-line tool for sorting ROM files into alphabetical sub-directories. The main feature was it could intelligently combine the smaller sub-directories, which is useful when you’re browsing on low-resolution screens. However after I got the code working I never got around to sharing it.

So I took some time to re-package the code into a small .NET 2.0 WinForms app. It is pretty straightforward to use, and even gives you a live preview of what the end result will be before you use it. Note that filename collisions will be marked in red and it won’t let you perform the sort if there are any.

Source and binaries (under releases) @ RomSort on GitHub.

Enjoy!

/jon

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,

/jon

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,

/jon

*: 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!

/jon