Meanwhile I spent spare time on Behave rather than the RPG thing, so now 1.4 is ready for release. TADAA!

This release primarily holds runtime optimizations, fixes and tweaks. Specifically I would like to highlight the ability to mark components as “instant”. The instant flag affects sequences and selectors when moving between child nodes. When an instant child component completes, rather than waiting for the next tick to tick the following child node, the sequence or selector does it immediately.

Anywho, get it on the asset store and remember to rebuild your libraries after installing.

The rest of the changes follow:

1.4:
 - Fixed decorator incorrectly initializing on every returning tick when tick handler returned Running.
 - Fixed debugger view dependency on active tree editor - causing reported null reference exception.
 - Fixed missing scrollbars on browser window.
 - Reduced logging noise from debug builds.
 - Agent blueprints can now be MonoBehaviour based.
 - Clarified wording on "library not loaded".
 - Now handling reset a bit cleverer - potential performance boost.
 - Changed the default success criteria of Parallel components from SuccessOrFailure to Success.
 - Added "instant" flag to components. Components marked instant will affect sequences and selectors when moving between child nodes. When a child node marked "instant" completes, rather than waiting for the next tree tick to tick the following child node, the sequence or selector does it immediately.
 - The compiler progress bar returns.
 - Editing a Behave asset now focuses the asset browser last instead of the tree editor.
 - Behave can now be installed in any subfolder of Assets - provided its internal folder structure remains intact.
 - Compilation speed improvements.
 - Enabled references across collection borders.
 - Added Tree.DataSize - returning the number of bytes used by a tree instance. This is also displayed in the debugger window.

You’ll find a link to the package in the download section. Have fun!

Unity forum thread.

By the way at that last conference I did a talk titled “AI in Unity” – the goal of which was to try and demystify the concept of AI a bit. I’ll make some noise when we have the recording of it available.

Oh and I fixed the comments on the blog, so I’ve just cleared out 300-something spam posts. Anyone got advice on how to avoid this on a WordPress blog? (Read: I’m too lazy to change blogging system if anyone suggests that). Oh and therefore I enabled the “must approve comments” thingy. Not sure if that is going to help anything, but at least it will reduce the noise on your end.

So what is next then? Well I’ve got a few things I’d like to release in a Behave point upgrade and then the plan is to move on to 2.0 which will hold some backwards-compatibility breaking changes.

At Unity there’s a bit more 3.5 stuff to do and some even awesomererer demos on the way. The extra awesomeness has been underway for quite a while, so I’m very excited to get this out soon.

I very recently started playing around with some RPG mechanics in my spare time (had a day off after Unite and couldn’t sit still). It’s so spare time that the plan is to have no additional plans. Let’s see where that goes.

Ah and I’ll work with some groovy dudes on getting a 3D themed workshop event up and going early next year. I don’t think it has been announced yet, but it will be awesome – and full of Unity of-course. That should hit right before the other groovy thing I’m working on again this year with more awesome dudes and dudettes. Fun times!

What else? Oh yea. With my low bandwidth for updates, I’ve turned increasingly more to twitter and the gist feature of github. Hopefully I will have the time to do some good reads in the Tips and Tricks section soon, but the gist setup is just so very quick.

I probably forgot a ton of stuff, but hopefully this was a good reboot of this blog thing. Let’s see what happens. Maybe I could start blogging about that RPG thing if it accidentally turns interesting. We’ll see.

Have fun!

This release is primarily a bugfix and editor polish release. One thing I’d like to highlight though is the addition of agent blueprints. From the changelog:

– Added agent blueprints – connecting to agent handlers through virtual methods rather than reflected handlers.

Generally this enables you to more explicitly tie up handlers and cuts down on tree initialization time. Oh and of-course you gain auto-completion when setting up your handlers.

Anyway, here’s the whole changelog:

1.3:
 - Fixed priority selector init flag resetting.
 - Fixed reference handling on tree renaming and deletion.
 - Fixed references still pointing at old collection post collection duplication.
 - Fixed compilation of actions and decorators with non-integral float parameters.
 - Fixed GUI list behaviours.
 - Fixed passing context back and forth between referenced trees and referrer.
 - Fixed reordering connections not causing save state to be set.
 - Various GUI tweaks.
 - Runtime optimisations.
 - Enabled scrolling of the tree list in the debugger window.
 - Exposed Tree.ReflectForwards.
 - Added Tree.ResetForwards.
 - Added agent blueprints - connecting to agent handlers through virtual methods rather than reflected handlers.
 - Made connections selectable in the tree editor via the connection nub.
 - Moved connection managing from the inspector to the tree editor, where it is more visible and handy.
 - Added support for disabling connections - for faster, less destructive debugging.
 - Double-click reference component to jump to referenced tree.
 - Changed "Cannot update unregistered tree" handling from an exception to an error message. Still need more info.
 - Now showing string and float parameters in the tree editor if either is set.

You’ll find a link to the package in the download section. Have fun!

Unity forum thread.

• AI in Unity
• Network
• Unity GUI

A week has passed and the second of six Unity specific IGDA SIGs is upon us. Like last time, the event will take place at the IT University, Copenhagen, Denmark at 1800.

We will meet in the reception and from there move to the auditorium. The originally planned physics bit of todays SIG has been rescheduled to next thursday, where Jonas Echterhoff will be in town and give the talk. Jonas is the man with the plan of the PhysX integration in Unity, so added awesomenessness!

This means that today Joe Robins will be talking about scene construction and I will be covering AI in Unity.

For this thursday we should be lucky and get even more Unity Tech people to participate in the discussion bit of the SIG. And remember afterwards we’re doing the bar meet and given it’s Saint Patricks, we’re likely to be a good group of people moving from bar to bar.

The original IGDA post w. schedule:
http://igda.dk/2011/02/01/unity-sig-unity-special-interest-group-launch/

IGDA post on the rescheduling of the physics talk:
http://igda.dk/2011/03/16/unity-sig-update-on-the-meeting-thursday-173/

The event is held at the IT University of Copenhagen and starts at 1800. Anyone can attend (for free) and this first SIG will be a general introduction to Unity – basic principles of the engine, workflow and such. The following five SIGs will dive into various specific areas of Unity.

For more information and the full program, see the IGDA DK blog:
http://igda.dk/2011/02/01/unity-sig-unity-special-interest-group-launch/

Something in the default license which doesn’t fit your project too well? Let’s talk about it. Please use the form available on the Licensing page, available from the navigation bar.

Furthermore, I added a link to the previously released introduction video to Path 2.0b1. While I will make sure to re-record it with the released build, 99% of the stuff in that video still applies.

Full API documentation is available in the documentation section – more documentation is on the way, as is integration between UnitySteer and Path 2.

That’s it for now. Have fun!

Unity forum thread.

Well I did it before we had a port of MonoDevelop available, so my options were limited. Now that we do have that port, you’ll be able to redo this exercise in there with some GUI drag-drop nicenessness. However, just because I can (and because it is healthy learning and lovely hacky) I will provide the command-line/perl script solution, which is still my approach.

First a quick “why”: As mentioned in my Unite talk, there are three reasons I wrap my projects in .net assemblies before distributing – and no it’s got nothing to do with keeping the source secure – assemblies are easily decompiled:

• Reduce deployment clutter. If I were to release Behave without being wrapped in assembly, it would span around 150 – 170 source files and textures in various folder configurations. Now I have two folders, three assemblies and about five script files.
• Reduce funky bug reports. While .net assemblies are very easily disassembled, it does at least take some dedication to do so. More than it takes to randomly change something in a full source distribution when things don’t go your way. So assemblies help you get rid of a portion of those really long bug reports which end up with “oh, by the way, I changed this one thing in your distribution – you think that might have something to do with it?.
• They can load in at runtime. This is really cool and quite useful if applicable to your scenario – for more information, check out this other tips and tricks post: downloading the hydra.

In this post I am going to show you how to build your scripts into a .net assembly (.dll) and add it to your Unity project. And just to spice things up, lets take that in reverse: Once your assembly is built, copy that bastard into your Assets folder. Done.

