Archive for August, 2009

Converting from UnityScript to C# (c sharp)

Here’s a situation most Unity3d developers run into: you have scripts in both C# and unity JavaScript, and you can’t get them to work together even after you figure out the bizarre compilation order because you want bi-directional communication.  What to do?  Unfortunately, it seems as though the only thing you can do is to convert the UnityScript (JavaScript) to C#. Unfortunately, there is no completely automated way to do this.

Running the following search/replace in vim (what else?) in the following order gets you about 85% of the way there:

%s/var \(.*\) : \(.*\) = \(.*\);/\2 \1 = \3;/g

%s/var \(.*\) : \(.*\);/\2 \1;/g

%s/function \(.*\)() : \(.*\)/public \2 \1()/g

%s/function \(.*\)/public void \1

%s/boolean/bool

Other things that the above find/replaces won’t catch are: foreach/for(a in b) dynamicly typed variables, variables whos types are implicit.. ie: var a = SomeFunction();, and it won’t currently ensure that you have an ‘f’ following your floats — 2.0f instead of 2.0.

As I mentioned at the Unity3d forums:

more of a PITA is getting around c#’s inability to set variables on member properties ( ie: foo.color.a becomes tmpclr = foo.color; tmpclr.a= 0.2f; foo.color = tmpclr); I decided to create class-specific private member variables to avoid dynamic variable allocation (so we dont have as much garbage to collect.)

Finally, the last thing to worry about is how Unity3d implements coroutines in C#.. but I’ll save that for another blog post.

Subtle C# vs Ruby Inheritence Difference

This subtle differences in ruby and C#’s inheritence semantics bit me in the ass.

In Ruby:

class A
  def foo
    bar
  end
  def bar
    "in a"
  end
end

class B < A
  def bar
    "in b"
  end
end

Calling “B.new.foo” will output “in b”. I assumed this is how method overriding worked in C#, but that was a mistake. The same example in C# would output “in a”, because the `bar` referenced in A is not a message (like it is in ruby,) the compiler just sticks in the reference to the locally defined function.  An hour, a fistful of hair, and a call to a good friend (thanks AJ) later, I came to realize that in order to get the same kind of behavior, you have to use the “virtual” and “override” keywords in your classes’ method signatures.

This is a great article that explains it all: C# Overriding (virtual, override)

Taming the complexity of Weapons Systems in Unity3d using C# Interfaces

I confess: A lot of the programming I do for unity is in UnityJS — the bastard language of Unity and ECMAScript that lets you get things working without a lot of overhead. It is great for prototyping.  We’ve all taken a prototpe too far and regretted the bird’s nest of code that ensues.   Here’s an example of a refactoring that I recently did to accommodate the increasing complexity of the code base, to help transition from prototype to product.  It takes advantage of a C# language feature that UnityJS lacks completely.

The Complexity Infects

Halt Yablonski, our hero, was prototyped with “just” a shotgun.  The shotgun was instantiated and parented to the character, and a script on the character had the script that controlled firing.  What all is  involved with firing?  Well, there is the game-level stuff ( removing ammo, rate-limiting, ) and the world-level stuff (activating animations, instantiating particle effects, throwing collider.)  With just one weapon, the character script simply had a ShootMe() method.  Then it was time to play with fire, and add in the flamethrower.  Well, I could just put in a whole bunch of if statements, which would be fine for two weapons, but what about when I want to add in the baseball bat?  And the next weapon and the one after that? A whole crapton of if() statements?  does UnityJS have a `case` or `switch` statement?  Ew, it just stinks.  The character object suddenly is implementing the behavior for a great many other domain objects. What we want to do is pull that behavior out of the character script and divide it among the appropriate weapons.

Cool.

Okay, wait a minute.  That sounds great, but how do we do that, really?  Well, we could have a script for each weapon, and then send a message to the weapon on an action.  As long as we implement support for all the messages (which we make easier with some inheritance), then we should be o-k. Using SendMessage is really slow and what if we want to do things like ask a weapon if it is fireable or how much longer until the reload is done — that kind of synchronous communication is all but impossible with SendMessage.  Also, what if we decide to add more messages later, how can we ensure that all of our weapons support all the messages?

Interfaces to the rescue!

In its simplest form, here is the weapon interface

public interface IWeapon{
	void Shoot();
}

So, our weapon would look like this:

public class Shotty : MonoBehaviour, IWeapon {

	private Controller controller;
	void Awake(){
		//in practice, i use the singleton technique instead of finding the game object. much faster ^_^
		controller = (Controller) gameObject.GetComponent("Controller");
		controller.Switched(this); // let the controller know we are done loading.
	}

	public void Shoot(){
		Debug.Log("Bang");
	}
}

Finally, here is the character script

using UnityEngine;
using System.Collections;

public class Controller : MonoBehaviour{

	public IWeapon weapon;

	public void Switched(IWeapon newWeapon){
		Debug.Log("New Weapon");
		weapon = newWeapon;
		weapon.Shoot(); //just for demo purposes,
			//normally this would be called elsewhere
	}
}

So, this lets us switch weapons easily, and maintains the nice separation of concerns between the character script and the weapons script. Now we can be free to implement the weapons however we like, but can use the type system to know that the weapon will have an appropriate response for everything I want to do with it.

Why not inheritance?

If these objects all have to have the same methods, why not make them all descend from the same class? Separation of concerns. Just like it makes sense to separate out the weapon from the character, it makes sense to separate the weapon interface from the implementation. Our Controller object shouldn’t give a rat’s ass about how the weapon is implemented! It only wants the guarantee that the objects it is passed work in the appropriate ways.

Downsides

It is a pain in the butt to get started. and totally not worth it for the early prototype phase. As your needs and product vision mature, the need for feature *expansion* becomes more pressing than the need for feature *creation*. Building a modular design that is used in only one configuration is a waste! You probably won’t need it.

Bottom Line

When we start getting unwieldy complexity, we need to straighten things up. We give a name to each of the tasks that the code has to accomplish, then instead of having branches all over the place, we a) make the list of tasks generic by creating an interface and b) implement the interface for each type . This way what was a really complex controller script now just becomes a simple controller script and a couple of other simple scripts for each type. Now we can keep on adding new weapons without ever having to change the controller code! Its hard to reduce the complexity any further than that.

Skype In Ubuntu Karmic Core Dump

If you are running ubuntu karmic and you `sudo aptitude upgrade`, and find you cannot start skype after reboot, then you may need to remove your existing install, set up the www.medibuntu.com repository and then aptitude install skype-static-oss. Then, things should work again.

Hopefully, the issue with the main distribution of skype will be resolved shortly.