4 ms·

> 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

by derefr 3y ago

> 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 https://www.squidi.net/three/entry.php?id=131 or https://www.squidi.net/three/entry.php?id=124 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.

meheleventyone 3y ago
Have you actually designed a game whether inexperienced or not? You generate a lot of verbiage without a lot of insight IMO. Ruminating on how games might be designed is all very well but it isn’t how they’re actually designed. Don’t mistake your strong opinions for good advice whether to inexperienced or experienced designers.
- derefr 3y ago
  > You generate a lot of verbiage without a lot of insight IMO. I do apologize for not having the time to edit these comments to be shorter. But if I did have the time to edit and polish text, then the polished text would have value as a blog post, so I wouldn't post it here. I see HN as a place for unpolished conversation — i.e. a place to drop long bullshit rants on people. AFAICT, this is how other people mostly see HN as well — they just don't type as fast, and so don't have time to write screeds as stupidly long as mine on their coffee breaks. > Have you actually designed a game whether inexperienced or not? Yes. I spent much of my teens and 20s designing games (first mods, then original games); immersing myself in the game design community; reading every book or blog post on the art of game design I could get my hands on, along with tons of interviews with game designers (and this was before decent ML translation, so I had to pay to get some translated, and also ended up learning functional Japanese because it came up so often); collaborating with other game designers and game developers online, and participating in game jams for things like puzzle-boxes and one-page TTRPGs; reverse-engineering the designs of games I love to determine what's so good about them, and the designs of games that "suck" to determine where the fatal flaw is, turning those into blog posts, and learning from the discussion those posts generate; etc. I have huge binders full of fully-worked game designs, many many paper prototypes, and many repos containing half-developed games that stalled on the custom-engine-development part (which led me directly to the advice that inexperienced designers should not attempt to design "art games", because they won't yet have a sense of what's practical in the medium.) And I used to have a blog much like the one I linked to, where I posted some of these as public-domain works, encouraging others to take them and build them. In my 20s, I set out to learn programming deeply in order to be able to pull off the development side of these more unique game concepts. My goal was to do one-man indie game development of fully-polished works — so there were a number of skills I needed to acquire, and programming was just the first. But I never got to the point of actually starting that studio, or of learning most of the other required skills, as I studied programming a bit too deeply and ended up as the CTO and cofounder of a very much not-gaming (financial data-analytics) company. Which is not to say I gave up on my dream. I just don't currently have time to execute on it. My eventual F-U money from this company, will be put directly toward my goal. My life's work is in games, not in programming. > Ruminating on how games might be designed is all very well but it isn’t how they’re actually designed. Though, with all of the above being said, I think you might not be aware of a distinction. I was trying to ignore it so far because it's the kind of finicky pedantry that nobody cares about if they're not already working in the field. But it's important here. A "game-mechanics designer" (sometimes called a "gameplay designer" or "systems designer", depending on the studio) isn't the same thing as a "game designer." The output of a game-mechanics designer, is mechanics, not games. In other words, the whole job of a game-mechanics designer, is to create "ways games might be designed." This distinction is behind my point about Miyamoto above: as a director of a game, he designs/offers up mechanics to the design team, and always has; he has never designed whole games. Designing whole games is not his job. Designing (or deciding on) game mechanics, is. Sometimes he thinks of a single mechanic and, boom — obvious game concept, built around just that one mechanic. Even if everything else in the game is derivative, it'll still be novel, because of that one mechanic. He takes that mechanic and pitches it to other Nintendo leadership as "the concept of the game." If someone scoffs, he has one of his EAD1 team-members prototype the mechanic, to prove out the fun. And then, assuming he's convinced everyone, that mechanic becomes the core for a project assignment brief to one of the development teams, where Miyamoto then serves as a product manager and creative director — that brief being, to build a game that develops naturally out the challenge-space of that mechanic. (He has defined exactly this workflow in numerous interviews.) Other times, he thinks of a mechanic, and it's not good enough on its own to be a game. Shelves it. Then, whenever a development project is spinning its wheels in the "prototyping to find the fun" phase, he looks at his mechanics backburner. Considers what each one might add to the combinatoric challenge-space complexity of the project. If there's a good one, he asks the design team to do a proof-of-concept rework of the base design of the game with that system made core to it. And often that's enough to give the project momentum. (Again, has mentioned this in numerous interviews. For one famous example of this: Yoshi's Island wasn't always a Yoshi game! Yoshi, and specifically the egg-laying-and-throwing, was worked into an existing game that was stuck in "design hell", the close neighbour of "development hell.") A game-mechanics designer, is to a game designer, is to a game developer, as: • a speedrun glitch/tech hunter (ideates tech, with a lot of thinking offline, and reverse-engineering the game, and "fact-finding experiments" by probing memory using debuggers, etc — and then just a little actual attempting-to-make-it-work); is to a speedrun route planner (takes tech and plans and produces practicable potentially-faster routes; does a lot of interactive R&D using e.g. TAS tools to prove out the route but also to figure out when and where the new tech works, i.e. what its constraints are); is to a speedrunner (takes a route plan, and executes on it to produce actual runs.) Someone can be all three, but these are still separate hats! • mechanical-engineering inventor (ideates something like "a wound spring used as a timer", produces a patent); is to a toy designer (licenses the patent, designs and prototypes a pop-goes-the-weasel box); is to a toy manufacturer (gets 100k such boxes made in a factory, sourcing the parts, figuring out the shipping logistics, etc.) Again: the same guy who invents the timing spring might then turn it into the pop-goes-the-weasel box, and even commercialize it. But, all different hats. --- The thing I personally love, and live to do, is game-mechanics design. My goal has was never really to be a game designer; and my advice isn't really targeted at people whose true goal is to pursue game design. However, I wasn't always aware that I really wanted to design game mechanics specifically. And I think this is a common thing. There are a lot of game designers who have never designed a novel game mechanic in their entire lives, even though they want to produce — their goal and their dream is to produce — novel and innovative games. To me, this says that they really want to be designing mechanics, but just aren't aware of it yet. These people never attempt to ideate on mechanics, because they don't think of game-mechanic design as this separate thing that you can intentionally set out to do. They think of novel game mechanics as only being things that might magically arise one day out of the aether while they're sketching out or implementing a game. And that kind of thinking, is the reason that we don't have more Miyamotos in the world. The Narbacular Drop folks developed a game with an innovative core gameplay mechanic, because DigiPen, as part both their Game Design and Real-Time Interactive Simulation programs, actually has classes on gameplay design and systems design, that teach students a reified concept of game mechanics. DigiPen also requires students to study industry advances (reading journals and conference proceedings, etc) and consider how the state-of-the-art can be evolved. Together, this means that students are thinking about how to create games with innovative mechanics, rather than just aiming for "innovative games" as black boxes. Which is to say: this mode of thinking gets results! So, with all that being said, let me restate my premise from my original comment: Paper prototyping is a way to do gameplay-systems design, separate from doing game design. This enables you to explore gameplay-systems design as its own discipline. You can also do gameplay-systems design interactively on a computer — but it's so very easy to get distracted into doing game design/development on a computer, that if you only ever use a computer, you may never end up putting any brain-power into doing gameplay-systems design at all.

