Unity is a cross-platform engine and authoring tool, most popularly used in games. It is being used to develop the new version of MissionMaker, which is itself a game authoring software, part of the Playing Beowulf project. Last year I worked on this project as part of my PhD at the London Knowledge Lab.
In this post I will briefly introduce Unity and present some of my own experiments with the engine.
The Power of Unity
Unity has become increasingly popular in the gaming community and among developers in general, due to its good performance, high quality (specially in terms of the graphics and physics simulation) and abundance of features.
But one of its biggest advantages is the support for a wide range of platforms – including desktop, mobile, consoles and web (although web support has become complicated lately, as explained further in this post). This allows not only a wider reach for projects done in Unity, but also a much more practical workflow for developers.
On top of that, the early 2015 Unity 5.0 release included a free fully functional version (the “Personal Edition”), to be used by anyone (and any company) with less than US$100,000 annual gross revenue. Although it’s still early to tell, this move has the potential to revolutionize game and software development – or at least to set a strong precedent -, by making this professional and powerful tool available to anyone willing to give it a try. ((Developers still need to purchase the license to publish in certain places, such as in Google Play and Apple’s App Store. But exporting a project as a standalone application or for the web is free (a Unity splash screen appears on startup, but most developers using this version seem to be OK with that).))
Compared to similar applications, Unity’s authoring tool is very accessible and straightforward, and at the same time powerful and flexible. Its interface and workflow allows combining traditional coding with visual programming. For example, it is possible to declare a variable in a script such that its value can be altered by sliders and input boxes on the graphical interface of Unity itself.[caption id="imageCaption" align="aligncenter" width="440" caption="Unity 5: graphical interface"][/caption]
Some developers may choose to use scripts sparingly, and do most of their work by dragging and dropping objects and elements using the graphical interface. Others may decide to focus on scripting, and even modify certain low level functions of the engine, such as those related to rendering or collision testing. ((Flash has a similar hybrid approach, although Unity is much more robust and stable (it doesn’t seem that Flash will be around for long anyways).))
Web Support: it’s complicated
One of Unity’s main advantages is its wide support across platforms, allowing a same project to be exported to a variety of different devices and operating systems, with very little additional setup required. However, recently web support has become less straightforward, and it should be a while until this is sorted out.
Unity has never been very popular in the web, at least not as much as Flash once was. The plugin always felt a bit to heavy and sluggish to me, as if it were constantly pushing the machine to its limits. Indeed, Unity is optimized for speed and performance, making an aggressive use of computational resources (to be fair, browsers don’t really feel like the best place to have this type of content in the first place).
But the real issue for Unity in the web now is the fact that its plugin depends on NPAPI, an outdated technology. Google Chrome recently stopped supporting NPAPI, and other browsers will probably follow sooner or later. The newer and more promising technology for web applications is WebGL, which is supported by Unity, however in a limited form. Even the makers of Unity don’t recommend starting any new projects having their plugin in mind, or to rely too much on WebGL, since the technology is still in a relatively early stage of development. It will probably take some time until it is able to achieve the same quality and performance of Unity’s own plugin (read more about this issue in Unity’s website here).
Games and “Non-Games”
Unity has always been mainly promoted as a tool for game development – in their website, the showcase is divided in two categories: games and “non-games”. This makes sense, considering that, as mentioned before, the engine does indeed emphasize performance and speed.
However, Unity is extremely flexible and can be used for virtually any type of digital creation, from architectural and product visualization, engineering simulations and advertising all the way to educational and artistic projects. Usually associated with 3D applications, Unity is also capable of dealing with 2D projects, as well as a mix between both.
Unity is also not limited to productions aimed at the end user. It can be used in the implementation of full standalone tools and applications as well (this is the case of the aforementioned MissionMaker 2).
Of course, there certainly are many reasons why a developer would prefer not to use Unity in their project, some of which I mention in this post. But its versatility means that, regardless of what needs to be developed, Unity is usually a good option to do it in.
Experimenting With Unity
In this final section I will briefly discuss my personal creative experience with Unity.
As a creator, I am always trying out new tools, languages and practices, both in digital and traditional mediums (although I do tend to focus more on the former). ((My creations in digital media can be viewed in this website in the following categories: generative, games and installation (other categories can be accessed via the menu on the top right – select creation).))
This practice, however, also informs my research. Currently I am researching procedural expressiveness, which consists on investigating the act of programming and the logic of algorithms as a language, in a similar way as traditional mediums such as literature and painting. This involves both the practical aspects of the tools, programming languages and paradigms, and also the more theoretical elaborations related to understanding the artist’s creative process.
Although my coding skills are very limited, I didn’t have too much difficulty in getting into Unity. In less than half an hour I had a decent prototype up and running (much less time than it took to download and install Unity in my computer, by the way). I made a little “game” in which cubes would constantly fall from random positions, and the player could control a box (using the keyboard) to “catch” them. I eventually got stuck trying to solve a specific issue with the physics simulation (“sleeping” objects…), but since I wanted to try other things I decided to move on.
For my next experiment I wanted to prototype something similar to the classic game Snake (or Nibbles), but in 3D. Although not a difficult task by any means, I knew it would require at least a few different concepts, such as camera movement, 3D vectors and dynamic object creation and manipulation. In under an hour I had implemented exactly what I had in mind, and some more (I was even able to run my prototype in an Android device and adapt the controls to detect the accelerometer). ((In 2009 I did a remake of Snake in Flash, called Nibballs. For this current project in Unity my plan is to have a different type of game mechanic.))[caption id="imageCaption" align="aligncenter" width="440" caption="Experiments: snake prototype"][/caption]
I did get stuck once again, as I began trying to include more complexities in the system (I ran into some problems related with classes and variable scope). However, this says much more about my limitations as a programmer than about Unity itself.
Update 2016/07/23: more images here.