EveryGame: status report

I can't believe it's been two years (and a day) since I posted my original writeup outlining the concept of a collaborative database site dedicated to computer and video games. I feel this would be a suitable juncture to give an update on the progress that has been made, other developments that have taken place in the intervening period, and my thoughts on the goals of the eventual site.

The original idea for the site was to create a gaming equivalent of Halliwell's Film Guide (or IMDB) and the Penguin Classical Music Guides, containing accurate reference data, points of historical and trivial interest, and expert criticism about every game in the medium's history. This original design was extended to include a writeup system similar to Everything2 and Community2's model, where an unlimited number of writeups could be contributed to a topic, retaining ownership by the author (differing from the Wiki model). Each game node would become a scrap book of contributions allowing each game to be thoroughly documented, appraised and explored by a variety of voices, with the different writeups being coralled into a navigable form through the use of contextual tags (see Flickr), and possibly some form of Wikipedia-like index creation.

Another idea that was thrown about at this time was the replacement of E2's voting, XP and Content Editors power structure with an alternative based on trust metrics, whereby editing rights and management/housekeeping of certain key nodes would be awarded depending on other users vouching for the applicant's authority on the relevant subjects.

Following the creation of the Everygame writeup and usergroup, there was a flurry of development activity on the part of Fuzzie, based around a new version of the Everything core (ecore) written in Python. This reached the prototype stage and in the process threw up many, many questions about the details of the implementation and the database model that would form the backbone of the system. Some time later, MightyMooQuack took up the gauntlet, setting to work on an implementation of the ideas tabled to date developed in Django, which we are assured is continuing.

Meanwhile, in the outside world, other projects with similar remits have been founded. Tyagi's Gamerwiki.com site, sparked from a discussion on the rllmuk games discussion forum, has made a fair amount of progress, both aided and hindered by the MediaWiki software. (Adding a new game to the Gamerwiki database is a tricky and longwinded process, and, as with Wikipedia, there are a number of inelegant hacks to try and retrofit specialisation onto the generalised Wiki structure.) It has become something of a running gag that Gamerwiki is collecting the data which will be transfered into Everygame, should it ever appear.

