And what an achievement that is! At time of writing,
The Food Run is only a week away from release.
It's our first project written in
Unity since we
moved away from programming in XNA late last year. We deliberately didn't go for something too ambitious - just a
2D puzzler to get us used to the development environment. We think it went pretty well but as is usually the case when learning something new,
the inevitable feelings of "if I could start again I'd do X, Y and Z differently..." were certainly apparent. Not all of the points in this
blog will be relevant to every first-time Unity developer out there, but if you are about to start the same new chapter in your game development
life that we have, and you have a couple of minutes to spare, take heed. Here are five things we wish we'd known
before we started Unity development...
1. Build a library of functions from the start
Thankfully we realised this fairly early on in the development process, and there aren't really any excuses for not doing it whatever language
you are programming in, assuming you intend to develop more than one thing in it. Thanks to a single folder named
"Battenberg Software Unity Functions", our second game can have its own configurable menu system imported into it, and generate custom message
boxes at any time with a single method call. And that's just the start - a library of functions should always be evolving, so no doubt our second
project will add more functionality that will give our third project even more of a head start.
2. Unity's built-in editor functionality is your new best friend
Already have a best friend? Get a new one, and make it the "UnityEditor" class! Seriously though Unity has some really powerful support for
modifying just about everything to do with its editor environment. You can even add your own menus to the top menu bar. The most useful thing
we discovered, however, was the ability to create custom property drawers which modified the view of the inspector window (for those familiar
with Unity, the inspector is the panel that by default is displayed on the right and allows the various properties of game objects to be
modified). You can read more on all that
here.
Spot the non-standard Unity menu (no prizes)
3. For 2D games on one single screen, the built-in UI functionality is better than using sprites.
Well that's our opinion anyway. In Unity version 4.6, a whole suite of user interface controls was introduced which caused much excitement
among the community because up until then it was something Unity had been lacking. And they're good! We found the "image" much easier to use
than the "sprite", which was the previous way of displaying 2D images. We also learnt the hard way that the two don't mix very well, so even if
you don't agree with this point, at least pick one or the other and stick to it :)
4. Screen resolutions are important... and well supported
For those of you developing PC games, the need to support multiple resolutions is essential. Only support a single one and you will most likely
cut out 90% of your potential audience immediately. Don't put the effort in (e.g. by just scaling the window to whatever resolution the player
is using) and your game will look unprofessional. Unity has good support for different screen resolutions, particularly with the UI components.
We found a combination of repositioning and a little scaling, whilst keeping the screen resolution within certain bounds worked well. Remember
as well that you don't need to support the idiot who tries to resize your game window to 1000 pixels by 3 pixels just for a laugh.
5. Develop, build, develop, build, develop, build...
As oppose to develop, develop, develop, finish project, build, why doesn't it work, panic, etc. One of the main selling points of Unity is its
ability to build on multiple platforms. But there are slight differences and there are bugs, so try to keep on top of them as you go along.
Remember whoever plays your game will never see the Unity editor that you are looking at day in day out - what they will see is what you output
to that final EXE file. It's also important to test a final build instead of confining all your tests within the editor environment.