The everyday blog of Richard Bartle.
RSS feeds: v0.91; v1.0 (RDF); v2.0; Atom.
1:29pm on Saturday, 28th April, 2012:
Comment
Although I teach game design in a Computer Science department1 , I don't actually teach much about computer game design. What I teach is primarily game design (and virtual world design). This is because, ultimately, all games are games. If you want to design a game, the platform is just another batch of constraints and opportunities to add to all the others you have.
Yes, these constraints and opportunities make computer game design somewhat specialised, but you do still need to know the foundations of all game design if you want to dive in. In the past, because games were considered low-brow, there wasn't much work being done in this area. Nowadays, although games are still considered low-brow, the fact that computer games have made such a cultural impact means that they can no longer be ignored by society at large and there is good work ongoing here. Computer games are now treated as cultural artefacts that can be deconstructed for their meaning, which is A Good Thing. It would be A Better Thing if people could read the gameplay, but as we don't have any theories of gameplay (nor even a decent formal notation for it), that'll be some time coming.
Gameplay simply isn't understood.
People approaching games from a Media Studies background tend to see the motifs and symbols of the game's setting, but not of the gameplay. That's in part because their home field doesn't have a vocabulary for gameplay, but mainly because it doesn't have a process-oriented view of the artefact being studied (the "text"). It reminds me of the arguments I used to hear in the early 1980s (when Computer Science departments still had computer scientists in them) regarding declarative versus procedural programming languages. Declarative languages say what you want done but not how to do it; procedural languages say what you want done in terms of how to do it. Computers are fundamentally procedural, but declarative languages are much more amenable to mathematical analysis (eg. proving the correctness of a program) 2. Their strength lies in the fact that they don't analyse process; however, that's a weakness if you actually want to analyse process. With games, gameplay is fundamentally procedural but it's if being analysed using tools developed for declarative texts, well, they're not really going to be able to capture the essence of what's going on because they don't have any kind of a handle on process.
Interaction between players is procedural. That said, computer games are unusual in that most of those that have been written are single-player. Single-player games aren't actually games at all: they're puzzles. They only really qualify as games if they have computer-controlled opponents that players interpret as behaving intelligently, meaning that players feel they can "lose" to them. This suggests that a lot of the analysis of computer games is actually an analysis of a puzzle in the context of its symbolic dressing. The steps involved in solving the puzzle have a narrative connection that can be read declaratively; the core gameplay loop that gets you from one step in the puzzle to the next has to be read procedurally, so tends to be ignored. It probably can be ignored most of the time, too, to be honest, as it rarely contibutes to the narrative. Sometimes it does — for example, in Dragon Age, the narrative will unfold differently if you favour some party members over others for gameplay reasons — but this is uncommon.
Multi-player games are another thing entirely, especially if they involve competition as well as co-operation. Lit Crit style analyses of these are not going to get very far at all. What does the interplay between strategy and tactics in an RTS "mean" for a narrative? What do the abilities of a character in an RPG "mean" to its player? You can't evaluate, interpret nor understand a game if you can't get a handle on its gameplay. You can't get a handle on its gameplay unless you understand the concept of gameplay. Gameplay is universal to games, whether they're computer games, board games, playground games, word games or sports. The creation of gameplay is at the heart of what game design is. That's why it's of crucial importance to game design.
I teach game design because I want us to have better games. Until we have ways of analysing gameplay, though, "better" is always going to be an intuitive measurement. We do, through player type theory, have an idea of what "better" means for MMOs, but from a developer point of view "better" simply equates to "makes more money than".
At the moment, we're thrashing around in the dark. Those who have the tools to analyse gameplay systematically — the logicians and theoretical computer scientists — simply aren't interested. It would probably take only an hour or two to write an operational semantics for Chess, but none of my colleagues at Essex University who could do it see any point to wasting their time that way. There is movement from the other direction (following Espen Aarseth's work on ergodic literature) but it's not making much progress. I have hopes for Ian Bogost's unit operations, which can capture process, but it hasn't yet fully booted up on gameplay and no-one seems to be using it for analysis. We're getting pieces, but nothing is coming together yet.
Damn, I wish I had the funding to get a PhD student working on this kind of thing...
1 Well, a School of Computer Science and Electronic Engineering that will become a Department of Computer Science if we don't hire more Electronic Engineers to replace the ones who have jumped ship.
2 Of course, this mathematical analysis is itself procedural — you have to "execute" a proof. Thus, if you want to prove that your proof is correct, you have the same declarative versus procedural loop to go through all over again. That's not important when it comes to the analogy with gameplay, but I thought I'd mention it as I like the irony.
Latest entries.
Archived entries.
About this blog.
Copyright © 2012 Richard Bartle (richard@mud.co.uk).