4 ms·

> a useful model Please explain the usefulness of a taxonomy that has "game", "activity", "event", and "toy" as discrete entities.

by dmit 6y ago

Smaug123 6y ago
Rosewater is a game designer; it's his job to distinguish fine details in his area of expertise. I find it interesting to hear an expert dive deep into things, especially into things which I'm familiar with as a complete layman (like games). Anyway, if they were genuinely exactly the same concept, why would we have so many different words for it? Synonyms pretty much never carry exactly the same meaning as each other; they have different colour or shades or whatever.
- dmit 6y ago
  I'm not arguing that all of them are the same thing. I'm 1) wondering why we need to distinguish between them in the first place; and 2) saying there's way to much overlap between the concepts for them to be presented as distinct.
  - Smaug123 6y ago
    Well, to quote the article: > Now that I was making games, I shared Richard [Garfield]'s belief that I needed to have a working idea of what exactly constituted a game. > Even if you're just a game player and have no interest in designing games, I think having a working idea of what you think a game is will shape how you think of games and help you further engage in the hobby. I want to stress that I don't believe it's important that everyone have the same definition of games… but I do believe it's important for each gamer to have a definition that works for them. Today's column is about my definition. This is an article about how a game designer thinks about games. Of course the properties are not orthogonal, but that's not to say the words aren't gesturing towards slightly different parts of concept-space. The words certainly don't cleanly demarcate disjoint chunks of concept-space, but Rosewater's article nevertheless does have some content.
  - danShumway 6y ago
    The point isn't to build categories for their own sake, the point is that categories allow us to group and exclude concepts based on whether they have similar "rules" or "feels". If you're designing a new thing or analyzing an old thing, it's useful to be able to sort through which heuristics and rules will likely apply to the thing you're examining. In other words, if we have generally good advice about how to make a game fun, and you know that advice is predicated on a certain definition of "game", it is easier to figure out whether or not that advice applies to the thing you're building. Rosewater's categorization of Minecraft as a toy rather than a game is a really good example: If you're a game designer, and you think of Minecraft as a game, there are a lot of game rules that Minecraft breaks. Its progression system is wack. It has a lot of design elements that don't really feed into its core loop well. And part of understanding why those "flaws" don't matter is understanding that Minecraft is working under a completely different set of design rules than a game like Doom. So one of the things we do as designers is we add distinctions between different types of experiences that allow us to make rules that are more consistent and predictable. If you're able to split computer experiences into different categories and say, "Minecraft and Doom are fundamentally different", then it's easier to come up with rules around flow, and progression systems, and difficulty curves, and unity of theme. As to why we need those rules in the first place? Because we want to make good games. Without narrowing a design space or coming up with heuristics to filter out good and bad ideas, designing games is just too stinking hard. There are always going to be exceptions to those rules, and that's fine. But the goal is still to give us mechanisms that in most cases allow us to talk about why an idea does or doesn't work. This is the same reason why games build player archetypes. Basically no one fits into a single player archetype, and there's heavy overlap between them, and there are players that defy all of the archetypes we come up with. That does not mean that player archetypes aren't extremely useful as design tools. People think about classification systems like they're some kind of moral or philosophical separation between objects. They're not, classification systems are entirely pragmatic, practical tools. All categorizations are wrong. No maps are completely accurate. But game design is an extremely fuzzy field, and it's hard to figure out what makes "good" design when your subject is so broad that literally every rule you come up with has exceptions. As a designer, I have multiple classification systems that I use for games and players, and some of them outright contradict each other. But all of them are useful lenses that I look through when I need to think about design decisions.

> a useful model Please explain the usefulness of a taxonomy that has "game", "activity", "event", and "toy" as discrete entities.

by dmit 6y ago

> a useful model Please explain the usefulness of a taxonomy that has "game", "activity", "event", and "toy" as discrete entities.

Smaug123 6y ago

Rosewater is a game designer; it's his job to distinguish fine details in his area of expertise. I find it interesting to hear an expert dive deep into things, especially into things which I'm familiar with as a complete layman (like games). Anyway, if they were genuinely exactly the same concept, why would we have so many different words for it? Synonyms pretty much never carry exactly the same meaning as each other; they have different colour or shades or whatever.

dmit 6y ago
I'm not arguing that all of them are the same thing. I'm 1) wondering why we need to distinguish between them in the first place; and 2) saying there's way to much overlap between the concepts for them to be presented as distinct.
- Smaug123 6y ago
  Well, to quote the article: > Now that I was making games, I shared Richard [Garfield]'s belief that I needed to have a working idea of what exactly constituted a game. > Even if you're just a game player and have no interest in designing games, I think having a working idea of what you think a game is will shape how you think of games and help you further engage in the hobby. I want to stress that I don't believe it's important that everyone have the same definition of games… but I do believe it's important for each gamer to have a definition that works for them. Today's column is about my definition. This is an article about how a game designer thinks about games. Of course the properties are not orthogonal, but that's not to say the words aren't gesturing towards slightly different parts of concept-space. The words certainly don't cleanly demarcate disjoint chunks of concept-space, but Rosewater's article nevertheless does have some content.
- danShumway 6y ago
  The point isn't to build categories for their own sake, the point is that categories allow us to group and exclude concepts based on whether they have similar "rules" or "feels". If you're designing a new thing or analyzing an old thing, it's useful to be able to sort through which heuristics and rules will likely apply to the thing you're examining. In other words, if we have generally good advice about how to make a game fun, and you know that advice is predicated on a certain definition of "game", it is easier to figure out whether or not that advice applies to the thing you're building. Rosewater's categorization of Minecraft as a toy rather than a game is a really good example: If you're a game designer, and you think of Minecraft as a game, there are a lot of game rules that Minecraft breaks. Its progression system is wack. It has a lot of design elements that don't really feed into its core loop well. And part of understanding why those "flaws" don't matter is understanding that Minecraft is working under a completely different set of design rules than a game like Doom. So one of the things we do as designers is we add distinctions between different types of experiences that allow us to make rules that are more consistent and predictable. If you're able to split computer experiences into different categories and say, "Minecraft and Doom are fundamentally different", then it's easier to come up with rules around flow, and progression systems, and difficulty curves, and unity of theme. As to why we need those rules in the first place? Because we want to make good games. Without narrowing a design space or coming up with heuristics to filter out good and bad ideas, designing games is just too stinking hard. There are always going to be exceptions to those rules, and that's fine. But the goal is still to give us mechanisms that in most cases allow us to talk about why an idea does or doesn't work. This is the same reason why games build player archetypes. Basically no one fits into a single player archetype, and there's heavy overlap between them, and there are players that defy all of the archetypes we come up with. That does not mean that player archetypes aren't extremely useful as design tools. People think about classification systems like they're some kind of moral or philosophical separation between objects. They're not, classification systems are entirely pragmatic, practical tools. All categorizations are wrong. No maps are completely accurate. But game design is an extremely fuzzy field, and it's hard to figure out what makes "good" design when your subject is so broad that literally every rule you come up with has exceptions. As a designer, I have multiple classification systems that I use for games and players, and some of them outright contradict each other. But all of them are useful lenses that I look through when I need to think about design decisions.