Cross Engine Mapping

Didn't I already say something about this? I think that I did

So - what're the new ideas here? They are twofold. First - the content description language is being based upon an established standard - and one which itself seperates description and content. Secondly - you can use this to build cross engine stuff that makes sense.

XMLise!

In case you hadn't noticed, the tendency today is to xmlise everything. A standard encapsulation for all data is in and of itself a good thing. No more worrying about chinese character sets, no more hassles about byte ordering... Good times ahead.

But, it's not always the right thing. And in the case of maps, I think that it is very much a bad thing.

XML is, basically, a tree format. Nodes have subnodes. Lots of data is good to represent this way. Three dimensional representations of space are not. At least not if you want a user to understand them.

Each 'sensible' way to translate a map to a tree leads to tying the tree data tightly to the engine in question. BSPs are in themselves trees. Portals give another way of splitting up space - and so on.

Ideally the space should be represented by a three dimensional structure. Failing that, surface-line-vertex trees will have to suffice.

Anyway, this isn't a big rant against XML; so I'll let it pass. XML may not be perfect, but it's good enough for a format on disk. You'll probably not want to use it internally, or edit it by hand though.

CrossEngining

So - why is this especially good? Simple.

XML seperates content from meaning. Style sheets are used to translate between human readable (or at least a bit more readable) tags to far less readable tags. But you can have several different style sheets used on the same data. Can you see where I am going with this yet? (Hint: Read the title)

That's right. Single map format, seperate stylesheets - and voila. Map that runs on both Unreal and Quake. And maybe in my VR browser too.

But we can go even better than this.

Currently, we define objects within a map as specific to the world it is designed to run. For example "tele_pad { (0,0,0) (4,5,6) tex_wibble, spawnflag_playeronly }"

But let us take an example from HTML. Rather than using "<FONT SIZE=+3><BOLD>" - we much prefer to use <H2> And using style sheets we actually start to say things like "<HEADER SUBTITLE ONCEONLY>" or any other description we prefer.

Similarly then, why not replace that telepad with "transporter { from AREA_1 to AREA_4 texture=normal passthrough-=MONSTERS }"

It means the same thing - and the style sheet would translate it into the same thing; but a stylesheet for a different game could ALSO understand it. And gracefully ignore the bits it didn't understand (my VRML app doesn't HAVE monsters. Cube only supports one texture of transporter. Whatever)

We can go further still with this. why not tag up areas of a map for the function the author expects them to fulfill. "Shinything - campspot - not_a_gun" "Shinything - trap - bigreward - camped_by AREA_3 - camped_by AREA_5". That way different mods which don't happen to support the gravy gun, or the banana-puppy can still fill it with *something*

Again - graceful failure is the rule.

And with games porting to different consoles, and having newer generations of engine that want to play the same old maps (heck - why shouldn't I be able to play a game of quake2 using my quake3 client? - Unreal is certainly moving this way) graceful degradation HAS to be the rule.

So get onto it. What format should the tags be in? Do we need to standardise anywhere - and if so where. Is there any problem with just ignoring newer tags than you understand (the way html does) or do we need some kind of 'anti-tag'? {whereby you must act differently if you do not understand it - like NOSCRIPT}

Let's Start Again

Blegh. This column brought to you by 'boring day with broken air conditioning' - not my best column. Sorry. so, here we go again.

What kind of power?

Power most awesome!

No, seriously - I don't see any limits here. Let's do this in order of 'how implementable' it is. The hope is that people will tag their work with tags that aren't used yet, and thus when engines evolve a bit, the content will be waiting for them. Kinda like my 'TYPE=Sarcasm' tags inside my 'EM' elements...

1. Tag up weapons and bonuses as seperate from 'furniture'. Tag up furniture as either 'blocking' or 'just here to look pretty'.
2. Tag up whether bonuses are intended to give power - if so whether it is a little or a lot. Tag seperately bonuses used to unlock secrets, and ones designed primarily as 'something shiny that the player wants but is really here to entrap them'
3. Tag up area traversals. If something is not intended to be easily reach except through use of another element, mark it as such. If a particular mod happens to give people a higher jump (and doesn't WANT to override this behaviour) then heck, go ahead and morph the geomatry to make the pillar higher.
4. Tag visibility and accesibility seperately. Maybe some areas can only be seen from certain places but not reached from there. If that is the intent of (say) a grille between the flag room and the way in, then tag it as such and the engine will know that it shouldn't be easily destroyable.
5. Right now we have a firm seperation between 'solid' and 'entity' - but in the future, probably not. Tag up your solid blocks with HOW solid they are, for tomorrow the player may have a shovel.
6. Inheritance. Solids have textures (and other shaders) areas are bounded by solids, entities live in areas. You ought to be able to specify arbitary ownerships and thus set default properties.

My reasoning for most of this is pretty simple. I create a map with a grappling gun pickup. This is intended to make the room with that pickup into a fighting room - and the exits accesible with the hook into camping areas. It works fine, until you import it into a mod which has a grappling gun given to the player at the start.

If, instead, I had marked those areas as' only if you have the item' and the item as 'attractive but not all powerful' and 'gives added motion' then maybe the game would be better able to cope.

And there's no reason to limit this to fps games either.

A jazz jackrabbit (platformer) level with 'rabbit fire' powerups doesn't translate automatically into a mario level. (After all, mario has no gun) - but if you mark some of them as 'lead you into a dangerous area' and others as 'reward for getting here' then you can translate better than just turning them all into (I dunno) coins.

Termination

My goal here is to make it easier to keep todays content alive in tomrrows world. As a finishing touch, I'd say it would be nice to be able to ADD to the tags in a map as a user. It is common enough for areas of maps to find uses the writer never intended, but which make the map much more fun. Perhaps a given piece of pretty furniture makes a shortcut to a powerup - or an exposed but hard to spot resting place for a sniper. Maybe the author never intended you to stand there at all; but it becomes the hallmark of that map. Being able to tag it as such, ensures that the next generation of gamers gets to enjoy the map as it was played, rather than as it was designed.

Not to mention all of the possibilities of enhanced bot AI these tags would cause.