Easy, right? Now, let’s take a look at the assembly building. And, before you start, yes this will run on all Unity supported platforms and no it does not require pro – run this on the base Unity license without issues.

Setup

So first off, if you are on windows, you’ll be needing a perl install. I usually got for ActivePerl. Not saying it is more awesomerer than anything else out there – just that I know it and it usually works just fine. If you are on OS X, you’re in luck, as perl comes preinstalled.

Now, let’s get perl hacking. This is in no way meant as a “my first perl script” guide. We’re just getting introduced to a means to an end – and it is not going to be pretty. So first off, create a new text file in your favorite text editor and save it as build.pl. Start the file off like so:

#/usr/local/bin/perl

use strict;
use Getopt::Long;
use Term::ANSIColor;
use File::Basename;
use File::Spec;
chdir (File::Spec->rel2abs (dirname($0)));

our $compiler = "/Applications/Unity/Unity.app/Contents/Frameworks/Mono/bin/gmcs";
our $assemblyUnityEngine = "/Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEngine.dll";
our $assemblyUnityEditor = "/Applications/Unity/Unity.app/Contents/Frameworks/Managed/UnityEditor.dll";

Now, that was a bit of a mouthful, but it should be pretty straight-forward. Lines three through eight include a lot of perl functionality we will be using later. And actually the last two ones are already used in line nine. Here we’re ensuring that the rest of the script is being executed in the context of the folder containing the file.

In the next few lines of interest, three variables are declared – pathes to the mono compiler shipped with Unity and the UnityEngine and UnityEditor assemblies. Notice that these are OS X pathes, for a windows setup (or if you installed Unity into a different folder than the default), you’ll need to correct these.

Debug command-line parameter

Next up, let’s add support for command-line parameters. “Why?” you ask – because they are going to be awesome for debugging our assembly later. The only command-line parameter we will be supporting for now is “–release”. This will basically let us toggle, when building the assembly, a bunch of logging and other stuff on or off. This is what it looks like:

my $optionRelease = 0;

GetOptions (
	"release" => \$optionRelease
);

We declare a variable named optionRelease, initialize it to zero and then call GetOptions, telling it to pass data on the use of the “release” parameter into our variable. Now, GetOptions has a bunch of functionality, but the way we use it here, it simply assigns one or zero to our variable – depending on whether the parameter is used or not.

Next up, we need to use this variable to affect the parameters we pass to the gmcs compiler. Like so:

my $debugOptions = $optionRelease == 0 ? "-d:DEBUG" : "";

The idea here is that gmcs takes a parameter -d:[name] which instructs it to, during pre-processing, run with the symbol [name] defined. Something we can work with in our code like this:

#if DEBUG
	Debug.Log ("I'm only visible in debug builds!");
#endif

Building two assemblies

Next up, a bit of info. Since Unity 3, we’ve enforced that scripts and assembly depending on UnityEditor, even if not using that, cannot be included in builds. This means that if you have some editor scripts, you would also like built to assembly, you will need to split these out into a different assembly than the one containing your runtime scripts.

Lets’s assume that is the case for this exercise, that the runtime scripts are located in Source/ and that the editor scripts are located in Source/Editor. So we will have to build two assemblies. That could mean code duplication, which should cause anyone pain, so let’s be nice and wrap some of the building up in a perl subroutine:

sub BuildAssembly
{
	our $compiler;

	my $target = shift;
	my $out = shift;
	my $arguments = shift;
	my $source = shift;

	print ("Compiling $out\n");
	print color ("blue"), "$compiler -target:$target -out:$out $arguments $source\n";
	print color ("red");
	system ("$compiler -target:$target -out:$out $arguments $source") and die ("Compilation of $out failed.");
	print color ("reset");
}

Let’s take this subroutine line by line. First off we pull in the global variable “compiler”. After this, we populate the variables target, out, arguments and source from subroutine parameters. With these at hand, the fun begins. First off, we print out the name of our build target (MyAwesome.dll) and the command we’re planning to execute – marked in fashionable blue.

Second we actually do the building – colouring any compiler output red (no news is good news – output is bad). If compilation fails, we kill the script – allowing the user to take action. If all went well, we remember to reset the colouring before returning from the subroutine.

