tl;dr version: The world of browser plugins has changed over the years, and the Unity WebPlayer is no longer functional. So I decided to upgrade my projects and make WebGL builds using the latest version of Unity in what I’m calling Maintenance Releases.

Over the past few years I’ve released a number of games and prototypes using the Unity game engine. I first started using Unity while it was somewhere in the version 3.x release cycle. Since then it has gone through a few major version numbers. In version 5.x, all the features of the engine previously limited to Unity Pro licenses became free to users of what was rebranded as Unity Personal (i.e. free). And now they’ve changed to a subscription model and have started using the current year as the version number, starting with Unity 2017.

Over this time there have been many changes to the Unity game engine, and I’ve learned that sometimes it is difficult to upgrade a project to the latest version of Unity due to incompatibilities introduced by these changes. But I’ve also learned that the longer you wait between versions, the more likely you are to have trouble upgrading. In other words, upgrading a project from Unity 3.x to 4.x is easier than upgrading it from 3.x to 2017.x.

Unity seems to have a built-in understanding of how to upgrade an older project. But I’m not sure how far back each version knows how to upgrade from. And in fact, Unity itself didn’t really track which version of Unity a project used until sometime in the 5.x cycle. So it seems to me that recent versions of Unity can’t tell the difference between any project made before Unity 5.x. As a result, the older a project is the greater chance there seems to be when upgrading it.

All this is to say that I’ve recently decided that I’m going to make an effort to make maintenance releases for my games to keep them compatible with the latest major version of Unity. I’ve already made one such release with Be Tiny, World! a couple months ago, but now I’ve decided to do it with the rest of my Unity games, where possible.

The biggest motivator for me in this decision is the fact that virtually all of my previous releases were playable in the browser with the Unity WebPlayer browser plugin, which has since become replaced with the WebGL player. Since most of my games are short prototypes or game jam games that can be played and finished within just a few minutes, being able to quickly play in the browser instead of having to download and unzip/install seems like a convenient way to try them out. So it’s important to me to make sure that the option to play in the browser remains a valid and up to date way to play.

Two things to keep in mind about my plans for these maintenance releases:

  1. The primary goal of these releases is just to upgrade the project to the latest version of Unity. It should be easy and relatively fast to do. Hopefully this just means opening the project in the latest version of Unity and, barring any glaring errors or incompatibilities, immediately making fresh builds. If it becomes too hard to upgrade a project due to incompatibilities between versions, then that project may not see any future maintenance releases.
  2. If a game is getting Maintenance Releases then most likely development for this game is discontinued. In other words, don’t expect new features. That said, I may make some relatively minor changes or bug fixes in the process. But no guarantees. Again, the goal is for this to be a fast and easy upgrade that takes me maybe one day at most to finish.

So, expect to see some maintenance releases showing up soon, and then about once per year after that.