> Doing too much design upfront can even be detrimental!
I totally agree! Doing too much game design up front can be detrimental!
But there's no such thing as "too much design" of a mechanic, because a mechanic is only a certain size.
And also, when you're designing a mechanic, you aren't usually designing it in the context of a game. You're often designing it for its own sake — and then you might see a way to make a game that just is that mechanic... or maybe not.
By analogy to programming:
Game design is like software architecture. Doing it up front (waterfall model) is bad, because you don't know enough about the game / what makes it fun yet. The only model that will get the design right is a gradual one that works hand-in-hand with development iteration and client validation.
Game mechanics design is like designing an algorithm or data structure.
• It's an act of invention, and the result has value all on its own, separate from being applied in a use-case.
• A novel one is invented in a moment of inspiration, usually arriving as a gestalt top-down sense of how the whole thing should work.
• That moment of inspiration will strike at random (though more often if you keep yourself in a receptive mindset for it, and know a ton about existing ones for your mind to do lateral-thinking against.) It's not something you can force.
• Trying to capture the idea will put you in a fugue state of furious writing, like trying to capture a fleeting dream in a dream journal upon waking. You won't want to stop because you'll lose the gestalt "sensation" of the idea, that you're using to generate the individual concrete working model of it, and there'll be no good way to get that gestalt sensation back, if you haven't fully realized the idea on paper. (Though, you might stop if you decide that the idea doesn't feel worth the time it takes to capture it.)
• This will go on for exactly as long as it takes. Maybe two minutes. Maybe three hours. Maybe four days. (You want to use a medium to capture your idea that minimizes the time. Don't prototype it in any sense yet; that'll require you hold the gestalt longer!)
• Once it's done, it's done. There are no more corollaries to the idea; the sponge has been wrung dry. You've successfully captured/communicated the concrete/formal partwise shadow of the gestalt sensation, allowing you to conjure it back at any time by reading your notes.
• Maybe you ended up with five bullet points. Or maybe a 100-page document. Either way, the notes themselves — and their level of detail — aren't the point. They only exist to summon back that gestalt sensation, in yourself and in others. To communicate the spirit of the idea, such that you or someone else who goes to actually use it, won't implement or integrate it in such a way that it "does what it says" without capturing that gestalt.
• If you are drained at this point, you put these notes away for later.
• But if you're still very excited by the idea at this point, then you immediately move on to prototyping — proving your idea out. You're turning those notes (probably full of private jargon) into something other people can understand the value of.
It's at this stage — when you have the notes for a discrete game mechanic, that has never been seen in a game before, and so has no clear "fun value" yet even in abstract — when you'd do paper prototyping.
(If you're working in a studio context, you'd likely be required to do this, to "sell" your concept to others — in the same way an architect of buildings makes architectural models to communicate their own design intent.)
This is analogous to the person who has an idea for a novel algorithm, taking their pseudocode and actually coding the algorithm in some language, to find out whether, when the algorithm is turned from a hand-wave-y declarative definition, into imperative code, it's practical / efficient to use.
Where do algorithms go when they've been proven out? Not directly into applications — at least not usually! (Not unless the algorithm unlocks the possibility of building a new kind of application, and you're the one to do that.) Instead, algorithms go into journal papers; library reference implementations; or language runtimes.
Where do game mechanics go when they've been proven out? Not directly into games — at least not usually! (Not unless the mechanic unlocks the possibility of building a new kind of game, and you're the one to do that.) Like I said, I keep mine in binders. And in theory, you could build a certain kind of game mechanic into some sort of component you could buy in an asset store.
But really, where novel game mechanics should be going — but aren't (because there isn't such a thing) — is to journal papers as well. In a journal of "gameplay systems research", probably treated as a interdisciplinary field crossing HCI and behavioral economics.
I totally agree! Doing too much game design up front can be detrimental!
But there's no such thing as "too much design" of a mechanic, because a mechanic is only a certain size.
And also, when you're designing a mechanic, you aren't usually designing it in the context of a game. You're often designing it for its own sake — and then you might see a way to make a game that just is that mechanic... or maybe not.
By analogy to programming:
Game design is like software architecture. Doing it up front (waterfall model) is bad, because you don't know enough about the game / what makes it fun yet. The only model that will get the design right is a gradual one that works hand-in-hand with development iteration and client validation.
Game mechanics design is like designing an algorithm or data structure.
• It's an act of invention, and the result has value all on its own, separate from being applied in a use-case.
• A novel one is invented in a moment of inspiration, usually arriving as a gestalt top-down sense of how the whole thing should work.
• That moment of inspiration will strike at random (though more often if you keep yourself in a receptive mindset for it, and know a ton about existing ones for your mind to do lateral-thinking against.) It's not something you can force.
• Trying to capture the idea will put you in a fugue state of furious writing, like trying to capture a fleeting dream in a dream journal upon waking. You won't want to stop because you'll lose the gestalt "sensation" of the idea, that you're using to generate the individual concrete working model of it, and there'll be no good way to get that gestalt sensation back, if you haven't fully realized the idea on paper. (Though, you might stop if you decide that the idea doesn't feel worth the time it takes to capture it.)
• This will go on for exactly as long as it takes. Maybe two minutes. Maybe three hours. Maybe four days. (You want to use a medium to capture your idea that minimizes the time. Don't prototype it in any sense yet; that'll require you hold the gestalt longer!)
• Once it's done, it's done. There are no more corollaries to the idea; the sponge has been wrung dry. You've successfully captured/communicated the concrete/formal partwise shadow of the gestalt sensation, allowing you to conjure it back at any time by reading your notes.
• Maybe you ended up with five bullet points. Or maybe a 100-page document. Either way, the notes themselves — and their level of detail — aren't the point. They only exist to summon back that gestalt sensation, in yourself and in others. To communicate the spirit of the idea, such that you or someone else who goes to actually use it, won't implement or integrate it in such a way that it "does what it says" without capturing that gestalt.
• If you are drained at this point, you put these notes away for later.
• But if you're still very excited by the idea at this point, then you immediately move on to prototyping — proving your idea out. You're turning those notes (probably full of private jargon) into something other people can understand the value of.
It's at this stage — when you have the notes for a discrete game mechanic, that has never been seen in a game before, and so has no clear "fun value" yet even in abstract — when you'd do paper prototyping.
(If you're working in a studio context, you'd likely be required to do this, to "sell" your concept to others — in the same way an architect of buildings makes architectural models to communicate their own design intent.)
This is analogous to the person who has an idea for a novel algorithm, taking their pseudocode and actually coding the algorithm in some language, to find out whether, when the algorithm is turned from a hand-wave-y declarative definition, into imperative code, it's practical / efficient to use.
Where do algorithms go when they've been proven out? Not directly into applications — at least not usually! (Not unless the algorithm unlocks the possibility of building a new kind of application, and you're the one to do that.) Instead, algorithms go into journal papers; library reference implementations; or language runtimes.
Where do game mechanics go when they've been proven out? Not directly into games — at least not usually! (Not unless the mechanic unlocks the possibility of building a new kind of game, and you're the one to do that.) Like I said, I keep mine in binders. And in theory, you could build a certain kind of game mechanic into some sort of component you could buy in an asset store.
But really, where novel game mechanics should be going — but aren't (because there isn't such a thing) — is to journal papers as well. In a journal of "gameplay systems research", probably treated as a interdisciplinary field crossing HCI and behavioral economics.
I want to subscribe to that journal! Don't you?