hence imo in the beginning, it's best to recreate existing games with atmost a small twist. This makes sure i'm learning one craft adeptly before moving to the next.

Here's a freeboard of a game I worked on recently: https://li-quoridor.vercel.app/ [Still a work in progress]

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

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.

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.

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

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) or a deckbuilding card game (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.)

The way I actually do design now is by Venn diagram. At the core of the diagram lies themes, principles, beliefs, or the so-called "design pillars". The "hook" of all games that reach an audience lies in offering a coherent belief structure: "I believe I'm doing this thing because it coheres with what I think the thing is about." And it doesn't have to be "about" anything very weighty; a ball sport amounts to an excuse to play with a ball in a certain way. And it doesn't have to be a popular belief, either. But it is a hard requirement that the game has this quality, because the alternative is that the player says "I don't know what this is about and why isn't it more like this other game". Game players still say that about successful games, but it's because their belief structure doesn't allow engagement with the core.

What fills out the rest of the diagram, and the design, is the supporting expression of that belief. If you believe the game is about throwing and catching a ball, you need to introduce some equipment and rules. But the reason why the game remains compelling as a whole is down to whether or not those things are facilitating the intended kind of play, and the reason to have genres of game derives from the mode of expression shaping that engagement: some games have a lot of legible rules and stats, others hide everything behind audiovisual expression. It's books vs movies, not action vs romance.

Miyamoto's training was in industrial design. That is, he brings "toy" qualities to video games. The way in which he designs follows from that: rather than exploring a core that is literary, like "hubris" or "rebirth", Mario's play value is in the experience of running and jumping. Therefore, Mario's world follows from providing elements that engage further with running and jumping - motives to progress, obstacles to face, abilities that change his relationship to those obstacles. And the direction of Nintendo as a whole, since he started working there, has been to make products tightly focused around toy concepts, with hardware platforms that allowed more experiments to take place.

Pacific rim? Giant robots and giant monsters are cool! How can we tell a cool story about giant robots and monsters?

For example, you would not imagine that portal could've been designed from using paper and tabletop. The feel of looking thru a portal, the orientation (or disorientation) of the player, etc are all crucial to making portal good.

You would also not be able to prototype a game such as Q.W.O.P. (and their incarnations such as "Getting Over It") on paper - it's impossible to imagine it, without first getting the smallest prototype that's interactable on the medium it's ultimately delivered.

I suspect that using paper and tabletop to design a game mechanic will surely bias you to produce discrete interactions in your game, even if the ultimate medium is in the computer and played interactively.

The original concept for Portal is actually really easy to prototype.

