There's also certainly the intent behind it, which is, "Are you trying to create a thing which is going to be really interesting to people, or are you trying to create this thing because you know people enjoy playing it?" Do you think that may have to do with some of that?

SH: Yeah, I'm aiming at the "fun" part myself, and money will come as a result of people having fun. It's much harder to do it the other way. If I'm out to make money, people don't have fun.

I wanted to talk about the concept of "game grammar" as espoused by Raph Koster.

SH: Establishing a grammar which would be accepted by everybody is obviously impossible to do. Given that we're talking about a global scope -- you'll definitely have to agree on a language to be used, when a lot of people are used to local dialects. That's going to be pretty hard to do. But I do subscribe to the idea of actually having a many dialects for communicating between people. That's kind of defined in the sense that they can actually communicate the idea. Especially if you have a problem in the design -- you can point to the exact point in the design that you think is flawed and causes the game to be not fun.

As I was saying earlier, there's this long talk on four different projects where people say that a game is not fun, but they actually can't say what's causing the game to be not fun. It could be the tiniest little detail, for example the user not getting adequate feedback for his actions. That might be immediately obvious and a designer could actually communicate that.

But especially if you're talking with someone who is not a designer -- it's real hard for these people to analyze these designs and be able to communicate exactly what their meaning would be, in the issues that they're trying to bring up. At least, if the grammar can be made simple enough so that even the non-designers could actually use it, it would be really beneficial for the industry, and I guess even for people outside the industry.

When I was talking to Denis Dyack, I was saying that with film, people understand the basic ideas like long shots, cuts, and things like that. People understand the terms that make up films. The only terms that we've established within the game industry, for the most part, aside from genre, are very technical terms that people don't understand. It wouldn't make sense to artificially create those terms, but if we could naturally evolve those terms so that people could understand those things easier, I think that would be really beneficial.

SH: Yeah, but if you look at the movie industry, those terms are pretty technical as well. A cut is really concretely referring to you cutting the film and changing to a different plate.

But it is conceptually easy to understand, because there's a break there. People know there's a break. And also for a long shot -- people know it's far away.

SH: Yeah, but I guess those are visual terms, so in the context of games, if people wanted to use similar things, you would be referring to the art of the game, and not actually the gameplay. You actually could be using the majority of the same vocabulary to talk about visuals within a game. It would be completely applicable, but Raph was talking about the more abstract part of the game -- the various activities that people are doing.

I guess there are some concrete examples of the abstract stuff that people actually know the terms for, like grinding, which is an activity that people do in the game that can be used to describe pretty accurately what it's all about. There's grinding, and Raph's actually talking about a grind as well, and saying there's a lot of games where you do grind, but the activity itself is obviously very different. But you can actually quantify different types of activities as grinding. I recall that he had some specific examples as to why that could be avoided.

I guess the vocabulary actually is establishing itself, but that's also... if you do look at grinding as a specific example, it's also partially because the games are actually doing similar things. People are used to doing grinding on so many different games. It's a phenomenon that's recognized by a population of people.

Given that it's actually hard to look at the abstract game design and separate that from the visuals, which is pretty much what Raph was talking about, it's harder to communicate about the game behind the visuals, because you need to go a couple of levels of thought deeper into what it really was that you were doing. And there's no need to actually do that.

Certainly he's really talking about the more binary level of games -- the games that take place within the games each second that you're playing.

SH: Yeah. I've been looking at the vocabulary defined by Eric Zimmerman in his books, and there's some really concrete, simple things that he's been quantifying, and telling that these things need to be in place for a game to be fun. Some are really concrete things, like the example I used earlier -- that players, when you do an action, need an immediate response, so that they know the action was committed. There are games where that's lacking, and that really does make the game not fun.

If you don't get a response, you don't know what you did wrong, and as a result, you know there's something missing. If you're talking about a game design and that's missing, it might be that the users can't really quantify and tell that that's the part that they felt was missing from the design. But if you actually do know that there is this thing and that vocabulary phrase telling that thing, it's going to be easier to communicate it.

It seems like there's almost a higher tolerance for that in the casual game market, because people expect computers to take some time to do something, especially with more casual users. That's just my perception. I don't know if you have thought about that at all. It seems to me like the delay of cause and effect is not as much of an issue there as it is in the more hardcore area.

SH: I don't think that's true at all. If you look at any of the Web 2.0 sites that are doing really well, like Flickr, it's packed full of these little visual cues that something's happening. Practically every time you actually press a button, the button changes, or you get a little progress indicator that something's happening. It might take a long time for the next page to load, but you at least know that something is happening.

That's especially important with AJAX stuff. The browser can't tell you that something is being loaded, so most of the really popular sites have implemented cues where the user actually does think that the UI is being responsive. It actually does work really well. If a page takes like five seconds to load, and that's the consistent behavior of your site, people will get bored pretty easily. You do have to do something about it, and tricking the UI to look a bit more responsive is a good tool.