Cape Guy

Why I Decided to use Unity

By

I decided to use Unity early on in Cape Guy’s life. Here’s the thought process that led to that decision.

Why not use a Bespoke Engine?

I’ve worked with several game engines in the past (bespoke engines at Sony and Frontier Developments and Unreal Engine at Rocksteady Studios) and they’ve all had their positive and negative sides. Working with Unreal really opened my eyes to the value of a really good, unified, set of editing tools for games development. Bespoke engines, at least in my experience, tend to encourage heavy use of XML or, if you’re lucky, JSON files and A LOT of code to set things up.

Visual editors in bespoke engines are incredibly rare in practice as development of game features is almost always prioritised over development of tools. Bespoke engines also seem to grow tentacles at an alarming rate with special case data formats for this or that and, while they eventually have lots of incredibly powerful features, only a few people have the specialist knowledge to really use each of the features with each one having a steep learning curve – and no real documentation or internet resources to assist with that.

I think game engines are now complex enough and have enough standard features that using a middleware engine is almost a no brainer, I’m sure there ARE edge cases but I’ve never really been convinced by any claimed instances of it I’ve come across. The ‘but my/our game is different’ argument is the most common. My only real response to that is that unless you’re not going to:

  • use a game object system
  • render anything (and especially not anything fancy)
  • use animations (and blend them)
  • use skeletal animation (skinning, and physics)
  • have interesting audio
  • have physics
  • release on more than one platform
  • benefit from creating or editing any data in a visual way
  • need to worry about packaging your game up for release
  • bring anyone new onto the project later on

then I’d say the cost of using a middleware engine is almost certainly significantly lower than the cost of developing what you need from scratch, or even the cost of assembling middleware building block components.

You also have to ask yourself why you’re making indie games. Is it to make great, interesting, games where gameplay mechanics, story, and design are front and foremost or is it to make cool technology? Even if the answer to the last question is ‘to make cool tech’ then using middleware allows you to make cool tech which nobody else has rather than having to reinvent a thousand wheels which are already in every other game.

Why Unity?

The choice between Unreal and Unity for me was based on a few factors.

  • Planning for success means choosing a pricing model which works for you if you are successful. I think Unity‘s model is success friendly while being reasonably priced before you’re getting income.
  • Unreal‘s development edit and test cycle is one of the fastest I’ve worked with but Unity‘s is absolutely incredible.
  • Unity supports all the major platforms.
  • Extending the Unity editor to add your own tools and features is actually pretty easy.
  • Unity‘s asset store (and the wider internet) is full of really useful things, obviously not everything in there is great but I’ve been generally impressed with the assets I’ve chosen to use so far (IUnified, TouchConsolePro, Json .Net for Unity, MissingScriptResolver and Console Enhanced being a few examples) and I’ve written my own Unity testing framework which I use with TeamCity for continuous integration which works pretty well, though Unity has since provided Unity Test Tools which I will probably switch to using at some point.
  • Unity comes with extensive documentation and a large and active user community.

Obviously there are other engine options available (eg. Unreal, Game Maker, Stingray (previously BitSquid), Torque and CryEngine). Which one is best for you or your company can come down to personal preference or team size (if I was choosing a development engine for a large team, I’d probably lean towards Unreal). However, there are very few circumstances, possibly none in reality, where I’d suggest not using one at all. Even if you’re only planning on using a subset of the features they provide.

It’s not Just me

If you think you need a little more convincing here are a couple of supporting arguments from other developers: