I think you're taking the phrase "paper prototyping" too literally. And also, perhaps, you're misunderstanding what I'm trying to say when I speak of a "fun gam

I think you're taking the phrase "paper prototyping" too literally. And also, perhaps, you're misunderstanding what I'm trying to say when I speak of a "fun game mechanic." 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 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.)