6 ms·
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. Thi
by 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 agoThe first release of Civilization was a board game.
- meheleventyone 3y agoI 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.)
- adamrezich 3y agoto the best of my understanding—but please correct me if I'm mistaken—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. then he sees what they've come up with and gives feedback; rinse and repeat until the game ships. with regards to paper prototyping though, while I believe it can be a useful tool in certain situations, I pretty strongly believe that its usefulness is being vastly oversold to aspiring video game designers, these days. the best use for paper prototyping is when the game you're setting out to make strongly resembles an analog game—like a roguelite deckbuilder, or Fortune Street. but if you're looking to create a design for a video game that truly embraces what's unique about the medium—instead of just making a computer-adjudicated board game—then there really isn't a better way to do it than just biting the bullet and prototyping the gameplay with code. in my opinion, the best-designed video games are not ones where the design was thought through to completion ahead of time before implementation began, but rather, ones where someone had an idea or two and sat down and started programming its implementation—prototype or otherwise—and the eventual design of the end product was discovered through playing around with the combinatoric outcomes of interesting rules and mechanics that interact in nontrivial and often unforeseeable ways, seeing what works and what doesn't, seeing what's interesting and what isn't, and gradually arriving at something special and unique. 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. but how can that even be possible? the main things that separate video game design from analog game design are 1.) the computer adjudicating the rules, and 2.) the much faster feedback loop between action taken action and observed outcome, from the perspective of the player. these are qualities inherent to the medium. you can choose to ignore them and design a more or less perfectly paper-prototypable game... but, if that's the case, perhaps you'd be better off designing a board game instead. just like how many AAA linear-narrative-focused games' narratives really would just work a lot better as a movie or TV series. now this isn't always strictly true of course—roguelite deckbuilders are fun as hell, even though they're generally very straightforward to paper-prototype. but again, of course these kinds of games lend themselves to paper prototyping, because they're really just essentially digital board games. and if that's all you ever want to make, then sure, go on ahead. but if you want to make something that embraces the qualities of the medium that make it stand apart from its contemporaries, then really, making a digital prototype is the only way to go. as a hackneyed example, consider Braid: its initial prototype had a functioning "infinite rewind" system, and its designer/programmer implemented more or less every idea he had (including World 1, the final level)... but much of the rest of the mechanics (such as World 4's "current point in time for all other entities in the level = the player character's x-position") only came about—were arguably discovered—through the act of implementation, as opposed being done in advance of implementation. if whether or not Braid was made hinged upon the perceived success or failure of preliminary paper prototyping, then it's quite likely it would never have been made. moreover, it is entirely possible to design a game through paper prototyping, and be reasonably satisfied with the design... only for you to then implement it and actually play it in the form of an actual video game, and find it to be underwhelming, unengaging, or otherwise completely unlike how you envisioned it with your abstracted paper prototype. 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. I just clicked on a random one: https://www.squidi.net/three/entry.php?id=224 https://www.squidi.net/three/entry.php?id=224 this is a cute idea, but without even testing it out myself at all I doubt it's actually very good at all. but hey, maybe I'm wrong, maybe it's the next Angry Birds, or something! I'm not faulting the author for posting it on their personal website, but really, it's nothing more than just a wholly untested, spontaneous idea jotted down in a notebook. until said idea is put into practice in the form of a playable video game prototype, there's no way of knowing whether it would actually be fun at all, or worthwhile to pursue developing further. but, to my point above: perhaps in building and testing a prototypical two-button FPS game, the designer might realize that their idea was utter garbage... except for some small aspect that they did not and could not foresee. perhaps it's entirely incidental to the "two-button FPS" game idea. maybe it's even just something as trivial as a bugged shader that produces undesired yet unexpectedly visually interesting output, or improperly-implemented movement mechanics that inspire a completely different, first-person-shooting-less idea for a game. conversely: if Vampire Survivors never existed, and you came to me with an idea for a single-stick no-button roguelite top-down shooter with barely-animated 2D sprites that look like they should be in a side-scroller instead, I would've thought your idea was mediocre at best, and not worth pursuing. but as it turns out, it's a great idea for a game, one that ended up spawning a whole subgenre—and anyone can see the appeal for themselves, just by playing it for only a few short minutes! paper prototypes can be useful for designing certain parts of certain types of games, but I completely and vehemently disagree that they're a useful tool for determining whether or not a broad, abstract video game design idea is worth pursuing further.