6 ms·

Having tried to get on board with and use paper prototypes for digital games I’d largely disagree with this. Unless the mechanics are complementary to a board g

Having tried to get on board with and use paper prototypes for digital games I’d largely disagree with this. Unless the mechanics are complementary to a board game then you’re largely not going to learn anything useful working this way. I’ve found that even in the case of digital games that do have good parity you learn a lot more as soon as you ditch paper and start working in the native format. With the reflex case this just gets worse, as the prototype medium gets ever further from any congruence to what you want to make. There’s just too much missing in what it feels like to play the game. From the affordances digital games have, to the feedback and automated book keeping.

crq-yml 3y ago
I concur. Digital game design lends itself to working "UI down" instead of "data model up" because most of the feel of the game derives from the interface. This is even true if you look at something like Civilization. The first release of that game was primarily built off the feel of the city management - the stats of everything were given very basic tuning. It switched from real time to turn based relatively late in development. So paper can be used, but mostly in a storyboard kind of way where you're presenting some interactions to testers without coding them up. You don't have to have a full game loop at that stage - the loop is just a hook to stay engaged with those interactions. The reason why the spreadsheets are relevant now mostly comes down to games having more and more content that needs stat balancing. This was immediately true of Wizardry and derived RPGs, but it's never been necessary for simple arcade games, and it's obviously wrong if your aim is something like a Sokoban puzzle.
- panzagl 3y ago
  The first release of Civilization was a board game.
  - meheleventyone 3y ago
    I don’t think the board game and the videogame are related other than sharing the name and the former acting as inspiration.
- derefr 3y ago
  > Digital game design lends itself to working "UI down" instead of "data model up" because most of the feel of the game derives from the interface. You're talking about a later stage of the ideation process than I am, I think. You seem to be talking about building a game in an established genre, where you know what kind of medium you'll use, and even what game engine you probably need, and so you can sit down and start iterating on game design through development — with mechanics being either just retreads of other games' mechanics, or being things that naturally arise during development. If you work for a game studio that makes games in one particular medium and genre, then this approach makes sense, I suppose. But I was speaking more of ideating novel game mechanics: what you're calling an "interaction", but a bit more — basically any element of a game's concept that can be extracted out to be modelled separately as its own abstract rules state-machine, its own "micro game." And I was speaking of these mechanics in isolation of any particular game engine, or even any particular medium — of any particular game genre. When designing such an isolated mechanic, you can use paper-prototyping to wrap the mechanic into a Minimal Viable Game — because your goal is testing whether the mechanic is fun, rather than whether the game is fun. Example: coming up with "a sequence of random-chance events to either buy or trade for unclaimed properties, or to be taxed by the current owner of the property" as a mechanic. Wrap it in a board game: it's an MVP version of Monopoly. But you could just as well wrap it in an async MMO game — then you've got something more like Elite or Dope Wars or EVE Online. Monopoly and EVE Online are two very different games in two very different genres, with two very different playstyles — but before you design either game, you can determine whether the core mechanic between both of them is fun even in concept. If it isn't, don't bother putting it in a game at all. (For another 300 examples: https://www.squidi.net/three/ https://www.squidi.net/three/) Games designed mechanics-first, are usually also designed mechanics out — which is similar to, but not the same as, "data model up." Mechanics constrain possible UX and possible data models, but don't fully determine either. And mechanics — or the particular combination of mechanics — determines a game's genre. (Often, adding one more mechanic to an existing genre makes people start calling games like that a new subgenre. Add "keys that fit multiple nonobvious earlier locks, incentivizing exploratory backtracking, with each key being qualitatively different in use" to a platformer, and you've got a metroidvania.) So the goal of a game-designer who is designing mechanics-first, is almost always to create a game with a set of unique, innovative mechanics — i.e. to create a game that is the first entry in a new game genre. What mechanics-first design often doesn't constrain, is medium. The same set of action-resolution and narrative-tension mechanics might work equally well in a CRPG or a TTRPG! The same set of competitive zero-sum character moveset concepts might translate equally well to a fighting game (https://www.sirlin.net/articles/balancing-puzzle-fighter https://www.sirlin.net/articles/balancing-puzzle-fighter) or a deckbuilding card game (https://www.sirlin.net/articles/designing-puzzle-strike https://www.sirlin.net/articles/designing-puzzle-strike)! Which is why paper prototyping often does work well for mechanics-first design: many mechanics can be evaluated for "can it be fun even in concept"-ness through a very turn-based, abstract, talk-y form of interaction with the mechanic. A collaborative hallucination of the mechanic. This lets you decide what random mechanic ideas you have stewing, you should bother to take the time to "translate" from their abstract-concept form, to something programmed. It also often allows you to find mechanics that "fit" together, even while they're still abstract. An entire game-genre of interlocking mechanics might just "click" and come together on paper, before any real examples of it exist. Now you just have to design an actual game that has those mechanics / is in that novel genre. --- Bonus potential hot take: I hypothesize that Shigeru Miyamoto — not Nintendo as a whole, just Miyamoto — does mechanics-first design. It's why no project he heads, or even greenlights, is ever just effectively a DLC/content-pack for a previous game. Which is in turn why Nintendo continually leads the industry in their games being the first entries in new game genres; but it's also why the newer Paper Mario games suck. And it's why there's never going to be a sequel to many people's favorite Nintendo games: there's just no clear thing to change about or add to the mechanics, that a whole new game's worth of content could be derived from, without that game having so little to do with the original that it wouldn't appeal to fans of the original. (Re: that last part, see also: why no Half-Life 3 or Portal 3. Those series are clearly founded on mechanics-driven design as well.)

