Reason For the Black Background

I just thought I could explain the black background.  Most people think that the black background is somethind that you would see on a wierd website or perhaps an adult themed portal, but actually it is because of eyestrain.  I don’t know if you’ve ever noticed that looking into a computer screen that is filled with white space hurts your eyes.  And since I am on my computer most of the day, I try to limit as much white space as possible.

In fact, I really wish that I could reformat my computer to have a dark background all the time so that I never have to see any white space, ever, so that I don’t have to strain my eyes.  But that seems most unlikely, given the bad rap black backgrounds have on the internet.

Simple Blob Architecture

So here is the class structure of the Blob AI system.  I have each class take care of it’s own problems so that the unity editor, and all blobs, don’t have any reliance on any other class.  This makes the system extremely modular and flexible. I will try my best at a simple but thorough explaination for each class.

  1. BlobAI_Blobs: This is the root inheritance for all blob types.  These blob types all share conditional groups, name of blob, priority number, and run type.  This class also publishes events if it’s permission or conditional has changed.
  2. sdfafd

 

Blob AI User Manual

Final Draft

Updated 12/12/2012

 

Table of Contents

Introduction 1

Overview of the Blob AI Classes: 1

Philosophy Of System: 2

Editor Code For Your Blobs: 2

 

Introduction

This system is very complicated with many details that must be adhered to especially when dealing with the editor classes. I will explain in detail all the different parts to each class as thoroughly as possible. First, I’ll go through a quick run down of all the parts to the blob system.

 

Overview of the Blob AI Classes:

  1. BlobAI_Blobs: All blobs will inherit this class, so that the editor can know, and that there are variables here that all blobs must share.
    1. BlobAI_GroupBlob: This is the ultimate blob that contains all other blobs, including other group blobs. This blob exists as a root group blob in the blob component that is placed on a game object. This blob follows all the same rules, but it also dispenses permission to run to all blobs that are inside this blob.
    2. BlobAI_RegularBlob: This blob just holds a list of actions to run if this blob has permission to run.
    3. BlobAI_StateMachineBlob: This blob holds a list of states and transitions. It renders itself out to the editor just like playmaker would. Each state has actions to run, and transitions that connect to other states.
    4. BlobAI_BehaviorTreeBlob: This is just like the rain one AI behavior tree. There are nodes that each do something specific. There are conditional nodes, action nodes, and other types of nodes.
  2. BlobAI_Component: This is the monobehavior that resides on the object that contains all these blobs. This publishes events so that the blobs can subscribe to any collision, or trigger, or event generic events.
  3. BlobAI_ConditionalsRoot: Just a basic root class for the conditionals.
    1. BlobAI_ConditionalGroup: This holds a list of conditionals.
    2. BlobAI_Conditional: This is the actual conditional that publishes events if there is a change in the conditional return variable.
  4. BlobAI_Action: This is run if called to run, and publishes events based on changes to it’s running state. This class is made specifically to be completely independent of any other blob so that it can be used in all the above listed blobs. So the state machine blob can use it just as well as the regular blob, without any problems.
  5. BlobAI_Variable_Root: This is the monobehavior variable root. This ensures that all the blob variables are serialized properly and can be referenced by any blob that asks for it.
  6. Bvar_Root: This is derived from the System.Object class, so it is used only in a user script. This class basically references the variable in the blob component. So a user that wants to use a blob variable integer, then uses this in his action or conditional script to then gain access to all the blob integer variables.

 

Philosophy Of System:

I wanted to build a system that was entirely modular and flexible so I can adapt it for use with any genre or game type out there. I could only do this properly if I made each class take care of it’s own variables and had no outside dependency at all. This meant having each class handle it’s own events, variables, and even editor rendering. This might sound a little radical, but it was the only way to make the system modular for all end users and genre types. I also needed to make a very strong data driven variable system that users can define their own variable types and have them interact seamlessly inside the unity editor window. This was the most difficult part because the unity editor is part of a different assembly so I had to ferry in information using an object and also trick the system by throwing exceptions. I will explain all of this later.

 

 

Editor Code For Your Blobs:

Here I will explain all the editor code for your blobs. Here is a list of all the interfaces that are used to render the blobs to the editor window.