But nowadays that doesn't make much sense does it? it's like writing an assembly compiler manually. Wouldn't it be simpler, considering AGS syntax is almost exactly C++, to let the compiler compile it to some sort of DLL with a big interface containing all our script custom functions -- that the engine could just call? We wouldn't have to care about syntax or optimization or "escape" instructions at all anymore.
Uhhh, you keep saying that AGS is almost like C++, but it is not! Syntax is not everything. C++ is unmanaged language, but AGS script is (well, relatively).
Anyway, there are two issues here.
Firstly, having a script interpreter written in a x86-processor fashion did not make big sense from the very beginning, because the instruction list gets bloated and execution is slower than it could be. For example, LUA script run with "LUA for AGS" plugin is faster, because LUA's engine is actually optimized for the script language.
IDK what Chris Jones plans were, I tend to assume, that he simply thought that using existing execution algorithm (from x86 proc) would make it easier for him to program it.
BTW, I do not know if instructions in AGS script actually map to x86 instructions by their codes.
Regarding compiling as DLL... this is like saying: let's write AGS scripts as C++ plugins. Yes, it's an option, Unreal Engine 4 does something like that.
- you screw up every AGS user who does not know how to program in C++;
- game developer will have to compile his game on exactly the system that needs to run it (because, native code...).EDIT
..Hmmm.. I just realized that by "let the compiler compile it to some sort of DLL" you could mean something different?
On other hand, we could allow AGS script in C#, like Unity does. Or we could take Lua-for-AGS plugin and incorporate it so that AGS will be scripted in Lua from now on.
At one point I was mentioning a possibility to make "script interpreter" plugin interface that would let to attach other script engines and write script in anything you want.