Unity Meets Melbourne

I had the good fortune last night to visit the Kelvin Club as part of the IGDAM gathering and listen to the representatives from Unity discuss a few topics involved with Unity game development. Now, a lot of great developers I know couldn't be there, because there was very limited seating, so I decided to take some notes to bring back and share, and the easiest way to do that would be to dust off the "Game Design" tag on versamus, and make another post in regards to my bloody career!

The talk was divided into three sections: Project Architecture in Unity, Mecanim, and Unity5. Unfortunately the 2nd part, Mecanim, was not actually discussed due to technical issues (I believe they didn't have the correct cables? Though, how you'd go to such a presentation without at least a spare HDMI, VGA, DVI and all adapters between I'm not sure, but anyway). However, they did talk a good long while on the other two, which gave more than enough information. I'll summarise the points below and expand upon them where I feel necessary. If you want more information on any one point, just let me know in the comments or contact me via Facebook, email, or phone.

Project Hierarchy in Unity

• Began with a parable about a house with broken windows, and explained the relationship between a poor living environment and a poor mental space. Expanded this to include project hierarchy and organisation: if you maintain project cleanliness, you'll maintain project morale.
• The problem with almost every project in Unity (that is, problems to do with the actual in-engine stuff, not with the team, etc) is in its architecture. If the project isn't planned and built correctly, it will fall down.
• To maintain project architecture, they recommended several key points:
• Use C#, as it is a lot more responsive to the Console system within Unity and will make finding game breaking bugs easier.
• Use strict naming conventions.
• Use descriptive names, including what the asset is, where it is likely to go, and any immediately important information.
• Don't be afraid to use spaces in asset names - Unity has no qualms with this.
• Use a strict and logical folder structure*.
• Maintain zero-tolerance for yellow warnings and red errors, and resolve them as soon as they present to prevent later back tracking.
• Maintain zero-tolerance for runtime memory allocation.
• Operate under a system of Core Application Logic (now please be advised that I didn't grab everything in my notes on this, as he did talk very fast, and was in a hurry to speed past the code examples. Thankfully they did provide us with the link to the examples, which I will post at the end of this article.)
• Use a Main Controller in your first scene.
• This controller will be used to manage all high level applications, such as level loading, caching resources, and dumping unused resources. Technically this sort of stuff isn't entirely necessary for PC projects, but will make mobile projects work infinitely better. It is, however, just good form to get into, and they advised it is best to always use as it will make cross-platform support a lot easier down the line.
• This should be placed in a blank scene at the very beginning of the project. It should be set to a Singleton Pattern, so that it exists throughout all levels of the game space.
• Now, here they talked about two aspects of Unity that I've never actually seen before, so I can't comment on them well - however, they will be the first thing I will investigate when I have some free time tomorrow: GC.Collect and Resources.UnloadUnusedAssets(). If you know either of these things, please let me know in the comments, as they intrigued the hell out of me.
• Basically, they seemed to be used to reclaim memory from unused objects within the game space. I don't know how they go about doing this, but I feel a closer inspection of the example code would help.
• They specifically called their states in an Array of Delegates, which you can see in the examples, which was very intriguing.
• Furthermore, they touched on the Unity "Profiler", which is an in-engine aspect which tracks performance. This will be invaluable to test these memory saving techniques, as they have a heavy up-front load time, but will save on runtime loading.
• They recommended using script Controllers for every repeating part of a game, including Scene Controllers, Player Controllers, Enemy Controllers, Asset Controllers, etc. Essentially, anything that has one or more instances that need to be tracked (I.e., everything) should have a central Controller which is mapped to the static public.
• Each Controller should be mapped to a Singleton Pattern, so as to prevent multiple instances of the Controller.
• Next, and perhaps most intriguing of all, they discussed Pool-Based Objects. Pool-Based Objects work in lieu of Instantiation in a rather brilliant way.
• Instead of instantiating and destroying instances of a prefab in runtime (which is massively taxing on memory, as can be seen in one of Impossible Worlds' recent releases SprawlRunner), you begin a scene with the maximum number of the prefab that can appear on screen at any one time.
• Next, you disable all instances that shouldn't be visible at the beginning, and add them to a List.
• As the object would normally be instantiated, you move the object to its intended location, enable it, and run its Awake() function.
• At the end of its usefulness (like being killed in the case of an enemy, or going beyond visible space in the case of a bullet) the object is disabled, moved back out of the way of the scene space, and added to the end of the List again.
• This way, if you could have a maximum of, say, 60 bullets on screen at any one time, you could preload all 60 on start-up, and then use them in your Pool as needed without having to tax memory by instantiating them. You're only calling transform values, instead of drawing whole new objects!

* I'm going to be writing up a document which will contain all the hierarchy and naming conventions that will be used as a standard template scene for Impossible Worlds in future, so I will post up the documentation and even template project files once that is created.

As stated, Mecanim was not actually discussed, which was a great disappointment. Luckily there is plenty of information online regarding it, so it wasn't a devastating hit, but was still annoying.

Unity5

Most of what was discussed with Unity5 was just a rehash of the teaser presented earlier this year, but there were a few key things noted which were not shown in the video that are worth discussing:

• The new UI tools which are being implemented to streamline the Unity design process will be implemented into Unity4.x as well, so even if you can't get Unity5 right away, you can still access it.
• The WebGL platform (which is awesome) is currently only working in Firefox and Chrome, but they are trying to get it to expand to others at the moment.
• The scene view will now be in full HDR, so will look the same as your in-game environment.
• They are improving load times for the Unity Asset Store, a badly needed update.
• A new Physically Based Shader (which emulates, but doesn't suffer the horrendous lag issues of Physically Based Rendering) has been developed.
• This Shader has essentially every Shader input you could need for a Shader, all of this have their values exposed and toggleable.
• As such, instead of using several Shader types in a project, you can use the one, and customise it to its needs in engine.
• This looked very impressive, and will solve a lot of the problems with standard Unity Shaders looking like shit - however, I don't know what this is going to mean for custom Shaders in Unity, and if this is going to affect the standard Shaders already in place.
• There are multiple new types of Ambient lighting to scenes.
• The only two we saw were:
• Skybox Lighting, which mirrors the colours of the skybox onto a cubemap and reflects them from an object, which is rather cool.
• And a 3-Point Gradient Lighting, which allows you to choose three colours: Sky, Horizon, and Ground, and your scene will be coloured depending on object facings.
• For instance, if you have a Red Sky, White Horizon, and Blue Ground, and a model with its hand sticking out, palm down, the top of the hand would be lit by red, the finger tips by white, and the palm by blue, with a smooth gradient between.

That was essentially it, from what I gleaned. Here are the Unity examples I spoke of, and if you have any questions or answers to my own questions, please let me know via one of my billion contact methods!

Hope this was useful!