- Articles

New Gear

2021-12-30 00:00:00 +0100

In 2015 I did a review of my active toolbox. As obviously a lot has changed since then, particularly with pandemic-mode operations, I figured an update would be appropriate.

I had hoped to have done a post on a new build agent setup we are working on, but unfortunately JetBrains support are still having some trouble replicating problems we are experiencing with Linux-based TeamCity Unity build agents. You will just have to look forward to that - hopefully not too far into the new year.

A central theme in the current toolbox is self-hosting and flexibility in general. Third party provided services are great until you get near the edge of intended use cases - which usually works well, but holds the capacity to (hopefully only) slightly frustrate every project flow you go through. We first dipped our toes in self-hosting some services pre-pandemic but since moving to be fully distributed we went all in - to the point of currently only relying on external services for text chat, email, and mobile build distribution.

That said, I will strive to keep the format of the earlier post - focusing primarily on local machine tools. So as mentioned the update here is flexibility and obviously a use case change as well, given the steep drop in need for working on the go.

Platform

The 2013 MacBook Pro got retired - initially in favour of a company workstation at the office and a personal one at home, for once pieced together from parts matching my needs rather than the sales considerations of a manufacturer of prebuilts. Moving our operations fully distributed, resulting in the company workstation moving in with me, the personal workstation then got converted into a server - replacing the basic Synology box which had previously been sufficient for the limited services we self-hosted when sitting multiple non-family-members in offices were a thing.

This change of hardware platform obviously meant a move away from macOS - marking the first change in the toolbox. Prior to retiring the laptop I had started dual booting Ubuntu on it in order to gauge how far the Linux desktop experience had moved since last I had a look at it. A clear goal in general was an increase in flexibility - not just limited to hardware choice, so if given an actually modern and fully functional desktop experience I was definitely going to prefer Linux over Windows. At the end of my trial run I was satisfied with the experience and had gradually moved to cross-platform software on the macOS installation as well - in order to reduce the number of new things I would need to deal with when jumping completely.

After landing well on the new platform and properly acclimating I did move around a bit before settling on my current setup, but as a migration point Ubuntu (with the default GNOME desktop environment) was excellent. For anyone doing the research today I would recommend trying out Zorin OS as the migration point in stead - regardless of where you consider migrating from.

I prefer to not use headspace for more tools than necessary, so I opted to use Ubuntu server for our self-hosted efforts - in order to work with the same underlying tooling available in the terminal application of my desktop. The before-mentioned moving around did eventually see me leave Ubuntu for both use cases - in favour of NixOS as the underlying system, with Plasma as the desktop environment on my workstation. Note that while Plasma may initially look to be “the Windows experience but on top of Linux”, the primary selling point of the environment is accessible customisation. If I were to describe my current setup in more familiar terms, it would probably be: a macOS-like header bar & launcher, no dock, window auto-tiling, and a functionality-focused high-contrast if dark colour scheme. You can basically adjust it to your hearts content, making it an optimal fit for your particular flow - which is what drew me to it.

I would not recommend NixOS as a migration entry point, but long term the paradigm shift is well worth it to me. The advantages are numerous, but personally I am mostly drawn by the declarative OS configuration enabling a single text file to describe a complete system and all of its settings. The flexibility on Linux is great, but just like any other system there are a ton of different locations to review & configure the full experience (Window settings panels meme: Engage!). Having a single file I can use to quickly review what a system is and to modify it is absolutely excellent. It is no animated semi-transparent GUI of smooth loveliness, but I’ll take it.

For control over hardware resources, service segregation, and advanced tools management I have opted to run a hypervisor on both server and workstation. Aside from massive cloud servers and game consoles, hypervisors are great for configuring and running a number of personal virtual machines on the same hardware - in particular when you have clearly segmented services and goals to work with. From a security standpoint network segregation in this environment is not as solid as with individual machines, given that virtual machine escape exploits are a thing. However neither my private nor our company threat model includes threat actors with the necessary budget and given that the alternative is third party services susceptible to the very same attacks, this configuration is entirely acceptable. This setup means that my day to day desktop experience is actually a virtual machine. Though with a dedicated graphics card and plenty of resources & CPU priority associated that distinction is entirely unnoticeable. In addition to this primary VM, the workstation runs a router for the different VMs, CI agents for the different projects, and other tools like distributed bake & generative services, devkit tools with picky environment requirements, and that sort of thing.

As an aside, I also ended up running NixOS on my tablet - though here I opted for GNOME rather than Plasma as the desktop experience. While explicitly not designed for touch devices, I find it the better experience of the two on such hardware. In addition to buttery smooth regular reading of books & comics + browsing + media activities, the gaming experience on the tablet is great - using Steam in-home streaming to run games from a VM on the server running an attached dedicated graphics card, with controls either via touch or the excellent Steam Controller. This on a minimum-spec dual-core device with four gigabytes of memory.

Tracking

OmniGroup only develop their software for the fruit company ecosystem, which meant I would of-course have to find an alternative to OmniFocus. Given the difficulty in finding a suitable project & TODO tracking solution described in the last toolbox post, this was by far the toughest workflow change.

Thankfully our self-hosting journey overlapped nicely with the local toolbox change here as I found an excellent combination of user experience and flexibility in the YouTrack solution we were already using for company project tracking. While a fully hosted version is available as well, we had already opted for self-hosted in order to more easily run some custom integration with the rest of our flow. The resulting setup is one install for the company, one for the family, and optionally one per project if it involves tightly integrated external parties.

The underlying data structures can have a whole lot of fields associated with each task/entry - making it a full Jira-like complex beast if that is what you want - or a simple TODO app if that is more your target. Combined with a mobile app and a very flexible system of searches/queries bookmarked or exposed in lists, dashboards, reports, and agile boards, I have found that I can easily tailor an experience to anything from a complex project through small efforts to grocery shopping without slamming into too many walls or facing highly “enterprisey” experiences for very simple use cases.

For flow integration we use the official .net API - as we as much as possible strive to standardise all our code- & data base to C# and markdown respectively. The experience here has been great as well. We have primarily used the API to update other systems based on changes in tasks, but our wishlist does currently include more bidirectional integration which should be fully supported by the API.

My calendar is still a central part of my day to day flow - essentially feeding tasks from the tracker through a planning phase and into the calendar. Continuing to use the iCloud calendar setup either through the web app or integrated with a local client is an option, but for forward-looking flexibility and a more stable experience I have opted for a self-hosted solution here as well. A couple of options are available here but probably of most broad appeal would be the CalDav service built into Nextcloud. So long as the service runs https, you can add the account to iOS just fine and on the desktop I have worked with a couple of different options until finally settling on the very lovely, but still-pre-release Kalendar project.

Typing

Since the last toolbox update the life of this typist has improved significantly. While Sublime Text is still great and a very important part of my toolbox, OmniSharp unfortunately did not last as a stable experience. Thankfully Rider picked up that slack and then some, offering a rock solid IDE with an extensive suite of tools and of-course neat integration with the other JetBrains products in our arsenal. As a tool for .net and Unity development, Rider has been a no-brainer for a while. Praise aside, particularly for our IL patching workflows I am not really satisfied with the assembly/IL browsing functionality of Rider when it comes to external assemblies rather than the assembled result of a loaded project. For this need I am still a very happy camper with the Avalonia ILSpy project.

Worth noting when speaking of Sublime Text is Sublime Merge - another newcomer since last update. While Fork is still excellent and would be my first recommendation to anyone, Sublime Merge offers better platform support and an interface striking just the right balance for me between simplification and utility.

Given that we standardise on markdown as much as possible, expanding the toolbox with a dedicated markdown editor only made sense. While it offers a lot more than just that, [Obsidian][obsidian] is my pick for markdown editing. At time of writing the WYSIWYG editor is very freshly released, but none the less it is my daily driver for the purpose.

Searching

Developed specifically for the fruit company ecosystem, Dash is another previously mentioned tool in need of replacement. Thankfully the developer is very open to clients on other platforms having great access to the largely-community-supplied documentation packages. The consequence is a healthy selection of alternatives, of which I went for Zeal. Available on Linux, macOS, and Windows, this offline documentation viewer is just as excellent a tool to me as Dash was on macOS.

I honestly did not really have much use of the editor integration of Dash in the past, so only having the global shortcut + search tags for accessing Zeal was not a real change for me. Integration may be available, but given the base I was operating on I just did not go looking for it. Thankfully more alternatives are available and perhaps even a fully editor embedded client - in case that is more relevant to you.

Before the platform & services shift mentioned throughout this write-up, I decided to complete my workstation ergonomics by looking at peripherals which for some inexplicable reason I had ignored through years of paying attention to desk, lighting, seating, and monitors. Perhaps the reason is that this aspect of ergonomics has an odd air of fringe vs. the other aspects.

Previously I had been using a flat wireless keyboard with short key travel and a nicely large wireless touchpad. There are a ton of options and semi-religious opinions in this area, but after a while I settled on a vertical wireless mouse (a regular mouse where your hand orientation ends up more vertical than regular horizontal) and a mechanical split keyboard. I found the ErgoDox open source design very compelling and the number of available options based on it equally so. Aside from being split, the layout is also column stagger rather than the default row stagger - resulting in a more natural primary vertical movement of your fingers rather than constant sideways switching.

Once I had the board in hand I realised the further room for ergonomic optimisation. Since the available boards implementing the ErgoDox design are fully customise-able via the QMK project, you can use visual editors to redefine key functions as you like or even dive fully into the C-based firmware and write your own custom layout & -functionality there. I used this opportunity to further reduce finger stretch by removing use of some keys entirely and moving other functionality to layers (while not accurate, if you think if the shift key as changing the keyboard layout to a layer of capital letters and different symbols, you have the general idea) - including a numpad and pre-baked shortcut keys like the copy key you double-tap to cut or the word left/right keys positioned just above the left/right arrow keys - which again are flanked by the line start/end keys.

Combining these ergonomic layout optimisations with baked shortcut keys and function keys mapped in Plasma to different functionality in different applications (like the macOS shortcut mapping demonstrated in the last toolbox post), my work environment took a significantly step forward on ergonomics, functionality, and sheer accessible speed.

As a bonus, the ErgoDox board I opted for came with per-key LED lighting. As I understand it you are supposed to utilise this for fancy animated effects, providing a clear speed & precision boost when gaming - and while I could certainly use both, I opted instead for using it to highlight key functions in the active layer - like a clear inverted T-shape for the arrow keys or a grid for the numpad etc.

Wrap

And that is about it. All these years later I do not have any current conference plans, but my toolbox certainly keeps adapting to my current needs. Overall I feel much more efficient and flexible in my day to day and am happy to have a feeling of being able to do much more with my local and extended environment - to adapt to personal and company needs on any given effort. I hope that this update has helped inspire you - if nothing else then to review your current toolbox - perhaps to see if anything in there could stand a revisit compared to available alternatives today.

Unity, iOS, TeamCity, AppCenter

2020-12-29 00:00:00 +0100

You can take the developer out of the tools company, but weaning the developer of tool making is another thing entirely. As per usual, at framebunker we remain focused on applying tools development where sensible to increase the efficiency multiplier on all efforts involved in development. This of-course includes a continuous integration setup, where we find another JetBrains solution to fitting our needs very nicely: TeamCity.

Aside from being able to rely on prior experience, we enjoy the flexibility afforded by the solution, suite of available plugins, and direct integration with other parts of our setup. The party trick? Integration in Rider allows not just running of build configurations based on what is already checked in to some branch, but also based on your current local state - for “hey, check this out!” and similar scenarios. Is this offered by other CI setups? Don’t know - probably? Is it cool? Very yes.

The [inaudible] X factor

While we find ourselves working in many different environments from time to time, we seem to gravitate towards Unity and iOS. When you add continuous integration to the mix, that means dealing with the Xcode cli for building and signing something actually useful in distribution. And this is where I wrote my TODO on writing this post. If you take a look around the wider interwebs for clues on how this interface works, you will come across a broad range of advice on how such a feat is achieved. All different, most fully correct at time of writing.

Historically things have changed in this area at least every couple of years which seems to pretty much coincide, with some padding, with how often I need to work with it. So every time I need to set something up, the environment has changed. Obviously underlying technology changes quite naturally over time, but in most cases that does not lead to people also radically changing the interface for said technology - desktop operating systems deal in windows, icons, and cursors, most cars have four wheels and a steering wheel, etc. - even if the technology underlying both has changed quite a bit over the years. Not so in this case. Exaggeration? Probably, but not by a whole lot.

Overview

Anyway, this is not the prime topic of the post - just part of its inspiration. I wanted to describe the whole flow outlined in the title of this post and provide some insight at each step. Hopefully you will find useful bits here and there even if the whole flow is not relevant to your needs - just as I picked up bits and pieces from other posts as well as the very helpful AppCenter support department (comparatively not a lot of community material out there, given how young the product is).

Overall the flow goes like this:

An iOS title is being developed in Unity. For us this means version 2019.4 - the latest LTS release at time of writing.
Collaboration happens via git - pushed to and pulled from a local server. Specifics are largely irrelevant to this flow, but in our case we use Gitea - including its support for git-lfs. Providing related support is an instance of the Unity cache server.
TeamCity is connected to the relevant project repositories and some build configurations are set to trigger as soon as fresh commits are detected. Among other things this provides us with up to date builds of the project available for download via the web interface.
For iOS builds that is not necessarily all that useful (aside from verifying that things build and pass tests) as you need to run an install flow in order to get on-device testing. Further, everyone relevant for distribution of test builds do not necessarily have access to our build server. So we rely on AppCenter (formerly Hockey App - at least this portion of it) to handle distribution of builds.

All of the above runs in Docker containers on our service network - with the exception of the macOS and Windows build agents which run in VMs on developer machines (enjoying that lovely trend of high core count desktop CPUs). In either case configurations easily transfered to other infrastructure - for example when dealing with client projects.

And why not do that? All of the above is definitely available for “free” or a minor fee, running on infrastructure maintained by someone else. Mostly flexibility. Running on someone else’s computer is great when you first start it up and everything lines up perfectly with your needs at the time. Reality, that is at least ours, unfortunately rarely remains on static spec - at which point maybe you can upgrade to a different plan or migrate to a different service, but more likely you end up just sucking it up and compromising your needs in order to not rock the service boat. Without spending time on depressing detail we have similarly had bad and potentially disastrous experiences with service operator support quality. Suffice to say I have no plans to again invite a session well past midnight of jumping VPN exit nodes to circumvent overzealous protection schemes while frantically laboring to salvage our data out of the fire of “computer says no”.

Unity to iOS

Building Unity projects on a CI setup means running the editor via command-line interface - loading the appropriate project in the right import target mode, cache server connected, invoking the appropriate editor script function you write to initiate the build you want, and finally routing output properly back to the CI system. Not a ton of work, but since a “runner” plugin for Unity projects already exists for TeamCity, we decided to not reinvent that particular wheel - relying on this plugin hopefully seeing some support. Our experience with it has unfortunately not been super smooth, so we may revisit that decision in the future.

A couple of things to keep in mind:

“Build and run” is what you would usually click in the Unity editor UI in order to end up with Xcode building a nice iOS app for you. Not so when going via Unity build pipeline API. In stead the flow is:
- Build (not run) - this produces an Xcode project for you.
- Optional modification of the generated Xcode project - utech has a library available for this.
- Instruct Xcode to build the generated (and possibly further modified) Xcode project via command-line interface.
While the build function in your editor script must be static, the class implementing it cannot be. Similarly you should avoid nesting it further than one level in namespacing. Failing any of these will lead to Unity not being able to invoke the function via its command-line parameter.
Builds must take place inside one call stack originating in the function invoked via command-line - so being reliant on processes which need to be requested via Unity API before then being collected via an EditorApplication.update invocation or similar, issuing the final build call, is a no-go. This may well be a result of how the TeamCity plugin structures the actual command-line invocation of Unity, which is part of why we have a review of that plugin scheduled.
Over a number of Unity updates we have unfortunately seen a loss of some build-related functionality. Our solution has been to patch out these regressions directly in the UnityEditor assemblies, but that may not be an option for everyone. I hope to be sharing that setup and such patches in the not too distant future, but we’re not in a position where work on that front pays the bills - so no timeline promises. Build-relevant issues at time of writing (LTS 2019.4):
- Preprocessing scenes is no longer possible - only postprocessing is.
  - Our patch bypasses the scene postprocess setup entirely and invokes our own, with the same sort of attribute markup, as appropriate. Internally it relies on a callback injected before Unity runs its scene processing - thus facilitating preprocessing. I am not aware of a non-patching alternative.
- As promising as it was, the quite new compile pipeline API invokes its events before the produced assemblies are actually moved into place on disk. As a result, any further work on said assemblies is at best not possible (no assemblies there) or at worst defeated (assemblies are modified, only to immediately be overwritten with newly generated copies). Bypassing this issue is further complicated by IL2CPP which makes timing even more critical (no longer a matter of “late enough”, but also “before IL2CPP”).
  - Our patch relies on the compiler pipeline API as a source of “what has been built” (usually “everything”, so gains vs. just assuming “all of the assemblies” are minimal), but otherwise completely bypasses it. For playmode patching we just respond to domain unload and for builds a new callback is injected at a point just prior to IL2CPP invocation, when updated assemblies are known to have been written to disk. I am not aware of a non-patching alternative - particularly when IL2CPP is in play.
- Aside from patching the Unity editor with these things (and other non-build-related stuff), we really enjoy the advantages of build-time changes to project assemblies afforded us by this post-processing flow. More than just code generation (like generating an enum based on Unity layer names), being able to modify, expand, and contextualise the actual code flow based the complete project - not just based on code structure, but actual usage as dictated by asset data - is quite exhilarating. Anyway, that’s an aside - not really build related. As stated - more on this in a later post (tm).

We implement the invocation of our Unity build script as one of two build steps (using the Unity plugin) of our TeamCity iOS build configuration. The other is the invocation of the Xcode CLI for building, signing, and packaging the Unity-generated project. This step is configured as the Command Line runner type, with the following “custom script”:

xcodebuild archive -project "output-path/Unity-iPhone.xcodeproj" -scheme Unity-iPhone -archivePath "output-path/name.xcarchive"

At time of writing that is really it! If you have worked with the Xcode CLI before or trawled the interwebs in search of this one line, you know how much other work has previously been involved. Fingers crossed that the above remains supported - if not static - for years to come. This of-course assumes that your build agent has already been configured to properly build and sign iOS applications when you invoke manually from the Unity editor UI.

The result of this step is an xcarchive - almost what we need for distribution.

iOS to AppCenter

Whether you need to iterate with on-device builds or are sharing progress with the team or external groups, you will eventually need to distribute your build. Signing configuration of-course has to be configured via Xcode and associated online services and I am sure it is possible to automate distribution that way as well - ultimately via TestFlight on the client side. However since that route is currently not mandated, we prefer to keep our multi-platform flow joined for as long as possible - hence AppCenter (or, originally HockeyApp - business will business).

Signing configuration aside, this is our only external service dependency. Given the subject matter, I am inclined to give this one a pass - especially as it means not needing to maintain an additional externally accessible network when distributing to external groups, and the much more manageable hit we would sustain should the service fail us. That said, I am certainly curious about self-hosted options.

While our iOS build configuration in TeamCity is set to trigger when new changes are detected, distribution is either a manual or scheduled step (“gimme NAO” vs nightly builds). Dependent on the project, several distribution configurations exist - one for each group “team”/”testers”/”this partner”/”that partner” as well as “me”. We rely on the TeamCity build configuration template and parameters features to avoid too much duplication between related, but specialised configurations. In the case of the AppCenter ones a template defines the parameters which it then uses in its “command line” build step, while inherited configurations define different values of those parameters (or use the default). For example, the “me” configuration defines the AppCenterGroup parameter as Direct-CI-%teamcity.build.triggeredBy.username%, which the template uses in the “custom script” of its “command line” runner:

COMMAND='appcenter'
COMMAND="$APPCENTER_CLI_INSTALL_PATH$COMMAND"

zip -ry Project.%env.BUILD_NUMBER%.zip Payload
mv Project.%env.BUILD_NUMBER%.zip Payload/Project.%env.BUILD_NUMBER%.ipa
echo "Starting upload now"
$COMMAND distribute release --file "%system.teamcity.build.workingDir%/Payload/Project.%env.BUILD_NUMBER%.ipa" --app %AppCenterApp% --group "%AppCenterGroup%" --token %AppCenterToken%

