There’s no constructive theory of fun
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.