Those of you who came here from my Livejournal have already seen this post, about a critical component for my Game Engine Engine. I would like to talk about this idea for a few minutes.

So, basically, what this project amounts to, is to create an environment in which plug-in modules allow any type of code to run and interact with each other. My main focus is on getting “native” code to easily interact with “interpreted” code, of some standard format, but I believe that to acheive this generically, it will be just as straightforward for “interpreted” code to interact with other “interpreted” code.

What happens is this: The engine, initially, can only load native code modules; in general, this will mean a “shared library” format for a particular platform. It then loads “language” modules — modules which can accept code in different formats and transform it, somehow, into “native” code.

Modules consist of both the actual code, and some sort of definition file which defines what format the module is in, what its exported functions are, and what modules it expects to be loaded. For the moment I’m imagining this in XML, because that’s just what one does. “I need a new file format. How about XML?” Anyway.

There needs to be a distinction between “language” modules (which allow the engine to accept code in a non-native format) and “code” modules (which actually get run, when all is said and done).

As well, the language modules need to be able to take this module definition file, and, at runtime, provide native bindings for their imported and exported functions. Initially I was imagining a language-specific tool which read the module definition and spewed out bindings in C, which could then somehow be compiled into a shared library and loaded into the engine. This is rather an ugly and inflexible solution, however.

Lately, I’ve been thinking — why not do a bit of JIT compilation? GNU Lightning is free, simple, and *portable*, for crying out loud. Have each format module have an import and export function which either binds a given native function to an interpreter, or outputs a native function which will call in to the interpreted one. Simple. Create a native function specification structure (it takes these types for arguments and returns this) so that binding can be done in a generic manner.

There’s still a fair amount of questions that need answering, but I’m starting to really be convinced that this is indeed quite a reasonable task, and one that’s worth undertaking.

I call this system, “Harmonium.”

Leave a Reply