These configurations are based on the output of the earlier described iOS build configurations. As such they rely on a snapshot dependency from there, with the rule: Project.iOS.*.xcarchive.zip!Products/Applications/**=>Payload/. This instructs TeamCity to collect the zip of the previously generated xarchive and from it copy out the contents of the Products/Applications subfolder - into a local Payload folder. A couple of things to be aware of both in this and how it gets used in the above script:

The choice of the “Payload” folder name is convention. A valid ipa file is a zip archive with the application contained in a subfolder by this name.
Moving the zip file into the Payload folder after compression is not related to the upload process at all. In stead, I simply make use of the fact that I have the build configuration artifact dependency configured to “Clean destination paths before downloading artifacts”. So by moving the archive in there I make sure that the build agent clears it along with the uncompressed app when next it runs this configuration. Note that this does not conflict with having the build configuration use the ipa as its artifact.
Note that while the earlier script example was cross-platform (aside from Xcode being macOS-only), this is a shell script written for Linux or macOS. Initially I had this be a batch script run on our Windows build agent, but since we wanted the distribution step to always be available (as opposed to whenever a developer machine with a Windows build agent was online) and the Windows environment ironically wasn’t ideal for running this tool, I moved it to an Ubuntu-based Docker [container][teamcity-appcenter-agent-docker which could run along with TeamCity and our other services.
While zip is the program you want for zip compression under Ubuntu, on the Windows 10 command-line, you need to use tar - which conversely does not produce zip archives on Ubuntu.
appcenter-cli does not provide any status output - hence the echo command. A --debug flag is available, but turning it on only outputs the REST data sent and received - no additional error information or status reporting results.
Not all AppCenter tokens are created equal. Make sure to use appcenter-cli to create the token eventually supplied to its distribute invocation - tokens created via the web UI are not valid for this use.

Build agent setup

As mentioned, while the TeamCity server itself runs in a Docker instance, the build agents performing the brunt of the actual build-related tasks generally run as VMs on developer machines - with the above exception. This gives us much more free hands to configure the build environments for the tasks needing performed - aside from setting up and running the build agent software itself.

For the AppCenter build agent that means installing nodejs and the appcenter-cli tool. A couple of notes on that:

While the appcenter-cli documentation does mention that it requires nodejs 10, that is not a minimum spec, but an absolute. Installing latest nodejs and hoping for the best will, at time of writing, only lead to long debugging sessions.
When setting up a Windows-based build agent for AppCenter use, you will want to not just install the appcenter-cli node package as a global package, but first modify the nodejs “prefix” from the default location somewhere in the current user path to something global (I go for C:\nodejs) - ensuring build agent accessibility regardless of its user mode now or later.
You may have noticed the APPCENTER_CLI_INSTALL_PATH variable used in the distribution script. This is just an environment variable set on the build agent - not something specific to TeamCity like the configuration parameters. Not only does this facilitate easy adaptation to different build agents offering the same capability - it is also usable as an agent requirement defined in the TeamCity build configuration. APPCENTER_CLI_INSTALL_PATH points to where appcenter-cli is installed, so any agent with that environment variable set should be able to run build configurations dependent on that tool.

For other agents (or the same - if you do not want to run appcenter-cli on unique agents), we just need a licensed Unity install of the appropriate version, the TeamCity agent software, and a Java runtime to run it. macOS agents with iOS-build capability will also need Xcode and its cli installed. Notes:

The TeamCity install provides the agent software - just navigating to the agents overview in the web UI provides an install link. Once the agent is up and running (having been authorized by an administrator via the web UI), the TeamCity install takes care of keeping the agent software up to date.
While Windows agents get a nice little UI installer, the macOS ones are a bit more manual. Minimal steps to get things going at time of writing are as follows (just pasted from our wiki):
1. Unzip buildAgent.zip file to ~/buildAgent.
2. Configure ~/buildAgent/conf/buildAgent.properties:
  - serverUrl=http\://[DNS-or-IP]\:[PORT]
  - name=[MachineName]-macOS(optionally function and number)
  - workDir=[full user folder path]/buildAgent/work
  - tempDir=[full user folder path]/buildAgent/temp
  - systemDir=[full user folder path]/buildAgent/system
  - env.TEAMCITY_JRE=[full user folder path]/buildAgent/jre
  - ownPort=9090
3. Create the folder ~/buildAgent/logs
4. Load the agent for initial connect and auto-upgrade from the server sh buildAgent/bin/mac.launchd.sh load
5. (Administrator authenticates the agent via the web UI)
6. Copy ~/buildAgent/bin/jetbrains.teamcity.BuildAgent.plist to ~/Library/LaunchAgents/
Further / more up to date details are available in this section of the TeamCity documentation.
The days of Java being easily available on macOS are unfortunately gone. Disregard the java install flow suggested by macOS / Xcode and in stead install / fix Homebrew, using it to install the necessary Java version (at time of writing Java 8):

brew cask install adoptopenjdk8

If opting to run appcenter-cli in a QUEMU/KVM based VM, do note that its upload process seems especially susceptible to problems in the default VM driver for the NIC. Making sure that this is set as virtio in stead eliminated some hefty delays when we were still running in a full VM-based agent.

Wrap and future

In general we are pretty happy with this setup. Iteration speed is really snappy, it serves all our needs, and the full flexibility facilitates some pretty cool options. Services are backed up off-premises on the same schedule as everything else and support delays & limitations are zero. Obviously establishing things took a bit more doing than signing up for some services and connecting them, but that cost is nowhere near a place where I would consider trading in all the upsides we have found.

Aside from that review of the Unity TeamCity plugin, we are not likely to be doing a ton of tinkering with this part of our service setup in the immediate future, but one opportunity I did come across while setting up the AppCenter flow was managing distribution group composition via the cli. If so inclined, it might be interesting to have an infrequently run configuration use this to synchronise distribution groups with the Xcode signing groups - especially in a scenario where large groups of recipients are managed and frequently modified. Not currently relevant for us, but it seemed like an interesting project.

Anyway, that’s about it. I hope you found something useful in this overview and best of luck in whatever it is you do.

RAID0 NVMe on Ubuntu

2019-12-07 00:00:00 +0100

A bit of an odd topic after a period of silence, but it’s something that annoyed me greatly recently and so I wanted to spare others that experience. Meanwhile, what has been keeping the updates? framebunker and StaticSky have! In case you missed it, I started (slowly) brushing off and open-sourcing some of our work there (yes, I’ll do what I can to move through my “to open source” list faster): https://github.com/framebunker/Utilities

Update January 2020: Found & updated the link to the blog post which mentioned the appropriate sectors to clear on SSDs for md. Also one of the people who assisted in the Keybase team, David Hauken, wrote a post on this topic.

Challenge

So anyway, I set up a new computer at home - the age of my 2013 laptop showing. On that I wanted to run Ubuntu off a full-disk encrypted drive. However a core point of the build is speed and full-disk encryption (via LUKS) does not necessarily go hand in hand with that.

To offset that, I decided to go for a configuration with two PCIe4 NVMe sticks running in RAID0 (well cooled). Simple enough in principle, but then you hit the community coverage on the topic of “RAID0 is dangerous! Remember to back up your things and don’t pour water on your hardware”. It would appear that an Ubuntu (or event Linux) configuration like this is not super common.

Luckily there were enough bits and pieces out there to, in combination with invaluable assistance from the people of the sysadmins_unite Keybase team, string together a solution.

Process

If, like me, you are migrating an existing install to this setup then first make a backup of that install. I just used rsync - making sure that all file flags etc. were left intact in the copy. In creating the RAID0 across the two NVMe sticks any data already present on either will of-course be lost.

Next, burn the Ubuntu installer onto a bootable medium. This approach probably work on a ton of other configurations, but given that I have only used it with Ubuntu 18.04, I am going to describe them in that known-to-work context.

Boot into your installer and fire up a terminal. In these steps it is assumed that the two NVMe sticks mount at /dev/nvme0n1 and /dev/nvme1n1. If that is not the case in your setup, replace in the correct name where used. On my setup I was able to verify the mount points both in this installer terminal and in the Asus BIOS.

The first step is to install the mdadm tool - for creation and management of md RAID configurations. Note that critical to this particular usecase is the clearing of superblocks and overwriting of first one gigabyte of data. Most guides I came across would instruct clearing data at the end of the target drives, but one (~~I unfortunately lost the link - sorry about that~~ never mind - found it in an old window of research tabs) pointed me to the first gigabyte. As I understand it, this is specific to how md operates on SSD or at least NVMe.

Configuring your RAID:

sudo apt-get install mdadm
sudo mdadm --zero-superblock /dev/nvme0n1
sudo mdadm --zero-superblock /dev/nvme1n1
sudo dd if=/dev/zero of=/dev/nvme0n1 bs=1M count=1000
sudo dd if=/dev/zero of=/dev/nvme1n1 bs=1M count=1000
sudo mdadm --create --verbose --level=0 --raid-devices=2 /dev/md0 /dev/nvme0n1 /dev/nvme1n1

With your raid up and running in your installer session, I really hope you did not forget to copy data you really wanted off those sticks. Anyway, the next step is to run the Ubuntu installer, opting to do “something else” when typical vs. not-quite-typical install configuration is chosen. This takes you to a screen where you get to specify which drives and partitions are get used for what in your fancy new install. Necessary config:

Format your new /dev/md0 drive. For me that was formatting to LUKS and then adding an ext4 partition to that. You could also format directly to ext4 if you do not want the encryption, but in that case you might want to do that outside of the installer - for optimum performance. See the later section for specifics on that.
Specify that the installer use your final ext4 partition as root /.
Use a different drive and partition for EFI and /boot. This is critical as your bios will not know how to assemble the md RAID and boot from it - you need /boot to handle that. There were some very creative suggestions in sysadmins_unite on where one might put /boot, but I simply have a SATA drive in my rig used for more rough work and first tier backup. I just set up /boot and EFI partitions there.

That’s it - configure the rest of the installer as you like and run it to completion. When it does complete and prompt you to restart, don’t do that. The RAID still only really exists within this installer session so if you reboot now, you might as well start over.

The Ubuntu installer will have your new install partition mounted at /target. You need to make some edits to it in order to have it properly mount and run off your RAID from boot. If you closed the terminal from before, open up a new one and run this:

sudo mount /dev/[partition used for /boot] /target/boot
sudo mount --bind /dev /target/dev
sudo mount --bind /sys /target/sys
sudo mount --bind /proc /target/proc
sudo cp /etc/resolv.conf /target/etc/
sudo gedit /target/etc/default/grub

In gedit you need to update the value of GRUB_CMDLINE_LINUX to "domdadm", save, and close the editor.

Finally you need to add mdadm to your new install, which will also apply your grub change along with its own to the boot setup, after which we are good to reboot and test the install:

sudo chroot /target
apt-get install mdadm
exit
sudo reboot now

If you just wanted a fresh install, then this is the “profit!” step. Otherwise, restore your previous install onto your new root partition and update it to support your new boot setup by rebooting into the installer again and running this in a terminal:

sudo apt-get install mdadm
sudo mdadm -A -s
sudo mkdir /target
sudo mount /dev/md0 /target
sudo mount --bind /dev /target/dev
sudo mount --bind /sys /target/sys
sudo mount --bind /proc /target/proc
sudo cp /etc/resolv.conf /target/etc/
sudo chroot /target
apt-get install mdadm
exit
sudo reboot now

And that is your “profit!” step.

ext4

If you just want to run ext4 as fast as possible directly on your RAID drive, you might want to manually work out the configuration of that partition to optimally work with the underlying RAID configuration. Key here is specifying the correct stride and stripe-width:

Chunk = 512 (output by or set via mdadm)
Block = 4 (ext4 dictated)
Devices = 2
Stride = 512 / 4 = 128
Stripe width = 2 * 128 = 256
Resulting in the formatting command sudo mkfs.ext4 -v -L nvmeRAID -m 1 -b 4096 -E stride=128,stripe-width=256 /dev/md0.

Wrapup

I hope this works out for you. It definitely took me more research, trial, and error than I would have liked to arrive at a functional approach. At this point I have been running the resulting setup for a month or two without the hint of an issue.

A Change of Gears

2017-12-28 00:00:00 +0100

Having completed my latest contract, working splendidly with Charles and Nicholas over at framebunker, we decided to extend our combined reach and potential by joining forces.

I got into contracting in the first place in order to find a new team. This year I had made it my mission to end that search and as it turned out, the team was much closer than expected.

What this means:

Contracting continues, now through framebunker. If you have a job that needs doing, give us a shout.
We enter into final production on Static Sky.
As Static Sky ramps down, we spin up new and exciting production – stay tuned for more updates on that.
I pick up the slack on the feed here as we launch a series of technical blog posts from framebunker.
Both Behave development and Game AI North organisation continue unaffected.

I am very excited about this change as it allows us all to be more productive, while maintaining a more stable work environment. I look forward to share more in 2018.

CoreObject

2017-07-04 00:00:00 +0200

I once built a talk with a collection of new hacks. This talk went through a couple of almost-delivered scenarios and with the new side projects I have since accumulated, scheduling gets difficult.

So I would rather share this stuff in post form now than stall for a possible eventuality. I have no idea how frequent I will be able to post, but here is one at least.

Challenge

Most Unity projects get spread across multiple scenes very quickly. This is advantageous not only for clearly segmented production, but also for tweaking of load times, streaming, and much more.

An unfortunate side effect of this is an increase of challenges in referencing objects in a live session, across those scenes. Desired targets include objects baked into specific scenes and specific instances created at runtime.

Common approaches to solving this include dependency injection and directory singletons – both of which work really great. Unfortunately they both introduce a level of indirection in the Unity serialisation system, making it impossible to track cross-scene dependencies with generic tools. This also usually adds a programming- or finicky book-keeping step to the process of introducing new conceptual instances.

If we could solve this challenge, we would end up with a clear dependency chain in the serialisation system, which would allow us to fully utilise the tracking and tooling benefits this yields, while greatly reducing the barrier to add new concepts and interact with existing ones.

Detour

With each scene a serialised island, there is one more (ignoring bundles) serialisation hub which all scenes can access: Assets.

Both the instance and its consumer can reference the same asset, which we can then use to facilitate a connection between the two. Further, with both referencing the same asset, we now have that dependency information in the serialisation system. Also, adding new conceptual instances is just a matter of creating a new asset, assigning it to either end.

Another bonus is easy listing of all conceptual instances by simply finding all assets of the type. You can demonstrate this via the object picker. Should you prefer a drop-down selector to the object picker, such would be a fairly straight forward piece of property drawer code. You could even utilise asset folder structure to define drop-down nesting.

Implementation

The base (5.3 tested) implementation of this needs three pieces:

A ScriptableObject type representing the conceptual instance as an asset.
- Example abstract, example concrete.
One MonoBehaviour registering a source.
- Example.
A serialized reference to the ScriptableObject type or a MonoBehaviour acting as a gateway to the instance – similar to a MeshFilter component.
- Example.

In the given example, the instances being passed around are just GameObjects. However in a real world scenario you may also want to create CoreObject<T> derivatives passing references to specific components. Not only does this facilitate quicker access to the components you need – it also naturally separates CoreObjects into categories.

A corresponding instance component could look a little something like this.

Variants

While this base functionality has plenty of utility, I have on occasion played around with variants on the concept. For one, the base idea passes a single-source instance producer to multiple consumers, but there is no reason why you could not use this setup to register/unregister to a list of instances in stead.

A personal favourite variant is more fundamentally different. In stead of facilitating references, the core objects wrap UnityEvents – turning them into global “game events”. This allows you to completely decouple event producers and consumers, while maintaining dependency tracking through the serialisation system.

The pattern I mostly use such events in start with the producers invoking the event via a serialised UnityEvent. Say you expose a “fire” UnityEvent to which you add a particle effect invocation, audio playback, and finally the invocation of the CoreGameEvent “gunshot”.

This “gunshot” event would then be referenced by CoreGameEventHandler components which also exposes a “handle” UnityEvent. The action list of this event could then include stuff like switching the soundscape, putting NPCs into an alert state, trigger an auto save, and whatever else might be useful.

Not only do you get decoupling of produces and consumers – you also get to centralise handling details around the individual consumers as opposed to leaving them all jumbled up at the producer.

So what do you think? Do you use something similar? What cool variants and tooling do you employ?

Source and examples

Unity Protocol Buffers

2017-02-17 00:00:00 +0100

Time for another “ah, crap – better put something up here before heading to GDC”-post. And since I did some re-tinkering with the integration of protobuf in Behave late last year, some sharing on that topic seemed in order.

So yes, stuff is happening with Behave – no abandonment has taken place. On the contrary I have been working on several, long-running, feature branches. I’ll get around to merging some of those in and doing another release. More on that soonish.

Anywho, last I checked, protobuf-net was still a more complete solution than the younger protobuf for C# one, so I still stick with protobuf-net and can therefore only talk about that here. However it looks like the latter is seeing more rapid development, so I’ll probably review my choice when next I need to tinker with the integration.

More interestingly, some of the initial people behind protobuf have since gone and built the new and shiny Cap’n Proto. This looks to be even more powerful than its predecessor, but at time of writing it is still not as mature or implementation-rich as protobuf. Critically for the context of this post, there is no C# implementation yet. Cool stuff, though – worth keeping an eye on.

Overview

So what is the Protocol Buffers project? Succinctly, it is a compact binary serialisation format with very fast cross-platform and -language implementations. Super useful when you need to quickly move some data between memory and some other location – a file / a network peer / whatever.

It was first designed, implemented, and maintained by Google for communications between network peers on their internal network. Since then, it has been implemented in a number of different languages – including the protobuf-net implementation, built and maintained by Marc Gravell.

Serialisation use in Behave has gone through a couple of distinct phases:

.net binary serialiser for asset.
protobuf-net for asset.
protobuf-net for asset and remote debugger protocol.
JSON for asset, protobuf-net for remote debugger protocol.

Additionally I’ve used protobuf-net for runtime saving or build pipelines on various client projects.

Aside from speed and compression, protobuf-net vs. the .net binary serialiser was also an escape of the frustrating lack of support for versioning or even simple structural refactors of serialised types. The switch to JSON for the .behave asset files of-course came when I decided that merge-ability could be a fun thing to support.

On top of this general migration, I also went through a couple of different protobuf-net integrations – as my use cases and requirements changed. It just so happens that this gave me full coverage of the three approaches supported by protobuf-net, so no need for extra research before writing this post. Win!

Integration

For serialisation to work, you need a a serialiser and a schema. Protobuf-net offers a couple of ways for you to provide those:

[Attribute] markup with runtime generated serialiser.
[Attribute] markup with pre-generated serialiser.
.proto file description with pre-generated serialiser.

I did this list in order of simplicity, which also happens to be the order in which I switched through them in the integration with Behave.

The first option is very .net esque and protobuf-net is indeed compatible both with its own serialisation attributes and the more general-purpose .net serialisation attributes. However since your interest here is in a Unity context, I’m sure that you have already spotted the problem with this approach.

Given that my initial use for protobuf-net was just for asset serialisation (which is editor-time only), I had no problem with the serialisation solution relying on JIT compilation in order to construct the serialiser at runtime. However as soon as I expanded my use case to include the runtime debugger, relying on JIT would mean not supporting the debugger on AOT platforms like iOS and consoles. Further, as Unity continues transitioning to their IL2CPP solution, you’re looking at a future where most will want to do AOT on all platforms.

So when introducing the remote debugger (previous debugger implementation was just 100% in-editor), I started to pre-generate the serialiser. This entails feeding your compiled assembly with [Attribute] markup to the protobuf-net precompile tool, which in turn generates an assembly with the serialiser type. For an example of how I used to do that, here’s a snippet of perl.

Extraction

Everything works! Win, right? Well… as I was expanding debugger support to non-C# targets and doing a general code cleanup, I got increasingly annoyed by having serialisation implementation detail in my general data type code. So I started looking at how protobuf-net supports the standard protobuf .proto format for schema definition.

As things stand, it takes a bit of work – specifically this work – to get going, but once there it is solid. In stead of using the precompile tool, you need to build and run the protogen tool from the protobuf-net repository. If you’re on Windows, things may just work straight out of the gate, but you may want to see what is in my patch anyway.

So how does this work? Well, the input is no longer [attribute] marked assemblies, but in stead a .proto definition file. You can find great detail on that in the general protobuf documentation, but you may want to consult the protobuf-net docs for implementation specifics/limits. Also, the output is not an assembly, but simply a C# file.

Keep in mind that protogen relies on the protoc tool from the general Google protobuf tools. I fetched this from homebrew as the “protobuf” package.

Again I have a snippet of perl to illustrate use – as well as an example .proto file. In this case the Behave debugger protocol definition.

Using this approach, I now have a nicely separated codebase and no duplication of schema definition between the C# debugger runtime and others. One trick remains though…

Object pooling

A mildly active Behave debugger session involves a lot of messages. I have very little interest in blowing up the garbage collector by constantly instantiating new messages and leaving them to get collected. So how do we integrate an object pool setup with the generated protobuf-net serialiser?

While not exactly as pretty as I would like, my answer is making use of the partialness of the generated types – in order to add a static pool and -constructor to hook it up.

And that’s pretty much what I’ve got. If I missed something or you have related questions, feel free to ping me and I’ll try to update this post when I can.

Behave 2.7

2016-02-13 00:00:00 +0100

The serialisation update is here! Ok maybe that is not the most exciting change for everyone, but I for one am quite happy about having finally shipped it. Aside from making life a lot simpler for anyone vaguely interested in collaborating on Behave libraries across version control systems, this lays the groundwork for a good number of runtime changes I have been wanting to do for a while.

Aside from just fixing up serialisation, this release focuses on improving editor usability with a good selection of tweaks and features. Some choice examples:

Behaviour tree minimap navigation.
Subtle indicator of tree origin direction when it is out of canvas view.
“Larger fonts” toggle for better visibility.
Hiding of component- and sidebar, plus a bunch of other canvas navigation tweaks.

Onward

After clearing this serialisation system obstruction out of the way, the road is now open for a host of planned features. Most of these are aimed at improving runtime flexibility, by increasing the available options for the tools you are already familiar with.

If you happen to be at this years GDC in a little months time, perhaps we could meet and exchange ideas on this?

Changelist:


2.7:
 - New library serialisation.
     - Backwards compatible with all 2.x variants.
     - All other formats are deprecated: text, binary, export/asset.
         - Exports are auto-upgraded, but please make sure to follow editor instructions when opening asset-type libraries.
         - Run your upgrades now. Future versions of Behave will not support deprecated serialisation.
     - Support for pre-2.0 decorators finally dropped.
     - Faster and less frequent serialisation.
     - Designed for optimal inter action with version control systems.
     - Custom inspector for Behave libraries is dropped in Unity 4.
         - Aside from the visuals, this just means that the Behave window now only can be launched by double-clicking the library or via the Window menu.
 - Behaviour tree minimap navigation - activate via alt+space.
 - Float/Clamp toggle for turning off canvas clamping when setting up large new tree structures.
 - Subtle indicator of tree origin direction when it is out of canvas view.
 - "Warn on non-mandatory actions and contexts" compiler toggle to support team communications.
 - "Larger fonts" toggle for better visibility.
 - Hiding of component- & sidebar.
 - Similar to reference components, components (and connections) referencing records can now also be double-clicked to navigate there.
 - Compiler adapted to new Unity distribution structure on OS X with Unity 5.4.
 - Home screen update.
 - Improved editor performance - particularly on larger libraries.
 - Better error handling for establishing debugger connections.
 - Tidying up and calming antivirus software by using Unity project Temp folder in stead of global temp.


2.6.4:
 - Fixed protobuf compatibility with Unity Windows.NET build targets.


2.6.3:
 - Fixed compiler execution on certain versions of OS X.
 - Minus one popup in the Windows compilation process.


2.6.2:
 - Fixed Windows compiler issue.


2.6.1:
 - Addressed Unity 5.1 compiler configuration compatibility issue.


2.6:
 - Removed backwards compatibility with Behave 1.x assets. That should be sufficient grace.
 - Removed a number of utility types from publicly accessible namespace - should be a lot less cluttered now.
 - Changed Tree.TickWrapping to now take exception handling behaviour parameter as an enum in stead of a boolean.
 - Changed Tree.LastTickTime to return DateTime ticks rather than a UnityEngine.Time.time value.
 - Fixed corner case where Unity could lock up while stripping Behave.
 - Fixed setting of Tree.LastTicked and Tree.ActiveID. Both will always reset to ActionType.Unknown, never -1.
 - Fixed compiler being able to handle Unity being installed on a path containing spaces.
 - Improved compiler error messages.
 - Added intellisense documentation to the runtime API.
 - Added int[] Tree.SupportedActions.
 - Added Tree.Owner for better handling of agent reassigning in pooling scenarios and similar.
 - Added ICollection. GetAsInt (int) and GetAsBool (int).
 - Action handler classes.
     - Added IActionClass and Tree.SetForwards (int, IActionClass) for init/tick/reset handling to a specific class instance.
     - Added Tree.ReflectForwards (GameObject) setting forwards for MonoBehaviours implementing IActionClass.
 - Editor polish.
     - "Now Behave library being edited" label now comes with a shortcut "Create" button.
     - More informative load messages in the home screen, including progress bars.
     - With Unity 5 dropping the engine feature delta, in-editor video viewing is now available on non-pro licenses as well.


2.5.4:
 - Address Unity 5 compatibility issue with the home screen.


2.5.3:
 - Fix issue with home screen not closing.


2.5.2:
 - Play nice on Unity free again.


2.5.1:
 - More rigid network code for setting up the debugger.
 - Upgraded protobuf-net distribution to r668, Unity, full.
 - Drowned out debug logging accidentally included in 2.5.0.


2.5:
 - Optional text serialisation.
     - Switch between text and binary serialisation in library settings.
     - Full and partial exports to text or binary file.
     - NOTE: Libraries opened in this version of Behave will be upgraded and are afterwards not backwards compatible.
 - Compiler upgrade.
     - Added lots of little CPU and memory optimisations.
     - Added tree analysis leading to larger memory saves on references when possible.
     - Improved handling of circular references.
     - Improved error reporting.
     - Changed name validation.
         - Underscores are no longer allowed in names - in order to avoid name clashes with pathed assets.
         - Fixed previously allowing leading numbers in names.
 - Runtime API.
     - Added library.ReflectForwards (ICollection, object).
     - Added library.SupportedRecords (ICollection).
     - Added blueprint.SupportedTrees.
     - Added Library.DidInstantiate (ICollection / Tree).
     - Changed generated enums to be valued continuously.
     - Changed get calls for unhandled records to now return -1.
 - Editor polish.
     - Improved debugger view.
         - Improved control bar layout.
         - Improved rendering of active referenced trees.
         - Fixes to follow-focus.
         - Debug view no longer re-crops to current visible tree area, preventing the previous behaviour of the view jumping around even without follow-focus enabled.
         - Improved sidebar listing of available- and connected runtimes.
         - Improved handling of disconnecting runtimes.
         - Improved tracking of available runtimes. No more need for refreshing.
         - Improved UI for adding debugger overrides.
         - Added "Add overrides enabled" setting (on by default).
     - Library vertical scrollbar replaced by standalone scroll buttons top / bottom when relevant - reducing visual noise.
     - Smaller tweaks and fixes.
 - Improved internal test coverage.


2.4.2:
 - Fixed some issues related to handling priority selectors in the recently update debugger.


2.4.1:
 - Fix corner case when restructuring library assets.


2.4:
 - Introducing “records”.
     - Float fields stored in “collections” - essentially ‘smart tables’.
     - Blackboard fields.
     - Utility curves.
     - Utility graphs.
     - Behaviour Tree integration.
          - “Tester” component.
          - “Writer” component.
          - Record mode for Priority Selector component.
 - Editor behavioural change: Deleting a tree no longer deletes reference nodes targeting that tree from other trees. Their target is merely cleared.
 - Editor behavioural change: The Reference node is only available in the component bar if the library contains more than one tree. Same behaviour for Tester and Writer with records.
 - Behavioural change: Invert flag is now properly applied by the Priority Selector.
 - Debugger connection stability improvement.
 - Connection disabling has been removed. This confusing feature caused more harm than good.
 - Video player now displays video title and description.


2.3.5:
 - Fix home screen video player.


2.3.4:
 - Better error messages in case of insufficient file access privileges (OHAI Perforce).
 - Added simple version check to the home screen.
 - New icons for Priority Selector and "form new tree".
 - Smaller, embedded, JSON library.
 - Fix annoying behaviour with tree renaming where text fields would keep last entry.
 - Fix similar behaviour with component text fields on tree selection change.
 - Unity 5 compatibility fixes (tested on beta 2).


2.3.3:
 - Fix focus handling issue with auto-complete.
 - Parametrisation is now correctly applied for reset handler calls.


2.3.2:
 - Fix sidebar item duplication and deletion only functional during rename.


2.3.1:
 - Fix GUI error being logged on tree selection.
 - Proper handling of currently edited library asset being deleted.


2.3:
 - Added support for instant repeaters.
 - Added support for mandatory contexts.
 - Added optional target parameter to Tree.ResetForwards.
 - Added Tree.TickWrapping method.
 - Added debugger auto-launch settings to library build options.
 - Added home screen - shown on launch or via the Help menu, full of resources.
 - Behavioural change: Decorators no longer forward the instant flag of their child node.
 - Behaviour of decorators receiving a Running signal from their control connection is now defined.
 - Dependencies now shipped as separate (replaceable) files for minimal project impact.
 - Editor polish.
     - Added support for running multiple editor debugging instances on one machine.
     - Added focus-follow for debugger and canvas.
     - Added both scrollwheel/pad and drag-to-scroll support to all canvas views.
     - Drag connection to occupied input slot to replace.
     - Directly drag-drop trees from the sidebar onto the canvas as reference nodes.
     - Instant flag doesn't show on nodes connected to parents ignoring the flag.
     - "Last edited library" now tracked per project.
     - Last selected tree is now also restored between sessions and playmode transitions.
     - A bunch of minor adjustments and improvements.
     - Performance + memory + disk space optimisations.
     - Minor bugfixes.
 - New documentation layout and enhancements (already released as available).
 - Reshuffling of code to make way for exciting new things down the road.


2.2.2:
 - Addressed protobuf issue causing Parallel component completion setting to not get stored correctly.


2.2.1:
 - Fixed issue causing parallel components to fail compilation.


2.2:
 - Behavioural change: Support for multiple different action handler signatures is discontinued effective immediately.
    - Generated agent blueprint as well as accepted reflected signatures are now only:
        - public BehaveResult [Tick/Init][Name]Action (Tree sender);
        - public void Reset[Name]Action (Tree sender);
 - Added Tree class accessors - all valid only during an active init/tick/reset handler call:
    - string ActiveStringParameter
    - float ActiveFloatParameter
    - IAgent ActiveAgent
    - object ActiveData
 - Rather than waiting for the Unity bugfix, the built-in compiler API is now bypassed in favour of direct compiler binary execution.
    - An additional system-level mono SDK install is no longer needed to work around this Unity bug.
 - Tree.SetForward now returns boolean success value rather than logging error when passed unused action.
 - Full-library export now also available from the library settings in stead of menu-only access.
 - Even more UI polish: Better word-wrap, more contrasts for emphasis, instant flag hidden in unaffected scenarios and much more.
 - "Form new tree" nicely moves the new subtree up around the root socket rather than retaining the old position.
 - Default frame-rate of DebugUpdater now set to 20 fps rather than every frame. Gun safety and all that.
 - Massive codegen size save for larger libraries - from optimisation of tree-agent introspection codegen. Compile-time win.
 - More rigid parameter evaluation (remove needless occasional extra codegen).
 - Fixed copy and duplication procedures incorrectly not copying parameter values.
 - Force Unity to write serialised data before compiling.


2.1.1:
 - Fixed issue with tree paramterisation breaking debugger visualisation.


2.1:
 - Added autocomplete on action names, string parameters and component contexts.
 - Added mandatory actions (present in library regardless of use in trees).
 - Added partial library export and library merging / import-to-library.
 - Added Behave stripping - leave behind only a very lean Behave runtime, for redistribution or super slim deploy.
 - Added parameterised trees - get even more re-use out of your trees by overriding context and variables per reference.
 - Behavioural change: Tree.Reset will now delay resetting tree variables until after complete component reset.
 - Behavioural change: Tree.Tick will no longer automatically reset the tree upon completion. This plays very well with:
 - Added Tree.TickContinuously (int iterationCap = 1024) - ticks tree till completion or iteration cap is reached.
 - Added BehaveResult Tree.Result (bool value) utility function to side with Tree.Invert (BehaveResult value).
 - Added int Debugging.Local.ConnectionCount property - facilitating debug behaviour dependent on Behave debugger presence.
 - Moved default install path from Assets/Behave to Assets/Plugins/Behave.
    - WARNING: See Readme.txt upgrade guide.
 - Fixed decorator control node removal resulting in detached control connection.
 - Fixed decorator incorrectly not forwarding the instant status of its child node.
 - Fixed scenario where agent classes would get reflected for handlers even if blueprint derived.
 - Fixed unexpected corner cases of bad library configuration failing compiles (now causing warnings or simply being ignored).
 - Fixed Behave window breaking down when exiting play mode after having been active there.
 - Fixes to context getting incorrectly reset in some scenarios.
 - Fixed copy / paste functionality missing in some text fields.
 - Lots of UI polish and minor fixes.


2.0:
 - New editor.
    - Unified all controls into one window.
    - Completely customised look - compatible with both Unity light and dark skin.
    - Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
    - Remote debugging.
    - Tick and reset.
    - "Unplug" for debugger-only control.
    - Breakpoints.
    - Action overrides - override the return values of specified actions.
 - Decorator rewrite.
    - Deprecated old decorator.
       - Still compiles, but cannot be added.
    - Decorators are now control-type components.
       - No specific decorator handlers on agents.
       - Control is achieved via third connection socket.
    - Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
 	- No more collections - for nesting, use paths in tree names.
 	- New serialization format - see Readme.txt for upgrade instructions.
    - Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
	- Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
    - int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
    - enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
    - enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
    - int Tree.ActiveContext { get; }
 - Changed IAgent interface:
    - Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
    - Trees -> TreeType.
    - Actions -> ActionType.
    - Decorators -> DecoratorType.
    - Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
    - int TreeID (Tree) -> static TreeType Type (Tree)
    - bool IsAction (int) -> static bool IsAction (int)
    - bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
    - public void Reset[Name][Action/Decorator] (Tree sender);
    - public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
    - Component bar.
    - Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
    - When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
    - When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
    - Behaviour tree decorators.
    - Stand-alone edition of the Behave editor.
    - Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
    - Not able to delete collections from library.
    - Not able to delete trees from library.
    - Not able to rename collections from library.
    - Not able to rename trees from library.
    - Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

Learn

2015-07-17 00:00:00 +0200

I’m just about to wrap up a weeks vacation before it’s back on the horse again – as I leave for the nucl.ai conference Sunday morning. If you’re going, maybe I’ll see you there? If not, you should go check out the live stream.

Basis

Anyway, so in my vacation I built a little project when I could find a bit of time here and there. It was inspired by work on a client project earlier in the year, where we looked at wiring up a neural network for analysis of a noisy sensor.

The problem at the time was that although I could find a few C# NN libraries here and there, they were either not really a good fit or had a not-so-open open-source license like GPL (good thing I don’t have comments enabled here, eh?).

Anyway, that felt a bit silly, so I figured that I’d at least get the ball rolling on a somewhat sane, MIT licensed, alternative. Either that or just have some fun with it until someone would point me at the obvious alternative solution, which I had overlooked in my earlier search.

Project

In its initial shape, the library just lets you construct a layered network, randomize its weigths, train it with a straight forward implementation of back-propagation with adjustable learning rate and momentum, and of-course run it.

There is no serialisation interface yet, I’ll probably want to do a simplification pass over it, and I have a few edge case tests I’d like to run. However all of that is noted on the project TODO and shouldn’t amount to all that much work – in case you fancy taking a stab at it.

I did set up a little Unity project for testing though (the library itself does not depend on anything in Unity). It has a few debug views, a test scenario of the XOR case, and a curve visualisation of training error. Look, I uploaded several pretty pictures:

Access

Feel like giving it a go? As mentioned, the license is MIT, so you can really do whatever with it. However should you want to contribute, pull requests are most welcome. I don’t know how much time I can spare on this next to contracts and Behave, but at least it was a fun thing to work-on-while-not-working.

Whatever the case, this is where you can find the repositories:

Behave 2.6

2015-06-13 00:00:00 +0200

Still plenty of open feature branches on Behave, but now is the time for the next drop. With a little over a week till Unite Europe and shortly thereafter nucl.ai (formerly GameAIconf), I’m also heading into a bit of a plenty-to-do period. Perhaps we’ll meet at the conference and have a chat about it?

With only minor editor tweaks, the 2.6 release of Behave focuses primarily on API changes and added capabilities. The more exciting of these is probably the addition of action classes, allowing you to implement actions not just as singular event handlers on agent classes, but as standalone classes – or in the case of Unity, as components.

The reference documentation has been updated with a “Composition” section describing the setup in more detail.

Do note that in this release, Behave is no longer backwards compatible with Behave 1.x assets.

Onwards

Unfortunately some planned features are taking a bit longer as they depend on a serialisation system refactor, requiring an extended period of focus. The groundwork for this has been effectuated and given time, should shoulder an effective change leading to interesting new capabilities.

Changelist:


2.6:
 - Removed backwards compatibility with Behave 1.x assets. That should be sufficient grace.
 - Removed a number of utility types from publicly accessible namespace - should be a lot less cluttered now.
 - Changed Tree.TickWrapping to now take exception handling behaviour parameter as an enum in stead of a boolean.
 - Changed Tree.LastTickTime to return DateTime ticks rather than a UnityEngine.Time.time value.
 - Fixed corner case where Unity could lock up while stripping Behave.
 - Fixed setting of Tree.LastTicked and Tree.ActiveID. Both will always reset to ActionType.Unknown, never -1.
 - Fixed compiler being able to handle Unity being installed on a path containing spaces.
 - Improved compiler error messages.
 - Added intellisense documentation to the runtime API.
 - Added int[] Tree.SupportedActions.
 - Added Tree.Owner for better handling of agent reassigning in pooling scenarios and similar.
 - Added ICollection. GetAsInt (int) and GetAsBool (int).
 - Action handler classes.
     - Added IActionClass and Tree.SetForwards (int, IActionClass) for init/tick/reset handling to a specific class instance.
     - Added Tree.ReflectForwards (GameObject) setting forwards for MonoBehaviours implementing IActionClass.
 - Editor polish.
     - "Now Behave library being edited" label now comes with a shortcut "Create" button.
     - More informative load messages in the home screen, including progress bars.
     - With Unity 5 dropping the engine feature delta, in-editor video viewing is now available on non-pro licenses as well.


2.5.4:
 - Address Unity 5 compatibility issue with the home screen.


2.5.3:
 - Fix issue with home screen not closing.


2.5.2:
 - Play nice on Unity free again.


2.5.1:
 - More rigid network code for setting up the debugger.
 - Upgraded protobuf-net distribution to r668, Unity, full.
 - Drowned out debug logging accidentally included in 2.5.0.


2.5:
 - Optional text serialisation.
     - Switch between text and binary serialisation in library settings.
     - Full and partial exports to text or binary file.
     - NOTE: Libraries opened in this version of Behave will be upgraded and are afterwards not backwards compatible.
 - Compiler upgrade.
     - Added lots of little CPU and memory optimisations.
     - Added tree analysis leading to larger memory saves on references when possible.
     - Improved handling of circular references.
     - Improved error reporting.
     - Changed name validation.
         - Underscores are no longer allowed in names - in order to avoid name clashes with pathed assets.
         - Fixed previously allowing leading numbers in names.
 - Runtime API.
     - Added library.ReflectForwards (ICollection, object).
     - Added library.SupportedRecords (ICollection).
     - Added blueprint.SupportedTrees.
     - Added Library.DidInstantiate (ICollection / Tree).
     - Changed generated enums to be valued continuously.
     - Changed get calls for unhandled records to now return -1.
 - Editor polish.
     - Improved debugger view.
         - Improved control bar layout.
         - Improved rendering of active referenced trees.
         - Fixes to follow-focus.
         - Debug view no longer re-crops to current visible tree area, preventing the previous behaviour of the view jumping around even without follow-focus enabled.
         - Improved sidebar listing of available- and connected runtimes.
         - Improved handling of disconnecting runtimes.
         - Improved tracking of available runtimes. No more need for refreshing.
         - Improved UI for adding debugger overrides.
         - Added "Add overrides enabled" setting (on by default).
     - Library vertical scrollbar replaced by standalone scroll buttons top / bottom when relevant - reducing visual noise.
     - Smaller tweaks and fixes.
 - Improved internal test coverage.


2.4.2:
 - Fixed some issues related to handling priority selectors in the recently update debugger.


2.4.1:
 - Fix corner case when restructuring library assets.


2.4:
 - Introducing “records”.
     - Float fields stored in “collections” - essentially ‘smart tables’.
     - Blackboard fields.
     - Utility curves.
     - Utility graphs.
     - Behaviour Tree integration.
          - “Tester” component.
          - “Writer” component.
          - Record mode for Priority Selector component.
 - Editor behavioural change: Deleting a tree no longer deletes reference nodes targeting that tree from other trees. Their target is merely cleared.
 - Editor behavioural change: The Reference node is only available in the component bar if the library contains more than one tree. Same behaviour for Tester and Writer with records.
 - Behavioural change: Invert flag is now properly applied by the Priority Selector.
 - Debugger connection stability improvement.
 - Connection disabling has been removed. This confusing feature caused more harm than good.
 - Video player now displays video title and description.


2.3.5:
 - Fix home screen video player.


2.3.4:
 - Better error messages in case of insufficient file access privileges (OHAI Perforce).
 - Added simple version check to the home screen.
 - New icons for Priority Selector and "form new tree".
 - Smaller, embedded, JSON library.
 - Fix annoying behaviour with tree renaming where text fields would keep last entry.
 - Fix similar behaviour with component text fields on tree selection change.
 - Unity 5 compatibility fixes (tested on beta 2).


2.3.3:
 - Fix focus handling issue with auto-complete.
 - Parametrisation is now correctly applied for reset handler calls.


2.3.2:
 - Fix sidebar item duplication and deletion only functional during rename.


2.3.1:
 - Fix GUI error being logged on tree selection.
 - Proper handling of currently edited library asset being deleted.


2.3:
 - Added support for instant repeaters.
 - Added support for mandatory contexts.
 - Added optional target parameter to Tree.ResetForwards.
 - Added Tree.TickWrapping method.
 - Added debugger auto-launch settings to library build options.
 - Added home screen - shown on launch or via the Help menu, full of resources.
 - Behavioural change: Decorators no longer forward the instant flag of their child node.
 - Behaviour of decorators receiving a Running signal from their control connection is now defined.
 - Dependencies now shipped as separate (replaceable) files for minimal project impact.
 - Editor polish.
     - Added support for running multiple editor debugging instances on one machine.
     - Added focus-follow for debugger and canvas.
     - Added both scrollwheel/pad and drag-to-scroll support to all canvas views.
     - Drag connection to occupied input slot to replace.
     - Directly drag-drop trees from the sidebar onto the canvas as reference nodes.
     - Instant flag doesn't show on nodes connected to parents ignoring the flag.
     - "Last edited library" now tracked per project.
     - Last selected tree is now also restored between sessions and playmode transitions.
     - A bunch of minor adjustments and improvements.
     - Performance + memory + disk space optimisations.
     - Minor bugfixes.
 - New documentation layout and enhancements (already released as available).
 - Reshuffling of code to make way for exciting new things down the road.


2.2.2:
 - Addressed protobuf issue causing Parallel component completion setting to not get stored correctly.


2.2.1:
 - Fixed issue causing parallel components to fail compilation.


2.2:
 - Behavioural change: Support for multiple different action handler signatures is discontinued effective immediately.
    - Generated agent blueprint as well as accepted reflected signatures are now only:
        - public BehaveResult [Tick/Init][Name]Action (Tree sender);
        - public void Reset[Name]Action (Tree sender);
 - Added Tree class accessors - all valid only during an active init/tick/reset handler call:
    - string ActiveStringParameter
    - float ActiveFloatParameter
    - IAgent ActiveAgent
    - object ActiveData
 - Rather than waiting for the Unity bugfix, the built-in compiler API is now bypassed in favour of direct compiler binary execution.
    - An additional system-level mono SDK install is no longer needed to work around this Unity bug.
 - Tree.SetForward now returns boolean success value rather than logging error when passed unused action.
 - Full-library export now also available from the library settings in stead of menu-only access.
 - Even more UI polish: Better word-wrap, more contrasts for emphasis, instant flag hidden in unaffected scenarios and much more.
 - "Form new tree" nicely moves the new subtree up around the root socket rather than retaining the old position.
 - Default frame-rate of DebugUpdater now set to 20 fps rather than every frame. Gun safety and all that.
 - Massive codegen size save for larger libraries - from optimisation of tree-agent introspection codegen. Compile-time win.
 - More rigid parameter evaluation (remove needless occasional extra codegen).
 - Fixed copy and duplication procedures incorrectly not copying parameter values.
 - Force Unity to write serialised data before compiling.


2.1.1:
 - Fixed issue with tree paramterisation breaking debugger visualisation.


2.1:
 - Added autocomplete on action names, string parameters and component contexts.
 - Added mandatory actions (present in library regardless of use in trees).
 - Added partial library export and library merging / import-to-library.
 - Added Behave stripping - leave behind only a very lean Behave runtime, for redistribution or super slim deploy.
 - Added parameterised trees - get even more re-use out of your trees by overriding context and variables per reference.
 - Behavioural change: Tree.Reset will now delay resetting tree variables until after complete component reset.
 - Behavioural change: Tree.Tick will no longer automatically reset the tree upon completion. This plays very well with:
 - Added Tree.TickContinuously (int iterationCap = 1024) - ticks tree till completion or iteration cap is reached.
 - Added BehaveResult Tree.Result (bool value) utility function to side with Tree.Invert (BehaveResult value).
 - Added int Debugging.Local.ConnectionCount property - facilitating debug behaviour dependent on Behave debugger presence.
 - Moved default install path from Assets/Behave to Assets/Plugins/Behave.
    - WARNING: See Readme.txt upgrade guide.
 - Fixed decorator control node removal resulting in detached control connection.
 - Fixed decorator incorrectly not forwarding the instant status of its child node.
 - Fixed scenario where agent classes would get reflected for handlers even if blueprint derived.
 - Fixed unexpected corner cases of bad library configuration failing compiles (now causing warnings or simply being ignored).
 - Fixed Behave window breaking down when exiting play mode after having been active there.
 - Fixes to context getting incorrectly reset in some scenarios.
 - Fixed copy / paste functionality missing in some text fields.
 - Lots of UI polish and minor fixes.


2.0:
 - New editor.
    - Unified all controls into one window.
    - Completely customised look - compatible with both Unity light and dark skin.
    - Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
    - Remote debugging.
    - Tick and reset.
    - "Unplug" for debugger-only control.
    - Breakpoints.
    - Action overrides - override the return values of specified actions.
 - Decorator rewrite.
    - Deprecated old decorator.
       - Still compiles, but cannot be added.
    - Decorators are now control-type components.
       - No specific decorator handlers on agents.
       - Control is achieved via third connection socket.
    - Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
 	- No more collections - for nesting, use paths in tree names.
 	- New serialization format - see Readme.txt for upgrade instructions.
    - Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
	- Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
    - int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
    - enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
    - enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
    - int Tree.ActiveContext { get; }
 - Changed IAgent interface:
    - Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
    - Trees -> TreeType.
    - Actions -> ActionType.
    - Decorators -> DecoratorType.
    - Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
    - int TreeID (Tree) -> static TreeType Type (Tree)
    - bool IsAction (int) -> static bool IsAction (int)
    - bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
    - public void Reset[Name][Action/Decorator] (Tree sender);
    - public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
    - Component bar.
    - Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
    - When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
    - When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
    - Behaviour tree decorators.
    - Stand-alone edition of the Behave editor.
    - Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
    - Not able to delete collections from library.
    - Not able to delete trees from library.
    - Not able to rename collections from library.
    - Not able to rename trees from library.
    - Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

Trusted Gear

2015-02-26 00:00:00 +0100

Yay! GDC is next week! Will I see you there?

Ahem. Straying a bit from my usual theme here of writing about whatever little snippet or gadget I’ve come up with, for this post I will in stead share some detail on recent changes to my tool-chain of choice, which I’m quite happy about.

Every craftsman has his or her opinion on tooling, but just about everyone share the desire to tune their toolbox. Even if your opinion / taste / whatever does not align with mine, I hope that you find something useful in here.

If you really had your sights on getting some funky code snippet out of this post, here’s an unholy perl module for firing off native prompt dialogs on OS X and Windows:

Unholy perl

And with that out of the way, let’s get something else sorted: This post will likely come off as an ad for a bunch of different software. Other than mentioning it here, I do not intend to do anything about that.

Note that I primarily work on OS X and some of the tools mentioned in this post are only available on that platform. You might still find at least inspiration in those areas though – likely very nice Windows and Linux alternatives exist. I did not look.

However if you are not on OS X, but on a tight schedule, just skip all sections other than the “Typing” section (which is probably where you’ll find the best stuff anyway).

Tracking

Everyone has a system for remembering projects and TODOs. If you in stead keep it all in your head, I am glad that you’re not a very busy person – if you are busy, I would worry.

Over time I have tried many different systems for keeping track of it all – having had it as a focus of mine ever since severe physical stress symptoms reminded me that my methods were entirely inadequate.

One tool that I kept coming back to and which I have recently re-focused on is OmniFocus.

While OmniFocus is by no means perfect (I have my fair share of open suggestion posts with the developers), it does provide me with the best feature combination I have seen in this type of tool. Important to me are:

No restrictions or requirements on nesting/indentation depth of items.
- The system has the notion of “tasks” existing in “projects”, but aside from this I can use folder nesting of projects and nesting of tasks as much as I like – assigning whatever meaning I want to that.
Everything is synchronised painlessly between fully-featured clients on my laptop, my phone, and my tablet. And it remains accessible when offline.
Easy, fast, unintrusive task entry.
- The mobile clients have an always accessible “add to inbox” button and the OS X client a global task-entry shortcut.
- The shortcut fires up a little window over whatever you are currently working, allowing you to quickly type in what you need to remember to do, hitting enter when you’re done. Optionally you can add more task details before hitting enter and continuing with whatever you were doing.
  - This is absolutely perfect when you remember a TODO unrelated to your current task or someone comes by your desk with a request.
  - My shortcut for task entry is ctrl+alt+space. I do not recall if this is the default.
- The OS X client also comes with a “service” integration, allowing you to easily create new tasks from other applications – like one based on a file or a snippet of text or perhaps an email.
Optional additional classification and data collection.
- Putting tasks in projects is your absolutely minimum flow. Even that I suppose is optional, as you could simply put all your tasks in your inbox. On top of this, you can scale it as little or as much as makes sense for your particular case. I use everything from no additionals to everything – all dependent on the nature of the task.
  - Aside from putting tasks in optional projects in optional folders, each task can also have an associated context. Different tasks in the same project can have different contexts and contexts can have additional information associated with them – like a location.
  - Assigning a due date to a task will put it in your Forecast view – allowing you to easily view what needs to get done today. This view can also show a quick overview of todays calendar and you can get notifications as the due time of a task is reached.
  - Each task can have an associated attachment. Anything from a snippet of text to a file / an email / whatever.

I use OmniFocus for all project and task tracking. However I do not try to replace my calendar with it. Scheduled events still go in my calendar (I just use iCal) and I also use my calendar to keep track of what I do with my time when on a contract.

This allows me to easily summarize for client reports when needed and I have a little Automator workflow calculate the total number of hours spent contracting this week – allowing me to easily balance the hours.

Typing

Once I am done dreaming up ideas and tasks, like so many others, the majority of my time is spent as a typist – translating those tasks into computer-friendly gibberish of one kind or another. Most of the time I find myself typing C#.

For quite a while I would bounce around between different editors for this task.

VisualStudio with resharper for maximum efficiency – at the cost of either rebooting into Windows or running around in the strange parallel universe of virtualisation.
MonoDevelop for an approximation of the tools provided by VisualStudio, feeling not quite native anywhere, but very beta.
Sublime Text for beautiful, responsive, unintrusive text rendering, with a wonderland of user-configurable keyboard shortcuts and extensions. And absolutely nothing in terms of VS- and MD-like project-wide assistance.

Then a while ago I added a bookmark to the “check this out” pile, for a project called OmniSharp. The promise was simple:

Get full Intellisense-like completion and resharper-like code analysis.
Use it in your text editor of choice.

Ha! Madness.

That was probably at least a half year ago – until I finally found some time to put aside my scepticism for a bit and try to set it up with Sublime.

You know what? It works!

This is what I currently use of the OmniSharp + Sublime Text feature set:

Compile check on save – with errors, warnings, and resharper-like code suggestions.
- Some suggestions I do not agree with and luckily, as with resharper, configuration lets you easily filter those out. Unity also suppresses some warnings when compiling, so I elected to filter those out as well.
File auto-format when triggered by shortcut.
Intellisense-like auto-complete – file, project and library-wide.
Jump to definition / list reference points.
Rename.

I am probably forgetting something, but suffice to say, I no longer feel the need to switch away from Sublime Text to boost efficiency on an unfamiliar codebase.

With regards to shortcuts and configuration, there are a bunch of little tweaks you can set up for Sublime, so of-course I have done exactly that. The good part is that Sublime preferences are all JSON formatted text files, so they are easily shared in a gist:

Preferences in a gist

For text editing, that produces a lovely fullscreen view like the one on the right (click for full size). Tasty, right?

Searching

After lolcat searches and menacingly typing at people who are wrong, I probably spend the majority of my browser time doing reference manual lookups. Extensions like Safari Keyword Search in combination with embedded search engines or Google site search have somewhat streamlined this task, but it never really worked solidly and of-course required that I be online while working.

Enter Dash. I can’t remember who brought it up on twitter, but that’s where I came across it and bookmarked it for later study. The idea is quite simple: It provides an offline search engine for docsets of your choosing – much like man pages.

You get to specify which docsets to download, associate a search key with each docset (IE “cpp:” and “.net:”), and specify a global shortcut for launching the search window – as you would Spotlight on OS X. But wait: There’s more!

Downloadable docsets include topic-specific downloads of wiki-fied Stackoverflow questions and answers. And since you can associate multiple docsets with the same search key, these are easily accessed when you search.

On top of all of this, Dash also comes with an iPad and iPhone client and integration for a bunch of different editors, environments and other tools – including Sublime Text.

You can find my Dash integration settings in the Sublime settings linked above. For global launch shortcut I chose ctrl+shift+space – I do not recall if this is the default.

Navigation

If you, like me, grow a tad too accustomed to the default Sublime Text shortcut of alt+cmd+left/right for tab switching, I would recommend giving it a go as a global shortcut across applications. Configuring System Preferences – Keyboard as shown below did the trick for me. I primarily use it in Terminal and Safari.

And that is about all I have for now. I hope that this is useful to you and do let me know if something in here is off or if you’re more curious about something. If you are at GDC in San Francisco next week, you could even do it in person.

Mad Mash Versioning

2015-01-02 00:00:00 +0100

Through 2014, I had every once in a while heard people casually mention that they were versioning their projects in a combination of git and SVN. I didn’t really take the time to ask for details on it, but it was one of those things, stuck in the back of my mind.

Filed under “delightfully mad hacks”, I finally found some time to look into it over Christmas – as I was dodging various boring tasks in finalising Behave 2.5.

The Excuse

Git is lovely for its decentralisation, easy branching and a bunch of other stuff. However where it is not so delightful is in its handling of binary files.

One alternative VCS which is pretty good at handling binary files is SVN. So by putting binary project files in SVN and text files in git, you should be able to get the best of both worlds, right?

That is the idea anyway.

The Hack

Regardless of whether it is a good idea or not, it is an interesting hack. Immediately, it seems like a terrible idea with way too high a potential of user error from its silly workflow overhead. So that is where we’ll attack.

The goal is then to have the user place binary files in one folder and text files in other folders – all under the same core project folder. And then simply commit, update and branch as normally, in the knowledge that everyones local drives will not explode with tons of versioned binary data.

Our primary concern is keeping SVN and git in sync – with the proper commits connected. No-one likes SVN, so we’ll hide that away and put git in the driver seat.

Luckily, git operations are also fairly easily customised on a per-repository basis, which is perfect for this case.

The idea will then be to have git operations keep track of the SVN working copy, making sure that everything there is committed before a dependent git revision is committed, at which point a versioned text file with the corresponding SVN version number, should be added to the commit.

This way, SVN becomes a dictionary of collected binary files, into which git adds new versions when committing and fetches copies when updating – using SVN version numbers as key.

Git Hooks

Our entry point in automating this stuff with git is in the so called “git hook”. These are scripts located at “.git/hooks/” for any git repository. Per default, this folder is populated with a few demo scripts, each containing an example of what to do in response to that particular git event.

For this hack, the two points of interest are:

The commit process – cancelling the commit if the SVN working copy is not clean, otherwise getting its current version and adding it to a text file in that same commit.
The checkout process – updating the SVN working copy to the version specified in the text file, every time a git checkout has completed.

This means that the files we are interested in are:

(Git clone path)/.git/hooks/pre-commit
(Git clone path)/.git/hooks/post-checkout

Note that these files are not by default versioned with the rest of your git repository, though I do recommend doing so anyway. For this hack, I chose to address this via a setup script which needs to be run once after first cloning the repository – as well as after performing any updates to the versioned hook scripts (which I’d estimate happening just about never).

Solution

My weapon of choice for this sort of hackery is Perl. If you would rather use something else, that is fine too – as long as your shell can run it, you should be fine.

Since we’re in glorious hack land, I chose to take it further over the top by expanding the text file with the SVN version to be a full JSON-formatted configuration file, with the option of overriding parts with per-user local configuration.

The project structure is as follows:

.gitignore – containing ignores for the local user config as well as the SVN folder.
VCS/ – this is where the core perl scripts are kept, as well as configuration.
Setup.pl – the run-once script for copying the hooks in etc.

In the linked Git repository, the example configuration has also been set up for a Unity project – with the SVN working copy placed in Assets/SVN. Though aside from this, nothing here is specific to any technology aside from Git and SVN.

Additional over-the-top-ness:

Place a JSON formatted file at VCS/LocalUserConfiguration.txt to override select values from what is set in the versioned configuration file.
Setup.pl will check for a working copy at the specified SVN path and run a checkout from the specified repository if none is found. So this is really a one-stop-shop kinda thing.
“autoCommit” and “autoAdd” options for mad driver-less running.
- “autoCommit” will, if enabled, see the commit script run SVN commit to push any local SVN changes as part of the git commit process.
- “autoAdd” is for off-your-rocker “Look, ma! No hands!” setups, where any unversioned files found in the SVN folder are automatically added to SVN as part of the git commit process.

Why no “ignore unversioned” flag? In the example configuration, the SVN folder is put inside a Unity Assets folder. This means that contained files are imported as part of the project and project files outside of SVN can depend on them.

If you have no problem risking gun-to-foot related injuries with commits missing dependencies, that’s just fine. However I will not assist you in the loading of said gun.

I hope that you find this stuff interesting as well – if not useful. You can find everything at the other end of the below github link and I would be very interested in any feedback and discussion (preferably over twitter).

Are you employing a similar combined VCS setup? Are you in fact one of those who mentioned using the git+SVN combination in particular? Do you have a suggested alternative to this madness?

The below github link

Behave 2.5

2015-01-01 00:00:00 +0100

Welcome to 2015!

I hope that you have had a great new years eve and will have a productive year. To assist with that, I would like to present you with version 2.5 of Behave.

Aside from lots of editor polish, particularly around the remote debugger, this version brings interesting compiler optimisations and optional text serialisation of Behave libraries.

Do note that this upgrades the serialisation version of any Behave libraries touched by 2.5. As with any software upgrade, I advise you to keep a backup or earlier revision of your libraries available before upgrading to 2.5.

Interestingly, the optimisation work on the compiler also brought with it some internal restructuring. This new structure facilitates even further optimisation work down the road.

Given the existing zero-allocation, low CPU, low memory footprint nature of the Behave runtime, it is likely that these optimisations will mean little to a lot of users. Should you, however, be running massive amounts of autonomous agents with Behave, you will likely get some actual bang for the buck here.

Also in this release are several changes and additions to the runtime, the details of which you will find in the full changelist below.

Onwards

Lots of interesting stuff in the pipeline, with the ground work for much of it already in place. Stay tuned.

Changelist:


2.5:
 - Optional text serialisation.
     - Switch between text and binary serialisation in library settings.
     - Full and partial exports to text or binary file.
     - NOTE: Libraries opened in this version of Behave will be upgraded and are afterwards not backwards compatible.
 - Compiler upgrade.
     - Added lots of little CPU and memory optimisations.
     - Added tree analysis leading to larger memory saves on references when possible.
     - Improved handling of circular references.
     - Improved error reporting.
     - Changed name validation.
         - Underscores are no longer allowed in names - in order to avoid name clashes with pathed assets.
         - Fixed previously allowing leading numbers in names.
 - Runtime API.
     - Added library.ReflectForwards (ICollection, object).
     - Added library.SupportedRecords (ICollection).
     - Added blueprint.SupportedTrees.
     - Added Library.DidInstantiate (ICollection / Tree).
     - Changed generated enums to be valued continuously.
     - Changed get calls for unhandled records to now return -1.
 - Editor polish.
     - Improved debugger view.
         - Improved control bar layout.
         - Improved rendering of active referenced trees.
         - Fixes to follow-focus.
         - Debug view no longer re-crops to current visible tree area, preventing the previous behaviour of the view jumping around even without follow-focus enabled.
         - Improved sidebar listing of available- and connected runtimes.
         - Improved handling of disconnecting runtimes.
         - Improved tracking of available runtimes. No more need for refreshing.
         - Improved UI for adding debugger overrides.
         - Added "Add overrides enabled" setting (on by default).
     - Library vertical scrollbar replaced by standalone scroll buttons top / bottom when relevant - reducing visual noise.
     - Smaller tweaks and fixes.
 - Improved internal test coverage.


2.4.2:
 - Fixed some issues related to handling priority selectors in the recently update debugger.


2.4.1:
 - Fix corner case when restructuring library assets.


2.4:
 - Introducing “records”.
     - Float fields stored in “collections” - essentially ‘smart tables’.
     - Blackboard fields.
     - Utility curves.
     - Utility graphs.
     - Behaviour Tree integration.
          - “Tester” component.
          - “Writer” component.
          - Record mode for Priority Selector component.
 - Editor behavioural change: Deleting a tree no longer deletes reference nodes targeting that tree from other trees. Their target is merely cleared.
 - Editor behavioural change: The Reference node is only available in the component bar if the library contains more than one tree. Same behaviour for Tester and Writer with records.
 - Behavioural change: Invert flag is now properly applied by the Priority Selector.
 - Debugger connection stability improvement.
 - Connection disabling has been removed. This confusing feature caused more harm than good.
 - Video player now displays video title and description.


2.3.5:
 - Fix home screen video player.


2.3.4:
 - Better error messages in case of insufficient file access privileges (OHAI Perforce).
 - Added simple version check to the home screen.
 - New icons for Priority Selector and "form new tree".
 - Smaller, embedded, JSON library.
 - Fix annoying behaviour with tree renaming where text fields would keep last entry.
 - Fix similar behaviour with component text fields on tree selection change.
 - Unity 5 compatibility fixes (tested on beta 2).


2.3.3:
 - Fix focus handling issue with auto-complete.
 - Parametrisation is now correctly applied for reset handler calls.


2.3.2:
 - Fix sidebar item duplication and deletion only functional during rename.


2.3.1:
 - Fix GUI error being logged on tree selection.
 - Proper handling of currently edited library asset being deleted.


2.3:
 - Added support for instant repeaters.
 - Added support for mandatory contexts.
 - Added optional target parameter to Tree.ResetForwards.
 - Added Tree.TickWrapping method.
 - Added debugger auto-launch settings to library build options.
 - Added home screen - shown on launch or via the Help menu, full of resources.
 - Behavioural change: Decorators no longer forward the instant flag of their child node.
 - Behaviour of decorators receiving a Running signal from their control connection is now defined.
 - Dependencies now shipped as separate (replaceable) files for minimal project impact.
 - Editor polish.
     - Added support for running multiple editor debugging instances on one machine.
     - Added focus-follow for debugger and canvas.
     - Added both scrollwheel/pad and drag-to-scroll support to all canvas views.
     - Drag connection to occupied input slot to replace.
     - Directly drag-drop trees from the sidebar onto the canvas as reference nodes.
     - Instant flag doesn't show on nodes connected to parents ignoring the flag.
     - "Last edited library" now tracked per project.
     - Last selected tree is now also restored between sessions and playmode transitions.
     - A bunch of minor adjustments and improvements.
     - Performance + memory + disk space optimisations.
     - Minor bugfixes.
 - New documentation layout and enhancements (already released as available).
 - Reshuffling of code to make way for exciting new things down the road.


2.2.2:
 - Addressed protobuf issue causing Parallel component completion setting to not get stored correctly.


2.2.1:
 - Fixed issue causing parallel components to fail compilation.


2.2:
 - Behavioural change: Support for multiple different action handler signatures is discontinued effective immediately.
    - Generated agent blueprint as well as accepted reflected signatures are now only:
        - public BehaveResult [Tick/Init][Name]Action (Tree sender);
        - public void Reset[Name]Action (Tree sender);
 - Added Tree class accessors - all valid only during an active init/tick/reset handler call:
    - string ActiveStringParameter
    - float ActiveFloatParameter
    - IAgent ActiveAgent
    - object ActiveData
 - Rather than waiting for the Unity bugfix, the built-in compiler API is now bypassed in favour of direct compiler binary execution.
    - An additional system-level mono SDK install is no longer needed to work around this Unity bug.
 - Tree.SetForward now returns boolean success value rather than logging error when passed unused action.
 - Full-library export now also available from the library settings in stead of menu-only access.
 - Even more UI polish: Better word-wrap, more contrasts for emphasis, instant flag hidden in unaffected scenarios and much more.
 - "Form new tree" nicely moves the new subtree up around the root socket rather than retaining the old position.
 - Default frame-rate of DebugUpdater now set to 20 fps rather than every frame. Gun safety and all that.
 - Massive codegen size save for larger libraries - from optimisation of tree-agent introspection codegen. Compile-time win.
 - More rigid parameter evaluation (remove needless occasional extra codegen).
 - Fixed copy and duplication procedures incorrectly not copying parameter values.
 - Force Unity to write serialised data before compiling.


2.1.1:
 - Fixed issue with tree paramterisation breaking debugger visualisation.


2.1:
 - Added autocomplete on action names, string parameters and component contexts.
 - Added mandatory actions (present in library regardless of use in trees).
 - Added partial library export and library merging / import-to-library.
 - Added Behave stripping - leave behind only a very lean Behave runtime, for redistribution or super slim deploy.
 - Added parameterised trees - get even more re-use out of your trees by overriding context and variables per reference.
 - Behavioural change: Tree.Reset will now delay resetting tree variables until after complete component reset.
 - Behavioural change: Tree.Tick will no longer automatically reset the tree upon completion. This plays very well with:
 - Added Tree.TickContinuously (int iterationCap = 1024) - ticks tree till completion or iteration cap is reached.
 - Added BehaveResult Tree.Result (bool value) utility function to side with Tree.Invert (BehaveResult value).
 - Added int Debugging.Local.ConnectionCount property - facilitating debug behaviour dependent on Behave debugger presence.
 - Moved default install path from Assets/Behave to Assets/Plugins/Behave.
    - WARNING: See Readme.txt upgrade guide.
 - Fixed decorator control node removal resulting in detached control connection.
 - Fixed decorator incorrectly not forwarding the instant status of its child node.
 - Fixed scenario where agent classes would get reflected for handlers even if blueprint derived.
 - Fixed unexpected corner cases of bad library configuration failing compiles (now causing warnings or simply being ignored).
 - Fixed Behave window breaking down when exiting play mode after having been active there.
 - Fixes to context getting incorrectly reset in some scenarios.
 - Fixed copy / paste functionality missing in some text fields.
 - Lots of UI polish and minor fixes.


2.0:
 - New editor.
    - Unified all controls into one window.
    - Completely customised look - compatible with both Unity light and dark skin.
    - Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
    - Remote debugging.
    - Tick and reset.
    - "Unplug" for debugger-only control.
    - Breakpoints.
    - Action overrides - override the return values of specified actions.
 - Decorator rewrite.
    - Deprecated old decorator.
       - Still compiles, but cannot be added.
    - Decorators are now control-type components.
       - No specific decorator handlers on agents.
       - Control is achieved via third connection socket.
    - Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
 	- No more collections - for nesting, use paths in tree names.
 	- New serialization format - see Readme.txt for upgrade instructions.
    - Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
	- Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
    - int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
    - enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
    - enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
    - int Tree.ActiveContext { get; }
 - Changed IAgent interface:
    - Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
    - Trees -> TreeType.
    - Actions -> ActionType.
    - Decorators -> DecoratorType.
    - Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
    - int TreeID (Tree) -> static TreeType Type (Tree)
    - bool IsAction (int) -> static bool IsAction (int)
    - bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
    - public void Reset[Name][Action/Decorator] (Tree sender);
    - public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
    - Component bar.
    - Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
    - When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
    - When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
    - Behaviour tree decorators.
    - Stand-alone edition of the Behave editor.
    - Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
    - Not able to delete collections from library.
    - Not able to delete trees from library.
    - Not able to rename collections from library.
    - Not able to rename trees from library.
    - Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

Behave 2.4

2014-11-28 00:00:00 +0100

It is finally time for a more substantial update for Behave. With version 2.4, Behave ventures out of its former behaviour tree comfort zone and adds built-in support for utility and blackboard constructs.

Records

Combined under the label “Records”, this expansion adds three primary new library objects:

Fields
Curves
Graphs

Similarly to how behaviour trees can be connected to agent blueprints, records are tied to so called “collections”. These are effectively “smart tables”, which can be queried (by name) for the value of a specific record – as well as be asked to set the current value of a record.

You can either choose to use these collections on their own or directly integrate them with your behaviour trees.

For more information, see the behave documentation as well as the new Records video.

Onwards

So as you might have guessed, the internal refactoring work mentioned in earlier releases, paved the way for this expansion. However, as per usual, the implementation is somewhat restrained. Any feedback and requests would be most welcome.

That is not to say that the expansion plans end here, but more on that later.

Changelist:


2.4:
 - Introducing “records”.
     - Float fields stored in “collections” - essentially ‘smart tables’.
     - Blackboard fields.
     - Utility curves.
     - Utility graphs.
     - Behaviour Tree integration.
          - “Tester” component.
          - “Writer” component.
          - Record mode for Priority Selector component.
 - Editor behavioural change: Deleting a tree no longer deletes reference nodes targeting that tree from other trees. Their target is merely cleared.
 - Editor behavioural change: The Reference node is only available in the component bar if the library contains more than one tree. Same behaviour for Tester and Writer with records.
 - Behavioural change: Invert flag is now properly applied by the Priority Selector.
 - Debugger connection stability improvement.
 - Connection disabling has been removed. This confusing feature caused more harm than good.
 - Video player now displays video title and description.


2.3.5:
 - Fix home screen video player.


2.3.4:
 - Better error messages in case of insufficient file access privileges (OHAI Perforce).
 - Added simple version check to the home screen.
 - New icons for Priority Selector and "form new tree".
 - Smaller, embedded, JSON library.
 - Fix annoying behaviour with tree renaming where text fields would keep last entry.
 - Fix similar behaviour with component text fields on tree selection change.
 - Unity 5 compatibility fixes (tested on beta 2).


2.3.3:
 - Fix focus handling issue with auto-complete.
 - Parametrisation is now correctly applied for reset handler calls.


2.3.2:
 - Fix sidebar item duplication and deletion only functional during rename.


2.3.1:
 - Fix GUI error being logged on tree selection.
 - Proper handling of currently edited library asset being deleted.


2.3:
 - Added support for instant repeaters.
 - Added support for mandatory contexts.
 - Added optional target parameter to Tree.ResetForwards.
 - Added Tree.TickWrapping method.
 - Added debugger auto-launch settings to library build options.
 - Added home screen - shown on launch or via the Help menu, full of resources.
 - Behavioural change: Decorators no longer forward the instant flag of their child node.
 - Behaviour of decorators receiving a Running signal from their control connection is now defined.
 - Dependencies now shipped as separate (replaceable) files for minimal project impact.
 - Editor polish.
     - Added support for running multiple editor debugging instances on one machine.
     - Added focus-follow for debugger and canvas.
     - Added both scrollwheel/pad and drag-to-scroll support to all canvas views.
     - Drag connection to occupied input slot to replace.
     - Directly drag-drop trees from the sidebar onto the canvas as reference nodes.
     - Instant flag doesn't show on nodes connected to parents ignoring the flag.
     - "Last edited library" now tracked per project.
     - Last selected tree is now also restored between sessions and playmode transitions.
     - A bunch of minor adjustments and improvements.
     - Performance + memory + disk space optimisations.
     - Minor bugfixes.
 - New documentation layout and enhancements (already released as available).
 - Reshuffling of code to make way for exciting new things down the road.


2.2.2:
 - Addressed protobuf issue causing Parallel component completion setting to not get stored correctly.


2.2.1:
 - Fixed issue causing parallel components to fail compilation.


2.2:
 - Behavioural change: Support for multiple different action handler signatures is discontinued effective immediately.
    - Generated agent blueprint as well as accepted reflected signatures are now only:
        - public BehaveResult [Tick/Init][Name]Action (Tree sender);
        - public void Reset[Name]Action (Tree sender);
 - Added Tree class accessors - all valid only during an active init/tick/reset handler call:
    - string ActiveStringParameter
    - float ActiveFloatParameter
    - IAgent ActiveAgent
    - object ActiveData
 - Rather than waiting for the Unity bugfix, the built-in compiler API is now bypassed in favour of direct compiler binary execution.
    - An additional system-level mono SDK install is no longer needed to work around this Unity bug.
 - Tree.SetForward now returns boolean success value rather than logging error when passed unused action.
 - Full-library export now also available from the library settings in stead of menu-only access.
 - Even more UI polish: Better word-wrap, more contrasts for emphasis, instant flag hidden in unaffected scenarios and much more.
 - "Form new tree" nicely moves the new subtree up around the root socket rather than retaining the old position.
 - Default frame-rate of DebugUpdater now set to 20 fps rather than every frame. Gun safety and all that.
 - Massive codegen size save for larger libraries - from optimisation of tree-agent introspection codegen. Compile-time win.
 - More rigid parameter evaluation (remove needless occasional extra codegen).
 - Fixed copy and duplication procedures incorrectly not copying parameter values.
 - Force Unity to write serialised data before compiling.


2.1.1:
 - Fixed issue with tree paramterisation breaking debugger visualisation.


2.1:
 - Added autocomplete on action names, string parameters and component contexts.
 - Added mandatory actions (present in library regardless of use in trees).
 - Added partial library export and library merging / import-to-library.
 - Added Behave stripping - leave behind only a very lean Behave runtime, for redistribution or super slim deploy.
 - Added parameterised trees - get even more re-use out of your trees by overriding context and variables per reference.
 - Behavioural change: Tree.Reset will now delay resetting tree variables until after complete component reset.
 - Behavioural change: Tree.Tick will no longer automatically reset the tree upon completion. This plays very well with:
 - Added Tree.TickContinuously (int iterationCap = 1024) - ticks tree till completion or iteration cap is reached.
 - Added BehaveResult Tree.Result (bool value) utility function to side with Tree.Invert (BehaveResult value).
 - Added int Debugging.Local.ConnectionCount property - facilitating debug behaviour dependent on Behave debugger presence.
 - Moved default install path from Assets/Behave to Assets/Plugins/Behave.
    - WARNING: See Readme.txt upgrade guide.
 - Fixed decorator control node removal resulting in detached control connection.
 - Fixed decorator incorrectly not forwarding the instant status of its child node.
 - Fixed scenario where agent classes would get reflected for handlers even if blueprint derived.
 - Fixed unexpected corner cases of bad library configuration failing compiles (now causing warnings or simply being ignored).
 - Fixed Behave window breaking down when exiting play mode after having been active there.
 - Fixes to context getting incorrectly reset in some scenarios.
 - Fixed copy / paste functionality missing in some text fields.
 - Lots of UI polish and minor fixes.


2.0:
 - New editor.
    - Unified all controls into one window.
    - Completely customised look - compatible with both Unity light and dark skin.
    - Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
    - Remote debugging.
    - Tick and reset.
    - "Unplug" for debugger-only control.
    - Breakpoints.
    - Action overrides - override the return values of specified actions.
 - Decorator rewrite.
    - Deprecated old decorator.
       - Still compiles, but cannot be added.
    - Decorators are now control-type components.
       - No specific decorator handlers on agents.
       - Control is achieved via third connection socket.
    - Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
 	- No more collections - for nesting, use paths in tree names.
 	- New serialization format - see Readme.txt for upgrade instructions.
    - Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
	- Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
    - int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
    - enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
    - enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
    - int Tree.ActiveContext { get; }
 - Changed IAgent interface:
    - Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
    - Trees -> TreeType.
    - Actions -> ActionType.
    - Decorators -> DecoratorType.
    - Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
    - int TreeID (Tree) -> static TreeType Type (Tree)
    - bool IsAction (int) -> static bool IsAction (int)
    - bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
    - public void Reset[Name][Action/Decorator] (Tree sender);
    - public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
    - Component bar.
    - Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
    - When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
    - When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
    - Behaviour tree decorators.
    - Stand-alone edition of the Behave editor.
    - Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
    - Not able to delete collections from library.
    - Not able to delete trees from library.
    - Not able to rename collections from library.
    - Not able to rename trees from library.
    - Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

Co-very-routine

2014-06-20 00:00:00 +0200

I really like coroutines. Like with most things, they should be applied in well-considered quantities, but when applied they can really expand what you can achieve in just a few lines of code. Particularly in our frame-bound world.

However there has always been this little subset of extra things, which I would have liked to have seen supported by Unity coroutines out of the box.

“Hang on, weren’t you just there?”

Yep. I was and terrible as the excuse might be, there was always something that seemed shinier or more on fire.

Then at Unite 13, Devin and Matthew of Twisted Oak Studios did an excellent talk about extending coroutines by using extension methods to insert a proxy layer between coroutines and the Unity coroutine-system. Unfortunately I didn’t catch the talk live (I don’t see many talks at conferences), but shortly after I could catch it on YouTube. Technology, yay!

In any case that really ended my supply of excuses, other than work.

Devin and Matthew had specifically implemented the setup to allow coroutines to provide a return value, provide a nicer stopping mechanism, as well as provide a useful way of handling exceptions thrown during the execution of coroutines. This provided an excellent platform to work off and did tick three items off my wishlist, but didn’t quite deliver the whole package.

It is an interesting talk and if you have the time, you should give it a look.

The Whole Package

So I slacked off doing work for a bit and somewhere in Q2 2014 got started writing my own implementation of extended coroutines, with the extra bits and bops on my list.

This here is the list:

Coroutines providing return values (yay! free!)
Handle exceptions thrown during coroutine execution (yay! free!)
Useful stopping behaviour (yay! free!)
Built-in soft stop.
Better built-in communication between caller and coroutine.
Easier way of intermixing threading and coroutines.
Built-in simple load balancing.

Soft Stop

Straight up stopping a coroutine is fine, but dependent on what it was doing while being stopped, it might leave a mess behind. The idea with a soft stop mechanism is that in stead of directly stopping the coroutine, the external controller in stead requests that the coroutine stops.

This allows the coroutine to monitor the state of the requested stop flag at appropriate points in its execution and terminate with the necessary cleanup in response.

Caller – Coroutine Communications

But why stop the communications at just requesting a nice stop? What if the work produced by the coroutine could have relevance throughout its execution?

By making the result of the coroutine accessible before the completion of the coroutine, we gain the capability of not just reading it early on, but also contributing to its building from outside of the coroutine.

Threading

Sufficiently intense tasks, working on data types not tied to the UnityEngine, API can benefit from threading. Unfortunately, most of the time things aren’t that cleanly cut out, and only part of the task is suitable for threading.

At that point the alternatives are to either forget about partially threading the task or to bridge the two types of concurrency system. Since the latter rarely turns out very pretty, the former is often chosen.

Building threading right into the coroutine system makes the choice easy.

Simple Load Balancing

Finally, heavy tasks which for one reason or another cannot be threaded (perhaps the very nature of the task requires dealing with the UnityEngine API), can in stead be frame sliced inside a coroutine.

However the logic for doing so can be more or less pretty and writing boilerplate is boring. Clearly this would be great to also have built into the base coroutine system.

Usage

So that is the full wish list implemented. Now let’s take a look at some quick example snippets.

Result

The base interface for using the extended coroutines is to start them via the new generic version of MonoBehaviour.StartCoroutine.

For running regular coroutines, the only other difference is that in stead of yielding directly to the return value of StartCoroutine<T>, you yield to the .Coroutine member of its CoroutineData<T> return value.

This is also the reference which gives you access to the result of the coroutine execution.

Example

Exception

Since the coroutine calls are executed by the coroutine system and not the callee, normally exceptions just get swallowed up by the coroutine system and logged out.

The approach of Devin and Matthew, as implemented here, is to swallow the exception, break coroutine execution and then re-throw the same exception when next the coroutine comes into contact with the caller – namely when its result is accessed.

Example

Stop

In stead of relying on the strange, existing methods of stopping coroutines and the limitations they come with (such as only stopping a coroutine initially started by string parameter or stopping all coroutines on a behaviour), the CoroutineData<T> reference yields another possibility.

Since it effectively represents an instance of an executing coroutine, adding a Stop method to it becomes much more intuitive.

Example

Soft Stop

Requesting that a coroutine stops, requires a line of communication between the caller and coroutine. This is provided in the form of the instance of CoroutineData<T>.

However in order to effectively pass this, the calling convention on the coroutine is slightly different. Rather than passing the return value of the coroutine to StartCoroutine<T>, the coroutine is passed as a delegate, taking CoroutineData<T> as its only parameter.

The rest of the flow is exactly as with Stop, except RequestStop is used by the caller and the coroutine periodically checks CoroutineData<T>.ShouldStop.

Example

Threading

The interface for threading is really very simple. Two new yield classes have been added WaitForWorkerThread and WaitForMainThread. Yielding to an instance of either will do exactly as advertised. Yielding break or the result or throwing an exception will terminate the thread and the coroutine.

When yielding WaitForSeconds on the worker thread, the thread will sleep for the specified amount of seconds. And finally the CoroutineData<T> holds a flag accessor to determine the thread state of the coroutine.

Example

Load Balancing

Load balancing could be done in a bunch of different ways and I would encourage you to add your own (I would love to see your ideas as well). So I decided to just do the simplest I could think of.

WaitIfFrameTime will yield until the next frame if the current frame has taken longer than the specified amount of time. This way it effectively sets down a max frame time while utilising all the time leading up to that cap.

Example

Fin

And that is it! I hope you find some use of these extensions to the extensions and do let me know if you come up with some cool further extensions.

Source and examples

Construct

2014-04-25 00:00:00 +0200

Updated April 28th: Added illustrations.

A while ago I published a post referencing Hollywoods take on programming anno 2001. It covered how to load additional code into a Unity build at runtime, which can be quite useful for patching, modding and similar post-publishing changes to your build, involving logic changes.

The post was pretty brief, just covering the raw basics of the technique and not dealing with any of the challenges in integrating it with a more complete patching solution.

Luckily I have recently had a chance to return to working with it and implementing it fully on a project. This post will cover the challenges met and my solutions to them.

Unlike the original post, this one is not exactly brief, so, uh, hang on to something?

Overview

The basic method of integrating new code in an existing Unity runtime is as follows:

Build the patch code to a .net assembly.
Load the byte stream of that assembly to an array at runtime.
Create a System.Reflection.Assembly instance from the bytes.
Instantiate classes, attach components and call methods via reflection.

This works really well for simple logic expansions. However if you want to couple the logic update with content such as prefabs and scenes using new components defined in this new assembly, you are out of luck.

New content can be loaded into Unity runtimes via asset bundles (these require Unity pro at time of writing). However in order to build these asset bundles as well as loading them afterwards, Unity needs to know all the components used in the contained scenes and prefabs.

Unfortunately this is not possible as that would require the presence of our new MonoBehaviours in the shipped build, which we are obviously not very interested in, given that we are working on a post-shipping patch.

The challenge is therefore to somehow construct asset bundles which can be built and loaded without the Unity editor or runtime knowing about all the MonoBehaviours used in the bundles.

Fun, right?

Approach

Right, getting this one sorted will take a few lines to explain, but let’s just jump straight into it. The solution I went with goes a little something like this:

Compile bundle scripts to an assembly, from which components are attached in bundle scenes and on bundle prefabs.
Before bundle build, pack each of these components into a container component, holding the data and type of the original, replacing it as attached on the same Game Object.
When loading the bundle, load the new assembly and then run an unpack step for each container component on each prefab, restoring the original data and references to a newly instantiated component of the correct type, on the same GameObject.
When scenes from the bundle are loaded, the same unpacking process runs for each container component in there.

While this does sound very straight forward, there are of-course a few gotchas in there. So let us jump in a bit deeper.

Workflow

The goal here is to make sure that the programmers, level designers and artists working on new bundles get to maintain as much of their familiar Unity workflow as possible.

So whatever building and packing solution we set up, the following must still be supported at the very least:

Assets are imported and used in prefabs and scenes as per usual.
Scripts are auto-compiled when saved and can be drag-dropped onto Game Objects.
Variables and references can easily be tweaked on new bundle components via the inspector.

At first, these workflow requirements do seem to conflict with our technical requirements, given that all code unique to the bundle must be built into a separate assembly loaded at runtime, rather than be part of the main script compile.

However where there’s a will there’s a way and a tall piles of hacks make for interesting realities.

In the Unity Hacks talk I demonstrate how to use an asset post processor to compile java files into a jar plugin automatically. The first step to keeping our workflow without breaking the technical requirements is to copy this, but for C# (and/or JS) files compiled into a .net assembly.

Rather than spending time going into detail on how you would do that, I point you to the beforementioned talk (and its available example code) as well as the gmcs compiler shipped with the Unity editor. You should be able to construct the flow just fine from that.

One important note is that the folder from which your asset post processor picks up your scripts should be somewhere in Assets/WebplayerTemplates, as Unity by default will not compile scripts located there into the main project assembly (this is set up to avoid website js getting mixed up for templates).

I chose a location looking something like this: Assets/WebplayerTemplates/Bundles/MyFirstBundle.

The asset post processor building the assembly should then drop it in a folder like Assets/Bundles/MyFirstBundle and make a duplicate of it, with the .txt extension.

The original will be from where you can drag components and the copy will be the one built into the bundle, since it is now imported as a TextAsset and can therefore be included, unlike the original assembly.

At this point you can start work on the contents of the bundle, saving scenes, prefabs and other assets unique to the bundle into the same folder as the assembly and text file – subfolders under that would work fine as well.

It is important to note that attaching behaviours from the assembly, as well as behaviours defined in the core project to scene objects and prefabs in the bundle is just fine. However prefabs, scenes and scripts outside of the bundle should never reference behaviours or assets from the bundle directly.

Building

Core

It is worth spending a little bit of time writing an automated build step of the core project, which deletes all the bundle folders before running the actual build. That way you can, after testing, be pretty sure that nothing in the core project inadvertently referenced the contents of a bundle directly.

Should you feel like wanting a bit earlier warning on something like that, I would recommend spending a bit of time writing an extension checking for such references as scenes are saved and prefabs imported.

Bundle

The folder created earlier in under Assets/WebPlayerTemplates is only used for storing scripts and building them into assemblies. So at the point of building the assembly, all that matters is the contents of the folder with the resulting assembly, its .txt duplicate and any other assets placed in there.

Before running the actual bundle build process, we first (as outlined in the Approach) need to pack and remove all instances of MonoBehaviours defined in the bundle assembly.

First, run through each prefab and scene in the bundle folder and consider each instance of these behaviours.

For each, attach to the same Game Object an instance of your container component type, defined in the core project – I am calling it BundledBehaviour in this post.

Packing

Store the full type name of the original in the BundledBehavior (we will need it to re-instantiate the original when unpacking) and add the two as a pair to a list.

Next, all serialised fields on the original must be stored in the BundledBehaviour. Iterating over that is a breeze with the SerialisedObject API.

Value types can just be straight up serialised to a byte array and chucked onto the BundledBehaviour. For my implementation I chose to use protobuf-net for that, but you can really use whatever meets your fancy.

Once the value types are dealt with, we should move on to the next behaviour in the list, before handling reference types in a second pass. The reason for this will become apparent when we start dealing with inter-component referencing.

References

Bam. Done. Wasn’t that quick? On to the second pass…

Reference types get a bit trickier than value types. For each serialised reference, we need to add to a list on the BundledBehaviour an instance of a class pairing the field name and the reference. In the context of this post I will refer to that container class as ReferenceField.

At this point we unfortunately need to start distinguishing between asset type references, like textures and audio clips, and component type references. Where storing component references in a field of type Component works just fine, unfortunately asset references need to be stored on a field of their exact type.

I forget the exact reason for the Unity serialisation system working like this, but for the purpose of this post, how about we just file that under “the law of the land” and move on?

The result is that the ReferenceField type will need to have a “field name” string field, a “component reference” Component field and then an “X reference” X field for each asset type X.

Annoying to deal with, but remember that these are just references, so after having written that list once, the slight overhead and dealing with it in general – through that wonderful interface you decided to put on it, will carry a minimum of pain.

When storing component references, do remember to first check if the reference is contained in that list of MonoBehaviour → BundledBehaviour pairs built earlier. If so, store the a reference to the BundledBehaviour in stead.

Finalise

Now that all components instances from the bundle assembly have had a BundledBehaviour instance created, containing the type name, value type field data and reference type field references, we can safely go ahead and destroy all the original behaviours.

Great! Finally before building the actual bundle, a neat trick is to create a little asset bundle manifest – basically a custom asset type which will be set as the main asset of the bundle, referencing assets we need handy.

Again, since there is plenty of documentation on how to do that in the Unity Hacks talk, I would direct you there rather than explain it here.

The bundle manifest should reference the TextAsset of the bundle assembly (since we need to load that before doing anything else) as well as all the prefabs being built into the assembly.

Once that is set up, all there is left to do is to initiate the asset bundle build process, specifying the bundle manifest as the main asset, rejoicing that this crazy cabal of hacks somehow worked.

Loading

So now we have an asset bundle which we need to somehow magically turn into a whole new self-contained game runtime or whatever it was we put in there.

First up, via bundle manifest – accessible as the main asset of the bundle, the bytes of the assembly need to be passed to a System.Reflection.Assembly constructor.

With that done, all the behaviours defined in the assembly are available for attaching.

Next, all prefabs should be unpacked first. For each BundledBehaviour attached, run an Unpack function.

Unpacking

By passing the type name stored on the BundledBehaviour to a GetType call, we can get a reference to the original type, which we can pass to AddComponent, creating a new instance of the original. Store this pairing between BundledBehaviour and new instance in a list – just like during the packing process.

Once available deserialise the simple fields, as stored in byte form on the BundledBehaviour, onto the new instance.

For each asset reference in the list of ReferenceFields, copy over the reference to the correct field on the new instance.

As with the packing process, dealing with reference type fields should be pushed to a second pass – once all instances of the original types are available.

References

We can now pass over all BundledBehaviour previously treated and copy all references stored in the list of ReferenceFields to the members with the proper names – as specified in the same.

When copying over a reference, check first if it is one of our BundledBehaviour instances and if so, copy over the new instance it is paired with in stead.

With all original data and references restored, all instances of BundledBehaviour on the prefabs can now be destroyed.

Scenes

Scenes can now be loaded normally from the bundle, since all prefabs have now been properly unpacked. BundledBehaviour should in its Awake handler start the same unpacking process used on the prefabs, so that loading a scene automatically unpacks it.

Violá! New inter-depended content and logic is now live in your runtime!

Recommendations and Limitations

Seeing as the BundledBehaviours are using Awake, that basically rules out behaviours depending on one-another during Awake. Not to worry though, you still have OnEnable and Start for initialisation. Just keep it in mind.

Depending on your use case for this, you might end up with an interesting web of different versions of bundles loaded on any given client machine. I would therefore recommend not spending time and resources on building a dependency tree between bundles and in stead strictly forbid one bundle using components defined in another. Additionally it would be a good idea to designate one namespace per bundle.

As mentioned in the original post, this whole trick depends on the mono JIT runtime being available. That means no fun for you if you are targeting iOS or the consoles – at time of writing, those are the platforms on which Unity employs AOT rather than JIT.

Security

Before we run out and celebrate our great fortune, a word on security: Since a likely application for this technique is to load self-contained bundles over the internet, remember that a third party could potentially insert themselves mid-stream and modify the contents of your transmission.

If we were just transmitting textures and meshes, that should be just fine, but in this instance we are transmitting executable code which we intend to run in our application.

So it would probably be a good idea to somehow guard against someone inserting malicious code in there. At the very least you should employ some public key signing of the bundles – optimally doing the whole transfer on a secured connection (whatever that means these days).

And that is about it. A fair bit of text, but I hope you found some use in this postmortem-ish post. I had fun writing it at least :)

The Engine Wars: Numbers

2014-03-25 00:00:00 +0100

So this years GDC did indeed not disappoint – lots of great talks, meetings and announcements. Thanks for saying hi if you did – if not, maybe next year. Of the announcements, I would like to just focus on the engine ones here.

Overview

Unity 5 was announced with a great feature set, Unreal 4 was released to the public on an attractive subscription license (including full source) and the same for CryEngine (though no source).

This heavy escalation of the engine wars means that now more than ever, the choice of tech to startups and indies is about tech rather than numbers.

However the numbers are not exactly transparent or directly comparable and not all information is out there yet (especially for CryEngine). I have done my best to collect the available information, but please let me know if something is off or missing.

CryEngine is now available (no source) for indies at 9.9 $/€ per seat, per month.

Unreal4 is available (source included) at $19 per seat, per month, plus 5% revenue share on gross sales (meaning you get 65% payout from iOS sales in stead of 70% for instance).

Unity5 has no change in its licensing model (providing more options, also rendering it more confusing) – it has a free version (some features locked away), a rental and an up-front model – no revenue share or source on any of them. One core difference in the rental model for Unity is that you always bind for 12 months.

The balance of the new CryEngine and Unreal offers in general over Unity is that most of the cost can be deferred to after sales, where Unity in general is up-front payment.

Comparison

In the form below you can adjust number of seats, duration of production and expected gross sales to see how this will affect the product prices. Note that the rows starting with “+” are added to the base cost.

Seats	Duration (months)	Gross sales

	CryEngine ¹	Unity5	Unity5 pro	Unity5 sub	Unreal4 ⁴
Base		$0
+ Android	$0	$0			$0
+ iOS ²	$0	$0			$0
+ WinPhone 8	N/A	$0	$0	$0	N/A
+ Blackberry	N/A	$0	$0	$0	N/A
+ Web/GL	N/A	$0	$0	$0	$0
+ PS4 ²	Call us ³	N/A	Call Sony ⁵	Call Sony ⁵	Call us ³
+ XboxOne ²	Call us ³	N/A	$0	$0	Call us ³
+ WiiU ²	Call us ³	N/A	$0	$0	Call us ³

¹ : On CryEngine:

While “Base” means Linux, Mac and Windows for the others, CryEngine does not support Mac and Linux.
Not a lot of details are available on licensing at this time.
It would seem that the as-a-service model has a company income limit – similar to Unity free being unavailable for $100k+ companies.

² : iOS and consoles require registering with platform owner

³ : “Call us” most likely means old-school licensing as in up-front large cash payment / larger rev-share or a mix.

⁴ : Keep in mind that since revenue share for Unreal4 is taken of gross, any publisher or investor deal involving revenue share will relatively scale your effective cost of the engine share.

⁵ : Sony has not promised outright to cover license expenses like Microsoft and Nintendo, but are likely to.

Also keep in mind that none of the providers are closed to the idea of doing tailored quotes on bulk or custom deals. This post is mostly intended for startups and indies who generally would not receive such quotes.

Sources

I hope you find this useful and again – this is what I could find. Do please let me know if something is missing or off.

GDC 14: The Quest For Fun

2014-03-13 00:00:00 +0100

Next week is that wondrous time of GDC again and boy am I looking forward to saying hi to old friends, meeting new ones and absorbing some great talks.

Unlike my previous visits however, this time I attend representing not an employer, but myself as a freelancer. Freelancing in Q3 and 4 of 2013 was filled with lots of fun and great challenges, so my mission at this years GDC will be to build my schedule to make 2014 at least as much fun.

For more information on my freelancing services and references, please see the Freelance and Work pages.

If you have a task or project you think we could do some good work on together / want to talk about Behave for a bit or just say hi, please do not hesitate to give me a ping.

Shortly after arrival I will pick up a prepaid SIM, so I am reachable via Twitter or the GDC app PM system.

I’ll also be co-hosting the IGDA Unity and AI SIG meetings Wednesday (Unity SIG) and Friday (AI SIG). Do stop by if you have an interest in either of those topics.

In any case, if you’re attending GDC I hope you have a good time – I know I plan to.

Moving in Unity

2014-03-07 00:00:00 +0100

Updated March 8th: Added a few more details on mapping to navmesh and extrapolating the root motion vector.

Moving something around on the screen in Unity is really not that hard. The point of this post is therefore not to introduce you to how this is accomplished, but rather to point out where you’re doing it wrong™.

Generally Unity moves objects using one of three systems:

Direct transform manipulation.
Physics.
Navigation.

In the end, movement is measured on transform updates. I make the distinction from the point of view of where you provide the input. Technically you could argue that animation should be up there as well, but I choose to lump that in with transform manipulation, since disabling the application of movement by the animation system has no other side effects.

As a side-note, since 4.3 it is possible to partially or completely disable having the animation system update the transform hierarchy.

Transform

So long as the goal is simply to move an object and nothing else, modifying the values of the transform component, or using its various useful methods to do so, is all you need.

This includes directly animating the transform via the animation window or by enabling animation root motion.

However chances are that your situation is more complex than this and you would do well to read on.

Physics

When your object in any way needs to affect and/or be affected by the physics simulation, you need to make some extra considerations. Simply slapping on a collider and calling it a day will ruin your next.

To properly participate as a dynamic part of the physics simulation, an object needs to have a rigidbody component attached somewhere in its transform hierarchy.

The physics system considers separate transform hierarchies as separate objects, so one (and only one) rigidbody component will mark the rest of its hierarchy as dynamic.

Multiple rigidbodies in the same hierarchy leads to undetermined behaviour (read: weirdnessness) – the only exception being if those rigidbodies are connected by a joint – thus making their behaviour again well defined.

To clarify, this does not apply to sibling hierarchies, but strictly scenarios where tracing from one rigidbody, through to the hierarchy root, encounters another rigidbody.

In general, many systems – both built in and third party – rely on dynamic objects being separate transform hierarchies. Building with such a design is both safe and recommended practice.

Kinematic

“But I don’t need gravity or forces or all that other nonsense!” – be cool, that is what the “kinematic” switch is for. This basically tells the physics simulation that your object is dynamic, but you will take care of all its movement.

Kinematic rigidbodies will not be affected by forces or collisions, but will collide with non-kinematic rigidbodies, sending collision events and pushing them out of the way (assuming there are colliders present somewhere in the transform hierarchy of the object).

“So why add the rigidbody in the first place? Things work just fine without!” – if you have Unity pro, I would direct your attention at the profiler as you move about – if not, take my word for it that it is not a joyous sight.

Any object (unique transform hierarchy) with no rigidbody present is treated by the physics simulation as static. For optimal performance, all static colliders are baked into a static collision geometry, securing optimal performance when doing collision checks.

However every time one static collider (note that this has nothing to do with the static flags on the GameObject – just the presence of absence of a rigidbody on the object in question) is moved, the whole static collision geometry is marked dirty and regenerated.

This is not a terribly costly operation, so moving pieces of level geometry from one position to another from time to time is fine. However moving a character of one or more static colliders around every frame will cost you.

Note that while moving by directly modifying the transform of a kinematic rigidbody is just fine, you will get better results for rapid movement by using the MovePosition and MoveRotation rigidbody functions.

The former will effectively “teleport” the physical object – fine for short distances and minor rotations, but less so for longer moves. MoveRotation and -Position effectively “drags” the object from A to B.

Kine-not-so-matic

“Ok, so maybe it would pretty useful if my character could walk into walls, get pushed by others and that sort of thing…” No problem. Disable the kinematic flag and start moving via the rigidbody component. If you wanted proper forces and all that, I’m sure you’re already all over the AddForce function and friends.

However if you still want strict control – just with a touch of presence – you should look at directly setting the velocity property of the rigidbody.

Given sideways and forward movement input, forming a velocity vector is easy. By setting the velocity of the rigidbody you add that information to the physics simulation as well as tell it to update the position of the object smoothly.

That includes pushes from other rigidbodies or pushbacks from static geometry. However directly setting the velocity will override any directional change and so momentum will remain unchanged.

Therefore consider factoring in some acceleration when building your target velocity vector – for a more natural look after your character is pushed or makes an abrupt change of direction.

Navigation

Parallel to the physics simulation you find the navigation runtime. Similarly to how the rendered world model is defined by static and dynamic geometry and the physics world model is defined by static colliders and rigidbodies, the navigation world model is defined by interconnected navigation mesh and dynamic obstacles.

While the static physics geometry defines areas of no access, navigation mesh defines areas which are navigable. This information is used for finding a valid path from point A to B, but more importantly it is used to constrain characters and inform them of their surroundings.

The physics simulation can be used for this as well and traditionally is. However the data covered by the physics system is vastly more complex and its ability to define traversable space is a side effect of its ability to define non-traversable space.

This is where you end up spending way too much time blocking off sections of scenery and later testing that there are indeed no holes in that. Navmeshes on the other hand define a surface on which characters of a given height and with a given radius can move.

NavMeshAgent

Similarly to the rigidbody component, the NavMeshAgent component wires an object to the navigation runtime. In stead of the single kinematic switch, however, the NavMeshAgent has separate updatePosition and updateRotation toggles.

To get things going, you can either set a path by one of the many accessors for that or directly set the velocity. Assuming that the NavMeshAgent is configured to update the position, this will start smoothly moving the object like with the rigidbody – only this time constrained by the navigation meshes rather than collision geometry.

In addition to pathfinding and staying on the navigation mesh, the navigation runtime will also attempt to have the various NavMeshAgents avoid one-another by adjusting velocity based on the position and velocity of nearby dynamic obstacles and NavMeshAgents.

Avoidance can be completely tweaked though – so that one NavMeshAgent can ignore it completely or itself be ignored or weigh different NavMeshAgents differently.

Direct control

“Pathfinding? I just need to move this character around based on input.” Sure, fine – that is where you just go set the velocity of the NavMeshAgent rather than trying to set a path or destination for it.

Like with the rigidbody, this starts moving the NavMeshAgent smoothly and tells the runtime about its current velocity – giving other agents a chance to avoid. Note that even if you do not let the NavMeshAgent directly control the position of your character, you should still feed the velocity back to it – in order to keep the avoidance runtime up to date.

Animation

“WAT! You did not count this as one of the three ways of moving stuff!” – nop, quite right. However root motion is awesome, so let’s briefly touch on how we tie that to the other systems for much greatness.

While most of what the animation system does is not of too much concern for your movement logic, one very useful feature is. By analysing animations on import, the surface movement relevant for those animations is calculated and later blended as the animations are blended.

By default the animation system will, with root motion enabled, move an animated object around by directly updating the transform position based on the root motion of the currently playing animation blend. Animation nicely synchronised with world movement.

I’ll root my own motion, thank you

However while that looks mighty cool, it really isn’t very considerate of your carefully crafted physics simulation or your neatly marked navigation runtime. Luckily it does give an in by allowing you to override the actual application of the root motion.

This is accomplished by, on the same game object as your animator component, attaching a script implementing the method OnAnimatorMove. Once that method is defined, the animation system will no longer directly apply root motion and in stead call this implementation post-evaluation.

In the implementation of the OnAnimatorMove callback, you could then update a target velocity vector by simply dividing animator.deltaPosition by Time.deltaTime and similarly rotation. And once we have desired movement in the form of a velocity vector, plenty of the earlier described scenarios become relevant.

Most interactive niceness

“Great, I’ll take one of each!” Sure, no problem. Well… It’s not exactly straight forward, but it is indeed possible to combine all of these things to get something that is responsive, embedded in your simulations and looks great.

The chain of data goes a little something like this:

Player controlled characters:
1. Feed input to the animator, resulting in nicely blended animations and root motion.
2. Generate a target velocity in OnAnimatorMove.
3. Set velocity of NavMeshAgent (configured to not update position or rotation).
4. Set velocity and rotation of non-kinematic rigidbody (properly constrained on rotation so it doesn’t tip over).
5. Map transform position to navigation mesh via NavMesh.SamplePosition.
Non-player characters or indirectly controlled player characters:
1. Set destination or path of NavMeshAgent.
2. Feed desiredVelocity of NavMeshAgent to animator.
3. Repeat as for player controlled characters from 2.

What this setup does not give you is responsiveness to being bumped into. However velocity-wise this is not something your movement implementation should handle directly unless you are ok with breaking that nice root motion setup you just established.

In stead I would recommend using queries on the surrounding physics and navigation environment to inform the animation state machine of special conditions like “player wants to go full speed, but there’s a wall two units from here” and handle slowing down, stopping and similar in there where the result will look good.

One simple trick is to do a navigation raycast along the forward vector of the moving transform for some amount of look-ahead distance and if a navigation mesh edge is hit and do a physics raycast further forward from a point slightly elevated from that edge hit point.

With that setup you can very simply gather information about where the character is headed – if into a steep wall or perhaps to a ledge or obstacle which could be leapt.

Unity Hacks

Since apparently I lumped just about everything into that project, unsurprisingly the Unity Hacks project has some work on this form of wired up movement. Particularly the Mover component attempts to create a system-agnostic movement interface as well as some simple movement on networked setups not covered here.

While not complete or in any way a final answer, I hope that with the information provided here, it turns out useful for you.

Mover.cs

Behave 2.3

2014-02-27 00:00:00 +0100

In good time for GDC, I present version 2.3 of Behave. Not exactly the rapid January release I had hoped for – admittedly I got a bit carried away. However that just means more goodies for everyone :)

Highlights from the changelist below:

Great new behaviour for Repeaters and decorator components in general.
Mandatory contexts.
Useful runtime API tweaks.
A good, thick coat of editor polish.

A word of caution on the new instant repeater: It will very easily send you into an infinite loop if you are not watching out. Just in case you by accident set one up, the compiler will warn about this potential scenario.

For this release, the AngryAnt community has again provided great bug reports and many suggestions for changes and additions. Thanks! I hope you enjoy this release – do let me know in either case.

Onwards

As noted in the release notes, a good deal of time was spent refactoring while working on this release. This puts me on a good path for some exciting additions later on.

However with GDC right around the corner, I will likely have to reduce my velocity on Behave a bit. So let’s keep this new stuff as a surprise for later. No need for letting out all the spoilers now, right?

Changelist:


2.3:
 - Added support for instant repeaters.
 - Added support for mandatory contexts.
 - Added optional target parameter to Tree.ResetForwards.
 - Added Tree.TickWrapping method.
 - Added debugger auto-launch settings to library build options.
 - Added home screen - shown on launch or via the Help menu, full of resources.
 - Behavioural change: Decorators no longer forward the instant flag of their child node.
 - Behaviour of decorators receiving a Running signal from their control connection is now defined.
 - Dependencies now shipped as separate (replaceable) files for minimal project impact.
 - Editor polish.
     - Added support for running multiple editor debugging instances on one machine.
     - Added focus-follow for debugger and canvas.
     - Added both scrollwheel/pad and drag-to-scroll support to all canvas views.
     - Drag connection to occupied input slot to replace.
     - Directly drag-drop trees from the sidebar onto the canvas as reference nodes.
     - Instant flag doesn't show on nodes connected to parents ignoring the flag.
     - "Last edited library" now tracked per project.
     - Last selected tree is now also restored between sessions and playmode transitions.
     - A bunch of minor adjustments and improvements.
     - Performance + memory + disk space optimisations.
     - Minor bugfixes.
 - New documentation layout and enhancements (already released as available).
 - Reshuffling of code to make way for exciting new things down the road.


2.2.2:
 - Addressed protobuf issue causing Parallel component completion setting to not get stored correctly.


2.2.1:
 - Fixed issue causing parallel components to fail compilation.


2.2:
 - Behavioural change: Support for multiple different action handler signatures is discontinued effective immediately.
    - Generated agent blueprint as well as accepted reflected signatures are now only:
        - public BehaveResult [Tick/Init][Name]Action (Tree sender);
        - public void Reset[Name]Action (Tree sender);
 - Added Tree class accessors - all valid only during an active init/tick/reset handler call:
    - string ActiveStringParameter
    - float ActiveFloatParameter
    - IAgent ActiveAgent
    - object ActiveData
 - Rather than waiting for the Unity bugfix, the built-in compiler API is now bypassed in favour of direct compiler binary execution.
    - An additional system-level mono SDK install is no longer needed to work around this Unity bug.
 - Tree.SetForward now returns boolean success value rather than logging error when passed unused action.
 - Full-library export now also available from the library settings in stead of menu-only access.
 - Even more UI polish: Better word-wrap, more contrasts for emphasis, instant flag hidden in unaffected scenarios and much more.
 - "Form new tree" nicely moves the new subtree up around the root socket rather than retaining the old position.
 - Default frame-rate of DebugUpdater now set to 20 fps rather than every frame. Gun safety and all that.
 - Massive codegen size save for larger libraries - from optimisation of tree-agent introspection codegen. Compile-time win.
 - More rigid parameter evaluation (remove needless occasional extra codegen).
 - Fixed copy and duplication procedures incorrectly not copying parameter values.
 - Force Unity to write serialised data before compiling.


2.1.1:
 - Fixed issue with tree paramterisation breaking debugger visualisation.


2.1:
 - Added autocomplete on action names, string parameters and component contexts.
 - Added mandatory actions (present in library regardless of use in trees).
 - Added partial library export and library merging / import-to-library.
 - Added Behave stripping - leave behind only a very lean Behave runtime, for redistribution or super slim deploy.
 - Added parameterised trees - get even more re-use out of your trees by overriding context and variables per reference.
 - Behavioural change: Tree.Reset will now delay resetting tree variables until after complete component reset.
 - Behavioural change: Tree.Tick will no longer automatically reset the tree upon completion. This plays very well with:
 - Added Tree.TickContinuously (int iterationCap = 1024) - ticks tree till completion or iteration cap is reached.
 - Added BehaveResult Tree.Result (bool value) utility function to side with Tree.Invert (BehaveResult value).
 - Added int Debugging.Local.ConnectionCount property - facilitating debug behaviour dependent on Behave debugger presence.
 - Moved default install path from Assets/Behave to Assets/Plugins/Behave.
    - WARNING: See Readme.txt upgrade guide.
 - Fixed decorator control node removal resulting in detached control connection.
 - Fixed decorator incorrectly not forwarding the instant status of its child node.
 - Fixed scenario where agent classes would get reflected for handlers even if blueprint derived.
 - Fixed unexpected corner cases of bad library configuration failing compiles (now causing warnings or simply being ignored).
 - Fixed Behave window breaking down when exiting play mode after having been active there.
 - Fixes to context getting incorrectly reset in some scenarios.
 - Fixed copy / paste functionality missing in some text fields.
 - Lots of UI polish and minor fixes.


2.0:
 - New editor.
    - Unified all controls into one window.
    - Completely customised look - compatible with both Unity light and dark skin.
    - Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
    - Remote debugging.
    - Tick and reset.
    - "Unplug" for debugger-only control.
    - Breakpoints.
    - Action overrides - override the return values of specified actions.
 - Decorator rewrite.
    - Deprecated old decorator.
       - Still compiles, but cannot be added.
    - Decorators are now control-type components.
       - No specific decorator handlers on agents.
       - Control is achieved via third connection socket.
    - Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
 	- No more collections - for nesting, use paths in tree names.
 	- New serialization format - see Readme.txt for upgrade instructions.
    - Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
	- Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
    - int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
    - enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
    - enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
    - int Tree.ActiveContext { get; }
 - Changed IAgent interface:
    - Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
    - Trees -> TreeType.
    - Actions -> ActionType.
    - Decorators -> DecoratorType.
    - Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
    - int TreeID (Tree) -> static TreeType Type (Tree)
    - bool IsAction (int) -> static bool IsAction (int)
    - bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
    - public void Reset[Name][Action/Decorator] (Tree sender);
    - public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
    - Component bar.
    - Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
    - When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
    - When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
    - Behaviour tree decorators.
    - Stand-alone edition of the Behave editor.
    - Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
    - Not able to delete collections from library.
    - Not able to delete trees from library.
    - Not able to rename collections from library.
    - Not able to rename trees from library.
    - Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

Unity and .net assemblies

2014-01-03 00:00:00 +0100

Since I started making middleware for Unity in early 2008, I have been working with Unity and .net assemblies. I have in this time had many opportunities to juggle the two in many different contexts, so I figured a sort of summary of what I learned would make sense.

Why not start off by setting a few facts straight, eh?

Aside from the extension and a header, .net assemblies have little to do with Windows Dynamic Link Libraries.
- Windows DLLs contain binary code, usually with a very simple interface, while .net assemblies contain .net bytecode (or CIL).
Unity pro is not required to use .net assemblies.
- Binary plugins require Unity pro (at time of writing) and must be placed in Assets/Plugins. However .net assemblies are just bytecode – just like what Unity turns your scripts into, so none of these requirements apply.
.net assemblies run on all platforms – including webplayer.
- Again, as we are talking about bytecode which is fed directly to the mono runtime – like the compiled result of your scripts, the same rules go.
Distributing .net assemblies in stead of script files does not copy protect your code.
- Since the mono runtime has to Just In Time compile your assembly to run on the current platform, the bytecode is quite verbose and while some information is lost, generally it is very easy to decompile and read .net assemblies.
- Remember that this is true for your script source in most project builds as well, since for most platforms Unity builds your scripts to .net assemblies.

Argh! But my kodes!

I will not get into source protection too much, but generally I would not worry too much about it.

Source code in and of itself does not mean that someone can instantly copy and use parts of your work. It takes actual skill and time investment to make use of it, integrated in a different setup from what it was originally designed for. In the end it is my opinion that it would not be worth it compared to doing the same work from scratch.

Consider that the entire source of Half Life 2 was very publicly leaked shortly before its originally scheduled release and how we are all now drowning in games based on it.

If you have client-side security measures which you would like to protect – like in-app purchases or other anti-cheat measures, you may indeed want to consider splitting out and encrypting part of this logic as well as applying some measure of source obfuscation.

A word of caution: While source-level obfuscation is fine and usually sufficient, assembly-level obfuscation can be risky as it generally relies on bugs in the mono runtime in order to function. Bugs which might get fixed at any time – at which point you will need to go back and revisit your security efforts.

And remember: Encryption and obfuscation is just about making it harder for people to do things you don’t want them to. In the end this all has to be understood by processors and even binaries are routinely reverse engineered. The best security is gained by not making what you wish to protect available outside of hardware in your control.

For more information on protecting sensitive client-side information from tampering, see the Unite Asia 2013 “Protecting Your Android Content” talk by Erik Hemming.

Note that Unity does not distribute .net assemblies on all platforms. Some platforms do not run the mono JIT compiler because reasons and for those Unity will in stead perform Ahead Of Time compilation on your code while building.

AOT compilation basically means that in stead of relying on the JIT compiler to at runtime load your bytecode when relevant and compile it for the specific hardware it is running on, the AOT compiler will compile all your assembly to platform-specific binary right up front.

This means that your source code assemblies, any assemblies present in your project as well as the Unity engine assemblies are all jumbled into one binary. In most cases this should disincentivise tampering sufficiently.

At time of writing, Unity employs AOT compiling on iOS and the console platforms.

What is the point then?

Now that you know what assemblies are not, you might be wondering why you should be interested in them at all. And rightly so.

I think it is always healthy to have some understanding of what goes on in the lower layers of your technology stack, but most Unity developers will not need to know about .net assemblies.

However here are some reasons why they are really cool:

If you are distributing middleware, they allow you to significantly reduce your distribution footprint without compromising your development environment (one assembly vs. a bunch of script files).
- Like their Windows cousins, .net assemblies allow embedded resources, which means you can literally put everything you need – textures, audio, whatever – inside one file.
Where JIT is available, new assembly can be loaded at runtime.
- So what? So live patching baby!

Since the JIT compiler routinely loads bytecode from disk and compiles and executes it, there is nothing preventing you from having it load bytecode which was not included in your original build.

The class System.Reflection.Assembly lets you load in bytecode from a file or a byte array, after which you can use reflection to find and instantiate types, call functions and all that other good stuff on what is contained in the assembly.

Remember that since Unity employs AOT and not JIT on some platforms, this functionality is not available everywhere.

For an example of loading in new assembly, see the code-in-asset-bundles example from the “Unity Hacks” talk available on the videos page (source included).

A word of caution: If you plan on employing remote patching, make sure to at least sign your transfers in order to avoid man in the middle injection attacks.

Wohoo! Assemble all of the things!

This is all great, but how do you get started building assemblies for all them things? Well, dear reader, there are different approaches:

If you are already set up with Visual Studio or Mono Develop, you can simply create a new project for a .net assembly using the project creation wizard. In order to access Unity types, simply add the UnityEngine.dll (and if necessary the UnityEditor.dll) assemblies to the project references and off you go.
Should you be of a different persuasion and if you are not one to shy away from a terminal window, you can use the the gmcs binary as distributed with Unity or the mono SDK to build your assembly by command-line.

Either of these will produce a .dll file with all of your kodes (and potentially resources). Simply drop it anywhere in your assets folder to gain access to the contained classes. The same compile order rules which apply to scripts, also hold true for assemblies.

Any public ScriptableObject or MonoBehaviour derived classes will appear as children of the assembly asset. Simply click the folding widget next to the asset in order to view and be able to drag-drop them.

Ah and if you were too lazy to check out the Unity Hacks talk (you really should, it is full of useful snippets), the trick for putting code in asset bundles is to compile the scripts to an assembly rather than letting Unity compile them and then save the assembly in your assets folder with the .bytes extension rather than .dll.

This makes Unity import the assembly as a TextAsset which is not addressed by Unitys compiler and can be included in asset bundles. At runtime, the bytes property of the asset reference is then passed to the Assembly constructor as described earlier.

And the catch?

Given that we are reaching the end of this article, that would mean it is high time for some dream bursting. This all sounds very easy and optimal to work with, but of-course it is not that simple.

While Unity makes it fairly straight forward to debug your scripts using MonoDevelop, it will by default do absolutely nothing to help you with your assemblies.

To help it on its way, you need to first build your assemblies for debug and secondly copy the generated [AssemblyName].mdb file to your assets folder along side the .dll file.

If you went ahead and looked for the mdb file right as I had ended the above paragraph, you would stand some chance of not finding it. Should you be on Windows, a pdb file rather than an mdb is generated and it is absolutely useless to the Unity debugging runtime.

Should you be stuck with a pdb file, you will need to use the pdb2mdb command-line tool as distributed with the Unity mono runtime or the mono SDK. However running this command by hand every time you need to debug gets old really fast, so I recommend adding it in as a post-build step on your MonoDevelop or VisualStudio project.

For more information on debugging assemblies in Unity and indeed general use of assemblies in Unity, see this excellent article in the Unity documentation: Using Mono DLLs in a Unity Project

And that is all, folks. I hope you find it useful!

Behave 2.2

2013-12-23 00:00:00 +0100

It is finally here! Sorry about this release taking a bit longer than the prior ones. I have experienced the very luxurious “problem” of having lots to do. The last contract of the year finished this Friday though, so here we are: 2.2 :)

While the full changelist will follow the body of this post as per usual, I would still like to draw out a few of the main changes in 2.2:

Behavioural change: Support for multiple different action handler signatures is discontinued effective immediately.
Rather than waiting for the Unity bugfix, the built-in compiler API is now bypassed in favour of direct compiler binary execution.

Watch out for that behavioural change – it will very likely break code. I decided on this in order to reduce the size of your obligatory agent code. Additional parameters have been moved onto properties of the sender tree.

The compiler change means we are finally rid of that annoying requirement of having mono installed next to Unity in order to run the Behave compiler. Yay!

The remaining changes are more or less just heaps of UI- and workflow polish, plus a few bug fixes – again, many thanks to the AngryAnt community for providing invaluable assistance in identifying and tracking these down.

Onwards

Early next year I hope to have some more time for Behave, allowing me to do some rapid releases with new features in January. As always, any feedback you might have is very much appreciated.

Changelist:


2.2:
 - Behavioural change: Support for multiple different action handler signatures is discontinued effective immediately.
    - Generated agent blueprint as well as accepted reflected signatures are now only:
        - public BehaveResult [Tick/Init][Name]Action (Tree sender);
        - public void Reset[Name]Action (Tree sender);
 - Added Tree class accessors - all valid only during an active init/tick/reset handler call:
    - string ActiveStringParameter
    - float ActiveFloatParameter
    - IAgent ActiveAgent
    - object ActiveData
 - Rather than waiting for the Unity bugfix, the built-in compiler API is now bypassed in favour of direct compiler binary execution.
    - An additional system-level mono SDK install is no longer needed to work around this Unity bug.
 - Tree.SetForward now returns boolean success value rather than logging error when passed unused action.
 - Full-library export now also available from the library settings in stead of menu-only access.
 - Even more UI polish: Better word-wrap, more contrasts for emphasis, instant flag hidden in unaffected scenarios and much more.
 - "Form new tree" nicely moves the new subtree up around the root socket rather than retaining the old position.
 - Default frame-rate of DebugUpdater now set to 20 fps rather than every frame. Gun safety and all that.
 - Massive codegen size save for larger libraries - from optimisation of tree-agent introspection codegen. Compile-time win.
 - More rigid parameter evaluation (remove needless occasional extra codegen).
 - Fixed copy and duplication procedures incorrectly not copying parameter values.
 - Force Unity to write serialised data before compiling.


2.1.1:
 - Fixed issue with tree paramterisation breaking debugger visualisation.


2.1:
 - Added autocomplete on action names, string parameters and component contexts.
 - Added mandatory actions (present in library regardless of use in trees).
 - Added partial library export and library merging / import-to-library.
 - Added Behave stripping - leave behind only a very lean Behave runtime, for redistribution or super slim deploy.
 - Added parameterised trees - get even more re-use out of your trees by overriding context and variables per reference.
 - Behavioural change: Tree.Reset will now delay resetting tree variables until after complete component reset.
 - Behavioural change: Tree.Tick will no longer automatically reset the tree upon completion. This plays very well with:
 - Added Tree.TickContinuously (int iterationCap = 1024) - ticks tree till completion or iteration cap is reached.
 - Added BehaveResult Tree.Result (bool value) utility function to side with Tree.Invert (BehaveResult value).
 - Added int Debugging.Local.ConnectionCount property - facilitating debug behaviour dependent on Behave debugger presence.
 - Moved default install path from Assets/Behave to Assets/Plugins/Behave.
    - WARNING: See Readme.txt upgrade guide.
 - Fixed decorator control node removal resulting in detached control connection.
 - Fixed decorator incorrectly not forwarding the instant status of its child node.
 - Fixed scenario where agent classes would get reflected for handlers even if blueprint derived.
 - Fixed unexpected corner cases of bad library configuration failing compiles (now causing warnings or simply being ignored).
 - Fixed Behave window breaking down when exiting play mode after having been active there.
 - Fixes to context getting incorrectly reset in some scenarios.
 - Fixed copy / paste functionality missing in some text fields.
 - Lots of UI polish and minor fixes.


2.0:
 - New editor.
    - Unified all controls into one window.
    - Completely customised look - compatible with both Unity light and dark skin.
    - Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
    - Remote debugging.
    - Tick and reset.
    - "Unplug" for debugger-only control.
    - Breakpoints.
    - Action overrides - override the return values of specified actions.
 - Decorator rewrite.
    - Deprecated old decorator.
       - Still compiles, but cannot be added.
    - Decorators are now control-type components.
       - No specific decorator handlers on agents.
       - Control is achieved via third connection socket.
    - Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
    - No more collections - for nesting, use paths in tree names.
    - New serialization format - see Readme.txt for upgrade instructions.
    - Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
    - Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
    - int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
    - enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
    - enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
    - int Tree.ActiveContext { get; }
 - Changed IAgent interface:
    - Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
    - Trees -> TreeType.
    - Actions -> ActionType.
    - Decorators -> DecoratorType.
    - Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
    - int TreeID (Tree) -> static TreeType Type (Tree)
    - bool IsAction (int) -> static bool IsAction (int)
    - bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
    - public void Reset[Name][Action/Decorator] (Tree sender);
    - public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
    - Component bar.
    - Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
    - When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
    - When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
    - Behaviour tree decorators.
    - Stand-alone edition of the Behave editor.
    - Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
    - Not able to delete collections from library.
    - Not able to delete trees from library.
    - Not able to rename collections from library.
    - Not able to rename trees from library.
    - Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

ReView

2013-10-11 00:00:00 +0200

Earlier this week ReView, a small Unity editor extension of mine, went live on the Unity Asset Store.

The story behind it is simply that I was getting tired of adjusting layouts all the time – as my tooling needs changed between authoring something in edit mode and testing it in play mode. The closest thing to something built-in addressing this would be the “maximise on play” feature. However that is basically only useful for demoing.

So I wrote ReView. It lets you define two window layouts – just like any other Unity window layout – with the key difference being that you append “-edit” to one and “-play” to another. Once you switch to the one relevant for your current mode, ReView will then automatically switch to its counterpart when you enter or exit playmode.

Behave 2.1

2013-10-06 00:00:00 +0200

A little over a month ago I shipped Behave 2 after having spent quite a while rewiring a lot of the core of the project. Today you get to see even more benefit of this work as already I am ready with version 2.1.

I would like to take this opportunity to thank the members of the AngryAnt community who have been a great help in identifying bugs I had not found and properly corner those I had.

While the full changelist will follow the body of this post as per usual, I would still like to draw out a few of the main changes in 2.1:

Auto complete on contexts, action names and string parameters makes for faster editing and helps guard against typos.
Partial library export and import-to-library makes moving trees between projects a breeze.
Parameterised trees increase tree re-usability even more by exposing select node settings as tree parameters, tweak-able per reference.

Onwards

While 2.1 brings great additions to the solid feature set of Behave 2, I am far from done.

I realise that many currently still on the fence with regards to upgrading from 1.x have asked for more in terms of examples and demos and I will do my best to get to that as soon as possible.

As always, I greatly appreciate any feedback you might have.

Changelist:

2.1:
 - Added autocomplete on action names, string parameters and component contexts.
 - Added mandatory actions (present in library regardless of use in trees).
 - Added partial library export and library merging / import-to-library.
 - Added Behave stripping - leave behind only a very lean Behave runtime, for redistribution or super slim deploy.
 - Added parameterised trees - get even more re-use out of your trees by overriding context and variables per reference.
 - Behavioural change: Tree.Reset will now delay resetting tree variables until after complete component reset.
 - Behavioural change: Tree.Tick will no longer automatically reset the tree upon completion. This plays very well with:
 - Added Tree.TickContinuously (int iterationCap = 1024) - ticks tree till completion or iteration cap is reached.
 - Added BehaveResult Tree.Result (bool value) utility function to side with Tree.Invert (BehaveResult value).
 - Added int Debugging.Local.ConnectionCount property - facilitating debug behaviour dependent on Behave debugger presence.
 - Moved default install path from Assets/Behave to Assets/Plugins/Behave.
    - WARNING: See Readme.txt upgrade guide.
 - Fixed decorator control node removal resulting in detached control connection.
 - Fixed decorator incorrectly not forwarding the instant status of its child node.
 - Fixed scenario where agent classes would get reflected for handlers even if blueprint derived.
 - Fixed unexpected corner cases of bad library configuration failing compiles (now causing warnings or simply being ignored).
 - Fixed Behave window breaking down when exiting play mode after having been active there.
 - Fixes to context getting incorrectly reset in some scenarios.
 - Fixed copy / paste functionality missing in some text fields.
 - Lots of UI polish and minor fixes.


2.0:
 - New editor.
    - Unified all controls into one window.
    - Completely customised look - compatible with both Unity light and dark skin.
    - Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
    - Remote debugging.
    - Tick and reset.
    - "Unplug" for debugger-only control.
    - Breakpoints.
    - Action overrides - override the return values of specified actions.
 - Decorator rewrite.
    - Deprecated old decorator.
       - Still compiles, but cannot be added.
    - Decorators are now control-type components.
       - No specific decorator handlers on agents.
       - Control is achieved via third connection socket.
    - Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
 	- No more collections - for nesting, use paths in tree names.
 	- New serialization format - see Readme.txt for upgrade instructions.
    - Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
	- Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
    - int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
    - enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
    - enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
    - int Tree.ActiveContext { get; }
 - Changed IAgent interface:
    - Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
    - Trees -> TreeType.
    - Actions -> ActionType.
    - Decorators -> DecoratorType.
    - Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
    - int TreeID (Tree) -> static TreeType Type (Tree)
    - bool IsAction (int) -> static bool IsAction (int)
    - bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
    - public BehaveResult Init[Name][Action/Decorator] (Tree sender);
    - public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
    - public void Reset[Name][Action/Decorator] (Tree sender);
    - public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
    - Component bar.
    - Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
    - When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
    - When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
    - Behaviour tree decorators.
    - Stand-alone edition of the Behave editor.
    - Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
    - Not able to delete collections from library.
    - Not able to delete trees from library.
    - Not able to rename collections from library.
    - Not able to rename trees from library.
    - Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

Behave 2.0

2013-08-25 00:00:00 +0200

In 2010 the Unity Asset Store launched with an editor extension already live. That extension was Behave 1. Three years later, after way too long a pause, I have finally gotten around to releasing version 2.0 of Behave.

As you might have noticed, especially lately, I have had quite a few things going on – not the least of which is my recent exit from Unity Technologies and entry into freelancing. This all meant not a lot of time for Behave.

So anyway, this is what I was doing when I was not writing that Unity Hacks blog post you were waiting for.

Behave

If you have no idea what Behave is and don’t feel like dropping by the subsection on this site dedicated to it, here is how it is defined on the Asset Store:

Behave is a system for designing, integrating and running behaviour logic using Behaviour Trees. At its core Behave has a drag-drop designer and a highly effective and flexible compiled runtime.

No funky runtime data formats or interpretation. Designer → Compiler → Your code.

What is the use of a workflow extension without proper rapid iteration tools? Connect the visual debugger with break, step, reset, breakpoints and overrides directly to your project in the editor or on your target device.

Update: An introductory video to Behave 2 is now available:

Future

Part of the challenge with any project is always to fight feature creep. This was very much also the case with Behave 2, so don’t worry – I have plenty of improvements to come. Not saying that this build is broken though – go get it!

License

Unlike Behave 1, version 2 is a paid package. Aside from having gone freelance and needing a financial basis to keep up support for the software, this also had to be done as the Asset Store long ago banned the use of custom licenses.

This, of-course posed a bit of a problem for Behave 1’s default “free if you show the splash” license. Fortunately the Asset Store team members are merciful gods and I got a veeery long grace period to beat Behave into compliance.

Included in the license is also access to a private community and internal support resources – including the beta list.

Launch

For a limited time after launch, Behave 2 will be available at a flat discount of 50%. Additionally, if you happen to bump into me at Unite 2013 in Vancouver next week, you can slip me your business card and partake in the draw for one of three free Behave 2 licenses.

If you already purchased a copy of Behave 2 and win a free copy, I’ll refund you the purchase amount.

Update: Details of the Unite license draw are available here.

Changes

So if you are a Behave 1 user and you are wondering what exactly is under the hood, I included the full Behave changelog below.

Now you might go “1.5? What the hell? Did I miss something?”. No you did not. That version unfortunately did not ship, but was in stead rolled straight into 2.0. But hey, water and bridges, right? 2.0 is here baby!

Behave 2 for Unity on the asset store.

Changelist:

2.0:
 - New editor.
	- Unified all controls into one window.
	- Completely customised look - compatible with both Unity light and dark skin.
	- Keyboard authoring interface in addition to drag & drop.
 - Debugger upgrade.
	- Remote debugging.
	- Tick and reset.
	- "Unplug" for debugger-only control.
	- Breakpoints.
	- Action overrides - override the return values of specified actions.
 - Decorator rewrite.
	- Deprecated old decorator.
	   - Still compiles, but cannot be added.
	- Decorators are now control-type components.
	   - No specific decorator handlers on agents.
	   - Control is achieved via third connection socket.
	- Two initial decorator types: Repeater and Interrupter.
 - Asset restructuring.
	- No more collections - for nesting, use paths in tree names.
	- New serialization format - see Readme.txt for upgrade instructions.
	- Collections are gone. Use Unix-style path names for tree organisation.
 - IAgent.Tick (Tree, bool) changed to IAgent.Tick (Tree)
	- Init calls can now only be handled explicitly
 - Full coverage online documentation and other community resources.
 - Countless fixes and polish items.

1.5:
 - Added Tree.TickActive - indicating if a tree is currently executing a tick or if it has completed evaluation.
 - In-tick tree reset requests now result in a reset at the end of tree evaluation rather than an immediate one.
 - Removed the legacy compatibility assembly (for compatibility with pre-1.2 assets) from the default distribution.
 - Fixed "X must be instantiated using the ScriptableObject.CreateInstance method instead of new X" warnings.

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.

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.

1.2:
 - Fixed release building.
 - Added the priority selector, introducing the API points:
	- int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
	- enum BL[LibraryName].PriorityType { PriorityName, ..., Unknown };
 - Added support for branch contexts, introducing the API points:
	- enum BL[LibraryName].ContextType { ContextName, ..., Unknown };
	- int Tree.ActiveContext { get; }
 - Changed IAgent interface:
	- Tick (bool init, Tree sender) -> Tick (Tree sender, bool init)
 - Added "Select asset" button to the standard inspector.
 - Interface polish.

1.1:
 - Made compatible with Unity 3.0 - including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
 - UI tweaks and polish.
 - Added the option to have return values of nodes be inverted.
 - Fixed compiler bug when facing sequence or selector with only one child node.
 - Renamed Library.Tree -> Library.InstantiateTree.
 - Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
 - Removed the abstract Library class.
 - Changed generated library class:
	- Trees -> TreeType.
	- Actions -> ActionType.
	- Decorators -> DecoratorType.
	- Tree InstantiateTree (int, IAgent) -> static Tree InstantiateTree (TreeType, IAgent)
	- int TreeID (Tree) -> static TreeType Type (Tree)
	- bool IsAction (int) -> static bool IsAction (int)
	- bool IsDecorator (int) -> static bool IsDecorator (int)
 - Upped editor performance.
 - New asset structure change with automatic import of Behave 1.0 assets.
 - Changed action and decorator handlers. These are now the handlers mapped:
	- public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
	- public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
	- public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
	- public BehaveResult Init[Name][Action/Decorator] (Tree sender);
	- public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
	- public void Reset[Name][Action/Decorator] (Tree sender);
	- public BehaveResult [Name][Action/Decorator] {get; set;}
 - Added support for collection duplication.
 - Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
 - Debugger now renders active sub-trees as well.

1.0:
 - Lots o fixes for Unity 2.5 compatibility.
 - Closer editor integration with new UI.
	- Component bar.
	- Node inspection.
 - Runtime tree debugging.
 - Direct mapping of action and delegate handlers via reflection.
 - Kitty demo.

0.3b:
 - Various tweaks to the editor UI.
 - Optimised the compiler.
 - Fixed the following editor bugs from the bug list:
	- When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour.
	- When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch.
 - Implemented the following wishlist items:
	- Behaviour tree decorators.
	- Stand-alone edition of the Behave editor.
	- Behaviour tree debugging features.

0.2b:
 - Made the demo project a whole lot more interesting.
 - Implemented the editor wish list item: Ability to move trees between collections.
 - Various tweaks to the editor UI.
 - Fixed a ton of bugs in the compiler.
 - Fixed the following editor bugs from the bug list:
	- Not able to delete collections from library.
	- Not able to delete trees from library.
	- Not able to rename collections from library.
	- Not able to rename trees from library.
	- Missing "tree has been changed, save changes?" dialog.

0.1b:
 - Some documentation is available.
 - Compiler is now creating sensible output.
 - A simple test tree and script using it is provided with the demo.
 - Documentation is linked directly from the unity help menu.
 - Less spamming of the log with debug information.

Pre-release:
 - Magic happened. Behave was born.

Unity Hacks: Dual sticks

2013-08-04 00:00:00 +0200

This is my third post in what looks like is going to turn into a series, examining parts of the example project I provided for the Unity Hacks presentation – delivered at a couple of the Unite conferences this year.

You can find the project and a recording of the presentation in the videos section of this site.

DualControls

The DualControls interface has a very straight forward purpose: Provide a 2 × 2 axis input interface across platforms and compatible units. This is exposed via the DualControls.Left and DualControls.Right accessors – each returning a Vector2.

Supported out of the box is:

WASD + mouse.
Xbox360 controller (windows-only)
ps3 controller (OS X-only)
Shadowgun-style touch controls (left/right screen split)

However abstraction is relaxed enough that virtual sticks or alternative input like the leap motion could be added fairly easily (assuming you have a means of capturing that input data in the first place).

Controllers

So controllers are not exactly nicely wrapped up in the current version of Unity. Which ungodly hack did I have to apply to get them to play along with just working out of the box in an easily installable package? It is actually not so bad. However I had to concede to some compromises up front. Basically when it comes to joysticks and controllers, you generally have two complications: the hardware itself and the driver.

So? What is so bad about that? Well, in a perfect world you had one driver for each controller type or at least all the drivers for the same hardware would map the buttons and axes in the same way, right?

Enter: This world. For every controller you always have at least two drivers set up differently: One for OS X and one for Windows (the Linux one often being based on the Windows one as I understand it). Why would anyone be content with just two drivers though? There exists a good number of different packages and open source solutions, vendor and OS provided drivers for the different controllers.

The way these are differentiated in the Unity runtime is via the joystick name string – as accessible via Input.GetJoystickNames.

This is what DualControls checks for in its Update handler. If a new joystick is found connected, it runs the name by the controller wiring and activates the appropriate controller (optionally if accepted by a callback).

Per default I have compromised and only provided wiring for the Xbox360 controller on Windows and the ps3 controller on OS X. This particular configuration stems from the fact that those OS’es ship with a pre-installed default driver for those controllers.

Microsoft clearly should support their own hardware and I’m assuming that Apple just supports the ps3 controller because it’s hardware from a direct Microsoft competitor.

However, again, the abstraction is loose enough that if you want to, you should be able to add support for more controllers fairly easily. See the end of the Controllers.cs script for that.

Oh, but I almost forgot the hack: As I am using the standard Unity Input API for this, the input manager needs configuring, right? So with no API for it, how do you go about doing that for a package?

You use the AssetDatabase API to load ProjectSettings/InputManager.asset and then the ScriptableObject API to modify it.

I hope you find this useful. For more details, these are the Unity Hacks scripts related to this post:

Unity Hacks: Cameras

2013-07-28 00:00:00 +0200

In my effort to pick apart the “Unity Hacks” project as made available, along with a recording of the presentation, in the videos section, I now focus on the camera system.

Overview

Like the other new components I was preparing for the new standard assets, a key part of this setup is modularity and versatility. This is why I from the start chose to have camera handling values maintained via the transform tree – as opposed to maintaining internal values to overwrite the transform values when updated.

This way, not only can camera logic be broken down into several components which can be optional or replaced, but co-operation between the camera system, animations and any other systems which could apply relative transformation, is much easier.

As this approach would be placing a certain requirement on the transform tree structure surrounding the camera in any case, I opted to go for greatest amount of possible detail vs. smallest impact. The structure therefore requires a three layers deep transform tree.

The root of the tree is designated the horizontal hinge. It takes care of movement in all three dimensions as well as rotation on the horizontal plane. The immediate child of this transform is referred to as the vertical hinge. This transform is expected to not move and will have its position reset every frame to enforce this. In stead, the vertical hinge is only responsible for rotation on the vertical plane.

The final transform, the child of the vertical hinge, is expected to not rotate and only move on its relative z-axis. This effectively makes it the zoom component of the rig. The GameObject of this transform is the one holding the camera component.

DualHingeCamera

Maintaining and abstracting this setup is the DualHingeCamera component. With reference to the different transforms of the rig, this component maintains the setup by apply three targets: targetOffset, targetHorizontalRotation and targetVerticalRotation. These are set by controller scripts and applied via constrained speed and offset variables.

Vertical rotation is clamped and damped by the verticalSpan animation curve variable. As explained in the presentation, the time value of the most extreme animation keys specify the vertical angles (relative to a vector pointing backwards from the rig root) at which vertical rotation is clamped.

The height of the curve at any point specifies the scale of the update speed – as the camera moves through that angle and further towards the end of the half of the curve it is on. As in: If the angle is above the middle of the vertical span and the camera is moving further up, speed is scaled according to the curve, but if it is moving down then no scale is applied. The inverse if of-course true as well. The effect, assuming the curve is not flat, is a smooth limit rather than a hard clamp.

Control

The base for any of the example camera behaviours supplied with the project is the CameraBehaviour component. This supplies wrapping of access to the DualHingeCamera, as well as a bit of default handling – such as automatically updating the camera activity tracking when the camera moves. It also offers up the MoveCamera method as a common interface for input scripts to apply movement instructions.

One of the most simple examples of a camera behaviour is the OrbitCamera. This camera simply takes the movement instructions (a Vector2) and apply them to the target horizontal and vertical rotation. The result is the familiar behaviour of being able to rotate around a subject, while rotating up and down within the clamped span.

There are several more camera behaviours in the project (which you should take a look at) and they are demonstrated in an example scene as well as within the presentation. However as a last example, I want to point out the TravelCamera component. Unlike the others, this does not inherit from CameraBehaviour – nor does it directly affect its rotation or position. In stead, it holds a simple piece of logic which enables and disables other behaviours, based on input activity. The result should be a behaviour somewhere between that seen in Journey and that of the Assassins Creed games.

I tried to keep this post short, but I hope you still find this useful and decide to build on the system. In any case, here are direct links to the resources covered in the post:

Unity Hacks: Touch gestures

2013-07-19 00:00:00 +0200

So earlier this month I could finally push the Unity Hacks example code and slide show project live – after one of the videos of the presentation was pushed live.

The project is a pretty big treasure trove of handy scripts though and I didn’t like just tossing it out there and let people pick it apart on their own(feel free to go excavating if you learn better that way though). Therefore I plan for the next couple of posts here to cover various bits and bops from that project.

Note that a bunch of these scripts – for instance the one I cover today – was at the time I was still at Unity Technologies slated for the new Standard Assets shipped with Unity. Since I left, I obviously can’t say if or when these are shipped and in which form. What’s in the Unity Hacks project is pretty much the last iteration I did on them before leaving.

TouchGestures.cs

The purpose of this component is to facilitate easy handling of common gestures on touch enabled devices. With one instance of the component placed in a scene, you can specify which gestures to track, some key measuring caps with sensible defaults and a list of MonoBehaviours interested in receiving notification when a gesture has been detected.

An example of how to handle gesture tracking event can be found in this particular snippet from the presentation Control.cs script from Unity Hacks:

This handler responds to single swipes, checking for strictly left or right swipes, handling them by progressing to the next slide/build step or jumping to the previous slide.

Great, so what do the different configuration values mean? First, let’s take a look at the tracking clamps:

maxDuration: If a tracked touch remains active for longer than this time, it is no longer considered as part of a gesture. This avoids misinterpreting drags or virtual joysticks.
min[Pinch/Swipe]ScreenTravel: How much of the normalized screen size should a pinch or a swipe travel before it is considered valid? This avoids misinterpreting taps as mini pinches or swipes.
maxTapScreenTravel: What is the maximum normalized screen movement a tap gesture can have before it is no longer considered a tap?
maxTapDuration: For how long can a tracked touch be live before it is no longer considered a tap?

The last elements are somewhat less finicky and tweak happy, though the tracking clamps should have sensible default values:

receivers: The list of MonoBehaviours interested in receiving a callback when a gesture has been identified.
trackingMask: This is a bitmask identifying which gestures you are interested in tracking. If you only need to deal with swipes, there is no need to spend time tracking any other gestures. Note that in order for this field to be set correctly, it is important that the custom inspector for the TouchGestures component is used.
trackMultiple: Should the gesture tracker allow multiple gestures to occur at the same time? Like a pinch and a swipe in different ends of the screen.

And that is about it! You should have what you need to start using the TouchGestures component. Hopefully you will find it useful.

OnRenderTextureGUI

2013-07-17 00:00:00 +0200

Have you ever wanted to apply a full-screen effect to your GUI without having to completely restructuring the way you set up your OnGUI structure? Or how about rendering text and GUI controls onto in-scene virtual screens and objects? Yea me too.

So a couple of years ago I did a friday project investigating the possibility of a setup like this. What I wanted was a Doom 3 – style in-game numpad, responding to mouse clicks. Unfortunately I couldn’t get there 100% and in a nice and straight-forward way, so I abandoned it with no further time spent.

The specific problem was that while I could get my GUI to render to the object just fine, the GUI system had no way of injecting events or modifying existing ones. This meant that if I wanted GUI to respond to events, I would have to bypass the GUI event system and effectively rewrite the basic GUI controls. That failed my “nice and straight-forward” requirement.

However a while later, I came across a similar need: I had a project where the screen was warped slightly fish-eye, to give an impression of an old-school CRT display. It looked great, except the GUI was just rendered on top of everything – as per usual – with no warping. Since the GUI was non-interactive, there was no down-side to using the approach I had come up with before to include the GUI in the full-screen effect rendering.

It was a snap to apply, I had no required changes to my general OnGUI structure and the result looked great. This setup also came in handy when I was working with the Oculus Rift – rendering the GUI on a plane, rendered always on top, in front of the Oculus cameras.

So what is the idea then? Well it is quite straight forward: OnGUI is invoked multiple times each frame (once per event) – at least twice – unless layouting has been disabled on the MonoBehaviour. The last event of the frame is the repaint event. In this, all resolved controls render to the active context. Which fortunately can be set by render textures.

The trick therefore becomes:

Remember that this is not immediately useful if you need interactive GUI as this would require work to handle input gathered from the regular UnityEngine.Input API. Nonetheless it will give you for instance a scrolling screen of text on an in-game monitor.

I hope you find it useful!

Unite 13 video "Unity Hacks" available

2013-07-05 00:00:00 +0200

The “Unity Hacks” presentation, containing a good chunk of practical tips & tricks and example code, I did for Unite 13 Korea, Japan, China and Nordic is now available as video and presentation/examples download. The specific video recording is the one from Unite Japan.

Find link to video, presentation and examples in the videos section.

The implicit local network interface

2013-06-07 00:00:00 +0200

I foolishly promised I would resume my posting of tech stuff on this blog, so I suppose I better own up to that.

Story time

You are playing some amazingly addictive game on your iOS device when commuting home. Let’s say it’s a Mario clone.

As you arrive home, you want more of this gaming goodness. So you switch on your television and use AirPlay to continue the game on your TV, controls on your iOS device, via your Apple TV or other AirServer hosting, TV connected, device.

Now your good friend Bob comes by (you forgot to lock the door, so he walks straight in). Obviously this game is too good to put down, so in stead you instruct Bob to buy a copy of it. Bob pulls out his android phone, jumps on your wifi, downloads the game and starts playing.

At one point in Bobs game he sees this funky spinning portal in the level and opts to tap it. And poof! Bobs character is sucked into your game on the TV.

Unfortunately Bob is a terrible player of this game and ruins your score, but it was pretty cool to try this game in multiplayer mode.

Do want!

The above scenario may sound complex to set up, but like so many other cases, it is just a nice combination of simpler bits. So let’s look into how we enable something like this in our (Unity based) game.

First up, AirPlay support was recently added to Unity and I posted a gist to help people get started with it.

Secondly, we need to host a network game pretty much all the time, so that others may join any ongoing session at any time. Of-course you might want to provide an opt-in/out setting for networked play in your game. Just remember that we are only enabling this feature for local network play – not internet play like Journey did it.

For information on how to easily set up this network game, see the talk I did at Unite 12 in Amsterdam: “Unity, Network Code, and You” – the example provided for the built-in networking is quite relevant to the above example. You can find the talk linked from the video section of this site.

So with those parts in place, we just need a bit of glue – namely the broadcasting of games on your local network. This gist deals with just that:

if (m_BroadcastTimer == null) // Setup broadcast of hosting service { m_BroadcastSocket = new Socket (AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); try { IPAddress broadcastGroup = IPAddress.Parse (kBroadcastGroup); m_BroadcastSocket.SetSocketOption ( SocketOptionLevel.IP, SocketOptionName.AddMembership, new MulticastOption (broadcastGroup) ); m_BroadcastSocket.SetSocketOption ( SocketOptionLevel.IP, SocketOptionName.MulticastTimeToLive, 1 ); m_BroadcastSocket.Connect (new IPEndPoint (broadcastGroup, kBroadcastPort)); } catch (Exception e) { Debug.LogError (string.Format ( "Exception when attempting to set up service broadcast ({0}:{1}): {2}", kBroadcastGroup, kBroadcastPort, e )); return false; } m_BroadcastTimer = new Timer (kBroadcastDelay); m_BroadcastTimer.Elapsed += new ElapsedEventHandler ( (object s, ElapsedEventArgs e) => { m_BroadcastSocket.Send (GetBroadcastBytes ()); } ); m_BroadcastTimer.Enabled = true; } return true; // …

byte[] GetBroadcastBytes () { /* Return byte array containing IP and port of our host socket plus meta data such as current level and perhaps location (for portal placement) */ }

