Unity Caveats

From EQUIS Lab Wiki

There are tons of reasons to use Unity! However, there are also some reasons not to, and a few reasons that are often overlooked! Some of these are not necessarily reasons to not use Unity, but simply points to consider. So before you get excited and delete your XNA project, review this document to make sure you don't run yourself into a wall later on during a crucial time! Also, if you discover more stumbling blocks, please share them with the rest of the lab by adding it to this page! Thanks!

• Certain features require the Pro license. See here for details.
• Unity uses a modified version of the Mono Framework, which means that some very specific things will not work.
  • C++/CLI plugins will NOT work. Only native dlls or pure .NET assemblies work as plugins. C++/CLI only works on Windows, and so is not supported by Unity.
  • Most plugins compiled for .NET 4.0 and later will not work. Compile for .NET 3.5 or below.
  • System.Diagnostics.Process.MainWindowHandle does not work. In fact, trying to get access to window information through processes generally does not work. You can use P/Invoke to call native methods that do the same thing. For example, GetForegroundWindow. Keep in mind that this doesn't mean that you can't create and work with WinForms in Unity, if you feel the need to. Just add System.Windows.Forms.dll to the Plugins folder.
• There is no step-by-step code debugging support for Visual Studio. You'll have to use MonoDevelop to do this. MonoDevelop projects are fully compatible with Visual Studio, though line-ending policies might annoy you for a bit until you change them. If you feel compelled to use step-by-step code debugging, there's usually another way around it in Unity.
  • Debug.Log shows very detailed stack traces. Just click the output line in the Console in the Unity editor.
  • Enable "Error pause" in the Console!
  • Make use of the Profiler! In addition to game-side resource usage tracking, it will show a very detailed tree view of the amount of time spent in each method.
  • You can always pause and step through the game frame by frame.
  • Using logical inference and a process of elimination will be enough to pin-point the bugs with just a couple of comment-outs or Debugs. Try to play "Guess Who?" with your code.
• If you are making a 2D game, there will always be a little bit of extra work when creating or importing assets. Although if you're smart about it, you can limit this extra work to the beginning of your project. Carefully weigh the benefits of Unity against this extra work when you're deciding on a tool to use!
  • In most 3D games, the appearance of an object is determined by a LOT more than just one texture. More often than not, multiple interacting textures will be involved. This means that every piece of geometry has a material applied to it, instead of just a texture. Knowing how materials and shaders and textures all work together is important. This applies to OGRE and 3D XNA as well.
  • Most 3D game textures are not transparent, since they are wrapped around 3D objects that define shape. Therefore, the default Diffuse material in Unity is not suitable for 2D sprites, which use transparency to define shape. You can get around this by choosing a good material once, then simply cloning it for every new 2D material you need.
  • In most cases, you'll need to constrain Rigidbodies to move only along the X and Y axes, and to only rotate about the Z, if at all. Again, you can get around this by duplicating prefabs.
  • General advice: Embrace 3D! If you start thinking of the game scene as 3D (like real life), instead of trying to force Unity to become more like XNA, then all of the stuff above will become second nature to you. Study 3D game math for physics, lighting, audio, etc. It's quite interesting. Besides, the same techniques apply to any 3D game engine/API, and may be useful to you in the future!