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.

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.

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.