It's amazing how long these end up taking, but I thought I'd share part of my answer to the following question.

Q: [Give details/examples etc of] A genuine passion for C#.Net development.

A: My wife has been using an iPhone app called Baby Tracker to keep track of my newborn son’s activities. Unfortunately the app has limited display options and no export functionality. I worked out that the app uses an unencrypted SQLite database to store its data. I am currently writing a .Net 4 WPF app using MVVM to display the domain data extracted using Fluent NHibernate in Visual Studio 2012.

Google tells me that lots of other people are trying to get data out of this app. If it turns out to be any good I'll OSS it and see if anyone wants to use it.

What is MonoBehaviour?

MonoBehaviour is the class from which all scripts attached to objects that exist in a scene derive from. What seems strange to many seasoned (non-Unity) programmers when they first encounter this beast is that all its methods seem to be missing. MonoBehaviour inherits from Behaviour which inherits from Component then from Object. None of these have the methods we're used to seeing, namely Awake(), Start() and OnGUI().

These are magic methods, summoned directly from the dark Unity overlord. Or, more likely, via reflection. Unity checks if your class contains any of these methods and will call them when appropriate. In the interests of clarity, from now on I'll call these methods 'Overridable Methods' as the Unity documentation does.

So back to the thing that irks purist programmers; Unity is using reflection here, so it skips the usual processes used to allow or exclude other classes from accessing methods. As you can see on the default class created by Unity.

    void Awake()
    {
    }

This methods is private, so nothing outside the class should be able to call it. But obviously stuff can otherwise nothing would work.

One way to think of it is the following.

public class MonoBehaviour
{
    public virtual void Awake()
    {
    }
}

public class MyMonoBehaviour : MonoBehaviour
{
    public override void Awake()
    {
    }
}

Then imagine the Unity Engine doing something like this

foreach (MonoBehaviour baseClass in listOfAllMonobahaviours)
{
     baseClass.Awake();
}

If you start of just using the default Unity created classes, it may take you a while to realise how many MonoBehaviour overrideable methods there actually are. At latest count there are 49 'Overridable Functions' that Unity uses. A full list of them is here. 

Now, don't let the fact that Unity magics up these methods for you discourage you from programming in a traditional manner. That is, you can still utilise inheritance in the manner that you might like to. The thing to remember is that the Unity engine is the only thing that will call these methods in an improper way, everything we do manually will work as expected.

For example, the classic 'new' vs 'override' issue.

public class BaseClass
{
    public void DoSomething()
    {
    }
}

public class DerivedClass : BaseClass
{
    public new void DoSomething()
    {
    }
}

Which method gets called depends on what the type is when we call it. I.e.

        DerivedClass newClass = new DerivedClass();

        newClass.DoSomething();
        (newClass as BaseClass).DoSomething(); 

...will call different methods. But in Unity, it doesn't matter what modifiers you add to your MonoBehaviour overridable methods, Unity will treat them as if you used

    public override void Awake()
    {
    }

...and call the Awake() method of the highest derived class.

