Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
October 23, 2014
arrowPress Releases
October 23, 2014
PR Newswire
View All
View All     Submit Event

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

My Unity gap year and Canaries
by Byron AtkinsonJones on 01/12/14 01:26:00 pm   Expert Blogs   Featured Blogs

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


I'm probably the biggest Unity evangelist you will come across, I'm always trying to get all the developers I know to use it - I constantly berate them about not using it. I also do quite a bit of Unity based consultancy, teaching studios how to use it or working on Unity based games. I love it. In fact my latest release, Blast Em! ( is a Unity game.

So, it may come as a bit of a surprise when I say that I may not be using it for the Vita, Xbox One and WiiU games I'm making. Instead, on those platforms I'm going back to native code using C++.

The reason is all to do with Canaries

When I was working with the NHL team at EA BlackBox in Vancouver, we had a visitation by the then CEO of EA Canada, John Schappert and he gave what I'm sure was meant to be a motivational speech about how NHL were the Canaries of EA. What he meant was they would be the first to use the new technologies that the tools & tech departments would be spitting out. Somebody in the crowd rightly pointed out that in coal mines the Canaries were used to detect gas pockets and they did this by keeling over dead.

The point was that the team were the first to release games in the current year's release schedule for EA which in turn meant they were the proving ground for all the new tech coming out of EA's R&D departments (of which I was a part). This meant they would be the first to find all the bugs and issues in that tech. It's a scary position to be in for a studio.

So what has this got to do with Unity and myself?

Unity on PC and Mac is very mature and apart from a few small issues it's very stable on those platforms. It's also quite stable on iOS and Android. However on the Vita, Xbox One and WiiU it's only just really getting started. In fact I'm not even sure it exists for Xbox One yet. So any project using Unity for those consoles is acting a bit like the Canaries, they are the proving ground, they are testing the way for the rest of us.

For myself, pretty much a one-man-band of game development taking the risk of using Unity on a platform that hasn't yet been proven to be stable is a huge risk. As an example, for the Steam release of Blast Em! I came across a Unity bug where on the Mac the full-screen mode would default to 1024x768 rather than the native resolution it should have done with the relevant tick box ticked. I submitted a bug report and within a day or so support came back to tell me they were able to reproduce the bug and a fix would be found but they were unable to say when it would be publicly available.

That's not an unreasonable response from Unity. It's a huge product and if they submitted public builds for every bug they fixed then chances are every day we would wake up to a new update. Unity probably has its own internal release schedules and all fixes, unless massive probably get rolled into those releases - giving them time to do essential QA such as regression testing.

While being reasonable, this is a huge problem on a console title, especially for us smaller developers. Not knowing when a potential show-stopping bug will be resolved can have destabilising effect on development and could delay the release of the game which in turn affects the revenue stream to the studio. The issue is compounded if a bug is found when your game is released. In fact, while I was writing this blog piece, two other developers on twitter are also having some issues with this kind of thing. Travis Woodward (@tryward) said:

“Ok, am officially stuck until Unity3D fixes some of their Physics2D bugs - they're marked as 'Fixed' so hopefully they'll be in 4.3.2...“

and Aaron San Filippo (@AeornFlippout) said:

“The worst bugs in software/games are the ones that are bad interactions between major pieces of software. Nobody wants responsibility.”


“I'm having an NGUI issue in Unity3D on Linux that affects Intel 400x cards. Whose job is it to fix this? Who knows.”

On PC, players are a bit more forgiving if a game crashes mainly because updates to a game can happen at any time. Console titles are a bit different, due to various testing scenarios the update cycle for a console title can be quite long which means it could be a few weeks before a game gets a fix which could be catastrophic for it.

This leads us neatly into TRC tests, or Technical Requirements Checks. Each platform has a different name for this but the principle is generally the same in that the game is put through a battery of tests to make sure that some fundamental rules of the console are observed. The primary reason for these tests is to ensure that the player has a smooth console experience but the upshot is that you as the developer have to make sure your game abides by these rules and passes the tests.

This is another factor that may be taken out of your control with Unity - what if there is a bug in Unity that fails one of these tests? You as the developer have to wait until Unity addresses it and releases an update. The worrying aspect to these tests is that Sony, Microsoft and Nintendo may start charging you for repeatedly failing as an incentive to make sure you really are ready before entering them. This is a fair deal if you are in full control over your game but if you are reliant on a third-party middleware then this is cause for concern.

Having said all of the above, I still love Unity and once it’s matured and has been proven on a few games on the consoles I’ll be more than happy to use it for those platforms. I'm sure for the most part those choosing to use Unity at this stage for Vita, Xbox One or WiiU (and even PS4) will be fine. I'm just erring on the side of caution and for my first games on those consoles and going native using C++.

Post release news...

It seems the rumour that has been flying around about Unity for Xbox One not being anywhere near ready are unfounded. Phil Waymouth pointed out that there has been at least one game released on Xbox One that was developed in Unity and it's

There's also a blog post about this game on the Unity site:

And now on Vita

Just today (15th of Jan) Unity have finally announced that Unity is available for the Vita. You can find out more here:

I'm going to be checking this out as soon as possible and will write a follow up article as soon as I can.

Exciting times!

You can follow me on twitter:

Related Jobs

Square Enix Co., Ltd.
Square Enix Co., Ltd. — Tokyo, Japan

Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Programmer
Avalanche Studios
Avalanche Studios — New York, New York, United States

UI Artist/Designer — Hunt Valley, Maryland, United States

Lead UI Engineer


James Coote
profile image
This very much depends on your circumstances.

For myself, I really don't enjoy low level and engine programming. With Unity, the shorter projects are likely to be the smaller, less sophisticated ones. So the chances of finding a bug in Unity are a lot lower. If it proves to be a complete show stopper, it's only a small project, so only a relatively small loss.

The longer projects, there is more chance the bug will be fixed between me discovering it and needing to submit for TRCs. Bugs found near the end of development ought not to be fundamental to core features, so if it has to launch with one less shiny effect, so be it.

I'm also doing multiple projects in parallel, so I can switch full time to one if the other hits a road block whose resolution is beyond my control.

Still, food for thought. There's a risk whatever you choose. My team just switched from Monogame to Unity because the former required quite a high level of OpenGL (on PC), which was causing problems for a lot of our beta testers (who rightfully couldn't understand why their 3-4 year old laptop couldn't handle a relatively unsophisticated 2D sidescroller)

James Rhodes
profile image
But at least in MonoGame you could have changed the minimum OpenGL level it requires; the source code is all there. With Unity your hands are tied; your project is completely dependent on a third party to have perfect working software.

I think it's a particularly worrying trend that we see more and more game developers solely relying on Unity without considering alternatives. It's getting to the point where there's the idea that if it can't be done in Unity, it can't be done at all; which is entirely incorrect.

In 2-5 years time I think we'll be looking back and realising that having a large portion of the independent game development community being entirely dependent on a closed-source, third-party vendor wasn't such a great idea.

Aras Pranckevicius
profile image
"In 2-5 years time I think we'll be looking back and realising"

We shall see! (but hey I'm biased :))

Amir Barak
profile image
@James C.
"So the chances of finding a bug in Unity are a lot lower."
But given that Unity is a much more complex software bundle there's actually a higher chance of finding bugs in it and ones that you can't fix yourself because it's a closed platform.

I'm not sure I understand your last statement; what do you mean "high level of OpenGL" and why is that slowing down your testers' computers? Also, MonoGame has a DirectX back-end and so does Unity (can you even control which back-end is used by Unity?).

@James R.
It is a worrying trend and I wonder at the ratio of programmers vs. designers who use (or prefer to use) Unity for game development. It also means that people understand their target platforms less and less and rely on "magic" to make cross-platform development.

Benjamin Quintero
profile image

At my work, there is a strong point of contention between the art team and the programmers. The programmers are compelled to create custom experiences and custom technology to make that happen. The result of course is that tools tend to be a little shaky and the end result is usually a little more unique and polished but at the cost of much more labor to make the magic happen. In-house tools often rely on script and configuration files instead of graphical languages and node-based material construction, etc. Obviously the artists like the easier the path but it can often lead to inefficiencies in the resources due to a lack of understanding of what happens when a few nodes get connected and slapped onto an object.

At my work, the art department has a very high quota for throughput and a small team size, so they tend to be off on their own with Unity to build demo's and pitch proofs while the programmers are often working on long-term projects. It's very tribal, and arguably poisonous, but it seems to work for now.

Unity is great for demos, but there's always something a little janky about final products made with it, which is my biggest argument against it.

scott anderson
profile image
Are you confirming open source Unity within 2-5 years Aras? ;)

Amir Barak
profile image
I work quite a lot with Unity... I write my own tech for my projects, take what you will from that statement.

Byron AtkinsonJones
profile image
Unity is still my first port of call for my own projects. Despite my fears for the early days of the console versions it's an amazing piece of work.

Ryan Christensen
profile image
It is a trade-off for sure.

However, using Unity is like having your own tech engine team. Doing it yourself, yes you can be more agile in reacting to specific edge cases, but in the long term most likely you will be slower on bigger changes. Android testing alone is enough to scare game ship focused devs into using Unity or other engine platforms.

The problem with making all the tech nowadays is that it is a major task, game developments are much longer, competing on releases is more difficult. Back in the day cycles were longer for everyone due to everyone making homegrown tech, now, most do not I'd wager. The control is awesome, occasional competitive advantages from being different, and the performance is better in many cases having your own tech, but the work is also much much greater. Many a game company fail at launching their titles when mired in tech rather than in launching games, thousand cuts of reacting to specific edge cases, the very benefit it brings can be the worst time filling side effect. I think Unity gives most small devs a fighting chance, even on console, an extended team that allows focus on games over tech, for a price of course. Framerate hits and various show stopper bugs are difficult to deal with sometimes on new updates. However, they are pretty quick compared to even doing it internally when it comes to breaking issues whether it be console, mobile, web etc. They just updated 4.3.2 for a breaking Mac Appstore bug.

As the console side gets bigger and more robust with the self-publish next gen I am sure the surface area of problems will be much smaller and the trade-off more favorable like it is on mobile/desktop. Because Unity wants to be the engine of choice on console as well they might treat canaries like special cases as the next gen has begun. Since the new gen is here, everyone's engines are in heavy iterations, Unity or custom.

Christopher Myburgh
profile image
What about Unity source licenses? I thought Unity quoted such licenses on a per developer/project basis.

Pedro Guida
profile image
"... and going native using C++ ...", or not:

Nathan Warden
profile image
I've been using Unity almost ona daily basis for a long time (since version 1.x) and have run into maybe two or three show stopping bugs. I can only think of one off the top of my head that occured in the web player in Unity 2.x that existed for maybe about a month or so.

I completely understand the fear behind not owning the code, I get it, especially on consoles as he mentions.

But, even the one bug the writer mentions isn't even close to a show stopper. You can set the fullscreen resolution the way many (and probably most) engines do it via script instead of relying on the magic that Unity offers you. Start the game in windowed mode with a black screen, grab the current screen resolution and then set the fullscreen resloution to the one you found. It's literally one line of code at startup.

In Unity (starting your app in windowed mode):

Screen.SetResolution(Screen.currentResolution.width, Screen.currentResolution.height, true);

That's it :)

I've worked with several developers who used Unity and complained that "Unity doesn't do X" when 9 times out of 10 it was that they simply didn't know where it was in the API or that they could go about it a slightly different way, or perhaps if worst comes to worse even just having to manually write that code yourself.

I think the article would have held a lot more weight if he would have actually mentioned a show stopping bug. I know they're out there, but all I get from this article is, "I'm affraid one day Unity might have a show stopping bug that I might run into so I'm not going to use it".

Hope this helps give another perspective,
Nathan :)