So how about some use of this subroutine, eh?

BuildAssembly ("library", "Awesomenessness.Runtime.dll", "Source/*.cs", "-d:RUNTIME $debugOptions -r:$assemblyUnityEngine");
BuildAssembly ("library", "Awesomenessness.Editor.dll", "Source/Editor/*.cs", "-d:EDITOR $debugOptions -r:Awesomenessness.Runtime.dll,$assemblyUnityEngine,$assemblyUnityEditor");

As you see, we first build the runtime assembly from Source/*.cs, with the RUNTIME and optionally the DEBUG symbol defined. We also make sure to include the UnityEngine assembly in the building, so that you can reference stuff from the UnityEngine namespace.

In the second line, we build the editor assembly – containing all our editor code from Source/Editor/*.cs. This time we define the EDITOR and optionally the DEBUG symbol during building. This assembly references not only the UnityEngine assembly, but also the UnityEditor one and the runtime assembly which was just built in the line above.

Distribution

And that’s about it! As mentioned early in this post, all you need to do in order to include these assemblies in your project is to drag them into your assets folder, but if you’re very nice, you could just make that copy a part of the build script:

system ("cp Awesomenessness.Runtime.dll Test\\ project/Assets/Awesomenessness");
system ("cp Awesomenessness.Editor.dll Test\\ project/Assets/Awesomenessness/Editor");

Notice that this uses the OS X cp command-line tool. For windows, replace with equivalent.

Limitation: Editor classes in assemblies

While MonoBehaviours can live just fine in assemblies, editor scripts (ScriptableObject derived classes) come with a limitation (currently still active, as of Unity 3.1): You can not initialize these classes via UnityEditor API calls. That would be calls like ScriptableObject.CreateInstance and EditorWindow.GetWindow.

However – you can create instances of classes via “new” just fine and you can derive scripts located outside of the assembly and instantiate those via UnityEditor calls without incident. Say for example that MyEditorWindow derives from EditorWindow and is located in an assembly. Now I cannot instantiate it via GetWindow, but if I create a .cs file in my assets folder containing a class which does nothing but inherit from MyEditorWindow, then that class can be instantiated via GetWindow just fine and will have the exact same behaviour.

Extra trick: Including resources in the assembly

For extra points, you can include resources, such as textures, in your assembly. This has the bonus of limiting the clutter of your distribution even more.

Including the resource in your build is as simple as appending the “-resource:[path]” parameter to your gmcs build command. This will add the bytes into the assembly manifest – under the name of the original file. You can fetch these bytes at runtime, using that name. For example, here’s some utility methods for fetching textures:

public static Stream GetResourceStream (string resourceName, Assembly assembly)
{
	if (assembly == null)
	{
		assembly = Assembly.GetExecutingAssembly ();
	}

	return assembly.GetManifestResourceStream (resourceName);
}

public static Stream GetResourceStream (string resourceName)
{
	return GetResourceStream (resourceName, null);
}

public static byte[] GetByteResource (string resourceName, Assembly assembly)
{
	Stream byteStream = GetResourceStream (resourceName, assembly);
	byte[] buffer = new byte[byteStream.Length];
	byteStream.Read (buffer, 0, (int)byteStream.Length);
	byteStream.Close ();

	return buffer;
}

public static byte[] GetByteResource (string resourceName)
{
	return GetByteResource (resourceName, null);
}

public static Texture2D GetTextureResource (string resourceName, Assembly assembly)
{
	Texture2D texture = new Texture2D (4, 4);
	texture.LoadImage (GetByteResource (resourceName, assembly));

	return texture;
}

public static Texture2D GetTextureResource (string resourceName)
{
	return GetTextureResource (resourceName, null);
}

Given that you added “-resource:path/to/Logo.png” to your gmcs build command, you will with the above utility methods be able to fetch that into a texture like so:

Texture2D logoTexture = GetTextureResource ("Logo.png");

Well, I hope you guys found some of this useful! I’ll see if I can’t do a follow-up on how to do this in MonoDevelop.