crq-yml 3y ago

I concur. Digital game design lends itself to working "UI down" instead of "data model up" because most of the feel of the game derives from the interface. This is even true if you look at something like Civilization. The first release of that game was primarily built off the feel of the city management - the stats of everything were given very basic tuning. It switched from real time to turn based relatively late in development. So paper can be used, but mostly in a storyboard kind of way where you're presenting some interactions to testers without coding them up. You don't have to have a full game loop at that stage - the loop is just a hook to stay engaged with those interactions. The reason why the spreadsheets are relevant now mostly comes down to games having more and more content that needs stat balancing. This was immediately true of Wizardry and derived RPGs, but it's never been necessary for simple arcade games, and it's obviously wrong if your aim is something like a Sokoban puzzle.

panzagl 3y ago
The first release of Civilization was a board game.
- meheleventyone 3y ago
  I don’t think the board game and the videogame are related other than sharing the name and the former acting as inspiration.
derefr 3y ago
> Digital game design lends itself to working "UI down" instead of "data model up" because most of the feel of the game derives from the interface. You're talking about a later stage of the ideation process than I am, I think. You seem to be talking about building a game in an established genre, where you know what kind of medium you'll use, and even what game engine you probably need, and so you can sit down and start iterating on game design through development — with mechanics being either just retreads of other games' mechanics, or being things that naturally arise during development. If you work for a game studio that makes games in one particular medium and genre, then this approach makes sense, I suppose. But I was speaking more of ideating novel game mechanics: what you're calling an "interaction", but a bit more — basically any element of a game's concept that can be extracted out to be modelled separately as its own abstract rules state-machine, its own "micro game." And I was speaking of these mechanics in isolation of any particular game engine, or even any particular medium — of any particular game genre. When designing such an isolated mechanic, you can use paper-prototyping to wrap the mechanic into a Minimal Viable Game — because your goal is testing whether the mechanic is fun, rather than whether the game is fun. Example: coming up with "a sequence of random-chance events to either buy or trade for unclaimed properties, or to be taxed by the current owner of the property" as a mechanic. Wrap it in a board game: it's an MVP version of Monopoly. But you could just as well wrap it in an async MMO game — then you've got something more like Elite or Dope Wars or EVE Online. Monopoly and EVE Online are two very different games in two very different genres, with two very different playstyles — but before you design either game, you can determine whether the core mechanic between both of them is fun even in concept. If it isn't, don't bother putting it in a game at all. (For another 300 examples: https://www.squidi.net/three/ https://www.squidi.net/three/) Games designed mechanics-first, are usually also designed mechanics out — which is similar to, but not the same as, "data model up." Mechanics constrain possible UX and possible data models, but don't fully determine either. And mechanics — or the particular combination of mechanics — determines a game's genre. (Often, adding one more mechanic to an existing genre makes people start calling games like that a new subgenre. Add "keys that fit multiple nonobvious earlier locks, incentivizing exploratory backtracking, with each key being qualitatively different in use" to a platformer, and you've got a metroidvania.) So the goal of a game-designer who is designing mechanics-first, is almost always to create a game with a set of unique, innovative mechanics — i.e. to create a game that is the first entry in a new game genre. What mechanics-first design often doesn't constrain, is medium. The same set of action-resolution and narrative-tension mechanics might work equally well in a CRPG or a TTRPG! The same set of competitive zero-sum character moveset concepts might translate equally well to a fighting game (https://www.sirlin.net/articles/balancing-puzzle-fighter https://www.sirlin.net/articles/balancing-puzzle-fighter) or a deckbuilding card game (https://www.sirlin.net/articles/designing-puzzle-strike https://www.sirlin.net/articles/designing-puzzle-strike)! Which is why paper prototyping often does work well for mechanics-first design: many mechanics can be evaluated for "can it be fun even in concept"-ness through a very turn-based, abstract, talk-y form of interaction with the mechanic. A collaborative hallucination of the mechanic. This lets you decide what random mechanic ideas you have stewing, you should bother to take the time to "translate" from their abstract-concept form, to something programmed. It also often allows you to find mechanics that "fit" together, even while they're still abstract. An entire game-genre of interlocking mechanics might just "click" and come together on paper, before any real examples of it exist. Now you just have to design an actual game that has those mechanics / is in that novel genre. --- Bonus potential hot take: I hypothesize that Shigeru Miyamoto — not Nintendo as a whole, just Miyamoto — does mechanics-first design. It's why no project he heads, or even greenlights, is ever just effectively a DLC/content-pack for a previous game. Which is in turn why Nintendo continually leads the industry in their games being the first entries in new game genres; but it's also why the newer Paper Mario games suck. And it's why there's never going to be a sequel to many people's favorite Nintendo games: there's just no clear thing to change about or add to the mechanics, that a whole new game's worth of content could be derived from, without that game having so little to do with the original that it wouldn't appeal to fans of the original. (Re: that last part, see also: why no Half-Life 3 or Portal 3. Those series are clearly founded on mechanics-driven design as well.)