Byron AtkinsonJones
profile image
I've been using Unity since version 1 as well :)

Okay, an example:

Currently I am integrating my game into Steam.

On Mac there is an issue in that when you launch the game via Steam the Unity config dialog box appears underneath the Steam window which makes it look like the game hasn't launched. I can't even supply Unity with a reproduction case for this because they would need to have a steam developer account to see it happen. It doesn't happen in previous versions of Unity as far as I can tell. I've submitted a bug report to Unity about this but since they are unlikely to be able to reproduce it I don't hold much hope that I will see a fix soon. We are going to have to rely on the description text telling people to move the Steam window or check the dock for a bouncing icon. I can see quite a few support calls to us about this one.

Another example:

While working on a client's project, an iPhone game we had an issue where the iPhone would run out of memory and would just bomb back to the home screen. We did a full analysis and as far as we could work out we should have been at least 40Mb under the limit. We then discovered that despite marking meshes as being static the iPhone Unity player was keeping two copies of all meshes in memory just in case they were to be modified by code. This appeared to be a hang-over from the desktop player where transferring mesh data from system RAM to GPU RAM is expensive but on iOS the RAM is unified which meant this was not required. Unity confirmed this was going on and would not be resolved till the next major update of Unity.

Amir Barak
profile image
"when 9 times out of 10 it was that they simply didn't know where it was in the API"
That's one of the biggest issues with Unity if you ask me... And it's not the fault of the developers that use it...

Nathan Warden
profile image

You're right, it's not their "fault", but it is their fault if they say "Unity can't do X" when it would just take a simple forum post (or asking someone else in the office who's likely sitting within 10 feet of them) to get an answer and find out that it can do X. And some of these API elements would take a good programmer a month or so to write themselves and get the bugs fixed.

In other words more often than not they should be asking someone "Can Unity do X?" instead of declaring "Unity can't do X".

If they find out that it really can't do X then they can say that, but almost everytime it's something they can write themselves as a plugin which still takes way less time than writing your own engine from scratch, which you'd have to write the code you could have just written as a plugin anyway.

Nathan :)

Nathan Warden
profile image

Those would have been much much better examples to include in your article than the screen res example, but just an honest question here... Would you spend more time solving these two issues than writing your own engine? For one or two guys to make a solid cross platform engine will probably take at least a year and I think I'm being extremely optimistic. I'm not saying use Unity per se as once I get some good freetime I've been wanting to try other systems myself such as Polycode.

Nathan :)

Ameen Altajer
profile image
Unity has always been a great tool for indies to prototype ideas, nevertheless, Unity is becoming such a reliable tool with multiple platforms support and decent documentation.