Now, I'm aware of similar concepts like aspect-oriented programming and the general theory of language embedding. However, these things miss one element that I think would really make this whole abstraction notion powerful: interchangeability. Specifically, if I embed Foo in my application (or game) and add bindings for Bletch, I then have to redo the bindings in Bar when I want some of Bletch's functionality. Even worse, if Bletch depends on "engine-side" core elements of Foo to work, I have a nasty chain of dependencies.
Let me clarify with an example. At Egosoft, we do things in a custom-built bytecode language called KC. KC has a C-style syntax with deterministic garbage collection, native string and hash table objects, and some other goodies that make it extremely powerful and yet still very convenient for building stuff with. I've often wished I could use KC, and the extensive library functions it has, for stuff like web applications. (In fact, we do some of that, but in general it's more of a toy than a genuine web-ready technology.) The problem is, the functions I want (mostly hash tables) are bound directly to the X engine, and a large part of the library functions' implementations lies engine-side in the bytecode engine code. This means I can't just wholesale lift KC and make a standalone scripting shell with it, for instance. This is what most embedded, tightly-bound languages suffer from: they are too domain-specific.
Compare this with stuff like aspect-oriented programming, which is a lot less domain-specific, but is tightly bound to specific code. Aspect-oriented programming, to do genuinely useful work, has to be bound to very specific chunks of code, and that means it takes some work to move a block from one project to another, especially if the block has nontrivial interactions that have to be redefined in a new domain scope.
My concept here is to not actually generate new languages but instead dialects. We get the benefits of enforced encapsulation and very well-defined interfaces, but the syntax stays the same, and in fact we stay loosely decoupled from an actual execution methodology; that is, the dialects can be compiled, interpreted, etc. at will, and each layer can be relocated to a different execution method on the fly. Say we build a language, Baz, that we can use to generate C++ code, or KC code, or even compile direct to assembler and hand-tune. Now, we can define all of our game logic in Baz, and then manually relocate chunks of Baz to different systems as we need it. Performance-critical bits of Baz can be dropped into C++ and compiled, or shot straight to assembler. Pieces that we want to dynamically modify at runtime can be interpreted or bytecode compiled.
Even better, our programmers only have to learn one language: Baz. KC has vastly different semantics and "good style" than C, C++, Java, Python, PHP, or any other language I've ever worked with. It is very unique, and I've seen it throw very competent programmers for a complete loop. Yet it remains powerful precisely because it lets us define and enforce an abstraction layer that is distinct from the game engine. It is high level, but it can talk to very low-level code, and do very low-level things - and it can do it fast.
Anyways, I have this sort of nebulous ideal about building a Baz-style system, and making a project out of it to demonstrate the potential. Unfortunately, I have no real interest in writing formally about it. I've been meaning to do it for weeks, but every time I sit down to write, I end up not writing. Every time I think about sitting down to write I end up getting a burger or going to bed or shooting things in BF2. This is usually a sign that I've picked the wrong topic to write about.
So instead, I'm going to shift gears a bit. Earlier today I caught a thread on highly linear vs. sandbox style gaming, and it piqued my interests. In fact, it reminds me of a panel discussion at E3 last year, in which somebody (I think it was Peter Molyneaux) commented that sandbox gaming was going to either become really big or die depending on whether or not content creators figured out how to tell compelling stories in a sandbox environment.
At Egosoft, it's basically our stated and sworn duty to produce highly kick-ass sandbox games in space (although I think the official company mission statement uses slightly different vernacular...). I'm officially, by my paycheck, a programmer, but I do a lot of gameplay-level design as well; and the issue of delivering compelling, motivating content in a sandbox game is very much a major part of what I do.
Thusly, I think I'm going to write about that, as I've got some things to say that are a bit less dense and obscure than hypothetical language dialects and abstraction concepts. It also gives me an excuse to mention space aliens in my article, which is always good.
