My life as a Unity Developer

Hi, my name is Olaf, from experimental dev studio LabLike based in Warsaw, Poland and I develop games in Unity.

“Hi Olaf!”…

Yeah, there’s enough of us around to start a support group. Lots of stories to tell, experiences to share, and an occasional trauma someone needs to come in terms with. Usual stuff, it’s probably more or less the same with every development platform.

Unity, however, is currently the one that covers the majority of the most desirable territory of the game development industry – the mobile. Even in our very own Warsaw, Poland, not a month (if not a week) passes without someone launching a studio oriented towards mobile gaming, and Unity is the predominant tool of the trade. That’s why a lot of people keeps asking the same question:

Is Unity a good choice for a mobile developer?

The short answer it: yes. But if you’ve got a few minutes to spare, the elaborate answer follows, and you might take out something more from this entry. It’s based on the experience of developing an elaborate title such as our Magic Flute: Puzzle Adventure and releasing it on multiple platforms.

We’re in love with Unity at LabLike. It’s a wonderful canvas for all creative uses and most of the times working it is a pretty stress-free experience. There are a few things, though, that we bumped into on our way and I’d like to warn all aspiring Unity devs about them.

Framerate eaters and bug-ins

Our game was first released on iOS and porting to Android didn’t go as smooth as we were hoping it would. Among some minor quirks and bugs that weren’t hard to spot and eliminate, one issue made the Android port unplayable at first. The framerate loss was very noticeable as the game suddenly decided to run at 20fps. People will warn you about many framerate-dropping factors: lights, high-res textures, particles and such. But in our case, the problem turned out to be related with shaders. Not the very use of shaders, but the fact that we used both new “standard shaders” and “legacy shaders” at the same time. If you do that and see a crippling framerate drop in your game, limit yourself to legacy shaders only. Once we did that, we got the game running at stable 60fps. Standard shaders – it would seem – still have some due optimization.

Then there’s the topic of plug-ins. Or as we like to call them now: bug-ins. The asset store will try to tempt you and seduce you with all sorts of fancy „ready-to-go” modules. You can easily get the idea that using one as your game core mechanics will be the shortest way to success. Well, it’s not. Don’t do it. Keep your core mechanics your own. There’s just too much riding on it to take a gamble.

It’s nice to have extra features in the game, and I would suggest using plug-ins for those. But not for your core functionalities. All the programming effort it will save you will be just relocated into tweaking the plug-in, hacking it to do your bidding, and fixing the bugs it will cause. If you’re lucky – it will even out. If you’re like us – you will end up doing three times as much work. We’ve made a mistake of using tird-party pathfinding mechanics in our Magic Flute: Puzzle Adventure. During development 4 out of 5 bugs and problems turned out to be directly or indirectly related to the pathfinding plug-in.

We managed somehow, sure. But then, with the plug-in’s update to Unity 5 version, the API was changed to an extent that forced us to code all the tweaks and fixes for a second time, practically from scratch. Never again.

Bumpy road to love

But all that is very specific, and if you’re reading this post, you are probably one of those aspiring devs looking for a recommendation if they should pick up Unity as their main development tool. Again, my answer is: yes, absolutely! Unity has its downsides, quirks, and limitations – just like any other development platform – and you’ll run into something that you’ll need to work around at least twice a week in your process. But there are two things that make Unity my personal tool of choice, and something I feel quite comfortable recommending to other developers.

Unity is user-friendly and accessible. The skill entry level is lower than with other engines such as Unreal or Cry Engine. If you ask me, the workflow was easy to grasp, and once I did, doing new things became quite intuitive. So, that’s perk number one. Working in Unity quickly becomes… comfortable. And when it’s not? Why, that’s when perk number two comes into play. You can always count on help and guidance from the extensive community gathered around Unity development. You will run into trouble, sometimes. But there’s a good chance that a dozen people already came across the same problem and a solution has been found and posted in the Unity forums. The Unity hive-mind might be the greatest asset of the platform, and I’m happy to be one of its voices.

The outtake

Bottom line: the life of a Unity developer is not pure bliss. That’s not how development works – regardless of the platform. But if you’re looking to pick your primary engine and you require accessibility, good support, and a balanced workflow, Unity is the one I would recommend. Since it’s available for free, without any limits to functionality, you risk absolutely nothing taking it for a spin!

Oh, and: no. This post was in no way sponsored or endorsed by Unity. We made a pretty extensive game, published it on both App Store and Android, and now we’re nearly done making a PC version that’s soon headed to steam. All that was relatively hassle-free and… well, I wouldn’t go as far as saying “easy”. But after our first release we have more multi-platform Unity projects – a few smaller ones, and one really big – in our pipeline. So yeah, I’m quite enthusiastic about the platform.