Home
WWWWolf's LifelessJournal
Random ramblings of a random wolf
July 17th, 2006 
Urrrgh.

You know, people seem to hate Mozilla's Mork file format. It's certainly ugly and braindamaging enough. I think I've finally found a contender. Not quite as bad, but still pretty darn awful and not very well thought out.

Now, let's face the facts: XML-based outline formats suck. Please consider the implications of that: XML was meant to make laying out structured information neatly easy and fun. Yet, OPML is a frigging ridiculous attempt at that: it stores data as attribute values, which is a huge big no-no. OML is slightly better, but no one supports it. Sane people would use some RDF-based thingy, but no one supports that, either.

But I forgive all those things right now, right here. Yes, even OPML. I thought OPML was the most annoying and illogical use of XML. How wrong I was!

I'm talking about OmniOutliner file format. This is version 2.x, which came with OS X 10.3. I have no idea if v3 is any better, because it's apparently a pay upgrade.

The file format itself is based on Apple PLists. PLists are only slightly broken format: I think the only miserable thing in it are the <dict> tags, which stores a <key>,typetag stream rather than pairing the keys and values in another container tag, which makes xpathing them a bit trickier. But it's better than nothing.

So how do you store that thing in a plist?

Not at all how do you think.

The first thing you notice when you open the file in Emacs is that the file is just a memory dump. Okay, a neatly text-serialised memory dump, but a memory dump nevertheless.

<dict>
    <key>Identifier</key>
    <string>39f711d444bac978055e0065</string>
    <key>MaximumWidth</key>
    <real>1.000000e+06</real>
    <key>MinimumWidth</key>
    <real>1.300000e+01</real>
    <key>OOPlainTextExportWidthKey</key>
    <integer>72</integer>
    <key>Title</key>
    <string>Topic</string>
    <key>Width</key>
    <real>5.120000e+02</real>
</dict>


Yeah, really useful information for other apps here. Okay, I'm not really criticising this, it's easy to ignore by other apps so far. But then we come to this wart:


<dict>
    <key>Page Layout</key>
    <data>
    BAt0eXBlZHN0cmVhbYED6IQBQISEhAtOU1ByaW50SW5mbwGEhAhOU09iamVj
    dACFkoSEhBNOU011dGFibGVEaWN0aW9uYXJ5AISEDE5TRGljdGlvbmFyeQCU
    hAFpEpKEhIQITlNTdHJpbmcBlIQBKxBOU0pvYkRpc3Bvc2l0aW9uhpKEmZkP


       (... 111 lines of base64-encoded crap omitted ...)


    hJmZDE5TTGVmdE1hcmdpboaShJ2ctaIkhpKEmZkLTlNUb3BNYXJnaW6GkoSd
    nLWiJIaShJmZCk5TTGFzdFBhZ2WGkoSdnISXl4J/////hpKEmZkLTlNGaXJz
    dFBhZ2WGkoSdnKKeAYaShJmZCk5TU2F2ZVBhdGiGkoSZmQCGhoY=
    </data>
    <key>SpellCheckingEnabled</key>
    <true/>
</dict>


Hey Apple! Be a bit more careful what apps you're bundling with OS X! I mean, people tell this sort of jokes about Microsoft Office, not OS X itself!

Okay, even that is easy to ignore by applications that don't need the page layout data (if that indeed is page layout data - could be encrypted blueprints of Russian submarines for all I know!)

What the parsing applications are really interested of is the actual outline data, right?

Well...

<key>Cols</key>
<array>
  <string>{\rtf1\mac\ansicpg10000\cocoartf102
{\fonttbl}
{\colortbl;\red255\green255\blue255;}
}</string>
  <string>{\rtf1\mac\ansicpg10000\cocoartf102
{\fonttbl\f0\fswiss\fcharset77 Helvetica;}
{\colortbl;\red255\green255\blue255;\red0\green0\blue0;}
\pard\tx560\tx1120\tx1680\tx2240\tx2800\tx3360\tx3920\tx4480\tx5040\tx5600\tx6160\tx6720

\f0\fs24 \cf2 Foo}</string>
</array>
<key>Expanded</key>
<true/>


