Automatic F# Compilation in Unity

I was playing around with F# and Unity integration and there are some nice examples out there  but they all relied on compilation systems outside of Unity, build some .dll in Xamarin then drop it into a Unity project.  Cool, but it’s not usable if we don’t hook into Unity’s build system and get a fresh build every time we edit a .fs file.  So, I decided to explore doing just that with UnityEditor.AssetPostprocessor.  When you implement a AssetPostprocessor you get called with a message every time you reimport an Asset.  This happens when the file gets touched on disk.  So what we can do with AssetPostprocessor is recompile a .dll full of F# code whenever a dependent F# file is edited.

Here is example code of that method:

In order to actually use this you’ll need to build a target in MonoDevelop for a .dll that will contain this AssetPostprocessor.  Put that .dll in your project’s Assets.  You’ll also have to make sure that your Unity project has FSharp.Core.dll as an Asset if you want to use your F# code.  I had luck using version 2.3.0.  You can check the version with “monodis –assembly <path to dll>”.  The build rule will have to be made a bit more robust if you wanted to compile something with a more complex dependency tree of course.  If you need help making MonoBehaviours in F#, this will help.

Sorry I didn’t didn’t post this on Github.  There is a considerable amount of work to make this idea handle most cases.  It served my purpose as is, maybe I’ll package it up later.

Auto Updating Custom Inspectors for Unity

The Problem:  You wrote a custom inspector for Unity, subclassing the Editor class, after using the inspector you found that it is only updating when you interact with it.  Values are changing continuously during Update() calls from the MonoBehaviour so there is no other event with which you can tie your inspector Repaint().

Solution:  I’d recommend tying your Editor.Repaint() to some event if possible, but if not I’d recommend putting a lambda on your MonoBehaviour which gets conditionally called if you are running your code in the Unity Editor inside your Update method.  Inside your inspectors OnInspectorGUI just set your targets lambda to something that will call your Editor’s Repaint Method.

Code:

 

Calling C Functions from Unity on Mac OS X/iOS

The Situation

At work I found myself needing to call previously written Objective-C code from Unity for an iOS app.  My options were to rewrite the code in C# or find a way to call the code from Unity.  I opted for not rewriting the code.

When looking around you’ll find ways to call C code from Unity on iOS apps using [DllImport(“__Internal”)]  This requires that when you build the app to device; the symbol you are referring is inside the executable somewhere.  Since on iOS dynamic libraries are verboten, this is your only option for iOS apps.  So just generate your xcodeproj, then edit it to link in your library that contains the C symbols you want to call from Unity.  This works but it will require that you build to device anytime you want to test your code that calls your C functions.  Unacceptable!  Especially since building to the iOS Simulator doesn’t work in my experience.

The other option is to make your library compile to a static library for iOS and a dynamic library for Mac OS X.  That way inside of the Unity editor we can load in the Mac OS X dynamic library to call the code without building to device, awesome!  There are a few gotchas though:

  • make sure your library is fat i386 and x86_64 (in my experience it only has to be i386 but I imagine this will change eventually)
  • you’ll need to have Unity Pro if you want to plop your library into the “Plugins” folder to have them magically distributed (if you are building for iOS this doesn’t matter anyways since you wont be distributing your dynamic library)
  • you’ll have to rename your library from “libfoo.dylib” to “foo.bundle”, the key part being the .bundle, it’s an error in the Mono runtime that they say will get fixed some day
  • if you aren’t using the Plugins directory you’ll have to put your library someplace where Mono can find it, like “~/lib”

The Code

The calling MonoBehaviour (NewBehaviourScript.cs):

The C code (foo.c):

The dylib Makefile:

shell command to put dylib in findable location:

 

References

 

Coming Back to Unity After Pause

Screen Shot 2014-10-10 at 4.46.16 PMI’ve had a few side projects going on for a while.  One was a clone of Bump n’ Jump in Unity to get a feel for Unity development.  I set it aside to work on other things, but because of developments at work I’m going to have to start playing with Unity again so I picked it back up to get back into the groove.  Today I’ve written a Breakout clone and I’ll record a few observations about Unity.  You can find the Breakout code as of this article: Breakout or checkout HEAD in case I’ve decided to do more cool things with it: Breakout HEAD

  • It’s hard for me to be so removed from performance.  For instance there is no way to inline a method.  I guess .NET and mono have it now but it hasn’t made it’s way to Unity 4.6 yet.
  • It’s difficult to layout the code conceptually.  In the Breakout clone I put most of the logic for the game into the BallController.  He is the guy that knows the most and is the controlling factor for the game but it feels weird for him to be the arbitrator of the score and game state.  I think an empty GameObject for the game who listens to the balls events would feel cleaner to me.
  • The 4.6 UI tools are very nice.  It’s easy to get UI pixel perfect on screen.
  • On that note, I had a hard time getting the coordinate space to pretend to be 640×480.  Maybe I was fighting the system a bit but 640×480 seems convenient for me to think about when making a 4:3 game.
  • MonoDevelop is horrible.  I had to turn that off, it can’t even kill and yank correctly.  I’m now using a combo of Emacs/omnisharp-mode.  Maybe I’ll make a blog post about this setup later.
  • There is some magic that has to be done to get Unity to behave well with Git, this guy on StackOverflow laid it out nicely: How to use Git for Unity?
  • Breakout has such a well define physics, it was interesting to consider if I should use Unity’s 2D physics or to roll my own.  I eventually opted for rolling my own instead of trying to hack the physics engine.  It would have been nice to be able to use the Colliders by hand without the physics but I didn’t see a nice way to do that, so I had to throw them out as well.
  • Levels in Scenes or XML?  I just have one level right now but it was somewhat tedious to lay it out by hand in the editor (especially because of the coordinate system).  But it was convenient to be able to see the results and if I had 30 different levels to able to click through them and see them would be helpful.  It seems like I haven’t found a good answer in Unity about when to use Scenes and when to use XML.

Now I’m feeling a pang to post this for the Unity Web Plugin so we can all play with it.  Hopefully I’ll get around to that to spare you the trouble of loading up Unity.