|
[In the second in this
series of articles which deconstructs a particularly fun or interesting
mechanic in a recent, relevant game, Jeremy Alessi pulls apart Valve's Portal and puts it back together again
-- to give us a clearer understanding of the compellingly-executed
teleportation mechanics central to that game's astoundingly entertaining
gameplay.]
EDITOR'S NOTE: To download the
associated demo and code sample for Portal Demystified, please click here.
Welcome back to Games
Demystified. This month we'll be examining the chief gameplay mechanic behind
last year's amazing Portal! Anyone who's played Portal
has heard GLaDOS state, "Speedy thing goes in, speedy thing comes out".
That line sums up the
mechanics that distinguished Portal from the rest of the herd this past
winter. Sure, the impressive story and rendering also had a part, but it's simply
not a game without the mechanics.
Game mechanics are usually
abstractions based on real-world physics. In the previous Games Demystified
column, we covered gravity as it was applied in Super Mario Galaxy, a
force that is mostly unexplainable and yet tremendously fun with the proper
application in gameplay.
This go-round we're looking at wormholes,
Einstein-Rosen Bridges, or portals,
if you will. These phenomena are predicted by Einstein's theory of General
Relativity.
Image
From Samuel Joseph George's description of The Einstein-Rosen Bridge
Like gravity, Einstein-Rosen
Bridges are mostly a mystery. Perhaps someday through imagination and cool video
games we'll gain a proper understanding. Until then, we've got a nice pseudo-laboratory
in Portal to experiment with these mechanics.
Just playing the game is a
mind-trip. Exactly how can we simulate a tunnel or wormhole through the fabric
of space-time? How do we do speedy-in, speedy-out, momentum redirection -- or "flinging",
as Valve calls it?
Teleport mechanics in video
games are nothing new. Puzzles from the original Gauntlet were memorable
-- and more than likely, that wasn't the first game to use teleportation as a
gameplay mechanic. The difference between Portal and all those that came
before it is that Portal's teleportation acts as a frictionless tube
between point A and point B.
Physics are still hard at
work inside the frictionless tube. Instead of simply repositioning an object
from point A to point B, the player enters point A with full velocity and exits
point B with the same speed, but moving in a new direction.
|
Printer-Friendly Version
Knowing how stuff really works is glorious.
Thanks for choosing to publish this, Gamasutra editors!
I also honestly hope that people won't start to say that anyone could have made Portal, notably because it's not that hard to "find" the code behind the rule. This is something recurrent you hear from jaleous mouths, but the point is that one guy did it, you others didn't, and too bad for you.
I suggest one slight modification to the transformation of the player velocity : instead of changing the velocity direction to the normal of the exit portal, thus changing any movement at a right angle to the portal normal into forward motion, i propose projecting the velocity vector onto the basis vectors of the entrance portal. This gives back the players velocity relative to the entrance portal's orientation. This new velocity can then be multiplied with the basis vectors of the exit portal, resulting in the "correct" transition.
Might be a few more lines of code (and a bit more of a hassle with setting up the basis vectors), but allows far more possibilities when playing around with portals.
Things could even be taken further when using different sizes of portals (ie differing, non-normalized basis vectors for the entrance and exit portals), in combination with scaling of objects passing through a portal. For a very nice example of this, see Peter Molyneux's GDC 2005 "Room" demo ( http://www.youtube.com/watch?v=vGiPUx9Zgi0 ).
PS: Very looking forward to you next article!
The Room from GDC 2005 is really interesting. I did not get whether they included this mechanic in BW2???
Maybe the next installment of the column could come back to Portal and analyze that part as well.
If not, I'd like to see the next one be about Braid's time rewinding mechanics! Seems like Jon Blow has described how he did it enough times that it would be easy to reverse-engineer. But even when you know you could do it yourself if you had to, there's something about seeing someone else actually implement it and share the code - even if it's a non-refined implementation - that gets the creative juices flowing. Thanks for the articles Jeremy!