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.

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.

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.

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.

I think the other point is that no taxonomies are authoritative. Most of the arguing comes from either people trying to diminish the work of others with negative descriptions or from people assuming others are trying to be authoritative rather than merely descriptive of their own work.

For everyone that doesn't think Minecraft is a game there are a bunch of people making, playing and talking about Sandbox Games.

That's a really good point.

One thing I try to get across to people when I'm talking about this is that not only are no taxonomies "official", but they even sometimes contradict each other, and that doesn't diminish their usefulness.

All models are at best approximations of reality, all taxonomies are based on somewhat arbitrary distinctions. The point is what the model/taxonomy can do for you. So if you have two models that give different results when fed the same input, that doesn't necessarily mean that one of them is broken. It might mean they're optimizing for accuracy in different directions, and that you need to think about which model is more applicable to the current situation you're in.

The game vs toy debate seems to get people more upset, I suspect in part because that was a debate used by some people who wanted to diminish the artistic value of Walking Simulators or other more experimental genres.

This even goes outside games for example in biology and taxonomies of species.

https://en.wikipedia.org/wiki/Species_concept

Thank you for the elaborate reply! There's a lot of room for thought there!

But while I'm here... Minecraft is a quintessential roguelike game. You arrive, naked and alone, on a hostile world. You then build yourself up by the skin of whatever. You mine and farm and build, and you acquire food and clothes for yourself. The only rule Minecraft broke is the one that says you can't code a financially viable game in Java.

(I guess there's no ascension, but at that point you've built heaven on earth anyway, so there's no reason to leave.)

> As to why we need those rules in the first place? Because we want to make good games.

I'm sorry, but super no. No game designer has ever feared that they would end up with a good toy, or a great activity, rather than making bank on Steam.

> All categorizations are wrong. No maps are completely accurate.

That's right! "All models are wrong, but some are useful." I was merely wondering what the use of the model presented by GP was.

In many ways, Minecraft is the polar opposite of a roguelike.

In a classic roguelike (Rogue, Moria, Angband, Hack, NetHack, etc.), everything you do is in service to the singular goal of delivering the killing blow to Morgoth or picking up the Amulet of Yendor. That's the whole game. Everything else is just a stepping stone to reach the turn that declares you winner. There are no real "side" quests because the whole point of everything is to acquire the equipment, consumables, and experience needed to survive the final battle.

Minecraft is the exact opposite. It takes about five minutes to build enough of a base to survive indefinitely. After that, you've essentially "won". For many years, Minecraft didn't have the End Dragon or anything approaching and "final boss". Even after adding it, in the culture of Minecraft, many players don't consider that the goal of the game. The game itself does not end after you've beaten the End Dragon. In fact, doing so gives you new items which implies there are useful play actions to do after killing the End Dragon.

Classic roguelikes are a game where most players don't really get to define what it means to win. The game explicitly says what your goal is. Minecraft is more like a play space that gives you a number of options to explore but it's mostly up to you to decide what kind of game you wish to play in there. I've played Minecraft for years and I've never been to the End, even though I almost exclusively play in survival mode.

You can play roguelikes like they're Minecraft (I used to carry a pet slime mold for fun in Angband) and you can play Minecraft like a roguelike (kill the End Dragon as efficiently as possible and then declare it over), but the games-as-artifacts themselves don't push you in the same direction.

> I was merely wondering what the use of the model presented by GP was.

For my money it's just a clarity of thought thing. The author and people that like his model can use it to guide their work. Similar to using design pillars but at a higher level.

Sorry.

For clarity of thought I mean if you decide to make a game you might want to work out what a game is to you. Like a mission statement that you can use as a razor to judge your subsequent ideas.

Design pillars are similar but about specific aspects of a game. A set of principles you can use to guide development.

> I'm sorry, but super no. No game designer has ever feared that they would end up with a good toy, or a great activity, rather than making bank on Steam.

If you want to make Minecraft, make Minecraft. If you want to make Doom, make Doom. These categories are not about validating or condemning either experience.

The point of the categorization isn't to say, "I can't do this because I would be making a toy instead of a game." The point is to say, "I want to make a game/toy, and because of that, I know that there are certain design heuristics that I need to pay attention to."

> The only rule Minecraft broke is the one that says you can't code a financially viable game in Java.

And the lack of permadeath for most players, and the general lack of resource scarcity, and the lack of difficulty increase as gameplay progresses, and the lack of a narrative justification for the world, and the lack of a single clear goal (ascend), and the lack of any kind of scoring system, and the blurring between cosmetic and gameplay rewards, and a bunch of other things.

Minecraft is brilliant. And if Notch had sat down and looked at Rogue and said, "this is where I'll get my design ideas", then Minecraft wouldn't have been brilliant. It's a fundamentally different experience than something like Rogue, or even Rogue-lites in the vein of Enter the Gungeon. It's fundamentally different even from other crafting/building games like Terraria, which have much more traditional game-elements like difficulty curves and general progression systems.

It doesn't really matter whether or not you want to call Minecraft a game. But it is useful to look at a game like Minecraft and to be able to say, "yes, I know that Minecraft decouples resource rarity from resource value, but that's because Minecraft is doing something different than other games, and in most games that would be a bad idea."

Game design is about filtering ideas. There are an infinite number of things a game can do, so a tool that lets us zero in on which ideas are likely to be good or are likely to be bad is extremely valuable.

You're right that the mark of a great designer is not in religiously sticking to a certain category. However, it often is the mark of a great designer that when presented with 7 or 8 ideas, they can quickly pick out, "this idea is worth implementing, and this one isn't". Categorizations help with that.

I have seen many designers look at very outside-the-box games like Minecraft or Animal Crossing and say, "well, I can reuse any design decision from those games." But the only reason those atypical design decisions work in those games is because they are atypical games that commit to a consistent philosophy. Understanding the core of that philosophy is what allows a designer to intuit whether or not two design decisions work together.

Making a good toy or great activity is awesome. But if you make a weird hybrid between a game and a toy with discordant design elements that contradict each other, that's just a bad experience in general, no matter what you want to call it. Categories allow us to group design elements that work well together and exclude design elements that are discordant. Understanding common categories allows us to predict when we might be falling into the trap of including discordant mechanics in our games.

TFA explicitly distinguishes between minecraft’s survival mode and sandbox mode, which is more like playing with lego.