FreeGameDev

@stefan: did I answer your question?

Yes. Sorry, didn't aswered because the last (and comming) days I didn't have much time.

Then I think AngelScript will be our choice, because it's the only system that has all our needs implmeneted without extra-packages. I think on the weekend I'll have some time to replace Lua with AngelScript.

svenskmand {l Wrote}:You do not get it we do not plan to use any more than one cpu, but we are going to support as many cpus as you want. Hence our game will be ready for the future where the number of cpus is the performance measure of a computer and not its speed.

If your game fits nicely into a single core, why does it need to utilize more? (it doesn't). Hence you are wasting time on a unneeded feature.

StefanP.MUC {l Wrote}:By the way, a question, possibly directed directly at oln, about the threading in OD (as this is also in discussion and planning currently): Has the script engine to be multi-threaded? What features does it need to have in this context?

It seems that only AngelScript is natively fully multi-threaded (that also allows to control the different threads manually, etc).
Lua needs addons, squirrel is not fully multi-theadable (or also only with addon).

Multi-thread support is not a requirement. (Unless it's a problem that the scripts run in a separate thread.) Thread safety can be done at the C++-level.

Also, about the new proposed thread model. It is partly an experiment, not strictly an attempt at making the game run faster.

Scripting languages:
Angelscript looks like it would fit very well into the game, as others have mentioned. ChaiScript seemed reasonably simple as well.
Guile seemed to C-centric, would be the same problem as lua.
Squirrel seemed simpler to integrate than lua, but seems to still need wrapper functions mostly.
So I would vote for angelscript or chaiscript. (Boost won't be a large issue as on windows, the thread library comes with the OGRE SDK and has to be compiled against anyhow, and on linux, it's likely to be installed anyhow. Also, there is other stuff in boost that could be useful.)

Never heard of ChaiScript before (seems less known than AngelScript according to Google results). Took a quick look:
Pro: Even easier C++ binding than AngelScript (I think there's no easier way left than ChaiScript's)
Con: the language itself looks less C++-like than AngelSript (but not much)

How about documentation and support/development. We would not like to end up in a situation where we cannot do something because of a bug in the scripting language, which might be unlikely to be fixed.

All engines mentioned in this topic seem to be actively developed, stable and documented.

Nice then there is free choice I vote for AngleScript then.

I just removed Lua and added AngelScript to the codebase. I'll now try to get the binding working.

Cool

These guys are using Angelscript, so you're in good company:
http://www.youtube.com/watch?v=MBDlP38uZcY

I updated the topic title since you moved from Lua to Angelscript.

Thanks for the topic rename.

Quick update:
After we decided how to link/distribute/store AngelScript in our codebase, I'll push a commit that contains the following (works locally for me already, that's why I already post it):

• Complete initialisation of the AS engine (including .as file loading and compiling, the script folder will be called "/script")
• callback from the AS compiler goes directly into our Console (we will directly see if the scripts contain AS syntax/parser errors)
• prepared and documented how to bind our classes, none are bound yet (this is something we should do "on-the-fly": add new bindings when we need it, I'll start with everything that is needed to move all the current console commands into scripts)

Also we should make documentation on how to use the scripting classes we bind, so we should make it mandatory to add some documentation every time we make a new binding. We should also remember that this documentation should be more oriented at mappers than OD programmers. So some sort of semi-difficulty in terms of needed understanding of the inner workings of the game, where programmers on OD have the highest understanding and players have or need none.

OK, now that we seem to have decided on how to include AS and the basic initialisation is working, I think I can start with converting the console input function from the frame listener to AS.

I thought of doing it this way, but If anyone has better ideas, let me know.
- create a file "console.as"
- Then convert the console input function to AS code (shouldn't be to hard, because AS code is almost the same as C++)
- This code is splitted up into: central function that does a switch on the command and then executes the function that belongs to the command
This way we have a console that can be extended by simply adding new commands to AS without having to recompile the game

Here is a quick overview of the structure in pseudo code:

{l Code}: {l Select All Code}

//console.as

void conExecuteCommand(string fullCommand)
{
    //here split command and args from fullCommand
    string[] args;
    command;

    switch(command)
    {
        case "print":
            conPrint(args);

        case "start":
             conStart(args);
    }
}

void conPrint(args)
{
  //print code
}

void conStart(args)
{
  //start code
}


And the C++ pseudo code:

{l Code}: {l Select All Code}

//user presses enter on console
asEngine->execute("conExecuteCommand()", command)


Good news: I just pushed a commit that makes AS working. I tested it with a real .as script file. Currently only our console with the "void print(string)" function is registered, however. But this means I can finally start start working on converting the old console to AngelScript.

I attached a screenshot with a welcome message from my AS test run. It did read a test.as file and printed the string to our console as a prove of concept.

I bid you a warm welcome AngelScript

Greetings AngelScript. May you survive longer than your predecessor Lua, for he was fed to the goblins!

Brainstorming:
Where should we store the .as files in our repos? SVN or Git (or: do we consider scripts as media or as code)? And: where to store the "scripts" folder (that's how it will be called) in the repo?

Hmmm though choice, I would consider it to be GPL as it is code hence in GIT, and since it is code I would again vote for GIT. It also makes it easier license wise to say that everything in GIT is GPL and everything in SVN is CC-BY-SA.

So I vote for GIT.

I vote for Git, too.

As for the folder I vote for: [root]/scripts

Any other opinions?

Current status on the AS code:
The current folder structure brainstorming is because, I'm very short before converting the console fully to AS: I just pushed a commit that adds the official AS array addon. I also made the arrays working and prepared the function that will call the AS console function.
What's next?
- Finally bind all the classes needed by the console commands.
- Convert the c++ commands to AS commands.

scripts is fine by me

Nice work with the AS implementation so far, kudos from here

Just added the scripts folder to git, plus two placeholder scripts with some TODO comments.

New brainstorming:
Should we have an "autorun.as" script file? Something that executes some general code when the game (alternatice: a map/level?) loads? What functions/tasks could that be?

I attached a custom language style for Notepad++ with AngelScript syntax highlighting. I found it on the internet, it's pretty useful.

And a quick update on the progress: Currently I'm reading through the command list in C++ code and register the needed stuff to AS and write the console.as script file (boring work, but has to be done ). But testing code without compiling is simply great!

Quick question: I currently have some problems with Ogre and AS. Do we use float or double with Ogre::Real's (Ogre has a OGRE_DOUBLE_PRECISION that can switch it, default seems to be float)?

I'm trying to convert the movespeed command that calls CameraManager::setMoveSpeedAccel(Ogre::Real), but this always crashes when called from AS...

That's set when compiling Ogre I think, so I would assume it is at the default value. Though if it's a problem you can change the function to use float, or make a proxy function.