Wednesday 22 August was the first day of the Unite12 Unity conference in Amsterdam, which I was lucky enough to attend. My first thought was Unity is larger than I thought – the conference was packed. A couple of sessions saw people sitting on the floor. The official attendance was 1200, over double my expectation (although 200 of that number are Unity employees). Also surprising, a nice lunch and breakfast was provided.
Day 1 notes from the sessions I attended are below.
After discussion of Unity’s popularity, the CEO showed off a large number of published games created with the tool. This included a few modern, well known and polished titles. Endless Space and Universe Sandbox particularly surprised me as Unity games.
The demos of Unity4 looked particularly impressive. I don’t think a small Unity developer like me need to worry about performance or premature optimisation as the tool is obviously plenty fast enough.
A new GUI system featured among some demos of future work (in alpha now, probably not in Unity4, but the version after). This is quite exciting for me. However, at 3-6 months before being available in beta, I think it will come too late and I need to continue with NGUI.
Peter Molyneux talked about his current work (using Unity). It is permanent, multiplayer online game about eroding a cube to see what is inside – not really my thing. What grabbed me about his talk is his motivations. Molyneux said that the common theme in his work is the creation of little worlds. Very similar to my ambition. He also said that games should be “simple, delightful, surprising, engaging and unique”. Sounds like good advice.
Performance Optimisation Tips and Tricks for Unity:
Use structs in preference to classes were appropriate as structs go on the stack and classes on the heap. Thus using structs results in less garbage collection and associated pauses.
Don’t put stuff in Update() that doesn’t need to be there.
Instantiate/Destroy can be slow so try to avoid their excessive use. Instead deactivate objects and keep them for reuse.
Cache UnityEngine method calls like transform. This has often been said, but here they explained why. GameObject.tranform is a .Net property not a field, that does a number of matrix multiplications and other calculations in order to derive the GameObject’s position relative to its parents.
Prefer primitive colliders over Mesh colliders.
Time.fixedDeltaTime can be used to change the time granularity of physics calculations. This is independent of non physics updates.
Never move a collider without a rigidbody. This is a static collider and every time such an object is moved a large number of calculations are performed.
Use texture atlases (multiple textures stored in a single image) if bound by Draw() calls.
Desktop machines should be able to handle a few thousand Draw() calls (mobile devices an order of magnitude less).
Building Realtime Multiplayer Titles with Unity and Photon:
Photon provide a socket-based game networking library similar to what I had planned. They also provide a cloud service for the server-side of game engines, with a small free option – worth a trial.
Load balancing seems to be achieved via a login server passing off connections to different game servers.
They suggest ConcurrentUsers x 10 = DailyAvgUsers x 10 = MonthlyAvgUsers << downloads
Hardware costs are likely to be quickly swamped by network traffic costs in online games. So the lesson here is to minimise the size of and number of network messages in your game.
Roadmap and Wish List:
This seemed to be more about making suggestions to participants as to what should be worked on and then getting feedback. Good to see that Unity is listening to the community.
An integrated debugger and editor (replacing MonoDevelop) seemed popular (much clapping). A Linux editor suggestion garnered no noise, so it probably won’t happen soon.
Integrated version control (starting with Subversion) and depreciation of the Asset Server got some applause. As did being able to serialise Dictionaries. Both are things I could use.
Supporting .Net 4 raised many hands, but it was unclear what benefit such work would bring.
Aliens vs Predator: Tools and Techniques:
Postmortem on a game coming out in a few months. Chose this opposed to GUI session as that is too far away from release to be useful for me.
Set up a condition/action system similar to something I have created. The difference is their conditions are GameObjects and so exist in the scene. This is handy for editing during gameplay, but soon got so many they cluttered the hierarchy. They had to write special tools just to manage them, but found no performance impact.