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 thi

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