Viridia.org

This is sort of a follow-up to my earlier post about game designers.

I get a lot of questions from people about the game development process. One question that comes up a lot is why so many games suck, even ones that have huge budgets and development teams. By “suck” I mean that while many games are technically and visually impressive, they leave a lot to be desired in the “fun” department.

The answer I give is this:

There’s no way to tell how much fun a game is going to be until you’ve actually built it.

By “built” I don’t mean finished – I mean that the game engine and rules are in a sufficiently developed state that the game is actually playable.

Now, I am sure that some of the readers out there aren’t going to accept this assertion of mine without some justification, so here is a more detailed set of arguments:

We do have a number of scientific theories about fun, but those theories are non-constructive. In mathematics, a non-constructive proof tells you that something exists, but not how to find it. There are formal methods that can be used to evaluate a game design; There are rules of thumb that can tell you what characteristics a good design ought to have; But none of these techniques can actually generate a new game design, they can only critique a design that already exists. And even these formal techniques can produce false positives.

What about non-formal, intuition-based methods? As I pointed out in my earlier post, there is a big difference between having fun and imagining having fun. I feel that it is difficult to estimate how much fun a new experience will be merely through imagination. The process of dreaming up a new game experience is in itself fun, and that feeling of fun gets confused with the fun of actually playing the game.

The most successful game companies – the ones that are consistently able to come up designs that are both novel and fun – are those who are willing to iterate on a design after the game engine has been built. In other words, they first build the engine, then collect empirical evidence on how enjoyable the game is (though testing and user studies), update the design based on that research, and repeat the process until the gameplay is of sufficiently high quality.

Note that this tends to make life hard for game programmers. In most parts of the software engineering universe, a programmer can expect (or at least hope) to get a detailed requirements document specifying what actually needs to get built. Once the software has been verified to meet all of those requirements, the job is basically done.

With game programmers, however, the problem is you don’t really know what needs to get built until you’ve built it. It means that there is an irreducible element of trial and error in the process of building a game. I know from personal experience that it can be frustrating having to re-implement the same game feature 20 times because the designer keeps “changing her mind”. It may even seem like a Dilbert-esque nightmare parody of the software development process. But at the same time, my frustration was tempered by the knowledge that the designer is just as much of a seeker and explorer as I am, and we both have the same goal in mind, which is to produce the best game possible.

Of course, the safest way to create a game is to use a game design that’s already been proven to be fun. This is why you see so many games that are clones of each other.

I recently learned about OpenID, a new distributed single-sign-on technology, and I am very excited about it.

What problems does OpenID solve? At the moment I have accounts on several different web sites – my bank, my stock broker, online merchants, blogs, forums and many others. Each one has a username and password that I have to keep track of. Of course, like most people, I don’t have a different password for every site, instead I have a small number of passwords that I use at many different sites.

Single-sign-on gives you a way to combine these different accounts so that you can sign on to many different web sites with a single username and password. Once you log in to one of them, you are effectively logged in to all.

Up to this point, the only single-sign-on system that has widespread adoption is Microsoft’s Passport system. However, Passport is a centralized authentication system, which means that one single entity (Microsoft) now has the keys to everyone’s private information.

OpenID is a distributed authentication system, which means that there are many small providers – you can choose which company you want to be your OpenID provider. If you are an AOL or LiveJournal user, you already have an OpenID identity.

Here’s how it works: Suppose you want to create an account at some site – let’s say ma.gnolia, a popular social bookmarking site (much like del.icio.us). Normally you’d be asked to enter a username and password. But ma.gnolia also allows you to enter an OpenID identity instead. An OpenID identity is just a URL. Mine is http://talin.myopenid.com.

Now, when you sign on to ma.gnolia, instead of asking you for your username and password, it redirects you to your OpenID provider (which might be LiveJournal or AOL or in my case myOpenID.) You log in to that site just as you normally would. It then redirects you back to ma.gnolia, with a special bit of data that says “yes, this user is who he/she claims to be”. The ma.gnolia site never sees your user name or password, all they see is that the proof that you are who you say you are. You can even set it up so that you only have to log on once – the next time you come to ma.gnolia, you’ll just automatically log in, as long as you are already logged in to your provider.

So it’s pretty simple. You can have more than one OpenID if you need to have multiple identities. If you decide you don’t like your OpenID provider, there’s a way to forward OpenID requests to a new provider that you like better.

What’s exciting about this, however, it that is makes lots of stuff possible that wasn’t before. A quote that I heard recently and which very much sums up my feelings: “People keep asking me to join the LinkedIn network, but I’m already part of a social network – it’s called the Internet.”

Once we have a secure way to identify people online, and to maintain a persistent identity that travels with us, we can do all kinds of interesting friendster-like things on the web instead of having to be locked in to a single service like myspace or tribes or whatever. I’m also interested in distributed reputation systems – so I can list all of the people I trust, and anyone who trusts me can trust them in turn.

Lately I’ve been quite involved with the Python language, in particular discussions of the future evolution of the language on the various Python.org mailing lists. In fact, I’m currently the author (or in some cases co-author) of 4 Python Enhancement Proposals (PEPS):

• PEP 3101: Advanced String Formatting
• PEP 3102: Keyword-Only Arguments
• PEP 3115: Metaclasses in Python 3000
• PEP 3119: Introducing Abstract Base Classes

Several of these have been officially accepted, others are still under consideration. Only the last one, 3119, has any significant unresolved issues.

In addition, it appears that I am going to be part of an informal discussion group at Google consisting of a number of Python developers – including Guido van Rossum, the creator of the language – who will be meeting regularly to discuss the ongoing development of the language.

I’m very excited about all of this, in partular I’ve been feeling for a long time a need to be “part of something” that I think is important, and more specifically part of a community.