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?

The Solution: Contracts

A “contract” is a set of rules, just like any legal contract, only in this case the rules we’re defining are the property rules by which a game’s content must abide. (programmers might want to think of “contract” as a synonym for “interface”). Let’s use my example from above: three games requiring a dragon to have sixty, thirty and six properties respectively. In the old model, the dragon might have as many as 96 properties defined already, and it’s a safe bet that an author of the six-property game won’t want to fuss with the other 90 (to say nothing of the obvious UI nightmare).

So we’re going to fix this by attaching a contract to each version of Dragon and a matching contract to each game. The contract defines the requirements of a character, an object, a location, etc. within a given gaming environment. What properties need to be defined to fulfill the contract? One game requires that Dragon have an intelligence property, another needs speed, and some other wants luck. The authoring of a Dragon isn’t complete and won’t be accepted into the Wikiup DB until it contains the requisite parts of the contract.

Clients can similarly subscribe to the contract, so a game needing a Dragon will only get one that meets the terms of the contract to which they both belong. By the same token, an author looking to amend the library can filter based on contract, ensuring that she never needs to know about those 90 properties irrelevant to the environment for which she is writing.

Neat, huh? It’s not just my imagination, right?

Other Advantages

Rapid(er) development

Of course Wikiup is all about rapid development, so consider a game developer writing an online Pokemon-style card game. He may have a new take on card games, but just as specific data have been created numerous times, so have general game systems. So our designer can find an existing game model among the contracts and get on with the business of bringing his unique vision to the existing genre.

Character portability

This has always been part of the Wikiup vision, but only now does it begin to take shape. Sure I can say that characters can move from game-to-game, but the advent of contracts really makes this come together in my view. Once multiple games have subscribed to well-written contracts, significant barriers fall and a Jedi knight really can become a ninja can become a paladin, since the properties transfer seamlessly from client-to-client.

Wikiup Wikiup contracts