I'm not quite sure what you mean. Could you give an example of how you would like the scripts to work, i.e. show a piece of script that give an idea of what you're trying to do?

Do you want the properties of the object to be accessed as global variables from within the script?

Or do you simply want to access the object from the script?

Unfortunately AngelScript hasn't been designed to do what you want.

Why don't you expose the application registered type to the module as an object itself? The scripts can declare their own global variables or class members if they want extra data, but when ever they need to access what the application also uses (such as entity position, texture id, etc) it would us the application registerd type.

Example:

// AngelScriptclass Npc{  void DoSomething()  {    m_extraVariable = 3.14;    m_entity.SetPos(0,0);  }  entity@ m_entity;  float m_extraVariable;}

I don't think it would limit you anymore than any other design.

The C++ game engine has to have some minimal knowledge of the game entities, e.g. position, size, velocity, texture, etc. No script can change this, I mean the scripts can change the values of these properties, but they can't really change what they mean or which ones are needed.

You would have one script class for each scriptable entity type, e.g. ogre, troll, door, sword, etc. Then the engine would instanciate multiple objects of each class depending on the entities that are in the game world. Each script object would get it's own game entity object that tells the game engine where the object is and so on.

It is possible to have one script module for each game entity. But, if you have two entities that should have the same logic you would have to compile the same script twice in two separate modules (otherwise the global variables would be shared between them), which would give you a much higher memory consumption.

I can't really tell you how you should use the script engine. There are so many different ways of doing things. I'm just giving you ideas on how I would solve it myself.

Just got another idea. I believe I've already seen something similar described by another user of AngelScript.

Basically you would let the script writer define two things, a set of variables, and a set of funtions. The game engine would then take these two sets and join them into a script class definition that would then be compiled. Example:

// C++const string className = "Npc";const string userVariables = "float myValue; bool myFlag;";const string userFunctions = "void DoSomething() {}";// Build the script section for compilationstring script = "class " + className + "{";// Add the required variables that the game engine will usescript += "float x; float y; int textureId;";// Add the user defined variablesscript += userVariables;// Add the user defined functionsscript += userFunctions;// Finish the class declarationscript += "}";// Build the class into a moduleengine->AddScriptSection(className.c_str(), className.c_str(), script.c_str(), string.length());engine->Build(className.c_str());// Create an instance of the Npc classasIScriptStruct *npc = engine->CreateScriptObject(engine->GetTypeIdByDecl(className.c_str(), className.c_str());// Get the properties that the game engine uses. Since // the game engine defines which they are we can get them by index only.float *pX = (float*)npc->GetPropertyPointer(0);float *pY = (float*)npc->GetPropertyPointer(1);int *pTextureId = (int*)npc->GetPropertyPointer(2);

Personally I don't quite like this way of doing it, as I feel the script engine gets too heavily integrated into the game engine.