Camen Design Forum

Open Game Data Format Idea

append delete theraje

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 ( http://en.wikipedia.org/wiki/SCUMM ), think of this format as a basis for an equivalent to ScummVM ( http://en.wikipedia.org/wiki/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 ( http://www.json.org/fatfree.html )), 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?

Reply RSS

Replies

append delete #1. jamesmiller5

So the Playstaion 3 and Playstation hand-held have something like this already implemented in their development kit. You can see shared resources such as assets and code that are ported from the ps3 version of a game to a lower quality but same mechanics run-time for the hand-held. The only reason this works, is because Sony has 100% control of both platforms and has an incentive to make them compatible aka sell more PS3's and sell more PSP's.

As for trying a one size fits all approach, there are two really big show stoppers.

First, there is no incentive for Sony, Microsoft or any other platform creators to make there platform more accessible to a competitors product, that isn't economical for them. One of the biggest criticisms of the PS3 is the games that have been 'ported' from the Xbox360 and just barely work, not taking advantage of the native PS3 benefits that PS3 owners had purchased and intended for titles to use. No games console manufacture will want interoperability between competing systems. The PC is mostly immune here as most people already want programs to work between Windows, Mac and Linux but it has been a long and hard road getting here and just now people are considering Mac's as a platform to support.

Second, games that haven't been tailored both mechanically and game-play wise to their medium are not going to perform as well as those that are. Take the Braid mechanics for example. Braid was written as a PC title for both Windows, Mac & Linux using SDL and C++. It was then ported to the 360 and had to have a huge overhaul because the current 360 has 512mb game memory and needed heavy memory access optimization to keep a playable frame-rate. The Braid team had no idea such actions were necessary to keep the game playable and said it had caught them by surprise. Game engines like Id Tech need to be aware of every underlying hardware optimization available to ride the sweet spot of hardware power to development time. Your idea would really only work in the browser space where sources are available to all clients and just in time compilation is practical and encouraged. If a binary code format was already given you will loose necessary context to the hardware.

As for game-play tailoring, there is no point in rendering a 60fps fighting game that uses an arcade stick in ascii other than novelty. Fighting games have very frame dependent game-play mechanics that don't translate to devices that have less than expected frame rates or don't support arcade sticks. First person shooters don't play well on touch devices because of the finger fatigue. The list of incompatible mediums continues. In short, porting a game to different devices requires UI changes and maybe game-play incompatibilities. It's totally possible to create a more fun game that is suited well for the device at hand than to try porting one from a different device.

It is technically doable but I don't think the upfront investment is worth the proposed portability payoff.

append delete #2. theraje

Hey, thank you for chiming in. :)

As to your reply, I have to say that not only do I agree 100% -- but that I have already taken those factors into account... or, more accurately, I never considered those as a factor, as those are irrelevant with regard to my ideas. :)

It would be overly naive of me to fathom that such a format would ever become a ubiquitous standard. Even today's "ubiquitous" standards are seen more as a guideline -- or even a suggestion -- for interoperability. HTML is the most obviously prevalent of these, yet it seems that even now, no one gets it consistently "right."

As for UI considerations, the whole idea of the format is to separate the data from the UI. In fact, the idea is to make a format that doesn't care about the UI at all -- the data just gives something that the host app (which WOULD handle UI) can use to figure out what needs to be done.

Some genres are largely incompatible, as you pointed out. And yes, playing any game intended for graphical interfaces is novelty, plain-and-simple... but that is not the point, so much as a side-effect, of the idea. With some of the work I've done thus far, I've figured out how to convert a real-time, first-person shooter type of game; to play as a turn-based 2D game, using the exact same data -- not because it is a "practical" feature of a game... quite the opposite, actually. :P

That's basically the crux of this project -- it's an experiment in impracticality. In other words, I'm not trying to land on the moon -- I'm just trying to get off the ground.

This project is closely related to Mbark. Mbark originally was intended for my own use exclusively. After all, there are at least one or two other more advanced (and just plain better) HTML5 gaming frameworks out there that do what I want. Mbark isn't really groundbreaking in any way -- why would anyone care?

Of course, to assume that no one would be interested is one thing... to remove the option completely from the table would be, IMO, presumptuous. So, really, these two projects are for my benefit alone. If someone sees something they like, I have no problem with that, just so long they understand and can accept that my methods are mine, and as such have their own (impractical for "production" use) quirks that must be dealt with and/or worked around.

Besides, many great innovations came about as a result of "insane" ideas... and in case you haven't noticed yet -- I am a master craftsman of crazy. ;D

Reply

(Leave this as-is, it’s a trap!)

There is no need to “register”, just enter the same name + password of your choice every time.

Pro tip: Use markup to add links, quotes and more.

Your friendly neighbourhood moderators: Kroc, Impressed, theraje, Martijn