6 ms·

> hence imo in the beginning, it's best to recreate existing games with atmost a small twist ...if your goal is to do game development. If your goal is to do

by derefr 3y ago

> hence imo in the beginning, it's best to recreate existing games with atmost a small twist ...if your goal is to do game development. If your goal is to do game design, though, then the place to start is making paper prototypes of your game mechanics. Almost anything turn-based can be prototyped on a tabletop with stuff you have lying around the house, and some rules about how you and your friends should move things. (For something like an RPG, you may want to write a few little calculator scripts for calculations the game would hide from the players, to run on a laptop at the table, just so everyone doesn't get dragged down doing hours of math that wouldn't actually be part of a player's experience of the game. But "a calculator script" is still a far cry simpler than a game engine!) Reflex-based video games are harder to prototype, but can often be tested "by analogy" to physical-movement games. Think: testing a design for a new FPS, by designing the mechanics as a set of LARP-y mods over paintball/airsoft/lasertag. For a reflex-based video game where the player avatar is expected to be superhuman (e.g. most platformers/adventure games), you might not be able to test the mechanics directly, but you can at least create paper rubrics — e.g. threat-radius circles for attacks. You can then do level design by building physical dioramas out of blocks (Lego — esp. Technics, to have parts of the diorama move — is great for this!) and then "testing" using your paper rubrics to ensure each course is at least possible. This isn't so great an idea — unlike the previous prototyping strategies, this one won't really indicate whether your game idea is fun to play — but it's at least something you can do to iterate on an existing game concept without constantly having to program in each new marginal idea. The only kind of game that's near-impossible to prototype without actually programming anything, is an "artsy" game where the mechanics play with lighting / mirrors / illusions / etc. in a way that doesn't line up with things that are physically possible in the real world. So... don't try to design one of those as your first game. :)

meheleventyone 3y ago
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.)

by derefr 3y ago

meheleventyone 3y ago

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.)