Beta version of edu-lite game

This has nothing directly to do with Wikiup. I just felt like I needed to write a game as I hadn’t done one in a long time. I just posted this: http://www.wikiupgames.com/games/higgs/ in beta form. Please post all comments/bug reports here.

This brings me to “The Rule of Joe”.

This is something I’ve thought about before, but my chat with Mike suggests it has more validity than I had thought at first. Very simply, the Joe rule is a sub-contract that sets down a benchmark representing a theoretical “average Joe” with a value of ‘1′ for all properties. If there’s a ’strength’ property in the game, Joe has a strength of 1. If there’s a ‘weight’ property, Joe has a weight of 1. All properties for other characters get set relative to Average Joe’s (so a horse might have a strength of “2″ and a badger “.2″…er, assuming a badger has about 20% the strength of Joe?). The advantage of setting this peg in the sand is that all games of a particular sort (obviously this doesn’t work so well with starship battles or chess) can define themselves relative to a common benchmark, thus (in principle) less fragmentation.

The rule is voluntary, not enforced. Like any other contract it exists to help establish a framework for development. But as with other contracts, it can be discarded if not useful.

So two basic questions:

1. Good idea, bad idea?

2. Is one peg in the sand sufficient? Do we need a second peg to establish range?

All thoughts greedily accepted!

Certainly folksonomic tagging has been in my head for a long while now. But honestly, I’m not sure about this for ratings,  since the Wikiup system by definition needs to be able to tease out quantitatively “best” versions within certain bounds. But I like the idea that the rating system could be multi-dimensional. Any thoughts world?

I started following Social Innovation Camp on Twitter today. Their mission is to discover and encourage online tools for positive social change. I’ve described a couple of ideas above where I think Wikiup fits that description, but I generally like to think of myself as someone interested in good (am I a positive socialist?). So I’m wondering if anyone reading this can suggest ways in which Wikiup can work towards the good. Are there other types of simulations (medical, political) we should be actively supporting? How else might a web-serviced, quantitative database be used positively?

Thanks for any and all ideas.

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.

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.

These sketches represent the editing portion of the tool. There’s also an Entity Explorer (accessed by the “W” button in the upper left corner of each screen), but we’ll deal with that separately.

General Orientation and Top Matter

The editor deals with editing, discussing and rating any individual Class within the Wikiup (a Roman Centurion, a maze, a leopard, a sword, a football pitch). As you can see, the bulk of the screen is occupied by a tabbed interface, with each tab responsible for a portion of interface.

The big buttons at the top of every screen are the common controls: The ‘W’ button to get to the Entity Explorer, a preferences button, a help button, and a big, friendly Post! button to post your entry. I’m thinking now there should be a “Save Draft” button also. There’s also some common info. The name of the class (fixed from birth), and the unique ID, the version number, the rating and the author of the current entry.

Basic Screen

This screen covers simple detail: information useful to humans for the purpose of comprehension, though largely irrelevant to a computer. The inheritance chain (how this Class inherits its traits) is displayed, as are a desription and folksonomic tags. Images may optionally be attached for visual reference.

A simple style dropdown allows the choice of a few tags (headline, body, list) in the description area.

Properties Screen

Here’s where most of the hard work happens. Properties, abilities and possessions of the Class are laid out inside an accordion component. Note that each item in the inheritance chain provides its own set of properties, so an author can easily see where a given property derives from. Though not shown here, the bottom item in any inheritence chain will need the ability to add new properties, abilities and possessions.

Discuss Screen

As in Wikipedia, a place to discuss the issues which arrive from a given entry. As with description, a simple style dropdown allows the choice of a few tags (headline, list, body, signature).

Rate Screen

As the name states, a place to rate the entry, but also to flag abusive behaviour and identify versions which you personally like. A given user can only tag one version of any class: this is the version that user “prefers”. If a client game chooses to filter based on a given user’s preference, this is the version they will receive.

XML Screen

Just the XML feed, as a client game would receive it. I have a notion that there are two versions of this feed: OO and concise. The OO form retains the Object Oriented structure, for facilitating editors like this one, while the concise form is more suited to games, where knowing the values is more important than determining how we arrived at them.

History Screen

The version history of this Class. A user can organise the versions by author, date, version or rating. Selecting a different version makes that version current, and any edits for new versions (as well as ratings, tags, etc.) will focus on the selected version.