I'd say Python speed concerns can be mitigated by choosing the fastest implementation for each problem domain but currently even PyPy is only close to equal to Lua. That might well change in the future and then it has to catch up to LuaJIT.

While there are C++ compilers for Windows it represents a possible failure point unless the game makers either bundles or anoints a blessed distribution due to quirks and implementation decisions made in the compilers. 

Lets be clear about this: Lua does not support multithreading.  It only has coroutines.  "Lua does not support true multithreading, that is, preemptive threads sharing memory" p.281 Programming in Lua, 2nd Ed, Roberto Ierusalimschy.

The scripting language does not necessarily have to support multiple threads. In general, you probably would not even need multiple interpreters, though I am certain using only one would have significant speed penalties to your systems. For a multithreaded system like Elemental, one could create a single Lua Interpreter and wrap in a semaphore or some other control code. Thus, each thread attempting to access the interpreter would be blocked if the interpreter was already being accessed and would become unblocked when the interpreter was freed. In a larger scale application like Elemental, you would probably want to use multiple interpreters, which use the same principle as the single interpreter system, to allow the various threads to access the scripting sections they require without constantly blocking other threads from accessing completely different script sections. This would also keep memory requirements low as each section could be encoded in such a way as to only load the necessary chunks for its section with only minimal overlap in cases where modders themselves have created significant overlaps, which depending on the separation would probably be unlikely.

One plus for scripting in Lua and Python contra C++(can be done but not a walk in the park) is the possibility of interactive development, testing and debugging by having a scripting console open while running a script. For one example of a Lua implementation see ToME T-Engine 4.

 That style of development has always been a favourite since way back when I discovered Lisp and Forth. Many modern development and testing techniques are a subset of this.

 There is also one elephant in the room of scripting languages that would place in my top three right between Lua and Python. JavaScript has three major implementations with major support and performance as well as a host of other implementations. JaegerMonkey, v8 and JavaScriptCore. It could quite possibly mean that you could use the browser as an IDE.

Such tools exist for C++, but are hard to find. I know of one but it was a demo that was with a tutorial on using a specific library to make such a tool. I recall it having issues when trying to use it with the Standard Library that goes with said library.

http://www.codeproject.com/KB/cpp/Personal_C___Compiler.aspx

Python dictates (ie: forces you to use) a specific object-oriented model, whereas Lua doesn't. Some projects are better written procedurally, rather than using objects - and vice-versa.  Lua gives you the power to do both.

 

I have to agree that Object oriented structure is very hard to grasp, especially when you are not the designer of that structure. So you first need to learn the language and then the structure. So it doubles the learning curve. I would only add the object structure when making 3rd level modding in c++.

In a perfect world you would put ole Jon to work developing an in house scripting language for kumquat games thats designed with the idea of being as simple as possible for non programmers. Designed with mid level functionality but maximum simplicity.

It reminds me of Hexen which had it's own scripting language which was similar to C. You could call all game effects like a function and pass parameters. That was very cool to use. Still I think creating your own language could simply make you waste time reinventing the wheel.

PS: I hate the quoting system - and the forum needs a preview

Well, at least your quotes appear in a box, mine does not

As Stardock uses Visual Studio and its compiler, any C or C++ compiler that target Windows should do.

When I was programming Wizardry, I was using Gcc for windows. I think it's called dev-cpp. The only thing I hope is that Elemental is not compiler dependent.

Lets be clear about this: Lua does not support multithreading.

Why do we need multi-threading? If it's multi-threading within a script, forget it. People does not need to make script that creates thread. If 2 different script cannot be run at the same time, then maybe it could e useful to get multi-threading. But again, it depends where the scripts is hooked in the game. Besides for AI, I do not see why the game would need to run another script while the game is waiting for the player in the first script. Because most of these scripts purpose is to change the rules of the game, not an animation in the background for example.

So after reading the various comments, I think my vote goes to Angel Script first and then Lua.

The langauges listed so far at most support OOP, but none of them require it.

The only things that would be compiler dependant would be those that are not not spec-ed by the standard. And as I said most of those things will be eliminated if they stick to things that must be a certain way for the WINAPI to work.

The multi-threading support in scripts does not matter, only the ability of the intepreter to not be a proformance bottle-neck or memory hog when used in a multi-threaded enviorment. As has been pointed out, some implementations do better than others.

Good.

-------------

Since some of these langauges have diffrent implementation, prehaps those that are interested is having certain langauges should look for which one(s)* are the best and then we can compare. Then we can find out which is best in various areas on a techinical level and let Stardock figure out what is most important.

* If there is no absolute best, then we can see how the better implementation stack up against the other interperters.

Some things that can be compared (if anything is missing, please mention it):

- How much extra space does the interpreter take?

- How fast does it execute scripts?

- How well does it interace with native code? (How much overhead does it add to calling or being called a native function?)

- Memory Management (Does it have ref-counting or pure garabage collection? Can it deal with circular references? Can custom memory allocation/frreeing functions be set (may or may not be important, some games have special allocation schemes to make it more effecient)?)

- JIT Compiler Support (Does it include one? Can JIT support be added without changing the source code?)

- Multi-threading (Does it allow multiple threads to invoke scripts at the same time and without having heavy a overhead cost to memory or proformance? The ability to let scripts create and/or manage threads is a non-issue. People who are using the scripts as an easier way to mod things should not ever deal with this.)

I'm for C++, and/or a scripting language with similar syntax (angelscript, javascript)

I despise codestructures that base their interpretation on the number of tabs at the start of each line

However knowing the best implementations of the other, I can see about comparing them to AngelScript. The only comparison I could find without doing an extreme amount of searching was done several versions back. It tested version 2.16.0, and the current version is 2.20.1. Link: http://codeplea.com/game-scripting-languages

A few notes about it:

- In the current version, the application defines its own 'native' string type for AngelScript to use, so the preformance on that will vary.

- The size of the interperter when I build it as a DLL is less than half the size it was for that test. The file size is 512 KB, though that is including padding that is not part of the code. (Static linking will make it even smaller, as some redundant code will be eliminated -- e.g. the C Runtime)

Who Stardock can get to integration is not something that can be tested for the sake of moving this discussion along, at least when it comes to non-subjective things.

Wrong priority 

Getting this API right is much more important.

I'd like to add "before_attack(attacker, defender)" and "after_attack" to the above list to point out that the event should be able to fully replace the game's attack handling code (before) as well as modify it (either before or after).

The same choices should also be available to a modmod - replace or keep and modifiy the "original" mod.

This will be an ongoing effort.

I'd like to ask for an overview documentation (maybe with a flow diagram of turn processing) that shows the different events and when and in what order they are called.

Additionally, there should be a strong collection of examples for common tasks - part of this can come from modders, but Stardock should pull commonly used examples into the official documentation.

While an IDE would be nice, it also is a huge amount of effort.

I'd settle for good error messages - both from the script interpreter and from the code around the events.

The code calling the event handlers must be ready for errors in the script and should also sanity check the values returned by the event.

And an external tool to build scripts, so that people do not have to start Elemental to see if the scripts build correctly.