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, 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.)
> (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!)
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.
I think you totally misunderstood what "game-mechanics design" is if you're thinking that Valve would be the one to do game-mechanical prototyping.
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!
Narbacular Drop is the result of making a 3D game engine (the way everyone had to at DigiPen before they changed things such that now apparently nobody does this anymore, sadly), learning about portal rendering (https://en.wikipedia.org/wiki/Portal_rendering) in the process, and saying to oneself, "yo, what if portals weren't just used as a 3D rendering trick, but as a game mechanic, where the player is given the ability to place portals on arbitrary walls, and you can actually walk through them, thereby allowing the player character to traverse the environment in ways he could not in real life, thus allowing us game designers to create levels with geometry that would be impassable without the use of portals? that sounds like a decent puzzle game mechanic that nobody's tried before—let's make it and see what happens!"
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?
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.)