When I was first introduced to neural networks, they were considered algorithms with extremely expensive computational requirements. Even the most trivial network required a high-end PC with lots of memory and floating-point math capability.
Of course, at the time a high-end PC processor ran at 90 megahertz, 32 megabytes of RAM is considered a lot, and floating point math required a separate (and expensive) floating-point co-processor.
Now the cell phones we have in our pockets have faster processor and more memory than those powerful PCs of old. Every current processor has floating-point math capability, no extra chip required.
Which means what used to be the domain of specialized programmers, running on expensive hardware, is now possible everywhere: running in a web browser like the TensorFlow playground.
But it’s still hard for a human to grasp what’s going on inside a neural network as it learns and adjusts. While the accessibility of the technology (meaning how easy it is to obtain) has improved, the accessibility of the knowledge (meaning how easy it is to understand) hasn’t.
Computer brains have made great advances in the past years…
Human brains have not.
After an intense few weeks with Unity, I’ve decided to put it on hold and come back to it later. The biggest problem is that, even though it can output to web browsers via WebGL, it is extreme overkill for projects that can be easily handled via Plain Jane HTML.
As an Unity exercise, I pulled art and assets from the old game Star Control 2. This was possible because (1) the creators of the game released the code in 2002, and (2) I’m no longer working at Microsoft. I was aware of the code release when it occurred, but my employment as a Microsoft developer at the time meant I could not look at anything released under GPL. Even that of an old game with zero relation to the work I’m paid to do.
Since it was a simple 2D game, bringing the assets to life using Unity severely underutilized Unity capabilities. That isn’t a problem, the part that gave me pause is that the end product is a lot heavier-weight than I thought it would be: Even when there’s only a few 2D sprites animating with some text overlay, it is a larger download with correspondingly slower startup than I wanted to see.
Given what I see so far, Unity is the wrong tool for this job. Now I have a decision to make. Option #1: Keep digging in on an old favorite, and work on SC2 code using some other framework, or Option #2: Find a project that plays more to Unity’s (many) strengths.
Option #1 goes to the past, option #2 goes to the future. (Specifically VR…. Unity is great for exploring VR development.)
Today, I find that I’ve caught the old SC2 fever again, so I’m going with #1. I’ll come back to Unity/VR/other explorations later.
Unity’s learning center has a lot of information, I chose to start with the headliner tutorials. These appear to be full-day lectures during the Unite conference, where they take the class through building a game from beginning to end.
Since real games take more than a day to build, many shortcuts were taken. One of these shortcuts were the use of built art assets. All came already created, complete with their own associated animation sequences. The tutorial only covered how to import the items and write a few lines of code to trigger the animation sequences.
I have no illusions about being an artist but I also know I don’t have an artist to call upon as I learn Unity. So I had to know something about creating these assets for myself. I thought I would start small with a few simple sprite animations… that turned out to be not so simple.
The Unity animation engine (sometimes called Mecanim in the documentation) is a very complex machine optimized to work with humanoid figures in 3D space. It can certainly do simple sprite animations, but trying to do so became an exercise in figuring out what to turn off in the big complex machine. It keeps trying to do too much, blending and interpolating and trying to be helpful when all I really want was to put a few 2D images on screen at discrete coordinates at specific points in time.
It took way more time than it should, but (1) I got my simple sprite animations working, and (2) I learned a whole bunch about what the animation engine can do for me, down the line, when I’m ready to move beyond sprites.
It was a bit frustrating, but now that I’m through it, I’ll call it a win. Time to move on.
After deciding to move on from Phaser, I looked around for other game engines to generate web games. I came across Unity again and again. Unity is not new to me, but I also knew their web support was via the Unity web player browser plug-in. This is a problem, as browser plug-ins have fallen into disfavor. All the major desktop browsers Firefox / Chrome / IE, are moving away from plug-ins.
So… dead end (or at least dying). Plug-ins are not the future of the web.
Because of the web player, I dismissed every mention of Unity for web development I encountered, until I came across information that slapped me upside the head and woke me up. The web player is not the only Unity web target: Unity now has another web-friendly build target: WebGL, no plug-in required! Wow!
This warrants a closer look. While WebGL might be immature and inconsistent across browsers, it is a shared goal of many interests to evolve and mature the platform and I share their high hopes. The browser plug-in model is going away. WebGL may or may not take off but all the signs today look promising.
And now I learned that I can even explore some parts of the web world with Unity. It is quite the Swiss Army Knife of software development. With this latest discovery, Unity has moved to the top of my to-do list. It is time to roll up my sleeves and dig in.
This should be fun.
In a quest for something more substantial, I looked into the HTML5 game engine Phaser. It has a large audience and an impressive set of features. It was fun poking through some of the source to see how it does its magic, but I ultimately decided against making my own Phaser creation because it is at its core a bitmap-based system.
Bitmaps don’t scale as nicely as vectors by their nature, and I place a great deal of importance on ability to scale well. In the modern HTML world, the customer might be running resolutions ranging anywhere from a 320 x 480 iPhone screen to a 3840 x 2160 4K desktop display.
The people behind Phaser isn’t blind to this. Part of the core features includes a ScaleManager class to help the process. There are also ways to load lower- or higher-resolution assets in response to the screen resolution used by the particular user. But it is an imperfect solution, there are still bitmap scaling artifacts around that plainly wouldn’t be an issue at all had the system been based on vector graphics.
Most of the Phaser titles don’t bother with scaling at all, or only scale across a few fixed resolutions. I find myself quite annoyed when I load up a sample app, just to see it take up a tiny 320×480 (resolution of the original iPhone) section of my desktop browser.
I’ll keep looking.