I came up with an interesting (to me, at least) idea with regard to game development... it's still not 100% fleshed-out, but hopefully with some ideas from the coders here, it will get there.

The basic idea is loosely based on making an open interchange format for game data. If you are familiar with SCUMM, think of this format as a basis for an equivalent to ScummVM. The kicker here is that "my" format is based on JSON (which is basically "The Fat-Free Alternative to XML" according to its designer), with some minor tweaks.

Although JSON is typically plain-text, it would be possible theoretically to embed "compiled" information into the notation given proper consideration. This would mainly be for purposes of efficiency (defining a model mesh as plain-text often adds much bloat), rather than obfuscation (since it would defeat the purpose of open interchange). The "compiled" notation files could also be minified to further eliminate storage footprint, even if by only a small margin.

One of the main issues I've been pondering is how to handle interaction. While assets are simple (since they tend to be static at source, and modified only in memory at run-time), it might be slightly trickier to handle logic code (which is key to allowing complete game sources to simply be loaded by a compliant host application). Scripting might be an obvious solution, but it isn't exactly "run everywhere" (Lua, Python, etc. will not run in a browser standard -- and standalone JavaScript interpreters aren't well-suited to contexts outside the browser).

As long as the host app (i.e. Web browser or native "VM/interpreter") supports metaprogramming in some way (which they do in general -- if not on their own, then with a library), tying events to the run-time host code would be doable. Of course, what those events *do* is the issue. OK, so Player1 has attacked Player2. What happens now?

I have ideas, but I need a little intellectual headbutting to make that final step.

If done right, I envision a format that would allow someone to write a game file that includes all the data necessary to have the game work in a 3D hardware-accelerated home console in the same (basic) manner as it might in a text console. In other words, the data notation format merely serves as a foundation -- it is up to the host app to "fill in the gaps" (such as having a player move from A to B by calculating a dynamic character model movement; or having a player move from A to B by wiping a console char and printing it in the new location).

I know it sounds insane, but I think with the right groundwork (and reasonable expectations) it would be workable. What are your thoughts?

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."

Here I got confused.

I read this as 'game A writes data, and game B reads it'. The main trouble I see here is that B must understand what A says. In a network, this is called a protocol, a set of agreements on things you can express in a communication, and it easily extends to off-line communication I think.

As for JSON with a twist, I'd advise against it. Using an open, commonly available standard, such as xml or json, is much more useful than any home-brewn format, as inevitable, the knowledge of reading it will get lost, be available in the wrong programming language or platform, etc etc.
If you worry about size, throw a standard compression algorithm against it. It will probably perform equal or better than any smart encoding you can think of, for a fraction of the effort. Besides, disk-space is hardly a problem nowadays (although, I am down to less than 8GB free :D ).

Further down your message, you mention 'someone writes a file', which got me thinking about languages for adventure authoring, is this getting any closer?


Pretty much still in the dark about what you intend to do,
Albert

_________________
My project: Messing about in FreeRCT, dev blog, and IRC #freerct at oftc.net

Right. This is not a protocol (in the sense of network communication) with which games communicate with one another. It is more like a data format that, for all intents and purposes, is a standard JSON file that uses certain keywords or "suggestions" for a host application that loads it.

Think of it as the same as any other game-related asset (such as a 3D mesh; or a world-map file), but for general game content.



It's not JSON with a twist in the sense that it would be a different format. These files would theoretically be standard JSON, with a few conventions layered on top.



That's pretty much what I was going to do from the start. I'm not looking to reinvent that particular wheel.



Yes, that's the whole purpose. This is aimed at allowing people to write a complete game, pack it up into a file, and then use a compliant host application to read and interpret the file. This concept is based on game engines such as Doom and Quake, where the game itself was just a host application that would load WAD and PAK files (respectively) to find its graphics, levels, scripts, and so forth.

_________________
What most people don't understand about "enlightenment" is that it is not an end-goal; but where you find yourself just before taking a new "first step."