I've been following angelscript for a year or so, but I've never really gotten to use it (partly because I didn't have any motivation to program in my free time). Anyways it has come back and I'm eager to integrate it into my little engine. Especially I want to expose the entire engine to angelscript so that I can (in theory) create an entire game without very little additional c++ code. I'm not quite sure if I can do that, but I'm willing to give it a try.

One thing that bugged me is how I should properly use angelscript when I have a lot of different tasks, like scripts for AI Actors, gameplay related scripts etc...
Should I put those in different as-modules? Maybe there would be a benefit because I could execute modules in different threads.
Is there anyone who actually has some experience with angelscript and especially using it in larger scales? It would be great if you could share your experience with the community (and me :D).

Hello there,

I am using AngelScript as the core for my audio game engine. This is an engine especially designed to permit the creation of games for the blind and visually impaired community, by end user's who don't necessarily have any prior programming experience. I wanted a system that would allow the creation of new titles with relative ease and without using a low level language such as C++ directly. Thus, I needed a scripting language that was easy to use while still providing high performance and AngelScript was a clear winner here. The way I'm doing it is to simply run everything in one module, and currently with only one context. AngelScript is fast enough to allow me to do all game specific things in the script, and only do low level things such as DirectInput usage and high resolution timing as well as any other tasks requiring maximum speed, in C++. I expose these as classes that are then used by the game writer, so you get a completely safe development environment in which one can develop things at lightning speed as compared to using C++ directly. I now write all my games using this framework, and it has worked very well. In short, I just do the grunt work in C++ and let one single script do everything else.

Kind regards,

Philip Bennefall
Blastbay Studios

Thanks for the input. I will try one module and see if it works for me as well.
Now I can start planning the interface classes between Angelscript and my engine.
Thanks :)

For my own game engine, I want to use the scripts as plug-ins. The game engine provides the framework, and the scripts are used to control specific entities.

Each entity type has it's own script module that can control that single entity. It can also communicate with other entities through messages.

I also use different scripts in other areas, such as the HUD and game menu.



I feel that having the scripts separate like this, makes it easier to manage. Of course, I'm also limiting what the script writer can actually do with the game engine.

I thought about something like that.
But there are several things I just can't get working in my head. I want to integrate my Entity system (very much like proposed by sneftel I think) into angelscript. That means something like this:


There will be several components that are completely defined by the engine. They can be instantiated by a script and attached/detached to/from an entity.
But the script writer might want to implement the behaviour for an entity. Therefore he shall be able to define a new Component and attach it to the entity as well.

Let's suppose I register an interface named ScriptComponent and create an actual implementation:


Although I like this idea very much, it leaves me with several problems:
-It's not possible to subclass an application registered class (Component)
-How can the entity actually store those objects (they're created within angelscript and I don't know any common base class)

It seems that mixing c++ and angelscript classes is the wrong way for my particular problem.
One possible solution would be to implement the entire component system in angelscript which would completely avoid my problem.

Another solution is that a user defined component looks more like this:


From your description I suppose you chose the second way, since it's quite easy to implement. Do you have any suggestions for this particular problem or maybe some more imput on your integration?

My way of doing it is probably more close to the first alternative.

You're correct that a script class cannot derive from an application class, but it doesn't have to. What you can do is to register a script interface with RegisterInterface, and then have the script class implement that one. The application can then register functions that receive this interface, as a asIScriptObject pointer.

My CEntity class holds an optional pointer to an asIScriptObject which implements the AI controller. If the asIScriptObject isn't there, the CEntity becomes a basic rigid body that only reacts to physics.

The asIScriptObject in turn has a pointer to the CEntity too, so that it can update it as desired. Actually, the asIScriptObject has a pointer to a weak link representing the CEntity. This allows me to cut destroy the CEntity object when the game engine needs to without having to worry about all potential references to it.

For the game entities I also have a simple object description file format to define actual object. In this format I describe the 3D mesh, physics shape, script controller, etc, which together define the object. I can then create a new object with all the configuration set up with a single call to the engine's SpawnObject.

Thanks for your quick and detailed answer.
I'm currently building a small test using the method you described.
One thing that kept me from doing so was that I had no idea what type of pointer I would receive, when declaring a function that accepts a handle to an interface "void attach(ScriptComponent@)". I couldn't find information about it in the documentation either, so if it's not there, it would be great if you could add it.

I do have another question though. From the documentation I gathered that when passing a handle to an object to an application registered function, angelscript automatically calls addref on the object and the application is supposed to call release on the object. Is this the right way to implement the c++ side of the script component?


I also thought about adding a configuration system for entities, which should make spawning the same entities over and over much more easier. I hope I can implement it soon :)

I personally would use the script object without wrapping it, because when you wrap it, you are responsible for it, not the engine. So yeah, seems to be about right to me.

Yes, this is how you should work with the handles. You may also want to refer to the manual on this subject.



Indeed, there are quite a few subjects that I need to improve in the manual. One of them is how to pass script classes to the application.