I met with my friend and colleague Mike Stead last night who as usual gave me a lot to think about, including some thorny issues with Wikiup. By far the easier to get my head around (I’ll deal with the more difficult one in a later post…want to mull it first) was the issue of mitigating ‘content fragmentation’. All this means is that we get more value out of a centralised data hub with fewer differences rather than more, so any steps taken to reduce differences between games probably helps.

This brings me to “The Rule of Joe”.

Read more…

Wikiup Wikiup Add new tag, contracts, fragmentation, Rule of Joe

Mike requested some visual explanation of the contracts concept, so here it is, along with some grounding in Wikiup’s essential attitude towards data. Read more…

Wikiup Wikiup contracts

This is a matter of new thought for me. So new as to possibly be a point of rank idiocy, and yet it seems to solve a few of the holdout problems in the Wikiup concept. So bear with me. As always, you’ll have the opportunity to call me out at the end.

The Problem

One big problem with Wikiup, obvious since the outset, has been the sheer impossibility that any single system could accommodate all variations of a game type. Three games might each need a Dragon, but each might require radically different definitions to play effectively. One game might require the Dragon to have sixty key characteristics, while another needs thirty and another only six. So even though I’ve always presumed that clients would filter data to streamline transport, the sheer number of properties threatens to deluge the system and become unmanageable. Would authors not fixate on the properties relevant to their application, leaving the rest to quietly bit-rot? Read more…

Wikiup Wikiup contracts