Glad to hear that some folks are latching onto the idea.
SHilbert, I'll be sure to read over your blog post in the next few hours. It doesn't surpise me that others are thinking along similar lines.
I find it useful to consider two scenarios of existing tech similar to what we're describing here. One is from XAML, the other is from web2.0.
First, a bit about XAML... one of the very satisfyingly simple aspects of XAML is that it basically takes a markup tag and translates it directly into an instantiated class of the same name. There are some additional subtleties related to namespaces, and some syntactic tweaks for complex types, but essentially you get the 1-to-1 of tag to class.
I find this very comforting, personally, as about 6 years ago I formed a group called OpenSWF.org (now defunct) whose goal was to maintain an open, standardized specification for SWF (Shockwave Flash) along with an open-source player. For those that don't know, SWF is a "tag"-based file format. In this case, it's not tags like markup languages (nested), rather SWF tags are equivalent to IFF chunks (i.e. a type field followed by a size field followed by a data payload). Are designs at the time were for a Java-based SWF player that communicated with what we dubbed a "Tag Server." Basically, if you were playing an SWF and encountered a tag that was unrecognized (from a newer version Flash file, for example), the player would contact the Tag Server and download the corresponding class/jar for the tag. Utilizing Java's dynamic class loading we were able to implement this trivially.
I've since toyed with applying the idea in my "day job" as a game developer. I've not worked on any Java-based titles (or .NET-based titles), just classic C/C++ console/PC titles. As a result, there's no simple convenience of dynamically loading classes. Of course, you can kinda fake it by using techniques similar to COM with DLLs (or whatever the appropriate platform-specific mechanism happens to be).
To bring this back to XAML: this is essnetially how XAML works. Again, like Java, XAML leverages the advanced facilities of the underlying language/runtime, .NET, to (almost) trivially provide this feature. XAML actually "cheats" in that it primarily produces source files for compilation (though it can function dynamically if desired).
My point of this lengthy explanation of backstory: my concern is not so much with worrying about defining a specific language that fits everyone's needs. That's why it's more of a framework. The language, the "tags" so to speak, can be wholly defined by the individual implementation of the framework (or extensions to a common framework implementation). It's more the notion of having a runtime that consumes the tags in a pre-defined (standardized) way; it's about having a notation that anyone could look at it and understand what was happening without knowing the specific tags or their implementations. In other words, the notation is self-documenting by-example and by the fact that it's human-readable and intuitively structured.
My second scenario is from web2.0. Specifically, I'm thinking about the elegant AJAX webapp called
TiddlyWiki. This webapp takes the standard notions of a "webpage" and an "HTML document" and turns them on their head. It's an excellent example of how the "structure" part of the three-pronged web2.0 idiom does not have to necessarily apply to the physical document structure, but rather the logical data structure (DOM as database). Specifically, TiddlyWiki uses div tags to represent little mini-docs in a database (what they call Tiddlers). These divs are then manipulated through the DOM to be displayed, edited, marked-up with Wiki syntax, searched, etc. The result is webpage that's a stand-alone application not requiring any backend server. Very cool...
And this raises a final, critically important point. In my comparisons to web2.0, I think I've given the impression that I want to be able to wholly create a game inside of this paradigm. I think this should be possible in many scenarios, but I also realize that "one size fits all" actually means "one sizes poorly fits many." Much like XAML, I would expect individual games to introduce custom tags that implement dramatically different features. I would also expect games to implement the "webserver backend" equivalent of web2.0 as well. Whether that backend is implemented wholly in the markup language (like TiddlyWiki), in an intermediate language in the engine (like PHP), through extensions to the engine (Apache mod_rewrite, etc.), or by customizing the engine (IBM WebSphere, etc.) is somewhat irrelevant.
At the end of the day, though, this is lots and lots of talk, and I need to put-up or shut-up... which means that this weekend I need to put together a prototype to actually test some of these ideas. Who knows, maybe I'll find it to be piss-poor... [grin]
