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.
When I set out on this adventure, I knew I wanted to eventually cover the basics of the major cloud services. Write some sample services to run on Amazon Web Services, Microsoft Azure, Google cloud services, etc.
I was surprised to stumble into an entirely different meaning of “cloud development”: writing code in a browser. I had seen the educational coding playgrounds of Codecademy, and I had seen small trial tools like JSFiddle, but I had no idea that was just the tip of the iceberg and things can get much fancier.
I had started a project to practice my newly-learned jQuery skills. Just with a text editor on my computer and running the HTML straight off the file system. As soon as I learned of these web-based development environments I wanted to try it out by moving my project over.
The first I tried was Codenvy, whose whitepapers are quite grandiose in what it offers for improving developer productivity. Unfortunately the kind of development Codenvy supports aren’t the kind of things I know anything about today. But I’ll revisit in a few weeks to check again.
The second I tried was Cloud 9, which does support simple HTML+CSS+JS projects like what I wanted to do. Working in Cloud 9 gave me some tools for static analysis and serving my file off a real web server. It also integrates into Github preserving my source control workflow.
When my little project goes awry, I resorted to loading up the project in a separate browser window and using the web browser debugger. This is on par with the simpler tools like JSFiddle and JSBin. I had hoped for better.
I’m cautiously optimistic I’ll find a tool with better debugging experience as I continue to explore.
While fiddling with my HTML experiments, I start feeling the need to keep different versions around and the desire to undo experiments (successes and failures both.)
I hadn’t planned to dive into version control for a while longer, but this is enough of a motivation for me to dive in starting with the Codecademy “Learn Git” class.
This class has significantly less hand-holding than the last few Codecademy classes I took, and almost no repetition. It also doesn’t go into a reasons why you are doing what you are doing in a class. As a result, I felt this class would not be a good introduction for a raw beginner.
To successfully complete this class, the student needs to:
- Be comfortable with a command line.
- Already know why you’d want to use version control.
- Navigate the in-class environment without instructions.
The last one was annoying. At one point in the class, the student is expected to open a file in the virtual work environment to be edited, but there was no instruction on how to do so.
The class worked perfectly for me – I could handle the above bullets, and the lack of repetition meant I was never bored. The lack of hand-holding meant I had to occasionally look up git commands on my own, or hunt around the UI of the work environment, but it wasn’t bad. I’m just not sure it’s good starting place for a coding beginner.
Setting aside the class material for now: the class implementation was interesting. I had expected the class learning environment to be merely a facade. Something that only accepts text input in the exact order required in the instructions. It turns out not to be the case – it appears to be a real (though restricted) instance of bash, connected to (a limited set of) git commands. I could issue any valid commands in the environment, and they would run!
Of course, if I veer off the course I couldn’t go to the next step, but I was impressed that they have created a sandbox for the student to play in.
A Science News article online experimented with interactivity not possible in their print edition. It was fairly simple at first glance: when a cursor hovers over certain places in the image, additional information pops up. Seen all over the web, like the little pieces of trivia behind bing.com background picture of the day.
What caught my attention is the link in the corner: “Made with ThingLink, Learn More” What I had thought was a simple piece of HTML is actually a business built around the concept.
A brief exploration found that ThingLink hosts the image (and associated server storage and bandwidth) plus the interactive scripting. The package of content is then available to be served alongside content hosted elsewhere, such as WordPress.com. I can embed a ThingLink right here in this post, if I had something interesting to show.
There’s a basic level of the service for free. To make money, they sell higher tiers with features like customization, branding, and analytic information. I’m ignorant on how this information might be valuable, but ThingLink has an idea: they believe the full set of features is worth over $200/month to some people.
So definitely not just a trivial piece of HTML. It is the tip of the iceberg of a corner of web commerce I didn’t even know existed before today.
The first step of documenting my experience on WordPress is… talking about WordPress itself. Self-referential, yes, but it actually served as a great introduction into a different mindset: Software as a Service (SaaS).
WordPress is itself a content management system designed to run entirely over the web. Not only is the content stored on a remote server, the management UI (like the text editor I’m typing this in) is served by the WordPress service over the web. There is no application to install on my computer. When I want to work on my WordPress site, I use my web browser.
SaaS is gradually taking over a lot of the software world, and as a Windows developer, I’ve been missing a lot of the action. It’s time to get to know this new cloud-based world. A world where the service is available anywhere there’s a web browser, because a browser is all the client software you’d ever need.
Or… is it?
It turns out the client-side software concept is not dead, not quite. And not even at WordPress. While it was no surprise to learn that WordPress have mobile apps to access the service on iOS and Android, I was greatly amused to learn they have also introduced desktop client software for Linux, MacOS, and…. Windows.
Yep, Windows client software.
What is old is new again.