Unity is a Game Engine
Unity is a Game Engine. It is designed to power games. 2D games, 3D games, mobile games, console games, PC games, it doesn’t matter. In fact, Unity can support almost every platform in existence that can run games.
Unity is a great Game Engine. It’s been around for a long time, had 5 major versions before it switched over to the current version numbering based on release years. When Unity’s own creators talk about it at conferences, such as Unite, they always talk about deploying your “game”, moving your “player”, downloading “levels”.
However, something new is happening around Unity. More and more people are starting to use it for things other than creating games. Actual “apps” are written in Unity – either because it supports all those platforms I mentioned before, or because it’s (relatively) easily accessible graphical capabilities and huge Asset Store are hard to match on native platforms – or maybe the developer didn’t have experience with other developer tools and languages for the target platform.
Small utilities, navigation software, kiosk apps, data visualizers, training applications, even some traditional grid / form-based enterprise software are being written in Unity. And recently, AR and VR has entered the scene, with its inherent hunger for a mature, performant 3D engine. And in this field, Unity has become the #1 engine by a wide margin – because of its wide platform support, and the ability to adopt to stereoscopic rendering other new paradigms required by AR and VR headsets.
Being someone who has developed “applications” during most of my career (apart from a fun, but unsuccessful excursion to the world of rhythm games), AR development is also where I met Unity. After I first saw the original HoloLens in person in late 2015, I decided that it’d be the next thing for me. And when I got my hands on a device, I began to get acquainted with Unity’s foreign concepts.
And oh boy, were they foreign concepts. From the flat, 2D scene of the web, WPF, Silverlight, Windows Phone and general XAML world, I got into the wonderfully crazy world of 3D: scenes, prefabs, GameObjects, MonoBehaviours (with an “ou”!), breaking of C# coding traditions (lowercase method names anyone?), game loops, pixel shaders, vertex shaders, private methods that are somehow still invoked by the engine, and the list goes on. Even after speaking at local and international conferences, keynoting Microsoft product launch events, being a Microsoft Most Valuable Professional for nearly a decade – I felt like a total noob.
Of course, the creators of Unity are incredibly smart, and they’ve given a lot of thought throughout the 14 years behind Unity on how a game engine should work, how games should be architected. They are calling private methods from the engine because that’s faster. They have broken C# coding conventions because the original scripting language of Unity was Javascript.
So that’s Unity. A Game Engine, used to create games.
AR is not a Game (for now)
But for AR headsets like the HoloLens, the market is not in games. No consumer has a HoloLens – the hardware is not there yet (even with the second generation), and it is way too expensive to play games. So, if I wanted to make money from developing for HoloLens, I had to create apps. For large companies. Enterprise apps, that make people’s training and work more efficient, allow them to communicate better, to achieve more.
But enterprise apps have different requirements than games. A game is all about exploration (find a way out of the maze, find the most efficient and cool way to defeat an enemy) and mastery (getting better at certain tasks, such as wielding a lightsaber or dodging bullets). But an enterprise app is poorly designed if you need to spend multiple minutes trying to find how to print a document, gradually getting better at it after many failures.
On a technical level, a game is usually all about performance. Animations must be smooth; 3D models need to be simplified so that they can be displayed at a solid framerate, and often in a way that thousands of objects can be rendered at 60 fps, with realistic lighting, physics and so on. It’s not an easy task by any means. But once a game is released, it is done – most games rarely gain new features after release, only patches to fix bugs.
Enterprise apps have other priorities. Enterprise apps need to be in service for years, expanding the feature set multiple times, due to a changing legal environment, end user requests and so on. Testability, an agile codebase, maintainability, separation of logic and presentation are all very important, while performance is OK if it is stuck at the “good enough” level. After all, your typical enterprise AR apps of showing a few text fields, and a couple of arrows pointing at different areas in the real world, with non-realistic lighting doesn’t take up much rendering performance. And yes, some performance optimization is still necessary for AR headsets (we are talking about mobile level CPU and GPU displaying 2xFull HD resolution), but if you’re careful about a few basic rules, you’ll be fine.
The Best of Both Worlds
When I was doing “apps” with XAML technologies, I took full advantage of the separation of presentation and logic. Often, we’d work in teams: I created the logic, made sure it worked properly using unit tests, and handed it over to my colleague who built the presentation layer in XAMLO on top of my logic. We rarely had to touch the logic layer thanks to the automated unit testing practices I followed. This was helped greatly by the MVVM architecture that is widespread in the XAML community and is still in use today.
But Unity doesn’t have MVVM, and its game-oriented internals force your app to have a game-y architecture as well. I tried to adopt the Unity approach to enterprise apps, but anything beyond a simple prototype got much more difficult to make than it should’ve been.
I set out to research how others were tackling this issue – and couldn’t really find a solution that fulfilled my needs. So, I started working on my own solution – MVP Toolkit for Unity.
MVPToolkit for Unity
MVP Toolkit for Unity is an implementation of the Model-View-Presenter pattern for Unity. It is open source, and available on GitHub.
I set out the following goals for MVP Toolkit:
- Provide a clean separation between business logic and presentation
- Allow the business logic to be testable outside of Unity, enabling unit test integration with build servers, super-fast unit testing, or even live unit testing (unit testing as you type) in tools such as Visual Studio.
- Be lightweight, so that you only have a few concepts to learn
- Doesn’t force you to use it – adapt for just a small module, or as you see fit
I’ve been using it and evolving it on multiple projects, including a complex real-life enterprise AR project. While I don’t consider it complete, I am happy that I managed to achieve my goals. We can work together with a Unity developer in a similar manner than I did in earlier XAML projects:
- I create the logic, using test driven methods
- My colleague takes the logic and attaches the views and presenters
- Things work on first try 90% of the time.
I plan on creating a blog post, and perhaps even a video series on the different aspects of MVPToolkit for Unity. In the meantime, please check out MVPToolkit-Unity on Github, and let me know what you think!
vbandi.net 