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

No truth

Each Class in the Wikiup comes in as many versions as there are opinions. Unlike the more familiar MediaWiki (i.e., Wikipedia) approach to content creation, there is no “official” version of the Class. Wikipedia provides the user with the most recent version of an entry, on the theory that the latest version more likely represents some sort of cumulative “truth”. But as anyone who’s seen the Evolution of Evolution will know, truth can be a very subjective thing. How much more so, then, with the entirely subjective representation of fictional data in a gaming environment.

For this reason, Wikiup simply stores each entry of a Class as a version. It’s not a “true” version, not a “false” version. Certainly, users will come along and rate each version, but that too is subjective. If a game developer doesn’t care what people think of the data, he can entirely ignore user ratings and go with what he thinks is right. If he doesn’t find a version to his liking, he can write one.

Multiple versions of a Class

No truth, just agreement

There may be no truth in Wikiup world, but there does need to be agreement. There’s not a lot of point having a common library if no one can find enough common ground to utilise anyone else’s work. We begin the process of agreement by naming Classes. A Green Dragon may mean many things to different people, but there are a few points of commonality (flying, magical lizard, perhaps) and we can loosely gather those points of agreement into the one class. We can also agree on some properties: strength, speed, power when attacking, defensive abilities, etc. We may disagree on what we want to call these properties, and we will certainly disagree on the specific values of those properties, but if I can find one that defines the concept I need to make manifest, then I can apply that to populate my game. But here’s where it gets tricky (and where contracts come in, at last!). I might have a game that requires the dragon to have six, sixty or six hundred properties. That’s a lot of variation to deal with. And if I’m working on a game that deals with six properties, I certainly don’t want to be wading around in a morass of six hundred.

So let’s bring in contracts:

The contract determines what certain Class types must contain

In this example, we have four different contracts. In fact, we have tiny stubs representing four contracts. An individual contract would need to define the required properties of all Classes used in the game, so we’re cheating a bit to keep things simple. We’re not defining the values of any of the properties, just the fact that these properties need to be defined by any Class using this contract. Under the contracts system, the Wikiup system will not accept any version of a Class which does not meet its contractual obligation. So if a client application attempted to define a Green Dragon under the supposed WiRPS contract that didn’t have a definition for Hit_Points, that version would be rejected to ensure that contracts were honoured.

Note that PokeUp only requires a few properties. WiRPS requires a few more. TwitchRing represents some monster simulator with dozens or even hundreds of required properties.

Meeting contractual obligations

Let’s look again at the Green Dragon versions.

Each version represented by a contract

Each version of the Green Dragon Class is compliant with a contract. Where a property is required, it is filled in. Note that this doesn’t mean that the definition is a “good” definition: that’s a decision for individual game developers, taggers and raters to make. All the contract does is ensure that the data implements the requirements. Note also that any well-designed user interface won’t show six hundred fields where only six are required. Authoring clients should also implement the contracts, revealing precisely the number of editable fields required.

Getting value out of agreement

So we have a bunch of versions and some of them are in compliance with one-another. Where does that get us? This is where we introduce the final piece of the puzzle: the client games.

Each client game implements a contract to filter data

Since each client game can also implement a contract (it’s optional, but very useful), they can ask for content that they know will suit their particular needs. A WiRPS character, abiding by the WiRPS contract will work in a WiRPS game. The developer might choose to tag a specific entry that she likes, but if she wants to rely instead on user ratings, it’s important to know that the version she receives will meet her needs. The two PokeUp games can draw from different versions, but the PokeUp contract means that the version will meet the minimum PokeUp requirements and won’t introduce bad data.

The Unknown Game has no contract. The red cross through the arrow might be a bit misleading. It can still get data, but the absence of a contract makes the nature of the data highly unstable (the developer can go through the database and tag specific versions of course). If the Unknown Game wants to gain the advantages of a contract, the developer can subscribe to an existing one, or, if nothing fulfills his exact needs, create a new one from scratch or by sub-classing.

Note that one of the big advantages of subscribing to a contract is the knowledge that someone else has already come along and defined a plausible gaming environment for you. They’ve considered what properties define a workable world for a particular purpose, and you can build off their work. As with other Wikiup features, this frees up the developer to focus on new features, rather than re-inventing old ones.

Wikiup Wikiup contracts