> for example, that page of 300 video game design ideas are likely mostly or entirely interesting at face value—but without being tested, are basically entirely meaningless.

You happened to pick one of the much less worked examples; and also one that I would argue really isn't a "game mechanic" in the way it's traditionally meant.

Try https://www.squidi.net/three/entry.php?id=131 or https://www.squidi.net/three/entry.php?id=124. These are examples of game-mechanical systems — conceptual systems or rulesets from which derive a combinatoric flood of inspiration for possible challenges (as the application of those systems or rules), that in turn inform the entire scenario design of the game.

The two-button thing is an interaction mechanic — which obviously isn't something you can paper prototype. Which is probably why it's just notes rather than a worked example. A worked example of an interaction mechanic would be interactive!

> many people disagree with my assessment here, because they want to believe that it's possible to create a design for a video game that is unique and interesting and special, whole-cloth, without ever writing a single line of code.

I don't know who believes this. I certainly don't. My argument is that you can discover novel, dense, combinatoric challenge spaces that arise from systems of rules, without writing a line of code. Spaces of scenario-element design.

(These aren't games, though. They're the potential for games. Or rather, potentials for novel game [sub-]genres — novel kinds of challenges. You still have to actually build them to see whether it's possible to find interaction-mechanics that translate these conceptual challenges into fun real challenges.)

And maybe you can't discover the challenge-space inherent to something like Braid, but like I said in my previous post, Braid is an "art game" — not the kind of thing that works well with paper prototyping. (More specifically, Braid is a modern art game: a game that is as much about the medium and its constraints as it is about some objective concept. Braid is to the computer platformer genre as Mondrian's works are to paintings.)

Inexperienced game designers should not be attempting to make "art games" — as they don't yet understand the constraints of the medium they're operating under.

My argument is that an inexperienced game designer who wants to really do game design, should do paper prototyping when doing initial ideation of game mechanics, because this will force them out of the rut of tinkering around inside Blender or Game Maker or RPG Maker or whatever — i.e. the thing that "game designer/developers" would do by default, which tends to lock them into genre and makes certain parts of game-mechanics-space more "available" than others (because those parts are available wholesale as libraries or as part of the runtime/framework; or because other people have already done things like that and so produced assets for something like that available in an asset store, etc.)

Even though this prevents them from exploring some parts of game-mechanics space (e.g. the art-game parts), the parts that will be accessible to them through paper prototyping, will be parts less explored by most game designers, with much low-hanging fruit still left to pluck. And the fact that these parts of game-mechanics space are unexplored, will keep away the automatic bias that "designer/developers" have toward mechanics that are easy to implement.

An experienced game designer doesn't need paper prototyping — they understand well the strengths and limitations of the greater "digital interactive medium", and so they can just imagine game mechanics into existence, and then go implement them. They have all the tools in their mental toolkit to know what it would look and play like, to implement something like Braid. So they can and should just go do that. Experienced designers would be wasting their talents on anything less!

But nobody starts experienced. You have to get that experience somehow. And IMHO the fastest method is to sit down with arts-and-crafts stuff to generate some truly "outsider art" game-mechanics, and then turn around and push the medium as hard as you can to implement those mechanics. Maybe they'll be fun, maybe they won't; but you'll certainly learn a lot more about both the medium and about "what's fun" than if you were just exploring the part of game-mechanical challenge-space lit by the streetlight of your game-runtime of choice.

> Miyamoto is not, and never really has been, what we would traditionally call a "game designer"—from what I can tell from reading numerous interviews, both with him and others who worked with him over the years, he's more like a Steve Jobs-type figure. he comes up with a broad interesting idea or set of ideas or even just general vibe, and then it's up to the programmers (and probably game designers nowadays) to figure out how to turn those ideas into an actual game.

I mean, "coming up with a broad interesting idea or set of ideas" is exactly what I've been talking about here — designing the game mechanics, coming up with the systems that both define and constrain the game-elements. I'm not talking about "game design" as in writing a design document, defining the whole game on a top-down level. I'm talking about finding a thing that makes the game into the game that it is; ideating the concept or system that can end up defining a new game series, or a whole new game genre.

Miyamoto does that. And I don't think he does it at a computer. (He probably mostly does it with his feet up on his desk, these days, since he's a very experienced designer at this point. But back when he designed Donkey Kong, he almost certainly designed it on paper. Especially because, for an arcade machine, the hardware to make the game possible to implement is designed in response to the game design!)

The other thing Miyamoto is, though, is a product manager. He says "no" to things. And so the ideas of the developers and game designers working below a Miyamoto-led (or Miyamoto-produced!) project, go through this veto filter — the output of which is almost always a very Miyamoto-esque game design, however much or little micromanagement he did of it.