Original Post
I''ve had this idea kicking around in mind head for years (if I work the dates right it would be late 2000, a bit before I got to see .NET which shares some of the same ideas, but doesn''t take it far enough). Finally, in response to the Arena thread (the idea of AI combat, and making a program for fairly doing it, is what got me thinking about it in the first place) I think it''s time to try and post this jumbled rant of an idea.
Basically the idea is two part:
A Common Bytecode Language (already done with .NET), which allows you to have a common base for game/application scripting. While things like Lua are nice, when you take a look at it scripting languages (especially for games) are stilling living in the early 1980s. Many different and completely incompatible standards. These means support for each one is small, and many people will not have encountered the one you choose for your game (ok if it''s just used for your own scripting, not ok for user mods/ai). With a CBL you allow seperation between the parsing and execution. This means you can have a C++ style parser (a bytecode compiler) that can be used with any game. If users don''t like C++, they can turn around and use the Perl, or Lisp, or Pascal, or Basic parsers with the exact same games. This means you and your users have a wide variaty of existing, quality tools for working with your game scripting environment (in addition to compilers you could also see debuggers and optimizers, since a common base allows many more people to work on the same thing). At the same time you also have freedom with your interpretter. In theory the bytecode language will make it much simpler to write a new execution unit (since you only need to worry about simple, properly formatted, machine readable instructions). You can now extend existing VM implementations, or create your own optimized one. You can even create special case VMs, such as those for AI competition. These VMs could not only provide a sandbox environment (sandbox means that the program can''t see or harm anything outside it) but also control execution speed. That way each AI gets exactly the same amount of "CPU" time (you can also use this outside of speed control, such as allowing for multitasking execution of long scripts in a game or application, something Lua can''t do unless you create multiple instances in multiple threads, which is cumbersome can often require ugly work arounds to get other things to work).
A Common Header Format (not done yet). While the compilers can in theory all produce bytecode that can be run on all virtual machines, there is really not point unless individual virtual machines can have their own game specific functions. There is where the header file comes in. The header file contains information about the virtual machine to be compiled for, and obviously, is used by the compiler. It contains three things: Special data types (structures), used by the VM. This could include both simple structures, as well as more complex ones such as arrays or variable sized structures. The second thing is VM functions. It outlines what parameters are expected, and I would hope already include some form of hinting structure to allow OO compilers to use the header to create Object types. The third thing is definitions for various types of entry functions. While some virtual machines might run the bytecode program as is (a single "void main()" type of function), others might use compiled bytecode more as a library, calling functions when certain events happen. These would be defined for the VM to include, and there would obviously be a standard header format for compiled bytecode files that indicated where these functions where located.
I''ve got more I can say (which has a lot more to deal with the actual byte code language), but I''ll wait for some feedback or whenever I catch my breath.