Let’s go over the interface for this gist:

kBroadcastGroup and kBroadcastPort are effectively shared keys we use to facilitate broadcasting communication between game instances. Broadcasting happens by way of multi-casting – an IP protocol feature allowing peers to send one package to multiple unidentified receivers. This is why our shared keys are in the form of an IP address and a port, though their value is completely arbitrary – all that matters is that both broadcaster and receiver use the same keys.

m_BroadcastTimer and kBroadcastDelay control how often m_BroadcastSocket will send out the broadcast message generated by GetBroadcastBytes.

This covers the transmission part of the broadcast functionality. The following gist deals with receiving the broadcast message:

if (m_SeekerSocket == null) { m_SeekerSocket = new Socket (AddressFamily.InterNetwork, SocketType.Dgram, ProtocolType.Udp); try { m_SeekerSocket.Bind (new IPEndPoint (IPAddress.Any, kBroadcastPort)); IPAddress broadcastGroup = IPAddress.Parse (kBroadcastGroup); m_SeekerSocket.SetSocketOption ( SocketOptionLevel.IP, SocketOptionName.AddMembership, new MulticastOption (broadcastGroup, IPAddress.Any) ); ReadBroadcasts (); } catch (Exception e) { Debug.LogError (string.Format ( "Exception when attempting to set up service listener ({0}:{1}): {2}", kBroadcastGroup, kBroadcastPort, e )); m_SeekerSocket.Dispose (); } } // ... void ReadBroadcasts () { /* Now set up periodic or event-driven reading from m_SeekerSocket, parsing broadcast packages containing IP, port and meta data of locally available games */ }