...if you intend to make any kind of sense at all out of this, please add an RTF parser in addition to XML parser to your application...

In another news, file formats that offer just serialisation of what the application has in memory suck. Won't change much if the serialisation format is "human-readable" or not. I sometimes find even Ruby YAML a bit hard to follow... The point is, while memorydumps are easy for programmer, they're not easy for another app's programmer.
Today, we ventured to the attic, where I found... old stuff.

The greatest bits I found had to do with RPGs. I'm going to publish all of this stuff one day to show everyone how NOT to design a RPG. Though I'm not so sure - back then, I wasn't exactly up to my current standards of copyright law, so I guess I won't include the earlier versions of the game that seemed to rip off a lot of stuff.

Anyway, this is the sad tale of Advances SuperQuest Professional Version:

Back in the day - that is to say, circa 1992-1993 - I had heard of these RPG things. The bad thing was, I didn't have any of those things around. So I made my own.

I just pulled a game system off my head. It was called SuperQuest. And then I made Advanced SuperQuest. And then Advanced SuperQuest Professional Version. And then I thought it might be cooler to use version numbers. Latest one I found was 2.5, from Sep/Oct 1993.

I couldn't find the WordPerfect files containing the original stuff, but now I found the printouts. Which is actually better considering how liberally the new word processors format these old files.

And what a weird system it is.

What a frigging lunatic system it is.

When I finally got the D&D box, I... uh... silently admitted my system sucked hard, and felt pretty silly for even trying to promote this thingy on BBSes. I suppose I was quite an idiot in the BBS world. Hopefully a relatively harmless idiot. (Not so sure about that either. But those were weird days and I remember little.)

Anyway, I can now only describe the document in - um, euphemistic terms - interesting. You see, it doesn't use dice, apart of some vague "random determination" of hits.

  • Determine (CombatWill + Skill + HP + Accuracy - (EnemyAC + 5))/4 = CombatValue.

  • Compare to (CombatValue + CombatValue)/2 = CombatAverage. (I think this is supposed to be average of the two combatants' CombatValues.)

  • If the (attacker's?) CombatValue > CombatAverage, "the creature's" (I presume defender's?) HP falls by how much damage the weapon does. Which is somehow weirdly determined based on protogygaxian tables or something.

  • If otherwise, randomly determine if it's a hit nevertheless. Eh...



Someone pointed out some odd numerical problems with this one right away. Yeah, I apparently knew what other problems were there: I was complaining a lot how awful the calculator in WordPerfect was...

Also of note is the fact how some character names and equipment names were stolen from a C64 game called FightMaster, which I didn't actually type up from the MikroBitti mag until much later. PC Hack was also a source of inspiration, it seems. (Damn. Reminds me, I still haven't ascended in Nethack.) Also, it seems the articles in Sininen Lohikäärme (the Finnish "edition" of Dragon) issue #1 were a bit of an inspiration - and it seems I've even put that to the acknowledgements, how sweet. =) A lot of inspiration, it seems.

And it seems there are some profound balancing issues.
"Rings: ... Universe Ring: You can do anything!"

And while I have to say that the game also didn't have any of the usual teenage-built-RPG cliches, it did have some... bits that I can even still recognise as my own handiwork.

"You have found the Diamond of Vantity (sic)! Phooie! I suppose the princess was indeed vain for wanting such a massive diamond. There is no item more tasteless than this! Well, the adventure is over in any case, let's go to eat."

And, looking back at the other material I made at that time, it seems that one big idea comes to my head: I was quite clueless, I didn't take critique too well either. (You know, school bullies' ideas of critique tend to make sure all sorts of critique comes across as crushing...) I hope I have learned about that a bit - I still get a bit shy about the critique but at least I read it nowadays. =)
This page was loaded Dec 30th 2009, 8:51 pm GMT.