Manually though, it all works as expected. You can hide and override to your heart's content for these overridable methods, but just accept that whatever you do, Unity doesn't care and will still treat method as having been declared as an override (even if it's private). And note that you can manually call all these methods, and if you do they will be treated exactly as you would expect in non-Unity programming. But it's probably best not to for the sake of clarity.

An exception to that rule however might be if you have a derived class and you want to call an overridable method in the base class. I.e. In the Awake() method of the derived class you manually call base.Awake(). Since the base class's implementation of Awake will never be call by Unity (since it will always be overridden) this seems ok.

Execution Order

However, it's worth noting that the execution order of the overridable methods is random. You cannot guarantee the order in which they are called. If this is a problem for you, I'd recommend just creating your own update method, MyUpdate() and then have a controlling class call them manually.

public class MyMonoBehaviour : MonoBehaviour
{
    public void MyUpdate()
    {
    }
}


public class MyController : MonoBehaviour
{
    void Update()
    {
        foreach (MyMonoBehaviour myMonoBehaviour in this.listOfAllMyMonobehaviour)
        {
            myMonoBehaviour.MyUpdate();
        }
    }
}

Namespaces and Inheritance

One of the other things that traditional programmers might notice is the lack of namespaces. Well, that's because Unity likes to pretend that it doesn't use namespaces, but it can.

The basic rule is that you can't put any MonoBehaviour derived class inside an explicit namespace, but that shouldn't stop you from using them completely.

Now if you do put a MonoBehaviour script inside a namespace you'll get this compiler warning. “The class defined in script file named 'MyScript' does not match the file name!” And none of the MonoBehaviour overridable methods (Start, Update) will be called because Unity will treat it as a normal class.

So what, you still shouldn't use namespaces right? Well, the documentation say no, but they are just so useful that I reckon you should anyway.

Having to give everything a unique class name for a project of any size is annoying to say the least. Now, for the MonoBehaviour classes we're screwed, but for everything else, go nuts. Now I tend to section off as much common code as I can into static libraries or helper classes, on top of using inheritance to concentrate common code in base classes.

For a simple example.

Create separate Constant classes for each level. Note: You can stick all these into the one file if you want. The requirements for Class name to match File name is only for MonoBehaviour classes.

namespace Level01 
{
	public class Constants
	{
		public const float Speed = 0.1f;
	}
}

namespace Level02
{
	public class Constants
	{
		public const float Speed = 0.3f;
	}
}

Create a Player base class and an abstract member (so it can be used within the class).

public abstract class PlayerBase : MonoBehaviour
{
	// Common code for Player

	public abstract float Speed {get;}

	void Update()
    	{
       		this.transform.position += new Vector3(0.0f, 0.0f, this.Speed * Time.deltaTime);
    	}
}

Then we create separate Player classes specific to each level. Each will import the required namespace and thus get access to the Constants for that level..

using Level01;

public class Level01Player : PlayerBase
{
	// Level 01 specific code for Player

	public override float Speed
	{
		get {return Constants.Speed;}
	}
}


using Level02;

public class Level02Player : PlayerBase
{
    // Level 01 specific code for Player

    public override float Speed
    {
        get { return Constants.Speed; }
    }
}

Note: Each of these is in a separate file.

Maybe a bit of a contrived example, but I'm just trying to show that you shouldn't throw away the traditional programming tools when you start working with Unity.

Note that I didn't have to make the base class abstract. Another option would have been to make the Speed property virtual and have the derived classes override it. But since we have no intention of actually using PlayerBase on a Unity object directly it makes sense to ensure it can never be used (Unity will spit it if you attach an abstract class to an object).

Performance

Finally a little word on performance. After I realised that I didn't have to use MonoBehaviours for everything, I started wondering about their performance overhead. Perhaps I should be avoiding them at all cost? Well it turns out that whatever overhead there is is almost negligible, at least according to my quick and dirty testing.

I created a scene with 1000 objects with a MonoBehaviour script on them and a task to be performed in their Update() methods, then another scene with only one MonoBehaviour class and an Update() method that did the same task 1000 time. I ran them both and measure how many times Update was called. The result? Pretty much the same. Now I'm not conclusively saying that there is no performance gain to be had by minimising MonoBehaviours, but in my opinion there are hundreds of performance tweaks you should look at first before considering it.

There is more info about what I'm trying to achieve on the other page, but I thought I'd talk a little here about what new and cool things I've learnt in the process.

Super fast serialization/deserialization

Maze rover is, as the title suggests, a maze game. Each level is a different maze. Alongside my Unity project, I've also had to make a level editor in order to draw the mazes. For this, I used pure C#, WPF, nothing to do with Unity. 

Here is a screenshot of the, incredibly ugly, level edit in action.

 I created a C# library, that both the level editor and the game would use, that contained my maze classes. Square, Bonus, Dimensions etc. The next question is how to get the info out of the editor and into the game.

What I'm talking about here is serialization/deserialization. I've already done a post on my final solution, protobuf-net, but it's interesting to document what extra technology I had to learn to get this to work properly.

The max size of my levels at the moment is 48 x 32 squares, or 1536 square. The way I've set it up, there is a maze container with a 2 dimensional array containing all the squares. My initial use of XML serialization wasn't very promising, with it taking hundreds of ms to deserialize in the game. With protobuf I think I'm averaging 10-15ms. Great improvement.

Dynamic Mesh Creation

After reading in the maze for a particular level, the next step is to create the maze. I initially started with creating pre-fabs of each type of 'square' and instantiating them one after another. But, as I suspected and is pretty obvious, this is not very performance friendly. Even if they are just simple squares, having 1000+ objects in a scene is just scary.

So, meshes. I didn't know much are creating meshes before I started this. But I looked at a few examples and realised that with a bit of maths, they are not too hard to create.

Here is a screenshot of the maze mesh.

Pretty simple, but dramatically more efficient that previously. Although I create the meshes using squares, they only contain the faces I need and each face is UV mapped as appropriate. In the pic above that is not shadows making the sides seem darker than the tops, it's just a darker texture. In fact, I'm not using any lights at all at the moment.

UIToolkit

For an in-game HUD solution I was initially going to use GUISpriteUI, which was created some time ago by Prime31, but when I went to check on progress he had released a whole new solution, UIToolkit.

Users of GUISpriteUI will understand how much better the new system is. No more mucking around with UvRects and ruining everything when your atlas is changed. UIToolkit uses TexturePackerGUI to do the work for you and, most importantly, now supports fonts.

So, long story short, 1 draw call now does all my HUD. In the pic below there are 13 HUD elements (not counting the FPS counter) that are all done in the one call. FYI - Crappy graphics are placeholder, don't freak out ;-)

If you've previously used GUISpriteUI and got frustrated by certain aspect, I highly recommend checking out UIToolkit. Things are so much easier and bug fixes and improvements are being added regularly. It's (kinda) open source, with Prime31 giving out GIT access to certain posters on Unity forums.

Stay Tuned

I will hopefully get some good feedback from releasing this prototype and it will all go in to making the game even better. Once I get the theme nailed down, I'll be looking around for artists to create the assets I need.

Hopefully we're looking at a release in the next few months.

NOTE: If you Googled this and are looking for a way to downgrade your iPhone while keeping all your data then this is not it.

Now, iOS is Apple's baby, and they are very protective of it. You will upgrade it as soon as possible, and if you think about downgrading it then you are a terrorist who has less right to live on God's green earth than a weasel.

This works fine for 99.9% of people with an iOS device. You plug your phone into iTunes and it installs the new iOS version for you and all is good. But for a developer it's not that simple because if you upgrade your iOS version then you also have to upgrade Xcode. This is a little bit of a problem for me because...

It's a 4.6 GB download! Because I live about 3km from my nearest exchange (and 6km from the CBD of a city with 1.2 million people!?!) my internet speed is crap. So when I sit down to start work for the day I can't really just quickly download Xcode and get to work. I have to put it on overnight, and then I forget to, then I'm back in the same position.

So, simple solution is to not upgrade until you have everything downloaded. Fine.

But, today I hit a problem where I want to restore my iPhone. Restore it to its current iOS version (not the latest). iTunes wont let you do that because it will, by default, restore the phone to the latest version.

But but, there is a trick. If you hold shift and press the Restore button you can choose which firmware version to install.

Magic, thank you apple. There is just one problem with this; iTunes automatically deletes old versions of the firmware, presumably to stop you doing what I'm trying to do.

So Google will helpfully show you the location where iTunes stores the files. On windows 7 it's in

C:\Users\USERNAME\AppData\Roaming\Apple Computer\iTunes\iPhone Software Updates

But you can look in there all you want because if there is a newer version of iOS out there, it will be empty.

Windows 7 is not helping me much here either, because a quick search of my whole system using Windows 7 new super duper 'I'll search but not everywhere and hide the options' method showed no IPSW files. That's the extension by the way, iOS firmware files look like this.

iPhone2,1_4.3.1_8G4_Restore.ipsw

So before I had downloaded the new iOS version, iTunes had helpfully deleted the old firmware, effectively forcing me to upgrate, or preventing me from using the device I own depending on your viewpoint.

But, before I gave up I fired up a DOS prompt and did a proper search of my system.

Lo and behold, there were my IPSW files. Lucky I am slack and never empty my recycle bin. So I went and looked in the recycle bin and there were my files (they actually show up with proper names when you look through the recycle bin). So I restored the one I wanted (iOS 4.3.1) and fired up iTunes...

Which then deleted it again of course. (I think it only deletes it when you hit Restore actually, but whatever...)

So I restored it again, copied it somewhere else then fired up iTunes again.

Then I was finally able to restore my iPhone to its current version. Of course, this wipes everything on the phone, which was fine for me because I'm just using it as a test device and don't care. A while ago I actually tried to downgrade my phone while keeping it's contents and I gave up. I wasn't sure if I would be able to restore my backup of all my contents after restoring the firmware since the backup would be a later version of iOS. I never tried it but I highly suspect it wouldn't work.

Old iOS versions are purged from the earth according to Apple. Wiped from history. You can't even find a link to old iOS firmware files on their website. The files are there of course, there is just no link to them. This site allows your to download old versions, with direct links to the Apple website and yet there is no information on the iOS Developer Center about where to get them.

I understand Apple's motivation for pushing their users to the latest version, but why does it have to be so impossible to do things slightly differently? Will the world come to an end if you downgrade the iOS version?

And we're developers for Pete's sake, sometimes there is a valid reason for having 6 devices all with different versions. I could understand iTunes doing what it's doing if there was a 'Firmware Control Panel' or something in Xcode that allowed us developers to do what we wanted. But there's not.

Crazy stuff Apple.

Now, I'm just the coder for this project, but if I was the owner I'd have called it version 2.0 at least, because a lot has changed since the original version.

It now has all ten events available, as well as bluetooth multiplayer support and a whole heap of improvements and bug fixes.

But getting it approved was not easy. A while ago I updated my 3GS to iOS 4.3 without thinking, and of course that meant that I had to update XCode to 4.0 to be able to build to device. Only then did I realise that perhaps this wasn't the smartest move after looking at the growing number of threads about the problems people were having.

One major problem was that the plug-in I used for bluetooth was definitely not compatible with Xcode 4.0. I used Prime31's 'GameKit Bluetooth/WiFi and Voice Chat' plugin. That runs some magic little scripts when you build in Unity to set up the Xcode project and they were broken. But, due to the awesomeness of Mr Prime31's service, after a quick message on twitter I was sent a beta of a 4.0 compatible version of the plugin.

So all seemed good, and the plethora of ad-hoc builds I'd done using Xcode 4.0 all worked fine, on iOS from 4.2.1 to 4.3.1 and iPod touch, iPad and iPhone. So we submit it to Apple and pretty soon get a rejection letter.

We found that your app failed to launch on iPhone 4 running iOS 4.3.1.

We encountered the issue when selecting the application on the Home screen - the app displayed a launch image then quit unexpectedly. This may be because iOS 4 uses a watchdog timer for applications; if an application takes too long to complete its initial startup, the operating system terminates the application. 

For information about the watchdog timer, please see Technical Q&A: Application does not crash when launched from debugger but crashes when launched by user..

Another possibility could be a missing entitlement. For more information, please see the Technical Note: Resolving "0x800003A", applications not launching and "missing entitlement".

For discrete code-level questions, you may wish to consult with Apple Developer Technical Support. Depending on your questions, be sure to include any symbolicated crash logs, screenshots, or steps to reproduce the issues you’ve encountered.

To appeal this review, please submit a request to the App Review Board

I had no idea what was wrong, and the documents that Apple linked to were not very helpful. But, I figured that maybe I had messed up in the signing process and used the wrong distribution profile or something. So I re-did it carefully and tried again. Nup, still rejected.

Then we finally found this thread on the Unity forums. Luckily I still had the Xcode 3.2 installer. So I installed that and re-build in Unity with the target SDK set to 4.2 and re-submitted.

Success.

Bloody hell Apple, you sure don't make it easy for us developers. Between the provisioning profile clusterf*ck, the insanely diffucult iOS downgrade process and the almost five gig Xcode downloads for even miniscule version updates, the world of Android development is looking better and better. 

But you're still where the money is... and that's why we love you.

Some Background

As part of a new game project I'm working on, I had to store level information in a file and read it in for each new level. I had created a simple level editor as a windows WPF C# project and then I would serialize my level model class onto the file system then include it in my Unity project to be loaded in during runtime.

I initially used simple XML serialization, but as the levels increased in complexity it was taking longer and longer (well, 100s of miliseconds, but every bit counts ;-) to deserialize. So, off to the web to find the fastest and easiest serialization. The best candidate was Marc Gravell's protobuf-net, which provides 'Fast, portable, binary serialization for .Net' using Google's protocol buffers technology. And he's not kidding on the 'Fast' part either, see the performance stats here.

So I grabbed the library, chuck it into Unity and start testing. It worked in Unity Windows, worked in Unity Mac but when I deployed it to my iPhone I hit this:

ExecutionEngineException: Attempting to JIT compile method

Now, I'm no expert on the inner working of .Net and it's relationship with iOS running Mono, but according to this thread on the Unity forums, the culprit is the JIT (Just in Time) compilation of classes that have not been seen by the system before. Mono on iOS is an AOT (Ahead of Time) only system, so that's why it craps out. I'm sure smarter people than me could provide a better explanation, but that will do for now.

So, I emailed Marc Gravell for help because he mentioned in this thread that version 2 of protobuf-net would have a 'pre-compile to dll' option, meaning that the serializer/deserializer classes can be pre-made in a dll instead of on the fly (and JIT'ed). I think that's how it works.

Anyway, he sent me an alpha version of a Unity iPhone friendly protobuf-net and that's the one that works. Woohoo.

I also have to say that this is all info that Marc sent me so all credit goes to him here. I wouldn't know a protocol buffer if it came up and bit me in the arse to be honest.

The Solution

First up, download the alpha version of the protobuf-net libraries. The link Marc sent me is this one but go check out the site to see if there is a later version.

This contains two libraries, the 'Light Framework' and 'Full Framework' versions of protobuf-net. The basic procedure is this:

• Create a library dll (assembly) of the model classes you want to serialize/deserialize. That is, just create a new 'Class Library' Visual Studio project and have it contain only your model. (I don't use MonoDevelop but I'm sure it's a similar process). You will have to reference the 'Light Framework' dll in this project in order to use the  [ProtoContract]/[ProtoMember] attributes, described in the Getting Started guide. Build this project to produce your MyModel.dll.

namespace ProtoTest
{
    // Simple model classes, with some inheritence and generics thrown in. 
    [ProtoContract]
    public class MyModel
    {
        [ProtoMember(1)]
        public int int1 { get; set; }
        [ProtoMember(2)]
        public TestEnum enum1 { get; set; }

        public List intList { get; set; }
        [ProtoMember(3)]
        public List floatList { get; set; }
        [ProtoMember(4)]
        public List stringList { get; set; }

        [ProtoMember(5)]
        public List anotherClassList { get; set; }
    }

    [ProtoContract, ProtoInclude(10, typeof(DerivedClass))]
    public class AnotherClass
    {
        [ProtoMember(1)]
        public string string1 { get; set; }
    }

    [ProtoContract]
    public class DerivedClass : AnotherClass
    {
        [ProtoMember(1)]
        public float float1 { get; set; }
    }

    public enum TestEnum
    {
        run,
        walk,
        skip
    }
}

Note: Make sure your model project is set to .Net 2.0 in the project properties, otherwise Unity will throw up the following error:

Unhandled Exception: System.TypeLoadException: Could not load type 'System.Runtime.Versioning.TargetFrameworkAttribute' from assembly 'MyModel'

• Next you need to create the serilization/deserialization classes. So create a new 'Console Application' Visual Studio project. Now, for this one you need to reference the Full Framework protobuf-net library as well as obviously your newly created MyModel.dll assembly. 
• Now you need the code to create the libraries.

var model = TypeModel.Create();

model.Add(typeof(AnotherClass), true);
// Note: you don't need to add DerivedClass here, in fact it craps out if you do. 
model.Add(typeof(TestEnum), true); 
model.Add(typeof(MyModel), true);
model.Compile("MySerializer", "MySerializer.dll");

• This will output 'MySerializer.dll' 

• Now we have our serialization library that we can use in our Unity project. So now you have to add three assemblies to your Unity iPhone project:
  • MyModel.dll
  • MySerializer.dll
  • Protobuf-net.dll (Light Framework)

And we're good to go.

To serialize the files in my external application, I used the following code. I haven't played around with writing files to the iOS file system so I won't post that code, but I'm sure it's similar once you get the paths correct.

MyModel myNewModel = new MyModel();

MySerializer mySerializer = new MySerializer();

using(var file = File.Create("TestFile001.bytes"))
{
    mySerializer.Serialize(file, myNewModel);
}

In my case I was creating my game level files in an external application, so having the libraries external was actually more convenient. Once I had run my level editor app and created the binary serialized output files, I figured the easiest way to load them in Unity was via TextAsset class. TextAsset can be used to load files from the Resources folder just like any other resource, and despite the name, it is also fine for binary files. 

Note: From the Unity docs on TextAsset

If you're using the text asset to contain binary data, you should make sure the file has the .bytes extension. For any other of the extensions the TextImporter will try to strip nonascii characters if it is unable to parse the file as an utf8 string.

So inside our Unity project scripts, to read in the binary file we just use this.

TextAsset textFile = Resources.Load("TestFile001") as TextAsset;

MySerializer mySerializer = new MySerializer();

MyModel readInMyModel;

using (System.IO.Stream s = new System.IO.MemoryStream(textFile.bytes))
{
    readInMyModel = mySerializer.Deserialize(s, null, typeof(MyModel)) as MyModel;
}

I had a look via Reflector and the second parameter to Deserialize() there is used in case your type variable is null, so I assume you can use either one.

And there you have it. A bit more work than just using a library directly, but if performance is an issue then it is well worth the effort. I haven't done proper metrics yet, but from a quick look it seems at least an order of magnitude faster than the XmlSerializer I was using before.

Edit: In response to the comment below about not being able to use Vector3.

    [ProtoContract]
    public class MyVector3
    {
        [ProtoMember(1)]
        public float x { get; set; }

        [ProtoMember(2)]
        public float y { get; set; }

        [ProtoMember(3)]
        public float z { get; set; }

        public MyVector3()
        {
            this.x = 0.0f;
            this.y = 0.0f;
            this.z = 0.0f;
        }

        public MyVector3(float x, float y, float z)
        {
            this.x = x;
            this.y = y;
            this.z = z;
        }

        public static implicit operator Vector3(MyVector3 v) 
        {
            return new Vector3(v.x, v.y, v.z);
        }

        public static implicit operator MyVector3(Vector3 v)
        {
            return new MyVector3(v.x, v.y, v.z);
        }
    }

Now, the manager-type scripts that are attached to our Unity GameObjects are essentially Singletons. I usually call them 'MonoBehaviour Singletons' because they usually exist just once and need to be accessed from all over the place. I'm talking here about things like a class that manages all the playing of sound for a particular scene. You create a script called, for example, SoundManager and attach it to a GameObject in the Unity Editor and it is the single point of sound management throughout your scene. What I'm talking about here is how to access that script from wherever you need it.

So here is our little SoundManager class that we want to access. It just has a single method, PlayClickSound().

public class SoundManager : MonoBehaviour
{
    public void PlayClickSound()
    {
    }
}

Direct Access

Now of course, the 'easiest' way to access that script is via a call to GameObject.FindObjectOfType or, if you have several classes of the same type, GameObject.FindWithTag where you have 'tagged' each gameobject differently.

(GameObject.FindObjectOfType(typeof(SoundManager)) as SoundManager).PlayClickSound();
// or
(GameObject.FindWithTag("Sounds").GetComponent(typeof(SoundManager)) as SoundManager).PlayClickSound();

But, calls to these methods are expensive and you absolutely do not want to be calling them often.

Keep a Reference

The first solution that is in the documentation is to call those expensive methods once in the Awake or Start method of each script that needs them, then store the reference for all further calls.

public class TestClass : MonoBehaviour
{
    SoundManager mySoundManager;
    bool needToPlaySound;

    void Awake()
    {
        this.mySoundManager = GameObject.FindObjectOfType(typeof(SoundManager)) as SoundManager;
    }

    void Update()
    {
        if (this.needToPlaySound)
        {
            this.mySoundManager.PlayClickSound();
        }
    }
}

From a performance perspective, that's pretty much all you'd need to do (unless for example you are doing this from a 'bullet' script and creating many bullets a second) and I'm sure you all know that, but I'm looking at it from a maintainability and ease-of-use perspective. With even a small project, the code above is going to be copied many times.

Singleton Manager

In my opinion, the lesser the code the better. So, what's next? Create a static class that holds this code that we can access from anywhere. Since this class is controlling our access to the MonoBehaviour 'Singleton' manager classes, I've called it the SingletonManager

public class SingletonManager
{
    public static SoundManager GetSoundManager()
    {
        return GameObject.FindObjectOfType(typeof(SoundManager)) as SoundManager;
    }
}

Then in our classes we can access it like this:

public class TestClass : MonoBehaviour
{
    SoundManager mySoundManager;
    bool needToPlaySound;

    void Awake()
    {
        this.mySoundManager = SingletonManager.GetSoundManager();
    }

    void Update()
    {
        if (this.needToPlaySound)
        {
            this.mySoundManager.PlayClickSound();
        }
    }
}

This is better in my option, but still not perfect. There is still a lot of code repeated in each of our accessing classes. The less code in our classes, the easier it is to see what is happening and the easier the maintain the code.

Singleton Singleton Manager

So, another option is to make our SingletonManager a classic singleton and have it store the references to all the MonoBehaviour singletons.

public class SingletonManager
{
    private static SingletonManager instance;
    public static SingletonManager Instance
    {
        get
        {
            if (instance == null)
            {
                instance = new SingletonManager();
            }
            return instance;
        }
    }

    private SoundManager soundManager;
    public SoundManager SoundManager
    {
        get
        {
            if (this.soundManager == null)
            {
                this.soundManager = GameObject.FindObjectOfType(typeof(SoundManager)) as SoundManager;
            }
            return this.soundManager;
        }
    }
}

Then we can access it like this:

public class TestClass : MonoBehaviour
{
    bool needToPlaySound;
    
    void Update()
    {
        if (this.needToPlaySound)
        {
            SingletonManager.Instance.SoundManager.PlayClickSound();
        }
    }
}

Note: I'm not touching on thread-safety here for simplicity but it shouldn't matter to most people. If you're doing anything with threads you'd better Google "threadsafe singleton"

This way we have concentrated the code accessing the MonoBehaviour singletons in one place. The Awake method can be used for more essential code needed there, and in many cases can be removed all together.

Interfaces - Use 'em

Now one final problem is that these MonoBehaviour singletons we are exposing with the SingletonManager are (obviously) extending the MonoBehaviour class, which is a huge class with many methods on it. This means that you have way too much access to that class and its attached GameObject that you need.

For example, you can type SingletonManager.Instance.SoundManager.transform.rotation = ... and suddenly you're able to change the rotation of the SoundManager's GameObject from anywhere in the code. From a good coding viewpoint this is not a good thing. The SoundManager should only let external classes have access to a very limited number of methods. That's where interfaces can save you.

So, instead of having the SingletonManager expose the SoundManager class directly, we create an interface ISoundManager and expose that.

public interface ISoundManager
{
    void PlayClickSound();
}

Then our SoundManager will use the interface like this:

public class SoundManager : MonoBehaviour, ISoundManager
{
    public void PlayClickSound()
    {
    }
}

And the SingletonManager will look like this:

public class SingletonManager
{
    private static SingletonManager instance;
    public static SingletonManager Instance
    {
        get
        {
            if (instance == null)
            {
                instance = new SingletonManager();
            }
            return instance;
        }
    }

    private SoundManager soundManager;
    public ISoundManager SoundManager
    {
        get
        {
            if (this.soundManager == null)
            {
                this.soundManager = GameObject.FindObjectOfType(typeof(SoundManager)) as SoundManager;
            }
            return this.soundManager;
        }
    }
}

Much better. Now, when something screwy is happening to our SoundManager, we know exactly what the external classes are capable of doing to it. Plus it essentially forces the coder to think about what relationship our MonoBehaviour singleton classes have with each other. If you need to do something more you have to add it to the interface, rather than hack away at whatever properties you want.

I highly recommend using interfaces in this way. You will thank yourself as your codebase grows.

The previous one used a kind of quazi Bézier curve with the control points being the waypoints around the point you're calculating. This one uses proper control points, and they are all nicely editable. 

 Here is the prefab once you drag it into the scene. It comes with two points. To create more just duplicate one of the points. The green points represent the waypoints that make up the curve, and the purple points are the left and right control points for each waypoint. 

With the added control, you can make any curve you want now. 

 To use this prefab, the only Interface you should have to worry about is IBezierCurveManager. This is the interface to the BezierCurveManager (duh) and it only has two methods. 

• Vector3 GetPositionAtTime(float time);
• Vector3 GetPositionAtDistance(float distance, float time);

Plus the options on the BezierCurveManager script editable from the Editor. 

• DrawGizmos
• DrawControlPoints
• IsFullLoop
• SecondsForFullLoop
• EnableDistanceCalculations

GetPositionAtTime - Gets a position along the curve at a time, with 0 being the start of the curve and SecondsForFullLoop being the end (or start again if IsFullLoop is true). 

GetPositionAtDistance - The same as GetPositionAtTime but with a distance offset. This is useful for having one object follow another. Because the speed along the curve is not constant usually (unless your waypoints are evenly spaced. In order to use this method you must have EnableDistanceCalculations set to true before starting. 

Now, it's a little hacky how I get the Distance calculations for use in EnableDistanceCalculations. I basically do a run around the loop first and manually calculate the distance. I'm sure there is a nicer mathematical way to do it, but this will do for now. But what it means is that there is a little pause on startup where it calculates it all. If you don't want this and don't want to call EnableDistanceCalculations then just set EnableDistanceCalculations to false. 

So, here is the Prefab Package. Hope it all works. 

And here is an Example Project using it. Here we have a red ball going really fast along the curve, a bigger red ball going more slowly along it, and two purple balls a fixed distance ahead and behind it. 

The example project has a source file Sphere.cs which shows simply how to find the IBezierCurveManager object and call GetPositionAtTime on it. 

A note on speed: 

This is crazy fast, so if you only have a few objects using it you should not have a problem with speed. The GetPositionAtDistance call does do more than the normal one, but it's just running through arrays which seem to be stupidly quick. I'm sure there are optimisations to be found, but I didn't see the point at the moment. I've tested it on my 3GS iPhone with negligible effect. 

Enjoy!

When you deploy to the Webplayer, Unity spits out a default html file that you can stick on a webserver and have your game playable instantly, which is also awesome, but it's a little limited.

First off, it's a little hard to work out how to embed it in a page other than the default one. Secondly it loads automatically, which if you have several Unity files on the one webpage (like a blog) then it will be pretty annoying for the user to have them all load at once. Not to mention what the performance will be like.

So, I've tried to simplify things a little. The goals are;

• To show an image first, then if the user clicks the image the Webplayer loads
• To make it easier to embed in a blog.

I started with the default Webplayer html, and pulled out all the script components. I've saved them all into a file called 'unityscripts.js'. Now, the chunk of javascript in the 'body' of the default file is the entry point to load the Webplayer, so I made this a new function called 'LoadUnityAfterClick' and added four arguments to it. The path to the unity file, a unique id,  the width and the height. This makes all the javascript generic so it can be reused all over the site.

Next it gets a little dodge. For detecting the Webplay in Internet Explorer, there is a vbscript method in the defaut file. This caused a bit of a problem, because I could not for the life of me work out how to call this method 'DetectUnityWebPlayerActiveX' from the now external javascript. If you know of a way to do that I'm all ears.

So I decided to rewrite the vbscript component in javascript. According to the Unity 3D documentation this is not the best because...

VBScript is used instead of JavaScript because after detection it releases the plugin resource immediately (whereas in JavaScript it would only happen the next time garbage collection is performed).

That didn't sound like too much of a deal breaker to me, so I've decided to ignore it.

So now that the whole thing is contained in one javascript file, embedding the Webplayer in something like Squarespace becomes much easier.

Now I'm no javascript or html expert, so for the Load on image part I was helped by some code from here.

First you just save the 'unityscripts.js' file somewhere. Then all the code you need to add is the image href that calls the javascript in its OnClick method, plus the noscript part for the tin-foil-hat brigade that think everyone is out to steal their porn stash.

I won't mess up this page with a whole bunch of ugly code so I'll just link to the files. I made them rtf so they have colours and are a little easier to read but there is also a text version which is what you should copy if you want to use this.

The Embedded Code is here  or as text here.

The UnityScripts.js file is here or as text here.

The UnityScripts.js file should work right off the bat, but the Embeddded Code part has placeholders that need to be searched for and replaced. They are fairly self explanitory.

• FULL_PATH_TO_UNITYSCRIPT.JS
• FULL_IMAGE_PATH
• FULL_UNITYFILE_PATH
• UNIQUE_ID
• WIDTH
• HEIGHT

So for an example, if you're wanting to add your unity file to a squarespace blog;

1. Go to 'File Storage' and add the UnityScripts.js file. Then hit 'url' to copy the full path. 
2. Do the same with the Image file and the Unity file.
3. Open up the 'Embedded Code' file in notepad or something and replace the variables above with the full paths you got when importing them, plus a uniqeId and a width and height that you'd like. Note: The UNIQUE_ID in the href needs the # in front of it so don't accidentally delete it.
4. Start a new post and hit 'Insert Code Block' and add the 'Embedded Code' to your post. 
5. ?
6. Profit.

 Here is a little demo...