I wanted to experiment with creating an object system. I wanted core logic to be easy to express on the C++ side and then expose the rest to a nice scripting language so the behavior could be defined.

What I envisioned would be a sort of entity file. Which would be a mix of configuration data and script functions.

So something like
entity: Blob
{
component: Blah
{
BlahValue: 1337; //Setting a property of the component

void OnDerp (...)
{
DoSomethingFun ();
BlurgCPPFunction();
}
}
component: Blurg
{
BlurgValue: 9001;

[MetaDataToExpressStuffForVariable]
Vector3 SomePosition; //Defining a variable and how it's networked and such

void OnSomethingElse(...)
{
BlahCPPValue = "I'm setting a value associated with another component.";
DoSomethingElseFun ();
}
}
}


Where my own parser would extract the data to assemble the Entity type, and then pass the script functions/variable declarations to the scripting language for processing. And then build an entity I could dump in my world.

The trouble is that the values passed by the C++ side are not global variables, they are local to an instance of the entity. When I attempted to investigate how to accomplish this myself I could only seem to find access masks (But there's only 32 of them) and using global variables. It seems to me it would be more suited to create a sort of hybrid C++ and script type. (Since that's really what the file is defining, a type of entity). I don't see a way angelscript supports this type of thing. But I figured I would ask since I really like the angelscript library and language.

Perhaps the 'game' sample that comes with the SDK can give you some ideas?

Basically it works by game providing a base class called the CGameObj. This represents the game entities and is implemented in C++. This class provides the basic properties that the game engine needs to handle the entities, e.g. name, position, etc.

Each game entity type then instantiates a script class that implements the game logic and event handlers, this is called the controller. The script class can declare its own additional properties that it uses for its own logic.

The game sample doesn't show how, but it is quite simple to have the game engine initialize properties in the script class too based on some input file.


The access masks are intended for exposing different interfaces to different types of scripts, e.g. game entity script versus gui script. They are not intended for exposing different information to the different scripts of the same type.

Thanks for the quick response! I figured the access masks weren't intended for my purpose.

I took a look at the game sample. I suppose where I got confused was where I was trying to avoid having the "self" handle shown in the script. (e.g just "variable" versus "self.variable") Hence why I was looking at globals. But that is a much simpler solution for the small price to pay of typing "self".

I feel silly for not looking at the samples.
Thanks again.