Unity is an engine built around the concept of rapid prototyping and iteration. If you have a basic idea you want to try out, you can usually have a proof of concept up and running within a week or two. Once you have a prototype built, you can then quickly make updates and fixes, to prove out if the idea is fun or not. Unity accomplishes this through a clean editor interface that allows you to run the game within the editor, and a rapid build process, where assets are converted and saved for platform deployment as they are changed or first imported, allowing for iterative builds for iOS and Android to be extremely quick.
Unity also has an asset pipeline that encourages content creators to work within the Unity editor, and get their assets out of their 3D modeling program, 2D texture creation program, or other content creation program as quickly as possible. With previous engines I have worked with, artists would assign materials, shaders, shader properties within Maya, export that data out of Maya, and the build process would convert the data for each platform to be run with the game. This meant that each new shader feature had to be implemented in the Maya tools, in the Maya export tool, in the build process for each supported platform, and in the game engine for each supported platform. Unity gets the content into Unity so quickly it took tasks that took me more than three weeks in previous engines to less than ten minutes. Putting much of this content editing within Unity gives engineers a single place to implement new features: as a script within Unity itself.
Another huge boost to iteration time for Unity projects are Unity editor scripts. Unity has a whole range of functionality for engineers to build tools that run within the Unity editor. During the course of development for almost any game, you will run into a highly repetitive task that needs to be done to a large list of assets. Instead of having someone spend hours running this task over and over on all of these assets, an engineer can quickly write a script that does this process automatically. While building a game, you will also find small one off things that are done often enough they are worth writing little scripts to solve. A common one I’ve seen here is a menu option to erase all save data. While yes, you will probably want to build this into your menu flow within your game, the process of run game, delete save, stop game, run game again with deleted save is a hassle, and it is much easier to have a process of editor menu, delete save, run game.
The multiplatform focus of Unity also benefits projects in a few ways. Sometimes, you have an idea for a game, but aren’t quite sure where it will fit. With Unity you can easily experiment with different platforms and see where it plays the best. Maybe you start a project focused on one platform, but through the course of development, decide it’s the wrong platform. You won’t lose months of work, and shifting platforms can be a quick process. There is also a bit of future proofing in this process. You can bet that the Unity development team stays on top of new and emerging platforms, if something new comes out you only have to download the latest version of Unity, instead of spending months and months engineering that platform into your pipeline. The biggest benefit to the multiplatform focus is you can just release your game everywhere. There is not a lot of benefit to exclusive platform releases nowadays, so why not take your Unity project and put it on every platform you can get your game to play well on?
There are some things to be aware of as you start Unity development. Everyone’s first few weeks with Unity involves wide eyes and a feeling of “If we had that on screen in one week, we can finish an entire game in a month!” Having a strong, quickly built prototype does not put you any closer to a finished, shippable game. Chances are for that first prototype, you put together a couple game objects, components, and had a fun micro-experience built out. From here it is still a lot of work to add in menus, more levels, more content, plugins, and finish building your game. Many teams mis-schedule their first Unity project due to past experiences with other technology. Chances are in most engines, by the time you have a character running around on screen, with a first pass prototype of the gameplay, core back end systems such as character factories, basic menu flow, basic level flow are built. It’s easy to compare that to your Unity project, and say “If we got here in two weeks, and it took us six months on our previous tech, then we should finish this game in no time!” There is still a lot of work to be done to make a complete game. You will need menus, lots of menus. You will need a UI solution for those menus and your HUD. You will need a character factory of some type. You will need to a source control solution. You will need localization tools if you intend to ship your game in more than one language.
It is also worth your time to learn what Unity is really good at, and not so good at. Unity is especially good at games that follow a more traditional design flow of menu -> gameplay level -> menu, with set scene transitions and points you can load and unload content. The scene system, and resource systems play extremely well with this style of game design. Unity does not play as nicely with builder style games, where everything takes place in different menus that slide in over the core game scene. This does not mean that Unity cannot handle this style of game, it just means you will have to spend more time building the tools and technology for this style of game. Memory and asset management for game designs like this take a lot more fine tuning.
The highly portable, and rapid iteration nature of Unity also makes it easy for developers to fall into bad work habits. Because the Unity editor allows for content creators to make and view changes so quickly, many developers can easily fall into the loop of implementing and testing changes for iOS and Android games nearly exclusively on their PCs and Macs. There is a huge performance gap between a Mac able to run the Unity editor, and the lower end iOS devices you might intend to support. It is very easy to dive too deep, build a game that runs and plays great on your Mac, with the intention of getting everything good on iOS once the game is complete. You might find that your game is using four times as much memory as you have available on device, or your framerate is so poor you do not even know where to begin. Strong development practices can prevent these problems from happening. I recommend you test on device often, and treat performance problems on device as highly as you would treat golden path and crash bugs.
I have really enjoyed the last couple years of working with Unity to build games, and I recommend anyone curious about it just download the editor and start poking around.