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.

*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

https://danielkummer.github.io/git-flow-cheatsheet/

https://getbootstrap.com/

https://cli.angular.io/

*****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

Choose the correct game engine first

Originally we started with an HTML5 game and hit a wall with what we could do. Sadly this resulted in losing about 9 months of development work (some of which we refactored into Unity). The HTML5 toolset is a bit limited compared to lower level systems like Unreal and Unity (both of which now export to HTML5). If you want to work with a small team (less than 10) use Unity. If you want a larger team go with Unreal.

Also be sure to research that whatever complex features you need (UI, pathfinding, ect). Make sure they’re all readily available natively or as a plugin. The last thing you want to do is spend months writing a feature from scratch that may or may not work. Or waiting for months on a game engine’s feature to be released.

You’re running a game marathon, not a sprint!

I used to put in 60 – 70 hour weeks constantly. I had to in order to make pressing deadlines our team agreed on. While I still do this on the occasion, this is generally not a good idea. Putting in massive amounts of time on the game, I found myself emotionally unstable at the end of ever week and feeling extremely depressed. I know a few other developers who did this for about 2 years, all of them have burnt out and quit.

The first RPG a successful indie team makes, usually takes about 5 years or more. To keep up for that long you need to pace yourself at 40 hours a week. Remember that being excited to work on something again the next week is a good thing. Don’t work yourself in a way that causes you to hate what you’re doing.

Avoid Excel Spreadsheets like the black plague

One of my biggest regrets for data entry was using an Excel Spreadsheet. Importing them is a pain and incorrectly formatted information results in difficult to debug errors. Instead you should build all your data directly into your editor. Modern game engines like Unity support this functionality.

Not you should consider using Excel Sheets to translate your game’s text. But beyond that I haven’t found a concrete reason to use them.

Build for sustainability and refactoring

Having to rewrite lots of code can be the nails in the coffin for a project. I’ve rewritten far more than I ever should have. Mostly because I tried to cram too many bells and whistles into each feature. As I should have focused on building solid partial implementations that could be scaled as our code base progressed.

Create a prototype as quickly as possible

The faster you can build a prototype to test out your ideas the better. As a majority of this code, development, and art are going to be scrapped long term. I recommend using the Unity Asset Store to find plugins or pre-built projects close to what you’re already trying to achieve.

Note that we use about 8 Unity plugins on A Dragon Named Coal. A chunk of the plugins we attempted to prototype with had to be discarded due to a lack of updates from the developer or inflexible APIs. Test your plugins before you integrate them with your project’s core.

Use visual scripting libraries combined with scripts

Managing large amounts of code with a team is difficult. Remembering what your code does when you come back to look at it several months later is even more difficult. Because of this I recommend using Behavior Trees and Finite State Machines. In Unity you can achieve these through PlayMaker and Behavior Designer (both of which I recommend).

Visual scripting libraries are important, as they will abstract out your API logic for inventory and other features. Plus it saves you from writing tons of scripts into your games whenever you want a simple interactive feature.

RPGs are built by teams, not individuals

Even the big name indie RPGs built by one guy have others helping them. For example the famous Dust: Elysian Tale had multiple people working on the project near the end. Even though is was primarily one guy.

Get a team together when you think you have something solid to talk with others about. You should have a story outline and prototype of the game before trying to approach others.

Build a solid stats and inventory system early on

If your game has combat you’ll want to figure out the stats system early on. This means figuring out how defense, attacks, specials, equipemnt, ect, and how it all fits together. When I ask many indies about this subject they usually just draw a blank and say “I have no clue how that will work.” You can figure out a lot of this by running pen and paper comparison of how these stat systems could work together. DnD rules are also another great source of inspiration. Although DnD’s d20 system is targeted at much fewer encounters than your game will probably have.

• GitHub Repository
• Live Demo

This is just the first iteration of Unity Skill Tree Pro. So the visual editor is still a little rough. That said it does a lot out of the box right now. If you want to customize it further the source is freely available online and it was written to be easily extendable without touching source code.