(And Portal is also a very good thing to spend some time physically prototyping, because it's a challenging thing to code on a computer — especially without any resources from someone who already figured out how to do it!)

To prototype a Portal puzzle, you will need:

• lego blocks, to build the puzzle room itself

• pipecleaners, sized to the jump distance of your character

• a smartphone

• a Bluetooth action camera that streams to the smartphone

• two hollow plastic rings — one orange-tinted and standing 1cm above the smartphone screen; one blue-tinted and standing 1cm in front of the camera (you could use those little "pizza saver" tables, cutting the centers out)

• orange and blue sticky notes, and a sharpie

Steps:

1. Build a puzzle room. Start with it being possible to clear using normal jumps.

2. Then find interesting portal-jumps in the room, by positioning the camera and smartphone as portals. Look through the smartphone (ingress portal) as you're placing the camera (egress portal) to determine a good place to put the egress portal, and to determine the correct angle for the jump — use the camera's lens-angle adjustment to simulate entering the ingress portal from an angle. (If you can't find interesting jumps, iterate on the room design.)

2b. Alternately, working backward from the room exit, position the egress portals where you want the jumps to terminate, and then position the ingress portals so you can see the chosen path out of the already-placed egress portals.

3. Ensure each jump is make-able before including it, by running a pipecleaner from a grounded jump origin waypoint — it should reach into the ring attached to the smartphone.

4. For each interesting portal-jump you find that you want to include, add a pair of sticky notes to the room where you had the camera and smartphone, with the same symbol written on each.

5. Lay out a success-line out of pipecleaners, from the start of the stage to the exit through the portals.

6. Modify the room until every step of this success-line is on the critical path — i.e. until it's impossible to traverse to the exit without at least going through this sequence of portal-jumps.

7. Now do it again 100 times with different room layouts. Keep the most interesting ones — the ones that are just mind-bending enough.

---

I hope it's clear from this, that what I'm talking about when I talk about a "fun mechanic" isn't necessarily a satisfying interaction; but rather a game system from which arises a novel, dense challenge-space that has potential for combinatoric mixing with the challenge-spaces of other game systems.

Once you know that Portal is a mechanic actually worth trying to implement as a puzzle game — i.e. that there are a good number of challenging puzzles that can be made in theory by requiring the player traverse a 3D space while "thinking with portals" — then you would implement and prototype the game system. At which point you could then test out puzzles that involve interactive reflex movement (e.g. portal-jump momentum redirection.)

Note, though, that nobody ever actually did this for Portal (at least, I don't think) because random people on the Internet had already been prototyping Portal in 2D by drawing portal-puzzles on paper or in MS Paint for years, before Narbacular Drop was developed. Most game mechanics that create interesting challenges in 2D, still create interesting challenges in 3D — so devs could just go straight ahead with a prototype in code, under the assumption that there would be plenty of challenge-space to discover. (On the other hand, there are concepts that don't work in 2D, but do work in 3D. That's when you should pull out the physical prototyping materials.)

> You would also not be able to prototype a game such as Q.W.O.P. (and their incarnations such as "Getting Over It") on paper

Even more ironic, as QWOP's premise is literally the digitization of a physical system: QWOP is a 2D https://en.wikipedia.org/wiki/Paper_doll, with very loose/lubricated joint pins, plus puppet strings attached to each extremity that can be pulled on.

Mind you, with modern high-level game physics engines, it may actually be faster to construct QWOP digitally than to construct the equivalent physical puppet. Especially if you're not already someone who enjoys handicrafts. But QWOP is the exception — it's less a game mechanic, and more a physics toy. So of course a game physics engine is going to be a good prototyping environment for it. :)

(The difference between "game mechanics" and "physics toys", being that "game mechanics" are systems with novel rules of their own, where much of the fun of the game comes from discovering, learning, and mastering these novel rules through encounters with increasingly worked examples; while a "physics toy" is a game element that obeys ordinary real-world physics — rules we already know! — in such a way that it poses a dexterity challenge, often mostly due to the impedance mismatch between the actual object and the input method used to communicate intent to interact with the object. Portal 2's paint is an example of both — the things the paint does once it's placed, form a game mechanic; but placing the paint, is a physics toy.)

how so? implementing functional portals given that you have the Source engine to start from isn't difficult at all. sure, it took a little bit of work to make them look good, and to tidy up things like making physics props go through them properly, and making it so you can shoot portals onto certain walls but not others and have that all work properly. but just making static planes that teleport the player through them while conserving momentum so as to be able to prototype puzzle design isn't that difficult, and surely was much easier to do in the Source engine with the Hammer map editor than wasting time with LEGOs and pipe cleaners—especially when you hired the Narbacular Drop people to learn what they learned in implementing a less-complex version of the same idea. it's just hacking around the already existing physics engine in Source, to add physics and further dimensionality to the design idea that Narbacular Drop already proved—one which was also not predicated on paper/physical prototyping!

I'm trying to figure out why you used Portal as a specific example, when you yourself admit that this is not at all how they designed Portal, given that the way they did design Portal—by building a prototype and playing around with level design in-engine—is clearly the far superior way to go about things.

> Note, though, that nobody ever actually did this for Portal (at least, I don't think) because random people on the Internet had already been prototyping Portal in 2D by drawing portal-puzzles on paper or in MS Paint for years, before Narbacular Drop was developed.

is this true? from my recollection, this all began in the wake of the release of the initial announcement trailer for the original Portal back in 2006.

The creators of Narbacular Drop — if their goal had been to make a AAA game ala Portal† — would be the people who should have sat down and worked things out with legos and pipecleaners.

† (Which it wasn't — they built a game basically as a class project, a proof-of-concept; they didn't care about making a fun game per se; about discovering a novel challenge-space wide enough to build out a set of scenarios deep enough that they could keep a player's attention for a few hours and make it seem worth $60 or whatever. They built levels just to prove that the physics worked.)

This is because, in order to actually implement Narbacular Drop, the creators had to sit down and write an entire custom game engine from scratch, to make their game possible.

(A.k.a. the "Sketcher Engine." The Source engine wasn't public in 2005! And no existing publicly-available game engine in 2005 had support for sub-rendering of secondary view frustums onto textures to be included in a primary view frustum; nor for "proxy" physics objects representing an object being in multiple places at once [Chell standing half-way through a portal] where both have collision but only with things on the same "side of the portal" they're in, so that they don't collide with their own alternate self. Oh, and even if they did — DigiPen doesn't let people in their game-design program use external black-box game engines in class projects. You always have to implement the game engine yourself.)

Insofar as Narbacular Drop is considered a separate game, though, Portal really doesn't have any novel game mechanics; it's entirely derivative (though it does combine the "3D traversal with portals" mechanics of Drop with more traditional 3D-puzzle-platformer and graphic-adventure game mechanics, to produce a novel — and very polished — game.)

As such, Valve didn't need to do any mechanical prototyping. Narbacular Drop was the proof-of-concept of the mechanics. Portal was a simple port of those mechanics into Valve's engine. You don't re-do mechanical ideation just to steal another game's mechanics. You already played the original; you already know the mechanics are good.

(I would note that Valve have never been one to innovate in game mechanics. Half-Life, for example, is an innovative game, but it's one built by taking a bunch of physics-toy interactions (e.g. exploding barrels) that were seen in older titles, and making a game entirely out of those interactions, where you're supposed to use them to kill enemies.)

> is this true? from my recollection, this all began in the wake of the release of the initial announcement trailer for the original Portal back in 2006.

The "Now You're Thinking With Portals" meme originated in 2007, yes.

But people have been trolling each-other with images of impossible 2D top-down puzzles saying something like "find the exit" — where one common "solution" is to draw a wormhole that takes you right to the exit — for years before that. And then parodying those, by drawing complex 2D-side-on platform-puzzler levels, where the player-avatar's route takes them through walls and narrow gaps.

This genre of meme-image doesn't really have a name of its own, which makes it hard to search. After portal, it evolved into the "Get The Cake" meme. But I can assure you that it existed before there was a cake involved!

crucially, portal rendering (with regards to the player-placeable portals themselves) is actually entirely incidental to most if not all puzzle solutions, both in Portal, and, if I recall correctly, Narbacular Drop as well. if I recall correctly, Portal had a "portal render depth" setting that could be even set to zero for performance reasons on lower-end PCs. recursive portal rendering is just a neat visual effect that helps "sell" the mechanic, but it is not mechanically crucial to the functionality of the mechanic itself. yet, portal rendering (a 3D graphics engine implementation detail) inspired one of the most unique and great video game mechanics in the history of the medium!

the idea of portals-as-traversal-mechanism only came about by means of creating a 3D engine from scratch—there's no reason such an idea would have occurred to them otherwise. there was no reason for them to paper-prototype the idea, because the idea itself was born from the implementation of a 3D engine. then, someone at Valve saw Narbacular Drop during a DigiPen Company Day, and said to themselves, "this is pretty cool, man, this wouldn't be that hard to implement in Source, and Source has better physics, and that could lead to a more robust design space, okay, let's offer these guys a job." and they were correct. Narbacular Drop became an excellent digital prototype for Portal, even though its physics engine was nowhere near as robust and capable as that of Source, such that it didn't, and couldn't, explore the full possibility space that was unlocked once the concept was literally ported over to that engine. sure, the student developers didn't consider it to be a prototype when they were making it, but that's just how many student games end up being—especially at DigiPen.

this is exactly what I've been trying to say here: the best, most unique video game designs aren't arrived at by conceptualizing mechanics in the form of abstract ideas and only choosing to attempt to implement said mechanics if they pass some "paper prototype test"—rather, they're the result of people writing code, and seeing what happens, over and over, until a game design reveals itself.

in order to design interesting, unique, and great video games, you have to write some code—it's unavoidable. but this makes sense, right? the act of using a medium's materials to create a work in said medium is instrumental to the creative process in many different media—why would it be different for video games?

can you think of a single video game with a great, unique, and interesting design, whose design was paper-prototyped first, so as to confirm said design as valid and good, before a single line of code was written? not only is this as far as possible from the norm in the entire medium, but I cannot think of a single instance of this ever having happened, that I'm aware of at least. yet you claim this is the best way to go about designing video games?

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

I watched some students prototype a simple diplomacy type game on paper first, targeted at phones. On paper people got it, talked to each other, negotiated. On the phone, people just stared at their screens, made choices entirely in isolation, no "diplomacy" what-so-ever.

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

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.

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.

Everyone’s process is different though and as long as you’re enjoying your own then more power to you. Hopefully one of your binders (or Lego models) makes its way to completion one day!

Right on. Took me a while to realize this. Game Design is the blue printing process of a game. Game Development is the actual building of the game. And Game Design is way harder than what I expected.

I built half the content of a VR game I released a long while back with a friend, and the only thing that got me through it was listening to talks by John Cleese on the topic of creativity. My process could be summed up as: beat my head against a wall, make something okay-ish, get frustrated, try again and again, sleep on it, and eventually repeating that enough times results in awesome stuff.

But I have a hard time calling it “fun” even with the luxury of 7 years of hindsight.

But in reality it’s actually a pretty technical job from what I’ve seen

Can involve a lot of staring at spreadsheets and dealing with stats

Do you recommend any books and tutorials aimed at experienced programmers with 0 knowledge of game development/design?

When I started with Blitz Basic, not only my productivity skyrocketed, but I also made better games, because I actually thought about gameplay, not about getting the maths right. Blitz Basic is a game-oriented variant of the Basic programming language, very simple and straightforward. You can try it if you want, but it is two decades old, so I don't know how well it aged. But the important part is to have something simple that can free you from technical details and boilerplate, it can be an engine.

That's unless you want to practice with the technical details, but doing that, the output will probably be more demo than game. And by the way, if you are into that you should check the demoscene, it is awesome.

If you really want to go low level with it, though, my personal sweet spot is C, Lua/LuaJIT and SDL2. Although practically speaking C++ is probably better.

My initial research suggest that Godot games are written in C#. Since you use C/SDL2, do you code directly your own OpenGL engine?

There are a few supported languages (including a custom Python-like language called GDScript). C# is just just one of them.

Also, Godot games are also written in its native scripting language (GDScript) and it supports other languages, although I don't know how well, or how up to date anything is.

https://ibb.co/pJGYF9S

people often get enamored with success stories like, "well, [indie game you've heard of] was the first game project [creator] ever worked on, and he spent years working on it and nothing else, and now it's popular and successful and everyone you know has heard of it, so why shouldn't I just go about things the same way?" well sure, you can try to go about things the same way, but there's very, very little guarantee of success in doing things that way—not just in terms of sales or popularity, but in terms of even just actually finishing making what you set out to make. it's often surprising just how much work it takes to implement everything necessary—even for a seemingly very simple, minimal game—and going through the process of figuring out what is needed to make it, and then making it, is an absolutely invaluable learning tool.

this is especially true if you've never done any sort of game design before. some people like to make video games by "paper prototyping" first, and while this is certainly an option, I find that the best, most interesting games are made by a programmer or team of programmers who have an idea, start formalizing said idea into code, and then sort of "discover" the rest of the game's design by exploring the possibility space that the formalized initial design idea provides, by playtesting and writing more code.

but all of this is a lot easier once you have a few finished small game projects under your belt, and learned some of the basic game development insights along the way.

These are by no means at the quality of the submission, but they were how my kids learned to use a mouse and keyboard.

I definitely encourage others to try making their own. It is fun.

https://alexsci.com/games/ (only works on certain screen sizes, some need a keyboard, no instructions, etc)

It's not "fun", but dad made it and he had a say in how it worked, which is huge for kids.

The smaller the game the more likely you are to finish. I usually started with making the movement fun and then developed some game like concepts around it.

I also highly recommend starting by making simulations instead of games as when you're alone they are still a blast to see come alive. Building boids is a fantastic exercise I do in any new engine.

Yesterday, a game made by this author, called 1D pacman, was trending with more than 1,700 points, available here https://news.ycombinator.com/item?id=38845510

For me, this proves that this guy really knows what he is talking about. Kudos!

[1] http://www.asahi-net.or.jp/~cs8k-cyu/

And there's also a breakdown of games by their included game mechanics at [2], which from my own perspective is perhaps more fascinating.

[2] https://abagames.github.io/action-mini-game-mechanic-tags/in...

They really are fun. In fact making small games was my pandemic challenge: I decided that it was finally time to try these things. I ended up building a tool for cutting up and annotating tile maps first - https://tmt.computerpho.be/ - then used it to create a minimal browser city simluator, https://pc.computerpho.be/. These also served as experiments into building single-file "apps" for the browser, which was fun as well!

Working with a tiny 1-bit screen and ~150MHz CPU puts some serious constraints on what you can do, which I've found to be pretty freeing (less analysis paralysis, more doing...)

I have one, it's fun to play with, and I have one of my games working on it, although I don't think it's good enough to release yet.

https://arstechnica.com/gaming/2023/12/ars-technicas-best-vi...

There's nothing quite like grabbing SDL2 and going HAM for a few days. Some of my fondest memories are with lazy foo's tutorials :)

https://lazyfoo.net/

And I played Baldurs Gate 3 a few months ago which really inspired me. I have been playing RPG games for a long time now but I never tried a real "TTRPG", most of my experience was playing JRPG's when I was younger. And I knew about DnD but never felt compelled to try it irl because it seemed "kind of lame". But then I played BG3 and I really understood what "RPG" means. The game made it all click for me.

It quickly went from a fun playground for experimenting with mechanics to a long term project. It's been a great learning experience, and still a lot of fun to work on. But the pure creative joy of concepting and building has been supplanted with the tedium of maintenance and bug fixing.

My game for those interested: https://gramjam.app

You'll find a lot of variation between dictionaries. I was surprised to discover that curating the dictionary is one of the hardest aspects of building a word game. People have a lot of opinions on what should or should not be included, I've spent a lot of time manually filtering out profane and questionable words. Another interesting constraint of this particular game is that unlike Scrabble there's a lot of accidental word discovery, which can create a poor user experience if a bunch of obscure words clear and ruin a player's intended word.

P.S. I will probably add tasers after you flagged it

You're right about the dictionary, actually the whole time I kept wondering about how annoying it must have been to choose a dictionary for this game. Even though not accidentally making non-obscure words without noticing is part of the challenge, accidentally making obscure words is annoying!

Maybe I just don't know enough words - but looking through my game log, I was annoyed by "cony", "smit", "huic", "yipe", "nome", "torii", "agon", "mairs", "imido" and "sial", some of which don't display a definition when you click them, but all of which appear in all the scrabble dictionaries referenced on the website you just linked. Meanwhile I was sad to discover vape is so far only in one scrabble dictionary :) And annoyed to discover "oxalic", which is also in all the dictionaries on that site, was not accepted.

I guess there's a spectrum between "advanced scrabble player level vocabulary" and "fun word game", because I imagine (and suspect you have probably had feedback along these lines) _not_ allowing a word which is obscure but still unambiguously used in the modern era would be worse UX overall - the sort that's more likely to make you rage-quit.

I can see why you'd try to get a bit of wordle-esque shareability out of the daily mode even though I like the classic mode more myself. But I think the tutorial popup isn't as comprehensive as it needs to be for someone's first game to be fun. The first time I clicked the link I did an abysmal job at the daily challenge, I think it wasn't obvious that swaps didn't need to be neighbouring like the given example. Something that might be better is to make an interactive tutorial for first-time visitors - come up with a 5x5 board that is quickly solved and demonstrates several strategies and then walk the player through clearing it. I also think the help popup being one click away would be useful.

I would also have liked the help popup to let me know that progress is saved if you close the page, I ended up checking in an incognito window because I had no time to keep playing but wanted to come back and try to reach the target I'd set myself another time!

Anyway - criticism and suggestions aside - well done, it is a fun game and concept!

I love finding little strategies like this. This is only possible in games with a tiny feedback loop, which I think makes them fun to play on a whole new level.

[0] https://abagames.github.io/crisp-game-lib-11-games/?timberte...

It's at https://play.sharats.me.

I had chatgpt make the code for this for me.