Common bytecode language for better game/application scripting

Started by
3 comments, last by Michalson 20 years, 9 months ago
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.
Advertisement
I think .Net already does that –

In .Net everything is compiled to MSIL first, which is like a virtual assembly language. The MSIL is then compiled into native code (via a tool called ngen IIRC, or JITted).

When you compile a .Net program it produces an ''assembly'' file than not only contains the source code, but "meta data" about the source code. From this meta data you can produce a header for any .Net compatible language. This is the most important aspect about .Net and what is different from the way Java works. This builds off of COM’s and CORBA’s IDL. .Net meta-data is cohesive, whereas IDL was a retro-fit (with many, many caveats).

If you are targeting the Windows platform .Net is ideal for scripting. VB.Net and C# compilers are part of the .Net runtime – you get the compilers & execution environment for free.

SharpDevelop is an open-source IDE written in C# - so it''s available on any platform that (fully) implements the .Net run-time.

The Mono Project is an effort to implement the .Net run-time for Linux.
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
However say I am targeting some new platform, with it''s own special functions. Can I simply take some provide file (from that platform), drop it in and use any .NET language to develop for it?
quote:
However say I am targeting some new platform, with it''s own special functions.

What do you mean exactly? Something like a DreamCast, a PS2, or a Palm? The task there is more difficult for numerous reasons (easiest for the DC since it runs WinCE).

(Early I think I overstated it when I said .Net is ''ideal'', viable is more accurate.)
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
I''m not talking about targeting things like Dreamcast for CE, this wouldn''t be a standalone system. I''m not looking to design something like Java which runs full programs, what I''m looking at is a scripting system, mostly for games but for applications (note, I don''t mean the game should be a script, but that the game engine makes use of scripts for level events or AI). When I talk about "special functions" I''m talking about all the things that make that particular game different. For instance an AI might have Look and Move functions as part of the virtual machine.

Look up Lua, it''s a fairly popular scripting library for use in games. That''s what I''m interested in, only making it so that you have more choice in syntax and tools (since any CBL compiler could generate the bytecode for your particular game), and people have an easier time implementing "custom purpose" (like competition AI) virtual machines, since the VMs wouldn''t need to worry about syntax parsing, just execution of a relatively simple set of bytecode instructions, much like a CPU.

This topic is closed to new replies.

Advertisement