Like with the broadcaster, kBroadcastGroup and kBroadcastPort are used with the same values to make sure we are listening on the same multi-cast setup as the broadcaster.

m_SeekerSocket is the socket on which broadcasts will be received – just like you would on any other reception socket.

And that is all there is to it. I hope you found it useful.

Talks and progress

2013-05-21 00:00:00 +0200

Recently I have been posting less hacks, tips and tricks than I wanted to and I fully intend to rectify this. However, first let me provide a brief overview of what I have in stead been squandering my time on.

2013 started off with lots of still-internal Unity work which I hope will be publicly available very soon. Shortly after that I was off to a very busy GDC with a very fancy booth sandwiched between Sony and Nintendo (very fitting given our announcements of partnering with both to support their new platforms).

Beforehand, I had been playing around with the Oculus Rift devkits we had received in the Unity Copenhagen office and at GDC a guy from Road To VR caught me for an interview about this. If you are interested in Unity and Oculus Rift, you can find the interview linked from the video section of this site.

Following GDC I had a week at home to reset my time-zone orientation again, before heading to this years Unite Asia tour (re-branded from last years Unity Asia Bootcamp). So that week obviously went completely into talk prep.

Unfortunately the talk recordings are not yet available, but as soon as they are, I will make sure to link them from the video section, where you can also find recordings and example source from last years Unity Asia Bootcamp.