by derefr 3y ago

meheleventyone 3y ago

Have you actually designed a game whether inexperienced or not? You generate a lot of verbiage without a lot of insight IMO. Ruminating on how games might be designed is all very well but it isn’t how they’re actually designed. Don’t mistake your strong opinions for good advice whether to inexperienced or experienced designers.

derefr 3y ago
> You generate a lot of verbiage without a lot of insight IMO. I do apologize for not having the time to edit these comments to be shorter. But if I did have the time to edit and polish text, then the polished text would have value as a blog post, so I wouldn't post it here. I see HN as a place for unpolished conversation — i.e. a place to drop long bullshit rants on people. AFAICT, this is how other people mostly see HN as well — they just don't type as fast, and so don't have time to write screeds as stupidly long as mine on their coffee breaks. > Have you actually designed a game whether inexperienced or not? Yes. I spent much of my teens and 20s designing games (first mods, then original games); immersing myself in the game design community; reading every book or blog post on the art of game design I could get my hands on, along with tons of interviews with game designers (and this was before decent ML translation, so I had to pay to get some translated, and also ended up learning functional Japanese because it came up so often); collaborating with other game designers and game developers online, and participating in game jams for things like puzzle-boxes and one-page TTRPGs; reverse-engineering the designs of games I love to determine what's so good about them, and the designs of games that "suck" to determine where the fatal flaw is, turning those into blog posts, and learning from the discussion those posts generate; etc. I have huge binders full of fully-worked game designs, many many paper prototypes, and many repos containing half-developed games that stalled on the custom-engine-development part (which led me directly to the advice that inexperienced designers should not attempt to design "art games", because they won't yet have a sense of what's practical in the medium.) And I used to have a blog much like the one I linked to, where I posted some of these as public-domain works, encouraging others to take them and build them. In my 20s, I set out to learn programming deeply in order to be able to pull off the development side of these more unique game concepts. My goal was to do one-man indie game development of fully-polished works — so there were a number of skills I needed to acquire, and programming was just the first. But I never got to the point of actually starting that studio, or of learning most of the other required skills, as I studied programming a bit too deeply and ended up as the CTO and cofounder of a very much not-gaming (financial data-analytics) company. Which is not to say I gave up on my dream. I just don't currently have time to execute on it. My eventual F-U money from this company, will be put directly toward my goal. My life's work is in games, not in programming. > Ruminating on how games might be designed is all very well but it isn’t how they’re actually designed. Though, with all of the above being said, I think you might not be aware of a distinction. I was trying to ignore it so far because it's the kind of finicky pedantry that nobody cares about if they're not already working in the field. But it's important here. A "game-mechanics designer" (sometimes called a "gameplay designer" or "systems designer", depending on the studio) isn't the same thing as a "game designer." The output of a game-mechanics designer, is mechanics, not games. In other words, the whole job of a game-mechanics designer, is to create "ways games might be designed." This distinction is behind my point about Miyamoto above: as a director of a game, he designs/offers up mechanics to the design team, and always has; he has never designed whole games. Designing whole games is not his job. Designing (or deciding on) game mechanics, is. Sometimes he thinks of a single mechanic and, boom — obvious game concept, built around just that one mechanic. Even if everything else in the game is derivative, it'll still be novel, because of that one mechanic. He takes that mechanic and pitches it to other Nintendo leadership as "the concept of the game." If someone scoffs, he has one of his EAD1 team-members prototype the mechanic, to prove out the fun. And then, assuming he's convinced everyone, that mechanic becomes the core for a project assignment brief to one of the development teams, where Miyamoto then serves as a product manager and creative director — that brief being, to build a game that develops naturally out the challenge-space of that mechanic. (He has defined exactly this workflow in numerous interviews.) Other times, he thinks of a mechanic, and it's not good enough on its own to be a game. Shelves it. Then, whenever a development project is spinning its wheels in the "prototyping to find the fun" phase, he looks at his mechanics backburner. Considers what each one might add to the combinatoric challenge-space complexity of the project. If there's a good one, he asks the design team to do a proof-of-concept rework of the base design of the game with that system made core to it. And often that's enough to give the project momentum. (Again, has mentioned this in numerous interviews. For one famous example of this: Yoshi's Island wasn't always a Yoshi game! Yoshi, and specifically the egg-laying-and-throwing, was worked into an existing game that was stuck in "design hell", the close neighbour of "development hell.") A game-mechanics designer, is to a game designer, is to a game developer, as: • a speedrun glitch/tech hunter (ideates tech, with a lot of thinking offline, and reverse-engineering the game, and "fact-finding experiments" by probing memory using debuggers, etc — and then just a little actual attempting-to-make-it-work); is to a speedrun route planner (takes tech and plans and produces practicable potentially-faster routes; does a lot of interactive R&D using e.g. TAS tools to prove out the route but also to figure out when and where the new tech works, i.e. what its constraints are); is to a speedrunner (takes a route plan, and executes on it to produce actual runs.) Someone can be all three, but these are still separate hats! • mechanical-engineering inventor (ideates something like "a wound spring used as a timer", produces a patent); is to a toy designer (licenses the patent, designs and prototypes a pop-goes-the-weasel box); is to a toy manufacturer (gets 100k such boxes made in a factory, sourcing the parts, figuring out the shipping logistics, etc.) Again: the same guy who invents the timing spring might then turn it into the pop-goes-the-weasel box, and even commercialize it. But, all different hats. --- The thing I personally love, and live to do, is game-mechanics design. My goal has was never really to be a game designer; and my advice isn't really targeted at people whose true goal is to pursue game design. However, I wasn't always aware that I really wanted to design game mechanics specifically. And I think this is a common thing. There are a lot of game designers who have never designed a novel game mechanic in their entire lives, even though they want to produce — their goal and their dream is to produce — novel and innovative games. To me, this says that they really want to be designing mechanics, but just aren't aware of it yet. These people never attempt to ideate on mechanics, because they don't think of game-mechanic design as this separate thing that you can intentionally set out to do. They think of novel game mechanics as only being things that might magically arise one day out of the aether while they're sketching out or implementing a game. And that kind of thinking, is the reason that we don't have more Miyamotos in the world. The Narbacular Drop folks developed a game with an innovative core gameplay mechanic, because DigiPen, as part both their Game Design and Real-Time Interactive Simulation programs, actually has classes on gameplay design and systems design, that teach students a reified concept of game mechanics. DigiPen also requires students to study industry advances (reading journals and conference proceedings, etc) and consider how the state-of-the-art can be evolved. Together, this means that students are thinking about how to create games with innovative mechanics, rather than just aiming for "innovative games" as black boxes. Which is to say: this mode of thinking gets results! So, with all that being said, let me restate my premise from my original comment: Paper prototyping is a way to do gameplay-systems design, separate from doing game design. This enables you to explore gameplay-systems design as its own discipline. You can also do gameplay-systems design interactively on a computer — but it's so very easy to get distracted into doing game design/development on a computer, that if you only ever use a computer, you may never end up putting any brain-power into doing gameplay-systems design at all.