white paper (1st draft)
What is ‘The Wikiup Games Project?’
What is a wikiup?
Possible applications and concepts
What features define a wikiup?
How do I create Objects?
Known issues with the wikiup model (and possible
solutions)
Why ‘wikiup’?
Why aren’t you using <insert my favorite
technology here>?
What is ‘The Wikiup Games Project’?
The Wikiup Games Project is a community-based exploration of the wikiup concept, to wit, “can a dynamic, open, collaborative, wiki-based system be used to drive data for a practical, data-driven application (specifically, a game)?”
Wikiup System
The Wikiup System is a testbed framework for the wikiup concept. In practice,
it will be a package of PHP files and MySQL instruction sets for deploying
a wikiup. In principle, anyone who can utilize these technologies on their
web server (which is just about everyone) can deploy an instance of the Wikiup
System.
Client applications can access the wikiup system by way of an XML API.
Wikiup Entity Explorer
A Flex-based application for viewing and editing wikiup content via the wikiup
API. The explorer will have at least two basic states: explore and edit. Explore
will allow a user to traverse the library using parent-chld relationships to
see the interconnection of Classes. Edit will allow a user to edit the content
of a specific class and post changes back to the server DB. Note that the Wikiup
System has an API accessible to any client technology, so third party editors
(whether browser or desktop based) are simply a matter of someone choosing
to build them.
Wikiup Dungeon
Wikiup Dungeon is a testbed deployment of the Wikiup System. This deployment
will be an freely editable wikiup with a swords-and-dragons fantasy theme.
Wungeon & Wungeon Constructor Set
Wungeon will be the first game written as a wikiup client. Developed in Adobe
Flash (Flash Player 10, Actionscript 3), Wungeon will attempt to leverage the
wikiup API to create a full-featured adventure game based on Wikiup Dungeon.
The Wungeon Constructor Set will be a Flash-based authoring utility for creating
Wungeon games.
What is a wikiup?
A wikiup is a system for collaboratively authoring content, similar to a wiki.
But whereas wikis usually focus on qualitative content, wikiups concern themselves
much more with quantitative information. That is, values which
can drive systems, such as games. A wikiup is not itself a game system or a
game: it is a library of game data, completely separated from any specific
game implementation. The information in the library is available to client
applications through the Wikiup API.
How is this useful? Well, consider a game that needs a host of characters,
environments, weapons and other objects. In a traditional game development
situation, the development team spends weeks authoring all these aspects of
the game. Then the game has to be shipped, complete with all that custom data.
While there’s nothing wrong with that approach, it requires a lot of development
time, a lot of consideration about what each character or weapon or environment
is like, and a lot of redundant conceptual work.
The wikiup approach suggests that a team – maybe even a population – collaboratively
develops the quantitative content that defines all these objects. Just as a
population contributes to Wikipedia to author a collaborative encyclopedia,
so do the users of a wikiup jointly develop the content of a game universe.
But more than that, the wikiup is far more (or perhaps far less) than a game
system. A wikiup is not itself a game system or a game: it is a library of
game data, completely separated from any specific game implementation. This
notion of separating data from the display of data is a common current in modern
programming (e.g., XML); freed from the specific requirements of any particular
implementation, content can be edited, shifted and re-purposed for a multitude
of uses.
To see the utility, picture a wikiup detailing the particulars of a Dungeons & Dragons-style
environment. For characters, we need knights, elves, demons, dragons, wizards,
clerics, unicorns and faeries. For environments, we need dungeons (of course!),
mountain caves and subterranean lairs, wastelands and deserts, towns, houses,
rooms and shops. We need swords, maces, shields, chairs, tables, ropes, gold
pieces, food, magic amulets and cursed artifacts. We need these and an infinitude
of other odds and sods. The more of these we have, the richer our game potentially
becomes. And each of these characters, each of these places, each of these
objects requires a set of properties and actions to define who it is, what
it does, how it behaves. In the traditional development approach, every game
developer or team must define these things: a long, complex process. But if
the game developer can simply reference an existing library – one which a large
population has developed – a lot of the work is taken care of. More than that,
this single library can potentially serve as a source for endless implementations
of the general game type.
 |
|
Image A. Content creation and use model – wikiup |
 |
