🔒 Locked 🎮 Unity

AngelScript integration

Started by trybaczek Jan 11, 2010 at 8:41 AM 0 replies 2k views

Original Post

Jan 11, 2010 at 8:41 AM

Hi Everybody! It's another day of AngelScript meets my engine :). This time I am wondering what will be the best way for me to use script modules and sections. One solution is to use modules for every script (eg. every game object has it's own module). Plus is that I can compile changes to game object script separately and I don't have to restart everything. Minus is that all game objects have separate environment (global vars etc) and there is probably bigger memory overhead. Other solution would be to use modules per gameplay/menu. Plus is that game objects see each other environment. Minus that after I change one game object's script I have to add all of them to module and build (it's not a problem after shipping a game because then scripts are closed). Do you see other solutions or pluses/minues for my solutions? I was wondering how to implement script function LoadScript(path, section, module) (load text from file, add to module, build). First if I call LoadScript with name of module I am calling LoadScript from, what will be side effect of that? Am I replacing code currently being executed? Should I always load script to different module then currently executing one? If so, what will be the best way to interact from script with code loaded to different module? It seems complicated... I'd prefer to stay with "one module for all" solution, but how can I load scripts from scripts then? WitchLord, thank you for explanations... You said you store the GameObject as a member of the script class, and GameObject also have a pointer to the script object. How do you avoid circular references then? Cheers Tristan

WitchLord

Jan 11, 2010 at 7:10 PM

You need to decide what your needs are in order to determine what the best way to meet them is.

In my own engine I have one script module for each game object type (not each object). I feel this makes it easier to manage the scripts, and as you accurately pointed out, it makes it easy to reload a script for a specific game object during testing. I also do not want different game objects to interact directly, because it will make it more difficult to exchange them independently. Instead objects communicate with each other through a common message queue, provided by the game engine.

Each script can consist of one or many script sections. You can think of these as C++ files. The CScriptBuilder add-on provides an easy way to support #include directives for the scripts, if you wish to do that.

It certainly is possible to join all script files in one module when loading the file, but then you'll have to make sure no two scripts use the same symbols (global variables, class names, etc). It has the advantage that the code is shared between objects, which can make it easier to have the objects communicate with each other.

When you call Build() on a module, it will replace all the previously compiled code. So if that is not what you want, then you should create a new module for each build, and only discard the old modules when you're done with them.

Yes, you're correct, a circular reference is formed. I resolve this by having the script object access the game object through a weak link, that can be easily severed when the game object needs to be destroyed/killed.

script object
-> game object link

game object link
-> game object

game object
-> script object
-> game object link

When the game object is destroyed by the engine, it will clear the link's reference to itself, then release the game object link. This will break the circular reference, but will not invalidate any references that still points to the game object (through the link).

Observe that all objects that need to store references to the game object do so through the game object link, so this pattern isn't just for the script binding. It makes the memory management within the engine a lot easier as well, as I don't have to worry about loose pointers that might crash the application at random times.

Regards,
Andreas

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.