While there are tons of unity behavior tree libraries on the Asset Store. I haven’t found one that meets all my game dev needs. There is the amazing Fluent Behavior Tree library. But for me it’s missing features and the project isn’t currently in development. What I’ve been craving is an open source Unity behavior tree library that’s easily extendible.

I’m proud to announce Fluid Behavior Tree. An open source behavior tree system that’s easily extendable without forking the code. This means it’s updatable and quite resilient to breaking changes on upgrade.

Download on GitHub

Behavior tree features

Here are a few highlights of why this library is awesome!

• Extendable, write your own custom re-usable nodes
• Pre-built library of tasks to kickstart your AI
• Heavily tested with TDD and unit tests

Other Features

• Minimal runtime footprint
• Tracks the last position of your behavior tree and restores it the next frame
• Documentation on how to use and extend
• Open source and free
• Built for Unity (no integration overhead)
• Includes a usage example of CTF

Usage Example

using UnityEngine;
using Adnc.FluidBT.Tasks;
using Adnc.FluidBT.Trees;

public class MyCustomAi : MonoBehaviour {
    private BehaviorTree _tree;
    
    private void Awake () {
        _tree = new BehaviorTreeBuilder(gameObject)
            .Sequence()
                .Condition("Custom Condition", () => {
                    return true;
                })
                .Do("Custom Action", () => {
                    return TaskStatus.Success;
                })
            .End()
            .Build();
    }

    private void Update () {
        // Update our tree every frame
        _tree.Tick();
    }
}

Why is this better than other Unity behavior tree libraries?

Most behavior trees for Unity are paid products. There’s nothing wrong with premium paid projects (and devs should be paid for their time). But it can be difficult to share code for proprietary software. Paid projects also run the risk of being deprecated or having difficulty getting enough critical mass to start a continued community.

Ever since I delved into TypeScript 2 years ago I’ve been intrigued by the idea of an application built on it from front-to-back. This idea isn’t that odd and many Angular 2+ seeds are already using this tech stack. The MEAN Checklist is an example app that demonstrates a full stack TypeScript application. It was written in one week and deployed through Heroku. While it isn’t perfect and has some rough Heroku integration due to timeline constraints, it’s a great example app for rolling your own full stack apps.

*NOTE*: Heroku’s free tier is pretty slow these days. It may take a minute or two for the app to initially load when it wakes up out of sleep mode. As Heroku puts apps in a sleep state if they haven’t been used recently.

• Live application hosted on Heroku
• Node.js source code
• Angular CLI source code

Technology Highlights

• Back-end
  • MongoDB
  • Passport
  • Express
  • TypeScript
  • Gulp
• Front-end
  • Angular CLI
  • Bootstrap 4
  • Font Awesome
  • Moment.js
• API Testing
  • Postman
  • Newman

If you haven’t already heard Bootstrap 4 is being widely used by tons of companies in production. Although it isn’t finished yet, it’s quite stable and in beta. If you’re a Bootstrap 3 user you’ll notice tons of needed features have been added. Such as better syntax for handling margins and granular control over background colors.

https://getbootstrap.com/

I’ve been meaning to learn Ember.js to cross-compare it against AngularJS. So I set myself to writing a Heroku application with Ember and Ruby on Rails. From what I heard they’re are supposed to work together magically… I was kind of right, kind of wrong.

*****IMPORTANT*****: You can still view the source code, but this app is now deprecated and no longer works on Heroku. See the MEAN Checklist app for a complete rewrite of this.

• Live checklist app on Heroku: https://ember-checklist.herokuapp.com
• View the Ember source: https://github.com/ashblue/ember-checklist
• View the Rails source: https://github.com/ashblue/rails-checklist

What was painful

Rails required a lot of adjustments to deliver data and Ember.js also requires a chunk re-configuring. There was little out of the box magic between both of them. Authentication with Ember’s simple auth plugin was a mess. Mainly because it, like most Ember related docs, is in a bit of messy transitional state between Ember 1.0 and 2.0. Google search results can be a nightmare since a lot of people are still using and writing material for 1.0.

What I like about Ember.js

The structure of Ember.js over AngularJS is more structured. As it has much better standards and specific ways of doing things. But, if you want to deviate from its standard way of doing things you’ll probably run into an avalanche of issues. Still, this is probably the best MVW / MVC framework for building something with a large team.

The Ember CLI is just as magical as Rails’ equivalent system. It does everything you want and even sets up the beginnings of a nice TDD environment. The CLI is years ahead of the Yeoman AngularJS equivalent.

View the live app

It took me about 2 weeks and 40 hours to get everything fully functional. Source code for the app is available and you can play with it live on heroku at the link below.

https://ember-checklist.herokuapp.com/

Learn how to link scenes together in Unity in a way that deletes and preserves specific code. Extremely important for games where a map is composed of multiple scenes.

Repo from the video tutorial: https://github.com/ashblue/unity-additive-level-loading