| Image B. Content creation and use model - client game perspective. A client game draws data via the API using filters to get only approved information. Optionally, the game may have a local wikiup (local to the client or the client’s server) for storing game instance and player data. |
Consider the following two charts. Both look at the wikiup content system
from differing perspectives.
The first chart (Image A) is from the perspective of a wikiup deployment.
A community of content authors uses either the Entity Editor or other 3rd party
tools (anything that can speak coherently to the Wikiup API) to create content,
stored in the Wikiup DB. Any number of client games may access the data to
populate their games. Some may chose to employ other web services or even other
wikiups to implement a game satisfies their needs.
The second chart (Image B) looks at deployment from the perspective of the
client game. It shows essentially the same story, but notice two things. First,
from the game developer’s perspective, the content authors are far removed.
The developer may or may not care about this authoring community, but from
her perspective, she simply receives a flow of data, without needing to worry
particularly about how it came into being. Secondly, note that we’ve added
a piece: another database listed as “local/server storage”. This
points out that the developer can deploy a purely local Wikiup that only her
organisation has access to. This allows her to add custom, even proprietary,
data, while still accessing the larger game sphere. One use for this local
storage would be to store instance variables, such as the health or wealth
of specific character instances. Having local game data that follows the conventions
of the larger wikiup can simplify development.
Possible applications and concepts
- Games.
- Rapid game prototyping.
- Mashups (client could subscribe to multiple
wikiups to create bizarre game combos: dinosaur-superhero-Jedi battles, anyone? - Data-driven knowledge banks.
- Modeling systems, e.g., an asset library. Note that the games industry
already employs a similar concept for 3D development with Collada.
What features define a wikiup?
Rules/Structure
Like a BBS, the system will have an administrator who can
define roles for the user base (users, mods, co-admins, others?). The administrator
may define several levels of exclusivity, depending on the needs of the wikiup.
A wikiup may be ‘free’ (requiring no approval before changes are accepted),
‘open’ (accepts changes with certain review procedures, such as sign-off
by a moderator), or ‘closed’ (no changes accepted, to accommodate feature freezing,
if required).
A wikiup should have a member list (possibly requiring a password to join),
but it should also have the facility to be open to anyone (at the discretion
of the admin). There should be a provision to ban users and block certain IPs
or IP ranges. Ultimately, a full-featured wikiup should probably contain all
the features of a BBS, coupled with the features of a wiki.
Database
A MySQL DB will hold content.
User Interface
The Wikiup API will be made up of a set of PHP-driven
methods. How this information is displayed to a user is at the discretion of
the developer. The current plan for the Wikiup Entity
Editor is for it to be a Flex-based application, but this is simply a window
onto the API. As with other web services, there’s no reason why HTML-based
forms or a desktop app could not be employed.
A typical Class form lists the
current Class, the classes from which the Object descends and is composed,
the editable properties of the Class, and a descriptive space. There might
also be room for pictures. It should be noted that pictures and description
are basically window dressing: they help clarify the nature of the Class being
described, but the practical application of the Class is totally tied up in
the numerical data. (These descriptives are nevertheless useful, as they help
qualitatively communicate the intent of each Class.)
Like a wiki, there should probably also be a tabbed interface with a history
of the object (an interface for diff comparison and rollback) and a discussion
section.
See rules/structure above for more detail.
Rollbacks
It should be possible to roll back any change made to any specific class. This
feature could be exclusive to users with privileges (such as mods), or might
be open to anyone. An additional administrative feature might be to roll
back using search-and-replace features. For example, one might want to delete
all the changes by a particular, abusive user.
Bear in mind that the reputation system makes it possible for abusive/unhelpful
content to be ignored by a client game, but rollback features are pretty much
built into the concept, and so might as well be included.
Hierarchical Class Structure
All classes subclass from one of the base classes, and can in turn be subclassed
from. For example:
Wikiup (core class) > Character > Dragon > Red Dragon > Fenric,
King of Red Dragons
Wikiup (core class) > Location > Room > Prison Room > Cell > Grimy,
Blood-Stained Cell
A Boolean property called ‘instance’ may well be part of the final implementation.
If set as true, the Object is no longer a class, but a unique instance. Fenric,
above, is a good case in point. Presumably there is only one Fenric (or Frodo
or Luke Skywalker or Berek Halfhand) and the ‘class’ should therefore never
be subclassed.
Compositional Class Structure
All classes (except base classes) can be composited to create variety through
composition (see How do I create Objects, below).
Core and Base Classes
 |
| Image C. A possible Class tree. Wikiup is the core class from which all others descend. The base classes are the first level of extension: central conceptual blocks that broadly define most aspects of any game. Descending from each of the base classes, we begin to get apply greater and greater specificity. I’ve shown a small number of character descendents to convey the concept, but of course the number of descendants is limited only by the imagination. |
All wikiups have a core class called Wikiup, from which all other classes
descend directly or indirectly. By inheriting from Wikiup, all classes gain
the inherent properties of a wikiup (see Wikiup
Core Class, below),
and may, in fact, be thought of as smaller wikiups unto themselves. The administrator
creates a set of further base classes (all direct descendents of Wikiup).
All classes within that wikiup would descend (directly or indirectly) from
one of these extended base classes. For a game implementation, the following
might define the set of base classes.
Wikiup Core Class: The core class from which all others descend. Importantly,
the wikiup class has a property called edit which
defines a value (0-100) indicating who can edit it. This approval key can be
independently set on any descending class (thus, everything) for the purpose
of freezing out users below a certain level.
Location: Base class for describing place.
Character: Base class for describing animate Objects.
Thing: Base class for describing inanimate Objects.
Ability: Base class for defining what something does. One never instantiates
anything descended from Ability. Rather, Ability extensions are used compositionally
to define the abilities of other classes.
Property: Base class for individual properties (e.g., strength, intelligence,
air speed, wobble). Numerical properties should have min and max values, but
some properties may be defined by Booleans, strings or other value types. Again,
used only compositionally.
XML API
A call to the wikiup returns an XML object containing the pertinent
details of the requested library entity. How detailed this entity needs to
be, and how configurable the request can be, are questions for further consideration.
What is certain is that calls for specific entities will allow for filtering
based on reputation information.
The API itself will probably be largely RESTful, with RPC methods to read
and write according to specific tasks, particularly filtering. Ideas around
the API are stil in flux, however, so any of this may change.
Reputation system
It will be possible for users to rate the work of other users, thus establishing
a reputation for each participant. This reputation provides several ways for
client game systems to filter data. Consider the figure below which defines
a Class called Berzerker.
 |
| Image D. Alternate ways of filtering using reputation. The entry by amanda94 is more highly rated, but lazyboy has a higher rating overall. The client game may use either of these reputation markers as a means of determining preferred content, or it may dispense with reputation altogether and simply choose to accept usernames it trusts. |
There are several entries for this class. For simplicity’s sake, we’re showing just
a few properties. But note the ‘Rating’ property. The best-rated entry is by
amanda94. So a game creator could request the best-rated version of the Class,
thus receiving amanda94’s entry. Alternatively, the game creator could ask
for the latest entry by the best-rated user. The entry by lazyboy was not rated
quite as highly as amanda94’s version, but lazyboy is rated highly overall,
so the game creator knows he’s getting the work of a generally reliable author.
Another API call could tag a specific user. If the game author is the user
tipperary, he mightn’t care what other users think of his work. He simply wants
to get his version of the class. Fair enough, he can have it without invonveniencing
anyone but the players of his own game.
Thus reputation serves the needs of author (better reputation),
game developer (better data), player (better game play) and the larger community
(overall better library).
How do I create Objects?
All Objects in a wikiup are created either by a combination
of inheritance and composition, or by inheritance alone.
Inheritance and composition are both methods by which one Object takes on
the properties of another. The wikiup object system enforces the rule that
all Objects are part of an object chain, descending from a single base Object
class. For the purpose of the wikiup, the distinction between inheritance and
composition can be thought of as an “is” vs. “has/can” quality. If an item
“is” a thing, it inherits the qualities of that thing. For example,
a penguin is a bird, so a penguin inherits all the properties of a
bird. A rock hopper penguin inherits in turn from penguin.
Composition comes in when we start defining the abilities and possessions
of an object. For example, the kestrel is also a bird (and inherits from the
Bird class), but can fly (unlike the penguin), so it gains the properties
of the Flight class through composition. Similarly, a knight has a
sword. It is much more useful and flexible to define different types of swords
as classes unto themselves, then place specific swords in the hands of specific
knights, rather than have to redefine the sword for each knight who might hold
one.
Note that once a class is composited into a class, it will always be acquired
by all subclasses through inheritance. So if the Bird class is defined as having
flight, all birds will acquire that ability. This is inaccurate, as
we’ve discussed above. It will be incumbent upon content authors/administrators
to carefully sculpt object hierarchies to avoid such oversights.
The combination of inheritance and composition allows for endless cross-factoring
of Objects. Note that all Objects can theoretically be extended or composited,
though we may implement an instance property which concludes the inheritance
chain for classes so finite that they cannot usefully be extended.
The UI for Object creation should be thoughtfully considered for usability
and flexibility. Specifically, a user should find a single class from which
to extend, and then click an “Extend this Object” button. The new Object will
inherit all the properties of the parent, using (by default) the same values.
There should also be a drag & drop facility for adding compositional features.
There should be a way to identify a “complete” entry from an “incomplete” one
(i.e., not all required values are filled in).
Known issues with the wikiup model (and possible solutions)
Volatility/Inaccuracy
Problem: Because a wikiup is constantly changing,
an application that relies on it may be rendered unstable. The wikiup is vulnerable
to inaccuracy and deliberate defacement.
Possible Answer: While all the above concerns are true, they don’t take into
account the ability of a client to filter based on reputation and
determine for itself what content to accept. As
long as changes are thoughtfully moderated to avoid bloat (and, if necessary,
run through an approval process) clients may be insulated from deliberate or
accidental errors.
Also, the wikiup implementation will forbid incomplete data sets, so no class
will appear in the library lacking values for required properties.
Speed/Bandwidth
Problem: The verbose nature of XML makes the API slow and
bandwidth-intensive.
Possible Answer: Still looking for an answer to this problem. I haven’t got
enough experience with XML APIs to be sure how others handle this. One possible
answer is to leave it to implementation (i.e., the game developer needs to
ask for library elements in advance if s/he wants to keep the game fluid).
Another possible solution might be varied feeds: XML-RPC for the testbed, followed
by other, lighter implementations down the road, as the dev community sees
fit.
Comprehensive Limits
Problem: Different games have different needs.
How can one library suffice for all implementations of a game?
Possible Answer: It can’t. There is no question that one library will never
suffice for all possible implementations. That said, one wikiup might be sufficient
for a great variety of games built around a common theme. It will be the responsibility
of the wikiup admin to decide how comprehensive a specific wikiup needs to
be. Bear in mind also that it is built into the Wikiup API that a client application
grabs only the data subset it requires. It is thus possible for an admin to
be rather expansive in determining what data to allow/require. There will be
a necessary trade-off between meeting the needs of game authors and maintaining
reasonable ease-of-editing for wikiup content authors.
[Addendum, March, 2009: I think I've identified a solution to this problem. Look for my tweets regarding "Contracts". I'll be publishing an article on this concept very shortly.]
Disambiguation of object names
Problem: What if two authors want to
define two characters with the same name, but subtly or totally different characteristics?
How does the game client tell these apart?
Possible Answer: Classes are not inherently identified by their object name,
but by a unique numerical identifier which remains with the Class from its
birth. Thus, while it is possible to have two similar characters with identical
names (say, two definitions for the beast Grendel), these are unique objects
which will be treated separately by the system. There are several ways within
the system to disambiguate these Classes. First, it should be the business
of the wikiup system admin and mods to identify duplicate namings and suggest
alternate names for clarity. Second, and probably more useful for the game
developer, is the wikiup API’s filter and built-in reputation system. A wikiup
library is ultimately quite vast and arguably not useful in its entirety to
any one game client. It is thus incumbent upon the developer to either tag
useful Classes herself, or else to rely on the reputation of taggers to point
to “better” implementations of ambiguous classes. Every wikiup API request
can carry a filter to find the data which the developer trusts.
Why ‘wikiup’?
The derivation from ‘wiki’ is obvious. In the American West, a wikiup is a plain,
single-room dwelling, usually covered in branches (applied to Native American
huts). The notion that our wikiup is something of a plain framework, covered
by organic matter, seemed appropriate.
It has also been brought to my attention that ‘up’ connects nicely to game
concepts such as “power up” or “level up”, so I’ll go with that, yeah.
Why aren’t you using <insert my favorite technology here>?
Simple. I do Flash. I use PHP, XML and MySQL (though I’m considering Ruby for the web service).
So do a lot of other people. Short of handing this over to someone else, I need to
use the technology with which I’m familiar. These technologies are also widely
distributed and commonly understood.