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