Another project is the much-publicised Game Innovation Database (another Wiki-based site) at Carnegie-Mellon. This is a rather odd (and arguably ill-conceived) project with most of its intended value catering for the academic study of games design rather than critical or reference interest. The content currently present on the site gives a strong impression that it is highly reliant on external sources (Wikipedia, Mobygames, GameFAQs) to provide any solid information about the games covered, being content to mention only the 'innovations' that each game is purported to have introduced. (There is some very dubious reasoning in the site's mission statement which basically says that for some reason it will be important for people designing games in the future to be able to precisely pinpoint the first instance of a game that implemented a particular feature. I have no idea why this should be the case - it does not seem to be necessary for any other creative medium.)

I have recently also read that the Library of Congress is planning to catalogue software and games.

I still believe that there is a need for a comprehensive reference site for games. Games are making further inroads into the mainstream, thanks to the casual games explosion on the PC, cheap, accessible handheld devices like the mobile phones and the Nintendo DS, and increasingly sophisticated integration with other mediums. This is resulting in a huge pool of interested parties, be they journalists, academics, parents, new and returning gamers, and even developers and publishers trying to break out of traditional niches, all of whom could benefit from a centralised, diligently edited guide to help them gain the knowledge they need to fully appreciate games and to encourage them to try new things.

In summary:

  1. The project isn't dead
  2. There is no end in sight
  3. There is still a pressing need for such a database to exist
  4. We still don't have an official title

If any of this has sparked your interest, the following links may be useful:

(Everygame usergroup)
Everygame thread on e2bb
Django homepage
GamerWiki (not affiliated in any way, shape or form)

Dear Claudia,

You'll never read this; even if you do, you won't recognize yourself. But I just wanted you to know that I've forgiven you. Or maybe I've forgiven myself enough to let you go. I don't know.

That "boys don't cry" line is crap: I leaked plenty of tears for you, alone at night when I couldn't bury the rancor in the noise of the world. But time heals all wounds, isn't that what they say? I moved on, you moved on, that's what people do. They move, because the world isn't a static place. It's a sink or swim place, and I'm too stubborn to sink. So are you, I knew that when I met you. I knew it, somewhere somehow, but I must have forgotten it for a while. Forgive me for worrying, I should never have doubted.

I should never have doubted, that's the weak way of saying that I realize belatedly what I did to you, smothering you like that. You were my prize fighter inferno, and had I opened my eyes to see it, we could have saved ourselves a lot of trouble.

No point in agonizing over it now. You were strong with me, you were strong by yourself, and you were strong with the next guy to come along. You will always be strong, Claudia, don't you ever forget that. Don't let anyone else forget it, either.


Well, if fondue is posting an Everygame update, I guess I can, too.

As I've stated a number of times in the past few months, I am still working on Everygame. I'm just waiting at the moment.

I chose the Django project after attempting to write my own prototype from scratch, utilizing nothing more than mod_python. While I managed to cobble together a basic working data model, I realised that it wasn't all that good, and I had a great deal of tasks yet to do. Like a good coder, I decided to look and see what was already written for Python.

Python has two major web frameworks. Turbogears is a package of a number of different pieces of software that, taken together, present a viable web design platform. SQLObject provides a database API, CherryPy communicates with the webserver, Kid is an HTML template system, and MochiKit is a Javascript library.

Django, by contrast, is a more unified whole. This does not mean it is a single monolithic piece of software. On the contrary, loose coupling is a primary design goal. Like Turbogears, it is entirely possible to swap out (for example) the template system for a different one.

However, Django's various components are quite nice, and I am using all of them. Its DB API has one serious drawback, however, which they are fixing in an upcoming version, and which I will describe below.

Let's say you're designing a database model that will act like E2. This means you have a collection of nodes of a variety of types. One of these types might be a document, another might be a user. Both of these have a variety of attributes in common. Most importantly, they share the same database column to represent their unique ID numbers. In this way, a user can enter an ID as part of a URL, and bring up whatever node that ID belongs to. In programming terms, it makes sense to represent these as a hierarchy of classes, with a node class at the root.

        /    \
document      user

The Django DB API does not easily support this concept. First, some terminology: A model is a Python class that maps to a database table. The three classes mentioned above would each be their own model. The Django DB API is largely concerned with how the coder accesses models.

In the current version (0.91) of the Django API, subclassing a model results in a new model (and, thus, a new database table) that looks just like the first one. This is a problem. Because the two models use two completely separate tables, they use two different ID columns, and so their IDs will clash, and the user cannot enter an ID as a URL and look up a node. So the way Django 0.91 can represent this is with something called a OneToOneField.

This is an attribute of a model that replaces the usual ID, and uses an ID from another model instead, which is exactly what we want. Our models might look something like this:

class Node(meta.Model):
    # the id field is implied
    title = meta.CharField(maxlength=100)

class Document(meta.Model):
    node = meta.OneToOneField(Node)
    content = meta.TextField()

class User(meta.Model):
    node = meta.OneToOneField(Node)
    password = meta.CharField(maxlength=30)

The trouble is that an instance of (say) Document uses two models: Node and Document. If we have an instance of Node and we want the "content" attribute of its associated Document, we need to say:


Ewwwww! This gets even more disgusting as soon as we try to relate nodes to one another.

This is not just a syntactic ugliness. The fact that these are two different models has important semantic consequences. For example, it is possible that we won't always know when we have a Node and when we have a Document, even if we are referring to the same conceptual node. This can rapidly get very confusing.

Version 0.95 of Django will implement this approximately the same way that SQLObject does, with something called model inheritance. Now, when one model inherits from another, it is implemented as a one-to-one relationship:

class Node(models.Model):
    # the id field is still implied
    title = models.CharField(maxlength=100)

class Document(Node):
    content = models.TextField()

class User(Node):
    password = models.CharField(maxlength=30)

An instance of Document, then, is a single model with both a title attribute and a content attribute. Additionally, Document's title attribute is stored in Node's database table, content is in Document's own table, and (most importantly!) its id attribute is keyed to Node's.

That ugly line of code above is now simply written as:


This is the primary reason I am waiting until version 0.95 of Django before I do more serious development of Everygame.

Q: Why not just use SQLObject?

A: No one actually asked this, but it is worth explaining anyway.

It is entirely possible to use SQLObject in place of Django's DB API. It supports this feature, among others. However, by using a DB API other than Django's own, I lose Django's wonderful built-in admin app. I also lose any add-on Django apps that I may wish to integrate in the future. Additionally, I rather like Django's DB API, and have no desire to use something else.

Source: Django wiki entry on model inheritance

Log in or register to write something here or to contact authors.