Making small games, which is fun in itself

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

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

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.