Aaron Blohowiak

Scenario: You load up Unity iPhone and suddenly all of your draw calls look like they’ve doubled.  Crap.  The game is running really slow when you build it out to your phone and you have no idea what’s going on. Suddenly, you remember that when last you were editing the scene, you were experimenting with camera positioning. D’Oh! You forgot to disable the copy of your main camera that you were using to explore new angles.  Whoops!  Disabling the second camera brings the world back to order. Whew! Another nightmare dissipated.

WARNING: do not try this at home, cardiac arrest or other deadly effects of panic may ensue.

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.

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)

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.

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.

Thanks to some hard work from my collaborator, I now have a model of the unicorn with its head separated.  When a unicorn gets hit with a shotgun and dies, its head pops off (every time for now, will be one of a few different death sequences eventually.) 

Sorry for the poor video quality… and sorry for the messy room, mom! ;)

Implementation:
When the unicorn dies, we actually replace the animated alive model with a new prefab, setting the position and rotation information to match the alive model.  We then delete the alive model.   This switcharoo lets us have two pieces of geometry (the head and body) where there used to only be one (the whole unicorn.)  This will let us have more alive unicorns on the screen at once, because the alive model is easier for the iPhone to render.  The decapitated prefab also has some physics.  We give the head a spherical collider so the rigidbody’s center of gravity will be correct.  Then, we apply some Force, randomizing the strength and angle within a reasonable range  to keep the head-popping interesting.  Random.Range for the win!

Lesson Learned:
Overlapping colliders make bad things happen.  I was getting inconsistent and unexplained motion of the head.  I deleted all my Force scripts, tried restarting Unity and even reconstructing the decapitated prefab, all to no avail.  So, I started working backwards to the last “known good” state.  Eventually I figured out that the behavior was only happening when both the head and the body had colliders. The colliders where both spherical because they are the most efficient collider (center + radius instead of complicated poly bounds calculations.)  It turns out that simulating the overlap of the colliders made the physics engine assume there was some form of collision going on, so it tried to separate the colliding objects. Normally, this is exactly what we want to happen.  If somehow in our simulation the feet of our unicorn get into the floor, it should get bumped out because two things cant occupy the same space at the same time.  One solution would have been to have the objects on separate layers, but after some thought I realized there was no need for the body to have a collider at all. 

Conclusion:
So, the lesson once again is YAGNI (ya ain’t gonna need it.)  If I had added the colliders only as-needed, then I would have a) avoided the problem, perhaps forever and b) instantly realized what was causing the problem if it did come up AFTER the system was known to work with only one collider.

I think my roomba is losing a fight with something on the floor in the other room, so I have to go tend to that.

Lighting is hard.  Really hard. It can drastically change the look and feel of a game, a movie or your family portrait ;)

With Halt Yablonski: Unicorn Hunter, we want to have a dark feel, so the player understands the seriousness of the situation and becomes immersed in the dark reality that Halt faces on his quest to clean up the streets.

Here are some experiments:

 

 

As you can see, each variation gives us a slightly different feel.  The first is brighter overall, but we lose that stark high-contrast effect.  The second has bright highlights and dark low-lights, but feels very unnatural.  The last is somewhere in between, but the details of our hero are kind of lost.  There’s definitely a lot more work to be done until we get it right! 

Feel free to drop me a line and let me know what you think!

I have been developing the concept for a game about a gruff hero that is out to clean the streets of drug-dealing unicorns for a couple months now.  I’ve decided to open up my progress to keep my fans, friends and peers up-to-date on my progress.   So far, I’ve mainly been making decisions and sourcing talent, software and infrastructure.  The game’s art will primarily be the work of a very talented friend of mine.  He has a great background, having worked on various movies and games, and is a real pleasure to work with, I hope he has as much fun as I do!

We have some initial assets imported into Unity and I’ve started coding the controls.

Additionally, I’ve started playing around with weapons:

Don’t worry, mom, I will keep a fire extinguisher nearby. ;)

I’ve also been starting with level design and lighting:

My plan is to apply to speak at GDC2010, submit the game to IGF and remain open and transparent about developing the game.   Should be a fun ride!