Jump to content
  • Advertisement
Sign in to follow this  
MarkCX

Angelscript Objects

This topic is 3716 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've completely confused myself for the past 3 hours trying to figure this out. What I'm trying to do is create an object using RegisterObjectType() (which worked), but now I want a module to automatically use this object.. use as in 'be the object'. I'm sure there has to be a way to do this, but it's been confusing me for several hours that I'd figure I should just post here and see if anyone else has come up with a solution.

Share this post


Link to post
Share on other sites
Advertisement
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?

Share this post


Link to post
Share on other sites
Well what I want is something like a module-class.

I basically want a module to 'inherit' a class so that it could contain basic properties such as the x,y,z, texture images etc.. (so I don't have to manually define all these for every npc and can easily add more attributes without editing each script)

Share this post


Link to post
Share on other sites
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:


// AngelScript
class Npc
{
void DoSomething()
{
m_extraVariable = 3.14;
m_entity.SetPos(0,0);
}

entity@ m_entity;
float m_extraVariable;
}

Share this post


Link to post
Share on other sites
but wouldn't that limit me to the engine? how would I go about defining extra classes if I were to wrap the script up in an npc-class.

my original thought was to just declare global-variables in each module that would be prepended to scripts, but then I wasn't sure how I'd get the proper pointers for each to use them in c++.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 compilation
string script = "class " + className + "{";
// Add the required variables that the game engine will use
script += "float x; float y; int textureId;";
// Add the user defined variables
script += userVariables;
// Add the user defined functions
script += userFunctions;
// Finish the class declaration
script += "}";

// Build the class into a module
engine->AddScriptSection(className.c_str(), className.c_str(), script.c_str(), string.length());
engine->Build(className.c_str());

// Create an instance of the Npc class
asIScriptStruct *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.

Share this post


Link to post
Share on other sites
Yeah I'm not a fan of that either (seems like its bastardizing the scripting a bit).

I was thinking of having it so that it prepended some variables, and then I would receive the proper references to these variables and store it into the class for the npc.

Unsure if it is smart to have each npc it's own module though.

*Edit*
Is it possible to have a 'const' variable in a module, but have it still editable through c++? I tried using GetGlobalVarPointer (worked fine), and then altering the const but it seems not to change.

Also when using RegisterObjectProperty, I get these warnings:
warning: invalid access to non-static data member
warning: (perhaps the `offsetof' macro was used incorrectly)

[Edited by - MarkCX on June 16, 2008 1:40:51 AM]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!