After the two weeks blast through Asia, I had taken three weeks of vacation to reset an at this point quite messed up time-zone orientation. While I did spend some time relaxing, however I of-course had a hard time not using such a great opportunity to make some headway on Behave 2.

Remaining tasks are mainly polish items and one fix for iOS AOT compilation – specifically I have moved serialization to use ProtoBuf-net for better performance and flexibility, however this library requires slightly different implementation for AOT compatibility than regular JIT platforms.

I hope to get this wrapped up and shipped very soon, however right now I am sitting on the train to Malmö – headed to the Unite Nordic conference. Tomorrow at the conference (May 22nd) I am scheduled to give two talks – “Unity Hacks” at 10:00 and “Cross-platform Considerations” at 14:30.

“Unity Hacks” is a repeat from Unite Asia, so if you don’t want to wait for the videos on that one, tomorrow is your chance for some great Unity hackery. For the complete conference schedule, see the Unite Nordic website.

Finally, after much consideration I decided to end my time at Unity Technologies. It has been great fun, but now seems the right time to get out and stretch my legs a bit. I do so by starting contracting again and if you’re interested in working together, please use the form I have provided for that purpose.

Or if you are at Unite Nordic or Nordic Game which follows right after, feel free to give me a poke there.

Until next time!

Five years of Unity expertise looking for contracts

