ScriptObject questions

#1 For the first question, there probably isn't a compelling reason to choose ScriptObject over SimObject - ScriptObject really doesn't add anything.

As for hooking it into the behavior system, what were you planning to do? I generally use ScriptObjects where I have a particular "thing" to manage and I want to have a "manager thing" manage those "things" - in the fashion of a sort of singleton object. Though on reflection I can see perhaps adding AI behaviors to a behind-the-scenes "leader" unit as an example....

<Edit>
I just remembered that SimComponent (from whence BehaviorComponent derives) is a child of SimObject so I'd probably want to make a cousin of ScriptObject that derives from BehaviorComponent (or is a full sibling of it) because diamond inheritance is more fun than I would want to have.

#2 There wasn't a particular need on my end for a ScriptObject to have behaviors, I was converting a tutorial to MIT and in one of the sections a stack is implemented via a ScriptObject class namespace. In my prototypes, I encapsulate almost everything within behaviors, so I was digging through the source to see if ScriptObject supported that.

That's how I discovered that ScriptObject is basically just a renamed SimObject. So the first thing that popped in my head was to give ScriptObjects a better reason to exist. Since only Scene and SceneObject are connected to BehaviorComponent, I didn't know if there would be a benefit to having a 3rd object that can use behaviors - since SceneObject carries a lot of "baggage" with it, would there be a performance/memory improvement in using a ScriptObject over a SceneObject to handle things - like the AI leader example you mentioned?

#3 ! I admit that the source code is as bare as possible, never noticed that before!

ScriptObject should definitely be repurposed, at least to add behaviors.

#4 On a slightly related note for anyone else reading along, one of the only redeeming features of the current engine docs from doxygen (not to be mistaken with the script reference, that is miles better):


I find the inheritance diagrams pretty helpful.

#5 Well, I did a quick test:

class ScriptObject : public BehaviorComponent
{
   typedef BehaviorComponent Parent;

public:
   ScriptObject();

   DECLARE_CONOBJECT(ScriptObject);
};

plus some #ifndef for the behavior files (modelled after SceneObject). So far so good, I can attach behaviors to ScriptObjects and they work in game!

I can submit this as a pull request, if we all want ScriptObject to be enhanced.

#6 Sure, why not? Like I mentioned, I usually use these for persistable singleton-like objects in my projects (because TamlWrite(%myScriptObject) is easier than doing it manually) but upon further reflection there are probably plenty of uses for a non-scene object that can use behaviors.