2013-05-14 00:00:00 +0200

On the 28th of June, after four great years at Unity Technologies, I part ways with my friends to go explore for a while – doing consulting / contract work.

I have had a great time and seen absolutely crazy growth and things while at Unity. I definitely am leaving with a nice big bag of great memories. However I feel the need to stretch my legs a bit, so off I go.

So I am available for contracts from July 1st, offering up among other things, my five years of Unity expertise. For more details on the things that I do there is this site and my LinkedIn profile.

And, well, that’s pretty much it. Want to play? Please use the handy contact form I set up: Handy contact form.

Automagic Unity Android Java gadget OF DOOM!

2012-12-22 00:00:00 +0100

Ok maybe not that dramatic, but pretty handy if you’re working with Unity Android and doing some Java plugin work.

I hadn’t really touched Unity Android specific code since setting up automatic testing of it, so a few months back I wanted to remedy that by diving in head-first with an obvious not-hello-world sort of project.

For christmas of 2011, my awesome parents had bought me a IOIO board¹. I wanted to push some more boundaries of mine and do some hacking which couldn’t all be contained in an email attachment and the IOIO seemed a great start for that.

In short, the IOIO board is a small, inexpensive IO board with a USB interface and Android drivers – allowing you to connect your Android phone to it and control its 48 IO ports from software running on that phone.

Obviously I had to write that software as a Unity project and I hope I’ll get some more time to polish up the last bits of the soft- and hardware for it soonish and tell you some more about it.

Anywho, that’s enough background. Long story short, I obviously started out (after consulting the Unity documentation on how to work with the Java interface with Unity Android which I would need to access the IOIO driver) by doing some editor scripting to reduce my iteration time on the Java I needed. Wisely I predicted that my Java would be so terribly rusty that I would need a significant number of iterations.

Basically what I wanted was to get rid of the multiple steps needed for compiling, signing and assembling a Java plugin. Initially I just hacked together a perl script to reduce those steps to one line of shell execution, but that still meant more context switching than I wanted.

So I leveled up the hack by having a Unity asset post processor automatically execute the perl script whenever a Java file got imported in the plugins directory – re-routing any output from it to the Unity console.

That was really awesome. I would make a change in my Java, save it, switch to Unity and see all my horrible compiler errors right there in the console. And as this was my only Android project, I was quite happy with my hack – proceeding to kill my compiler errors and build my IOIO project.

Some friends had been poking me about cleaning up and generalising the hack a bit more and luck would have it that in my christmas vacation I spent a lot of time being sick. So I used some time here and there to clean up the Unity Android plugin builder and yesterday I pushed it to github – without any project specific bits, without perl and somewhat more user friendly.

Check it out and let me know what you think. If anything is broken or you’d like to request a change or addition, please use the github issues feature:

The JavaPluginBuilder repository on github

¹ The IOIO board

Invading Planet from your couch

2012-10-03 00:00:00 +0200

So yesterday was Tuesday which would normally mean I head to the local hackerspace and play around with my RC car and IOIO board. However that plan was completely shot down by girlfriend homework leading to required baby juggling. Which is always fun.

Obviously I did not let that deter me from getting some hacking done anyway, so I picked up another project I’d had on my TODO for a while.

You see I quite like my home entertainment setup. So much that aside from music, reading and the occasional iOS game, I only consume entertainment from my couch.

Photo shows Star Craft II running in order to appease the SC2 gang at work which is not at all impressed with the amount of hours I manage to spend training with them. I tend to play more Alpha Centauri and Galactic Civilizations II ;)

That includes the occasional gaming on my mini which I mostly use for TV and videos through Plex¹, so launching a game means hiding or quitting Plex, finding the game in whatever launcher, running it and then reversing when done.

Now, I’m lazy and I miss a feature of Plex 8 which allowed you to launch apps from within Plex – right from your apple remote. So my hacking session last evening was creating a small Plex plugin which brings that feature back – as I have been unable to find a pre-existing solution from someone else.

And it works just lovely. I now only need to select AppTV from my Plex main menu, select Alpha Centauri, get out my bluetooth mouse and keyboard and get gaming.

And you can too! Go find the AppTV project on github and have some fun :)

Oh and if you add something cool, pull requests would be awesome.

¹ Plex

Mountain Lion and laggy bluetooth and duct-tape

2012-09-28 00:00:00 +0200

If you, like me, run a bluetooth keyboard and mouse on your Mountain Lion machine, you might have noticed recent occasional slow-downs in the response time from those devices.

A bit of googling told me that was not an uncommon problem and that apparently it happens mostly after resuming the OS after sleep. Also the solution appears to be restarting the BT radio.

So until apple addresses this, I’ve written myself a little utility apple script for turning the radio off and back on again. It’s based on blueutil which is available with source if you worry about malware and simply turns off the radio for five seconds before turning it back on.

I hope you find it useful.

do shell script "sudo /usr/local/bin/blueutil off" with administrator privileges delay 5 do shell script "sudo /usr/local/bin/blueutil on" with administrator privileges

Unite 12 video and new videos section available

2012-09-23 00:00:00 +0200

While I was away at gameAIconf 12 in Vienna, the recording of my networking talk at this years Unite conference was made available.

Rather than spreading more sporatic linking in various blog posts, I created a videos page collecting up talks, interviews and documentation videos. I’m hoping it will serve as a good addition to the blog and my gists.

The new section can be found over at /videos

Asia Bootcamp videos now available

2012-08-28 00:00:00 +0200

OHAI!

Good news everyone! Having just gotten back from Unite 12, I’ve just been informed that the videos from the Asia Bootcamp earlier this year are now available for public consumption!

Here are the two talks I did on the tour (recordings from the Tokyo event):

Note that example projects and slides are linked just below the videos.

At this yeas Unite I gave the talk “Unity, Network Code, and You”, which was also recorded. I’ll make the recordings and example projects available for that as soon as everything is cut and online.

Path is now MIT licensed

2012-05-17 00:00:00 +0200

Hey guys. Obviously I’ve been pretty busy and since I’d like to spend the spare time coding time I have on Behave, I have just made the Path repository publicly available with an MIT license attached.

https://github.com/AngryAnt/Path

Note that I will be monitoring and taking in pull requests as well as compiling builds for releasing into the asset store (obviously as a free package). Let’s make this project as awesome as can be :)

Issue tracking and wiki development (I would appreciate collaborators on that as well) is still happening on https://github.com/AngryAnt/Path-release.

Happy hacking!

Unity forum thread.

Behave 1.4 released

2011-11-30 00:00:00 +0100

So obviously I ended up not spending more time on that RPG thing… I did however work on some 3.5 stuff back at Unity, some upcoming demo stuff and baby Lili was born.

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:

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.

So I've been a bit busy lately

2011-10-09 00:00:00 +0200

Little under half a year later and I’m still here. Things have been rather hectic since my last update. In Copenhagen we conquered more office space and my team moved in there. I made some demos (Third Person MMO Controller and Astro Dude), went to a conference, worked on a Unity release and pitched in to realize another killer conference.

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 increasingly turned 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!

Behave 1.3 released

2011-04-28 00:00:00 +0200

After quite a long break (including shifting around at utech, doing a Path release etc.), Behave is finally getting another update!

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:

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.

IGDA Unity SIG slides

2011-04-23 00:00:00 +0200

OHAI! Sorry about the delay – things have been a bit hectic around here. Per request, I’m making available exports of three of my slideshows from the recent IGDA Unity SIGs. I hope you’ll find them useful:

Second Unity IGDA SIG this evening: Scene construction and AI

2011-03-17 00:00:00 +0100

OHAI

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/

First IGDA Unity SIG this evening

2011-03-10 00:00:00 +0100

Quick announcement for anyone in or around the CPH area: I’m doing the first of six IGDA Unity SIGs (Special Interest Groups) this evening, with Joe Robins.

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/

Alternative licensing available

2011-03-03 00:00:00 +0100

After having been poked on the issue for a while now, I’m finally offering the option of requesting alternative licensing on Path and Behave.

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 download page.

Pathfinding in two lines

2011-02-15 00:00:00 +0100

I just updated the Path documentation with a short tutorial describing the simplest possible interface between your code and the Path runtime: “Pathfinding in two lines”.

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.

Path 2 released

2011-02-15 00:00:00 +0100

That’s right, Path is back in business – easier to use and more powerful than ever before! Version 2 is now available for download on the Unity asset store. Find a link to it in the download section – along with an example seeker script.

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.

Assembling and assimilating

2011-02-02 00:00:00 +0100

So this post has been delayed for quite a while… One question I got from many sources after my Advanced Editor Scripting talk with Adam Mechtley at Unite ’10 was “so how did you do that assembly building thing?”.

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:

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:

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:

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:

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.

Path 2 intro screencast

2011-01-29 00:00:00 +0100

As promised – a quick screencast of how to set up and use the Path 2 beta:

Path 2.0b1 quick intro

Path 2 beta release for GGJ

2011-01-29 00:00:00 +0100

With the Global Game Jam underway, I figured I would do an early beta release of Path 2. While I’m home with the flu – not able to participate in the Nordic Game Jam myself, I might as well do a bit of documentation on this thing and see if anyone finds it useful.

So documentation is on the way, but the Path2 package is available from the download section right now – as is the demo seeker script.

Path 2.0b1 feature set:

Throttle-able, co-routine driven seeker jobs for maximum performance.
Super simple Navigator.targetPosition interface.
Additional. Navigator.RequestPath interface.
Very straight forward and powerful editor interface.
Waypoint auto-connect and auto-scale empowering network authoring.
Custom weights based on the Unity built-in tags system.

No release schedule yet. Documentation as I can have it ready. Have fun!

I’m off to recording a screen cast of this.

AIgameDev master class video now online

2011-01-25 00:00:00 +0100

For those of you who didn’t have a chance to dial in live, but would still like to view the master class I did for AIgameDev last year: The video recording is now available here:

http://aigamedev.com/premium/masterclass/unity-behave/

Expanding beta

2011-01-09 00:00:00 +0100

Due to an increasing number of users, I’ve decided to expand the Behave beta testing group.

You will find more information on this and how to join in the “Beta” page of the “Behave” section on this site – http://angryant.com/behave/beta.

Behave AIgameDev master class public stream

2010-11-28 00:00:00 +0100

Hey guys – as promised, the live stream is now just about ready to go. The clock reads about ten minutes to impact, so join up!

The direct link is available in the following forum post: http://forum.unity3d.com/threads/68843-Behave-master-class-on-AIgameDev.

Behave master class on open AIgameDev stream tomorrow

2010-11-27 00:00:00 +0100

Hey guys. Just a quick reminder here. Tomorrow I am doing the AIgameDev masterclass on Behave (times below). Alex of AIgameDev has been so kind as to make the stream publicly available. That’s right – no membership or subscription needed. Notice though that access to the stored video will still require a paid subscription, so don’t miss out! Drop by tomorrow.

Keep tabs on this site, as I’ll be linking to a forum post with the stream link when it’s available.

Masterclass time: 22:00 European time, 16:00 East Coast, 13:00 Pacific time, 21:00 U.K.

Interview with AIGameDev

2010-10-29 00:00:00 +0200

November 28th I’m doing a live interview with Alex Champandard of AIGameDev.com on the subject of Behave. We will be going in depth into how the tool is used, a bit of the back end and do a demo.

Drop by. It’ll be fun!

Time: 22:00 European time, 16:00 East Coast, 13:00 Pacific time, 21:00 U.K.

http://aigamedev.com/premium/event/session-behave-unity/.

New video: From tree to code

2010-10-24 00:00:00 +0200

Hey guys!

This morning I recorded a video as a guide on how to go from installing Behave to using a behaviour tree in a script. I hope you guys find it useful.

From tree to code.

Issue tracking on github Behave release project

2010-10-23 00:00:00 +0200

Hey guys

Per request, I’ve now set up a means of reporting issues and feature requests. I decided to do this though the github issue tracking system. You’ll be able to track and report any issues or feature requests at this URL:

http://github.com/AngryAnt/Behave-release/issues.

Similarly, please use the Behave release thread on the Unity forums for questions and discussions on Behave:

http://forum.unity3d.com/threads/61849-AI-Behaviour-trees-in-Unity-Behave-1.1-released.

IT University Copenhagen Unity course completed

2010-10-22 00:00:00 +0200

Hey guys!

So that was the last of the five days of “Exploring with Unity” course at the Copenhagen IT University. Thanks for having us. It has been good fun.

Sorry about the broken link to the files from Thursday. This is now fixed, and the files from today’s lecture are available from this (verified) link:

Friday

IT University Copenhagen Unity course files Thursday

2010-10-21 00:00:00 +0200

Hey guys!

Attached to this post, you’ll find the projects and resources used on today’s lecture:

Thursday

CPH IT University Unity course files

2010-10-20 00:00:00 +0200

Hey guys.

For those of you not attending; Joe Robins and I are running a Unity course at the IT University of Copenhagen this week. Given the highly mixed crowd, the our lectures range from absolutely no Unity knowledge required to at least some understanding needed for full potential unlock.

During these lectures, we create projects for demoing the focus of the lecture. These are either pre-prepared or built on stage and often get modified based on requests from the audience.

So now that we are all on the same track: Attached to this post you should find three zip files of the content we have gone through in the classes so far. This is their state post responding to questions, so some of the stuff demoed earlier on might differ slightly.

Behave 1.2 released

2010-10-11 00:00:00 +0200

That’s right! I know it’s only been … uh … well less time than I usually take to get it together and push out a new version. But since I was a bit on a roll with the release of Behave 1.1 not too long ago, and given that a last minute bug has snuck into that release, I decided to push on.

So here we are – new version out in a jiffy. What’s new you say? This is what’s new:

Fixed release building.
Added the priority selector, introducing the API points:
- int IAgent.SelectTopPriority (Tree sender, params int[] IDs);
- enum BL[LibraryName].PriorityType { PriorityName, …, Unknown };
Added support for branch contexts, introducing the API points:
- enum BL[LibraryName].ContextType { ContextName, …, Unknown };
- int Tree.ActiveContext { get; }
Changed IAgent interface:
- Tick (bool init, Tree sender) → Tick (Tree sender, bool init)
Added “Select asset” button to the standard inspector.
Interface polish.

I’ll make sure to update the documentation to reflect the new API changes and yes, more is coming on that front.

And yes I will be releasing a new demo project. I just wanted to make it something different, and nice for you guys, y’know? So hang in there.

Video: Behave - starting from scratch

2010-09-29 00:00:00 +0200

I just finished uploading a new video for the Behave documentation section. It is a brief general introduction to the Behave authoring environment and shows you how to get up and running with Behave from a blank project.

Behave runtime documentation updated

2010-09-29 00:00:00 +0200

It is no secret that the Behave documentation has been in a quite bad state for a while. With this release I intend to correct that and as a starting point, I have moved the outdated documentation offline and replaced it with documentation of the Behave runtime. Rest assured that I will be adding documentation on the authoring environment as well.

Go check it out: http://angryant.com/behave/documentation.

Behave 1.1 released

2010-09-29 00:00:00 +0200

Hello reader. It’s been quite a while since my last conf… post.

Yea sorry about that. Busy, busy, but then again I suppose most had probably figured that one out. However, I have had a bit of time here and there over the last few months to polish away on Behave and keep it compatible with Unity 3 as it developed.

A lot of this keeping up to date work at times resulted in some good old fashion rewrites – like the entire asset handling and parts of the compiler. This is probably not very interesting to you, but it is quite so to me as it has allowed me to restructure internally in ways that make the system as a whole more flexible and ready for change and additions.

One of those additions which I did sneak in next to the polish and updating is a new debugger. The in-game debugger has been thrown out in favour of one living in your editor environment. YAY! No really, yay. You will like this and not just because I say so. Ah and as much requested this one actually dives into sub-trees, making it actually quite useful compared to its predecessor.

Oh and the compiler runs on Windows too now. And I also shaved off some cruft in the action/decorator handler syntax, making Ricardo extra happy.

I will be putting up some short documentation for Behave 1.1 shortly, but if you still haven’t decided to download yet, here is a short teaser on the new debugger: This text is a link to a movie file. Click it. It will be fun!

Enough blabbering though. The package is available in the download section and the changelog is right here:

Made compatible with Unity 3.0 – including ensuring that the 2.5-2.6.1 bug preventing compilation on Windows is fixed on the Unity side.
UI tweaks and polish.
Added the option to have return values of nodes be inverted.
Fixed compiler bug when facing sequence or selector with only one child node.
Renamed Library.Tree → Library.InstantiateTree.
Added Tree.Tick () and Tree.Reset () methods using the IAgent instance given at instantiation of the tree.
Removed the abstract Library class.
Changed generated library class:
- Trees → TreeType.
- Actions → ActionType.
- Decorators → DecoratorType.
- Tree InstantiateTree (int, IAgent) → static Tree InstantiateTree (TreeType, IAgent)
- int TreeID (Tree) → static TreeType Type (Tree)
- bool IsAction (int) → static bool IsAction (int)
- bool IsDecorator (int) → static bool IsDecorator (int)
Upped editor performance.
New asset structure change with automatic import of Behave 1.0 assets.
Changed action and decorator handlers. These are now the handlers mapped:
- public BehaveResult Init[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
- public BehaveResult Tick[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
- public void Reset[Name][Action/Decorator] (Tree sender, string stringParameter, float floatParameter, IAgent agent, object data);
- public BehaveResult Init[Name][Action/Decorator] (Tree sender);
- public BehaveResult Tick[Name][Action/Decorator] (Tree sender);
- public void Reset[Name][Action/Decorator] (Tree sender);
- public BehaveResult [Name][Action/Decorator] {get; set;}
Added support for collection duplication.
Moved debug rendering into the editor with its own dedicated debugger window, including actor listing.
Debugger now renders active sub-trees as well.

Oh and if you are upgrading a previous Behave install in a project, please see Readme.txt for details on snags you might hit and how to solve the whole thing in 4-5 steps.

Ah and one more thing: Behave 1.1 removes the “only for non-commercial work” clause from the license.

Have fun! And remember to tell me about all your awesome projects!

FAFF cleanup: Sketch

2010-03-19 00:00:00 +0100

As some of you might have read, at Unity we have a thing called FAFF – very much the same as Google and other IT businesses are doing. It generally lets you step out of the bit stream for a day and just, during work hours, go with whatever crazy idea(s) you’ve been throwing around.

Some of these ideas are pushed into the product later and others are just filed under “something to play with when bored” and “now I can stop wondering about that”. Sketch was a micro FAFF project I just remembered I had filed under “this was fun” and then forgot all about. Since then I’ve continued work on other projects and started new ones – in all likelihood I’ll not return to this project.

So I figured I’d push it to github and let you guys take it for a spin. If nothing else, it’s a nice demo of what you can do with Unity editor scripting.

The idea of Sketch is to have simple tools inside the Unity editor to modify meshes in your assets. My goal with the project was never to turn Unity into a mesh authoring environment, but rather to give people an extra tool for rapid prototyping.

So what’s in there now? The simplest I could think of: Triangle selection and movement.

Workflow:

Go to the GameObject → Create Other menu and click Sketch Cube.
With the cube selected, click a triangle and with the handle that appears, drag it around to modify the mesh.
GOTO 1.

Alternatively, you could drag in your own mesh from the Assets folder (make sure that it generates a mesh collider in its import settings) and attach the Sketch script to it.

NOTICE: Sketch modifies the imported asset. This means that:

If you modify a some of the basic geometry meshes (such as GameObject → Create Other → Cube), the changes will apply to all cubes until editor relaunch.
If the geometry you’re modifying is based on an imported 3D asset, reimporting it will mean you loose your changes.

Structure-wise, Sketch consists of two components: A MonoBehaviour (Sketch/Sketch.cs) and a custom inspector (Sketch/Editor/SketchEditor.cs). The purpose of the MonoBehaviour is merely to do some bookkeeping and provide utility functions (it will even destroy itself at runtime) while the custom inspector holds the logic for doing the modifications.

Woah. That’s a lot of talk. Here’s the repository – go nuts: http://github.com/AngryAnt/Sketch.

Building a menu of delegates and enums

2010-03-15 00:00:00 +0100

I like delegates. I also like enums. Furthermore, I happen to be part of a small group of people who actually enjoy the immediate mode GUI system in Unity. And I want you to like it too :)

So – menus. After having observed quite a few very funky approaches, in the IRC channel, to building main menu functionality and giving advice in there, I decided to sow together those ideas into a short example.

The main idea here is to be able to build and manage a menu system quickly and easily. This line adds a new submenu to the system – designated MyMenuState and implemented in the OnMyMenuGUI method:

Notice that since we’re using delegates, the GUI method needn’t be implemented in the same script and could even live on an entirely different GameObject. Why is this so clever (besides enums and delegates being cool)? Because managing and switching between menus set up like this is insanely easy. This is the central GUI method for the menu system:

And this is GUI code inside a menu GUI method for switching to a different submenu:

So there. Enough talk. Have some example code:

using UnityEngine; using System.Collections; using System.Collections.Generic; public class Menu : MonoBehaviour { delegate void OnGUIImplementation(); public enum MenuState {Main,Settings,Credits}; public struct Settings { public bool m_ThisSetting, m_ThatSetting, m_TheOtherSetting; }; static Vector2 m_StandardMenuSize = new Vector2 (200.0f, 300.0f); static string m_LogoURL = "http://download.unity3d.com/images/top-menu/mm_unity_icon.png"; static Texture2D m_Logo = null; private MenuState m_CurrentState = MenuState.Main; private Dictionary m_Menus; private Settings m_Settings; void Awake () { m_Menus = new Dictionary (); m_Menus [MenuState.Main] = OnMainMenuGUI; m_Menus [MenuState.Settings] = OnSettingsGUI; m_Menus [MenuState.Credits] = OnCreditsGUI; StartCoroutine (GetLogo ()); } IEnumerator GetLogo () { WWW www = new WWW (m_LogoURL); yield return www; if (www.error == null) { m_Logo = www.texture; } } public void OnGUI () { m_Menus [m_CurrentState] (); } static void BeginStandardMenu (string title) { GUILayout.BeginArea (new Rect ((Screen.width – m_StandardMenuSize.x) * 0.5f, (Screen.height – m_StandardMenuSize.y) * 0.5f, m_StandardMenuSize.x, m_StandardMenuSize.y)); GUILayout.BeginVertical (GUI.skin.GetStyle ("Box")); GUILayout.Label (title, GUI.skin.GetStyle ("Box")); } static void EndStandardMenu () { Color color; GUILayout.BeginHorizontal (); GUILayout.FlexibleSpace (); color = GUI.color; GUI.color = Color.grey; GUILayout.Label ("My game version 2.4X"); GUI.color = color; GUILayout.FlexibleSpace (); GUILayout.EndHorizontal (); GUILayout.EndVertical (); GUILayout.EndArea (); } void OnMainMenuGUI () { BeginStandardMenu ("Main menu"); if (m_Logo != null) { GUILayout.BeginHorizontal (); GUILayout.FlexibleSpace (); GUILayout.Label (m_Logo); GUILayout.FlexibleSpace (); GUILayout.EndHorizontal (); } if (GUILayout.Button ("New game")) { Application.LoadLevel ("Level one"); } m_CurrentState = GUILayout.Button ("Settings") ? MenuState.Settings : m_CurrentState; m_CurrentState = GUILayout.Button ("Credits") ? MenuState.Credits : m_CurrentState; GUILayout.FlexibleSpace (); EndStandardMenu (); } void OnSettingsGUI () { BeginStandardMenu ("Settings"); m_Settings.m_ThisSetting = GUILayout.Toggle (m_Settings.m_ThisSetting, "This setting"); m_Settings.m_ThatSetting = GUILayout.Toggle (m_Settings.m_ThatSetting, "That setting"); m_Settings.m_TheOtherSetting = GUILayout.Toggle (m_Settings.m_TheOtherSetting, "The other setting", GUI.skin.GetStyle ("Button")); GUILayout.FlexibleSpace (); m_CurrentState = GUILayout.Button ("Main menu") ? MenuState.Main : m_CurrentState; EndStandardMenu (); } void OnCreditsGUI () { BeginStandardMenu ("Credits"); GUILayout.Label ("This game was created by some of the most awesomestest people on the planet. Having failed in their mission to Pluto, they started making games, which – as you can see – resulted in much joy and success!"); GUILayout.Space (20.0f); GUILayout.BeginHorizontal (); GUILayout.FlexibleSpace (); GUILayout.Label ("The awesomestest people inc."); GUILayout.EndHorizontal ();

GUILayout.FlexibleSpace (); m_CurrentState = GUILayout.Button ("Main menu") ? MenuState.Main : m_CurrentState; EndStandardMenu (); } }

Example project: Menu.zip – built with Unity 2.6.1

Pick me! Pick me!

2010-03-10 00:00:00 +0100

Say you’re developing an RTS or maybe a connect-the-dots sort of game. What would be the easiest way to go about handling object selection? This is my suggested solution.

In the given example, I’m taking advantage of the object-mouse event handling that MonoBehaviours on GameObject with colliders on them give for free. You might be in a scenario where raycasting or otherwise resolving selection requests makes more sense, but the basic logic still applies. This example is merely intended to get your from start to goal as fast as possible.

First off, we need a selection manager class (cleverly named SelectionManager in my example). This is where we store selection state and via static accessors, we can get and modify the current selection. Seeing as this class is both public and all accessors are static, you can put its source anywhere. In my example I’ve simply put it right after the MonoBehaviour used for testing it.

SelectionManager

using UnityEngine; public class SelectionManager { private static GameObject s_ActiveSelection; public static GameObject ActiveSelection { get { return s_ActiveSelection; } set { s_ActiveSelection = value; } } public static void Select (GameObject gameObject, bool selectionValue) { if (selectionValue) { Select (gameObject); } else { Deselect (gameObject); } } public static void Select (GameObject gameObject) { ActiveSelection = gameObject; } public static void Deselect (GameObject gameObject) { if (ActiveSelection == gameObject) { ActiveSelection = null; } }

public static bool IsSelected (GameObject gameObject) { return ActiveSelection == gameObject; } }

And the promised MonoBehaviour using the SelectionManager class:

using UnityEngine; public class SelectableObject : MonoBehaviour { public Rect m_SelectionWindowRect = new Rect (10.0f, 10.0f, 300.0f, 100.0f); public void OnMouseDown () { SelectionManager.Select (gameObject, !SelectionManager.IsSelected (gameObject)); } public void OnDisable () { SelectionManager.Deselect (gameObject); } public void Update () { renderer.material.color = SelectionManager.IsSelected (gameObject) ? Color.green : Color.white; } public void OnGUI () { if (SelectionManager.IsSelected (gameObject)) { m_SelectionWindowRect = GUI.Window (GetInstanceID (), m_SelectionWindowRect, SelectionWindow, gameObject.name); } }

void SelectionWindow (int id) { GUILayout.Box ("I am the selection and my name is " + gameObject.name); GUI.DragWindow (); } }

And that is all there is to it. By popular demand, I’m now starting to provide pre-built projects with these tips and tricks posts. Download, unzip, open and play. Requires Unity 2.6.1: SelectableObject

Optimising coroutine yielding in C#

2010-01-14 00:00:00 +0100

When needing to yield a coroutine for a single frame in C#, most people – including myself usually go about it this way:

However, as Rodrigo recently brought to my attention, this approach ofcourse performs unneeded memory allocation, given that the zero needs boxing and unboxing before its passed to the coroutine system. Using null in stead saves you that work and allocation.

This might not seem like a lot at first glance, but if you make this a habit every time you need to yield for a frame, I guarantee you that you’ll see results in larger scenarios.

The more optimal way of yielding for a single frame in C#. Minor difference, but allocation saved – which is always awesome:

An interesting test could be to, on a larger co-routine heavy project, do a project-wide find and replace on “yield return 0;” and “yield return null;” back and forth and measuring the performance difference with the profiler (for non-pro users, maybe the performance gain is even measurable using external monitoring tools).

Downloading the hydra

2010-01-05 00:00:00 +0100

So I’ve seen some people asking how you would go about downloading executable code from an external location, reading it into memory and executing it in ones running application.

Now some readers might go “eh? why the heck would someone want to do that?”. Well first off, its cool™, but seeing as that is rarely an argument which convinces decision makers, here’s a few others:

Patching. The ability to modify the behaviour of your downloaded executable after distribution, without requiring re-download.
Highly dynamic online content. Say you’re building a virtual world or something. You might want to have the ability to add more complex behaviours to downloaded content – more than what a data-driven approach allows for.
Or how about expanding the capabilities of user generated content?

There. Those are my alibis and I’m sticking to them.

Now this example is quick and simple so as to not bloat the post too much. Regardless of your use, you’ll likely be wanting to add in for instance some cache functionality for real-world use.

Right. So this example contains three pieces of eight, uh, code:

The loader utility – responsible for downloading and making available the remote code.
The assembly – you know, the one we’re downloading.
An example handler. For easy re-use, I’ve designed this example to allow for easy re-use of the loader utility by externalising handling of the assemblies via messages. This example handler shows some techniques for accessing the data of loaded assemblies.

Using the example:

Download and save /Assets/WWWAssemblyLoader.cs, /Assets/NewBehaviourScript.cs and /MyAssembly.cs.
Download and install the mono runtime (or the .net equivalent on Windnows – not tested, but should work just fine).
Build the assembly from the terminal – using the build command supplied at the end of this post.
Upload the assembly to some host (save the URL for later).
Open up your Unity project.
Add the WWWAssemblyLoader and NewBehaviourScript scripts to a GameObject and set the URL property of the first to that of your uploaded assembly.
Press play.
Profit!

And now the codes!

/Assets/WWWAssemblyLoader.cs

using UnityEngine; using System.Collections; using System.Reflection; public class WWWAssemblyLoader : MonoBehaviour { public string m_AssemblyURL; private string m_ErrorString = ""; private WWW m_WWW; private bool m_Complete = true; public void Start () { if (m_AssemblyURL != "") { ReloadAssembly (m_AssemblyURL); } } public string AssemblyURL { get { return m_AssemblyURL; } set { if (m_AssemblyURL != value) { ReloadAssembly (value); } } } public float Progress { get { return m_Complete ? 1.0f : m_WWW.progress; } } public string Error { get { return m_ErrorString; } } public void ReloadAssembly (string url) { m_Complete = false; m_ErrorString = ""; m_AssemblyURL = url; m_WWW = new WWW (m_AssemblyURL); } public void Update () { if (!m_Complete) { if (m_WWW.error != null) { m_ErrorString = m_WWW.error; m_Complete = true; SendMessage ("OnAssemblyLoadFailed", m_AssemblyURL); } else if (m_WWW.isDone) { Assembly assembly = LoadAssembly (); m_Complete = true; if (assembly != null) { Debug.Log ("Done"); SendMessage ("OnAssemblyLoaded", new WWWAssembly (m_AssemblyURL, assembly)); } else { Debug.Log ("Failed"); SendMessage ("OnAssemblyLoadFailed", m_AssemblyURL); } } } } private Assembly LoadAssembly () { try { return Assembly.Load (m_WWW.bytes); } catch (System.Exception e) { m_ErrorString = e.ToString (); return null; } } } public class WWWAssembly { private string m_URL; private Assembly m_Assembly; public string URL { get { return m_URL; } } public Assembly Assembly { get { return m_Assembly; } }

public WWWAssembly (string url, Assembly assembly) { m_URL = url; m_Assembly = assembly; } }

/Assets/NewBehaviourScript.cs

using UnityEngine; using System.Collections; using System.Reflection; public class NewBehaviourScript : MonoBehaviour { private string m_MessageString = "Waiting for assembly"; void OnAssemblyLoaded (WWWAssembly loadedAssembly) { m_MessageString = "Assembly " + loadedAssembly.URL + "\n"; System.Type type = loadedAssembly.Assembly.GetType ("MyClass"); FieldInfo field = type.GetField ("myString"); m_MessageString += (field.GetValue (null) as string) + "\n"; object instance = loadedAssembly.Assembly.CreateInstance ("MyClass"); MethodInfo method = type.GetMethod ("LogMyString"); m_MessageString += "Return value: " + method.Invoke (instance, null).ToString (); } void OnAssemblyLoadFailed (string url) { m_MessageString = "Failed to load assembly at " + url; }

void OnGUI () { GUILayout.BeginArea (new Rect (0.0f, 0.0f, Screen.width, Screen.height)); GUILayout.FlexibleSpace (); GUILayout.BeginHorizontal (); GUILayout.FlexibleSpace (); GUILayout.Box (m_MessageString); GUILayout.FlexibleSpace (); GUILayout.EndHorizontal (); GUILayout.FlexibleSpace (); GUILayout.EndArea (); } }

/MyAssembly.cs

using UnityEngine; public class MyClass { public static string myString = "This is my string from my class in my assembly";

public int LogMyString () { Debug.Log (myString); return 2 + 2; } }

The assembly compile terminal command

New license of Path: GPL

2009-11-15 00:00:00 +0100

Since I started at Unity, I haven’t really had the time to do much updating (read: none) of my private projects. In sheer size, Path is the largest of those, so a while ago I realised that maintaining that project is simply not feasible.

By adding the GPL license option to the existing two license options (the show-my-logo license displayed on download from angryant.com and the option for a custom negotiated one), users are able to test and modify the source of Path directly – before deciding on one of the other licenses.

Also, although very messy (yes – very), the source could also serve as a good learning resource for Unity editor scripting.

The project repository is available on github .

CopyInspector

2009-11-04 00:00:00 +0100

Yea I know. It’s been a while. I do have two very good excuses though: 2.6 and Unite ‘09. If you enjoyed those then zip it and read on. If not, I’m really out of ammo and sorry for the delay.

At Unite, I attended the talk by John Grden of infrared5 on the special (free) Unity for flash users day. During this session he complained about wanting to be able to copy his runtime transform changes inside the IDE (he was copying by way of paper notes it seemed). I decided to take up the challenge when he continued with “… but someone is probably going to show me how to do that after this” and after his talk I handed him a custom inspector editor script for solving that specific problem.

Later at the conference I had some time to kill and did a rewrite to expand the script to be general for any component type. I didn’t have the time to hand John that version, but I suppose I’ll just email him a link to this post.

So anyway – lets talk implementation:

Add CopyInspector.cs to Assets/Editor.
Add CopyTransformInspector.cs to Assets/Editor.
For each other component to be made copy/paste-able:
- Add CopyYourComponentTypeInspector.cs to Assets/Editor.
- Rename it appropriately.
- Rename the class to match the file name.
- Change YourComponentType in “[CustomEditor (typeof (YourComponentType))]” to the type of component you wish to affect.

You’ll notice that CopyTransformInspector has some additional code to it. This is due to the fact that this inspector is rendered non-standard and the code provided just replicates that.

Not really sure why syntax highlighting is not kicking in… Will have a look at that later.

Codes!

CopyInspector.cs

using UnityEngine; using UnityEditor; using System.Collections; using System.Collections.Generic; using System.Reflection; public class CopyInspector : Editor { static System.Type m_OriginalType; static Dictionary object> m_Values; private List GetProperties (Component component) { List <string> ignoredProperties; List properties; properties = new List (); ignoredProperties = new List <string> (); foreach (PropertyInfo propertyInfo in typeof (Component).GetProperties ()) { ignoredProperties.Add (propertyInfo.Name); } foreach (PropertyInfo propertyInfo in component.GetType ().GetProperties ()) { if (ignoredProperties.Contains (propertyInfo.Name)) { continue; } properties.Add (propertyInfo); } return properties; } public override void OnInspectorGUI () { DrawDefaultInspector (); OnCopyInspectorGUI (); } public void OnCopyInspectorGUI () { bool enabled; List properties; Component component; component = target as Component; if (component == null) { return; } GUILayout.Space (10.0f); Color backgroundColor = GUI.backgroundColor; GUI.backgroundColor = new Color (0.8f, 0.8f, 0.8f); GUILayout.BeginVertical ("Toolbar"); GUI.backgroundColor = backgroundColor; GUILayout.BeginHorizontal (); GUILayout.Space (10.0f); GUILayout.Label ("Copied: " + (m_OriginalType != null ? m_OriginalType.Name : "Nothing"), "MiniLabel"); GUILayout.FlexibleSpace (); if (GUILayout.Button (new GUIContent ("Copy", "Copy component values"), "MiniLabel")) { m_OriginalType = target.GetType (); properties = GetProperties (component); m_Values = new Dictionary object> (); foreach (PropertyInfo property in properties) { m_Values [property] = property.GetValue (component, null); } } enabled = GUI.enabled; GUI.enabled = target.GetType () == m_OriginalType; GUILayout.Space (10.0f); if (GUILayout.Button (new GUIContent ("Paste", "Paste component values"), "MiniLabel")) { properties = GetProperties (component); foreach (PropertyInfo property in properties) { if (!property.CanWrite) { continue; } property.SetValue (component, m_Values [property], null); } } GUILayout.Space (10.0f); GUI.enabled = enabled; GUILayout.EndHorizontal (); GUILayout.EndVertical ();

GUILayout.Space (-2.0f); } }

CopyTransformInspector.cs

using UnityEngine; using UnityEditor; using System.Collections; [CustomEditor (typeof (Transform))] public class CopyTransformInspector : CopyInspector { public override void OnInspectorGUI () { Transform transform; Vector3 localPosition, localScale; Quaternion localRotation; transform = target as Transform; localPosition = EditorGUILayout.Vector3Field ("Position", transform.localPosition); localRotation = Quaternion.Euler (EditorGUILayout.Vector3Field ("Rotation", transform.localRotation.eulerAngles)); localScale = EditorGUILayout.Vector3Field ("Scale", transform.localScale); if (GUI.changed) { transform.localPosition = localPosition; transform.localRotation = localRotation; transform.localScale = localScale; }

OnCopyInspectorGUI (); } }

CopyYourComponentTypeInspector.cs

Magnetic

2009-10-04 00:00:00 +0200

You know how Little Big Planet, Kingdom Hearts and similar have various pickups move towards your character when you get up close? Yea I also find that’s a nice bit of polish.

One way of getting that up and running in Unity is via the code below. Setup:

Add all objects you want to get attracted to the player to a special layer.
Attach the script below to your player.
Set the layer mask on the component to include the layer from step one.
Tweak, play, repeat.

using UnityEngine; using System.Collections; public class Magnetic : MonoBehaviour { public LayerMask m_MagneticLayers; public Vector3 m_Position; public float m_Radius; public float m_Force; void FixedUpdate () { Collider[] colliders; Rigidbody rigidbody; colliders = Physics.OverlapSphere (transform.position + m_Position, m_Radius, m_MagneticLayers); foreach (Collider collider in colliders) { rigidbody = (Rigidbody) collider.gameObject.GetComponent (typeof (Rigidbody)); if (rigidbody == null) { continue; } rigidbody.AddExplosionForce (m_Force * -1, transform.position + m_Position, m_Radius); } } void OnDrawGizmosSelected () { Gizmos.color = Color.red; Gizmos.DrawWireSphere (transform.position + m_Position, m_Radius); } }

GUI drag-drop

2009-09-18 00:00:00 +0200

A lot of people have been asking for tips on how to implement drag-drop functionality in Unity GUI scripting, so I decided to put together a reusable script for the purpose.

Basically the solution requires that your data class derives from GUIDraggableObject and at some point in its OnGUI method call Drag( Rect ) – just like GUI.Window handles dragging.

Right. Codez. First off the GUIDraggableObject.cs file:

using UnityEngine; using System.Collections; public class GUIDraggableObject { protected Vector2 m_Position; private Vector2 m_DragStart; private bool m_Dragging; public GUIDraggableObject (Vector2 position) { m_Position = position; } public bool Dragging { get { return m_Dragging; } } public Vector2 Position { get { return m_Position; } set { m_Position = value; } } public void Drag (Rect draggingRect) { if (Event.current.type == EventType.MouseUp) { m_Dragging = false; } else if (Event.current.type == EventType.MouseDown && draggingRect.Contains (Event.current.mousePosition)) { m_Dragging = true; m_DragStart = Event.current.mousePosition - m_Position; Event.current.Use(); } if (m_Dragging) { m_Position = Event.current.mousePosition - m_DragStart; } } }

An example data class inheriting from GUIDraggableObject – DataObject.cs:

using UnityEngine; using System.Collections; public class DataObject : GUIDraggableObject // This class just has the capability of being dragged in GUI - it could be any type of generic data class { private string m_Name; private int m_Value; public DataObject (string name, int value, Vector2 position) : base (position) { m_Name = name; m_Value = value; } public void OnGUI () { Rect drawRect = new Rect (m_Position.x, m_Position.y, 100.0f, 100.0f), dragRect; GUILayout.BeginArea (drawRect, GUI.skin.GetStyle ("Box")); GUILayout.Label (m_Name, GUI.skin.GetStyle ("Box"), GUILayout.ExpandWidth (true)); dragRect = GUILayoutUtility.GetLastRect (); dragRect = new Rect (dragRect.x + m_Position.x, dragRect.y + m_Position.y, dragRect.width, dragRect.height); if (Dragging) { GUILayout.Label ("Wooo..."); } else if (GUILayout.Button ("Yes!")) { Debug.Log ("Yes. It is " + m_Value + "!"); } GUILayout.EndArea (); Drag (dragRect); } }

And finally, this script demonstrates how you could have your data manager class use Unity GUI for data visualisation with drag-drop enabled – MyMonoBehaviour.cs:

using UnityEngine; using System.Collections; using System.Collections.Generic; public class MyMonoBehaviour : MonoBehaviour { private List< DataObject > m_Data = new List< DataObject > (); private Rect dropTargetRect = new Rect (10.0f, 10.0f, 30.0f, 30.0f); void Awake () { m_Data.Add (new DataObject ("One", 1, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Two", 2, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Three", 3, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Four", 4, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Five", 5, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); } public void OnGUI () { DataObject toFront, dropDead; Color color; GUI.Box(dropTargetRect, "Die"); toFront = dropDead = null; foreach (DataObject data in m_Data) { color = GUI.color; if (data.Dragging) { GUI.color = dropTargetRect.Contains (Event.current.mousePosition) ? Color.red : color; } data.OnGUI (); GUI.color = color; if (data.Dragging) { if (m_Data.IndexOf (data) != m_Data.Count - 1) { toFront = data; } } } if (toFront != null) // Move an object to front if needed { m_Data.Remove (toFront); m_Data.Add (toFront); } } }

Ah yea and an example of how you could do the same in an editor window – MyEditorWindow.cs:

using UnityEngine; using UnityEditor; using System.Collections; using System.Collections.Generic; public class MyEditorWindow : EditorWindow { private List< DataObject > m_Data = new List< DataObject > (); private bool doRepaint = false; private Rect dropTargetRect = new Rect (10.0f, 10.0f, 30.0f, 30.0f); public MyEditorWindow () { m_Data.Add (new DataObject ("One", 1, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Two", 2, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Three", 3, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Four", 4, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); m_Data.Add (new DataObject ("Five", 5, new Vector2 (20.0f * Random.Range (1.0f, 10.0f), 20.0f * Random.Range (1.0f, 10.0f)))); } [MenuItem ("Window/MyEditorWindow")] public static void Launch () { GetWindow (typeof (MyEditorWindow)).Show (); } public void Update () { if (doRepaint) { Repaint (); } } public void OnGUI () { DataObject toFront, dropDead; bool previousState, flipRepaint; Color color; GUI.Box(dropTargetRect, "Die"); toFront = dropDead = null; doRepaint = false; flipRepaint = false; foreach (DataObject data in m_Data) { previousState = data.Dragging; color = GUI.color; if (previousState) { GUI.color = dropTargetRect.Contains (Event.current.mousePosition) ? Color.red : color; } data.OnGUI (); GUI.color = color; if (data.Dragging) { doRepaint = true; if (m_Data.IndexOf (data) != m_Data.Count - 1) { toFront = data; } } else if (previousState) { flipRepaint = true; if (dropTargetRect.Contains (Event.current.mousePosition)) { dropDead = data; } } } if (toFront != null) // Move an object to front if needed { m_Data.Remove (toFront); m_Data.Add (toFront); } if (dropDead != null) // Destroy an object if needed { m_Data.Remove (dropDead); } if (flipRepaint) // If some object just stopped being dragged, we should repaing for the state change { Repaint (); } } }

Logging an entire GameObject

2009-09-17 00:00:00 +0200

More stuff from the shadowy corners of my hard-drive. Don’t remember the context, but someone needed to log every single piece of information available on a particular GameObject. I suppose this could be useful for end-user “This GameObject Just Went Completely FUBAR”™ scenarios.

Anyway – it has reflection in it which by definition makes it cool.

Le codez:

using UnityEngine; using System.Reflection; public class Utilities { /* … */ static void LogGameObject( GameObject gameObject, bool children ) { Component[] components = gameObject.GetComponents( typeof( Component ) ); FieldInfo[] fields; PropertyInfo[] properties; Debug.Log( gameObject.name + ":" ); foreach( Component component in components ) { Debug.Log( " – " + component.GetType().Name + ":" ); fields = component.GetType().GetFields(); foreach( FieldInfo field in fields ) { Debug.Log( " ." + field.Name + " = " + field.GetValue( component ) ); } properties = component.GetType().GetProperties(); foreach( PropertyInfo property in properties ) { Debug.Log( " ." + property.Name + " = " + property.GetGetMethod().Invoke( component, null ) ); } } if( children ) { foreach( Transform transform in gameObject.transform ) { Debug.Log( "->" ); LogGameObject( transform.gameObject, children ); } } } static void LogGameObject( GameObject gameObject ) { LogGameObject( gameObject, false ); }

/* … */ }

I bet you can't type an A!

2009-09-07 00:00:00 +0200

Keys got special meaning and shouldn’t be fed into parts of the GUI? This handy little snippet takes care of that job:

private string text = "I bet you can't type an A!"; static void DisableKeys( KeyCode[] keys ) { if( !Event.current.isKey ) { return; } foreach( KeyCode key in keys ) { if( Event.current.keyCode == key ) { Event.current.Use(); } } } static void DisableKey( KeyCode key ) { DisableKeys( new KeyCode[]{ key } ); } void OnGUI() { DisableKey( KeyCode.A ); text = GUILayout.TextArea( text ); }

Where did that component go?

2009-08-31 00:00:00 +0200

In larger Unity projects, components sometimes “get lost” – you refactor something and there’s an audio source still attached somewhere in your hierarchy and you simply cannot remember where.

You’re not the first one. A while ago I created a simple editor script to combat this issue as a response to a similar frustrated post on the Unity forums. Earlier this week I stumbled on the script again, picked it up and dusted it off a bit and decided to give it another chance to shine in some spotlight.

Use:

Save the script as ComponentLister.cs.
Place it in /Assets/Editor in your project.
Launch the window from the Component menu – should be the last item titled “Component lister”.
Click “Refresh” to list all components in your scene and the GameObjects to which they are attached.
To investigate, click a GameObject name in the list and it will be set as the active selection in the hierarchy.

Codes:

using UnityEngine; using UnityEditor; using System.Collections; public class ComponentLister : EditorWindow { private Hashtable sets = new Hashtable(); private Vector2 scrollPosition; [ MenuItem( "Component/Component lister" ) ] public static void Launch() { EditorWindow window = GetWindow( typeof( ComponentLister ) ); window.Show(); } public void UpdateList() { Object[] objects; sets.Clear(); objects = FindObjectsOfType( typeof( Component ) ); foreach( Component component in objects ) { if( !sets.ContainsKey( component.GetType() ) ) { sets[ component.GetType() ] = new ArrayList(); } ( ( ArrayList )sets[ component.GetType() ] ).Add( component.gameObject ); } } public void OnGUI() { GUILayout.BeginHorizontal( GUI.skin.GetStyle( "Box" ) ); GUILayout.Label( "Components in scene:" ); GUILayout.FlexibleSpace(); if( GUILayout.Button( "Refresh" ) ) { UpdateList(); } GUILayout.EndHorizontal(); scrollPosition = GUILayout.BeginScrollView(scrollPosition); foreach( System.Type type in sets.Keys ) { GUILayout.Label( type.Name + ":" ); foreach( GameObject gameObject in ( ArrayList )sets[ type ] ) { if( GUILayout.Button( gameObject.name ) ) { Selection.activeObject = gameObject; } } }

GUILayout.EndScrollView(); } }

UnitySteer

2009-08-19 00:00:00 +0200

Ok so I’ve been quite busy lately and so I haven’t been updating the site as much as I should. In the beginning of July, UnitySteer was released. Ricardo Mendez of Arges Systems did the majority of the work and I did some early coding and design on the project.

UnitySteer is a collection of steering behaviours – enabling complex movement behaviour by combining the default behaviour set or creating new custom ones. The project is based on OpenSteerDotNet which is a .net port of OpenSteer. During the implementation of the Unity interface, however, a lot of the existing code base was either rewritten or discarded completely, so code based on the previous OpenSteer versions is not directly compatible.

For more information, check out Ricardo’s blog post and the library and examples repositories.

UnitySteer is open source, released under the MIT license .

New and improved: Behave 1.0 released

2009-05-18 00:00:00 +0200

After lots of late night tinkering, Behave 1.0 is finally out. This version fixes all known issues with unity 2.5, brings in lessons learned from Path 1.0 meaning a smashing new interface plus lots of new additions.

The new tree editor contains interface improvements allowing for much faster tree building: A brand new component bar, sub-tree movement, integration with the standard unity inspector and more.

In this version, the Behave runtime have also received an update. More runtime data is more easily available from the tree and library classes and methods implemented in your agent scripts are now mapped directly (by name) to action and decorator invokes.

This site will be updated as soon as possible with all the changes and additions and the documentation will be brought up to speed.

So what are you waiting for? Head on over to the downloads section and get your copy today!

Behave 0.3b and unity 2.5

2009-04-08 00:00:00 +0200

Apart from the hotfix, the following steps need to be followed when using Behave 0.3b in unity 2.5:

When building an asset, make sure to use the shortcut for it and not the menu.
Behave.dll needs to be in a subfolder of your Assets folder named “Assets”. That is, for instance, “MyProject/Assets/Assets/Behave.dll”.

I’m currently working on a new version of Behave which will resolve these and other issues apart from adding new features.

Behave 0.3b hotfix

2009-03-20 00:00:00 +0100

Changes in the unity 2.5 editor API has resulted in some bad issues in Behave 0.3b – a hotfix to solve the most critical ones – making the Behave editor interface usable again is available in the Behave downloads section.

I’ll be working on a more extensive rewrite. Stay tuned.

Path tutorial video available

2009-03-19 00:00:00 +0100

I just finished the first Path tutorial video. Give it a look.

Path 1.0 launched!

2009-03-18 00:00:00 +0100

Earlier today unity 2.5 launched so here we go! Path 1.0 and a pretty new website is now online. Victory!

Continued community tutorials

2008-12-17 00:00:00 +0100

Arges from the unity community has been keeping busy. His latest tutorial goes more in-depth with Behave and unity, providing an interesting and useful example to work with.

Have a read at http://www.arges-systems.com/articles/14/behavior-trees-branching-paths-with-selectors .

Community tutorial

2008-11-30 00:00:00 +0100

Arges from the unity community just made a tutorial on Behave available. Check it out at http://www.arges-systems.com/articles/2/behavior-trees-in-unity-with-behave .

New tutorial

2008-11-28 00:00:00 +0100

Just added a second tutorial “Taking advantage of OOP in agents”. It is now available in the Tutorials section of the Documentation page.

First tutorial available

2008-11-04 00:00:00 +0100

Check it out in the Tutorials section of the Documentation page.

Behave 0.3b

2008-11-02 00:00:00 +0100

Fixes and additions:

Various tweaks to the editor UI
Optimised the compiler
Fixed the following editor bugs from the bug list:
- When the editor scrips are recompiled and when the user enters and exits play mode, running editors will loose references, causing undetermined behaviour
- When a compile fails, the Behave compiler is locked and unusable – requiring a unity relaunch
Implemented the following wishlist items:
- Behaviour tree decorators
- Stand-alone edition of the Behave editor
- Behaviour tree debugging features

unite '08 open-mic session

2008-10-25 00:00:00 +0200

At this years unite, David and Tom (of unity3D) persuaded me to do an open mic session a day into the conference. I’ve been informed that this session was captured on video, so as soon as it is available to me, I’ll make it available here. I had one day of preparation for this while attending the conference, so I have no idea of its usefulness, but I guess it’s better than nothing. Stay tuned.

Behave 0.2b

2008-09-24 00:00:00 +0200

Fixes and additions:

Made the demo project a whole lot more interesting
Implemented the editor wish list item: Ability to move trees between collections
Various tweaks to the editor UI
Fixed a ton of bugs in the compiler
Fixed the following editor bugs from the bug list:
- Not able to delete collections from library
- Not able to delete trees from library
- Not able to rename collections from library
- Not able to rename trees from library
- Missing “tree has been changed, save changes?” dialog

Behave 0.1b

2008-09-09 00:00:00 +0200

Fixes and additions:

Some documentation is available
Compiler is now creating sensible output
A simple test tree and script using it is provided with the demo
Documentation is linked directly from the unity help menu
Less spamming of the log with debug information

Behave pre-release

2008-09-08 00:00:00 +0200

The purpose of this pre-release is to let the curious try the waters. It is shiny, but don’t build a project around it just yet.

Currently the editor is functional, assets can be loaded and saved, the compiler runs and results can be tested. However some minor features are not yet available in the editor, compile results are faulty to say the least and very little testing has been done. Run it at your own risk as usual.

Finally the license will be revised. Currently I just duplicated the license from the Path project in order to get this boat floating asap. Documentation will be available shortly.

Specs:

Available for indie as well as pro
Can run in webplayers as well as stand-alone
Requires no additional installations

Features:

Implements behaviour trees
Re-use common behaviour by reference
Drag and drop editor interface inside the unity editor
Simple connection to character actions via C# interface
Designed trees are built to .net assembly code for maximum performance

Path beta 0.3b

2008-04-15 00:00:00 +0200

Fixed some more bugs and improved on the path seeking algorithm which is now not limited to a single orientation of an entire mesh. For instance a PathFinder will now be able to walk up the walls, across the ceiling and back onto the floor if you so desire.

Path beta 0.2b

2008-04-12 00:00:00 +0200

In this version several bugfixes have been implemented and additional debugging information has been made available. See online documentation for more information on bug reporting.

Path beta 0.1b

2008-04-05 00:00:00 +0200

In this version, the interface of the Path library has gone through some radical changes and should be much easier to use and adapt to special needs.

The demo project now also includes a unit controller for units using the unity character controller interface which also demos how animation could be used in Path projects.

Also a range of bugs have been corrected (and no doubt new ones introduces so please toss all the feedback you can come by at me). Last but not the least Path is now almost feature complete which means feature requests will be considered at this point.

Dig in!

Path pre-release

2008-03-30 00:00:00 +0100

This version of the Path project implements the A* algorithm on a user-provided NavMesh. It includes support for multiple inter-connected NavMeshes in one scene and provides an easy to use interface for requesting and handling calculated pathes.

Updates and feedback takes place on the unity forums: Pathfinding in unity.