Slashdot Mirror
Examining Portal's Teleportation Code
Gamasutra is running a story deconstructing the mechanics of Portal's teleportation programming. They present a snippet of Portal's code and a downloadable demo. They ran another article in this series earlier this year with an analysis Mario Galaxy's unique take on physics. We've discussed the development of Portal in the past.
"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."
Update: 8/26 at 19:37 by SS: Dan notes that the code was not directly from Portal; it was written to approximate Portal's physics.
If you could put a portal on a fast falling object, when it lands on you while you are standing still would you have momentum at the other of the portal or would you just poke through since the portal has the initial momentum? (IE nonplayer movement being different than player movement)
What would that say about your reference frame? Could you use that to distinguish which of two objects had "universal frame" movement? That'd be kinda neat, theoretically, but it'd be way more interesting to be able to put a portal on a crate hanging from a crane, then make the crate fall while standing under it to catapult yourself from a low position.
In the game, GlaDOS says "momentum is conserved through the portal." Assuming our physical system is the character, momentum definitely is not conserved. Neither is energy. The description "the player enters point A with full velocity and exits point B with the same speed, but moving in a new direction" is exactly correct: a textbook example of momentum non-conservation. However, what drives the exciting "flinging" effect, which makes Portal's teleportation so unique, isn't just momentum redirection. It's that you instantly obtain the potential energy of your exit location. This new potential energy can be converted back into kinetic energy, increasing your speed...mix in a little momentum redirection at the portals then wash, rinse, repeat. Although GlaDOS describes the game physics incorrectly, there is a game walkthrough where the programmers do describe it correctly. If you take any physics courses from me, you can expect to see some Portal questions on future quizzes :) Nice article overall.
i\hbar\dot{\psi}=\hat{H}\psi
That's not entirely correct, from a programming standpoint.
In most old games, "physics" were limited to jumping (and, occasionally, explosions knocking players around). Rather than try to simulate ballistic trajectories for every object in the game, rockets and other projectiles were simply moved forward a certain distance for every "tick" of game time.
So the transporter didn't preserve the rocket's momentum - it just put the rocket at a new location, and the game then resumed moving the rocket forward.
How can I believe you when you tell me what I don't want to hear?
I don't recall if you jumped into the teleporter if you'd exit and continue your jump arc,
To some extent, I'd guess. It wouldn't be perfect, but let me put it this way: Duke 3D was a two-and-a-half-D game, not a 3D game.
This implies, among other things, that the engine didn't actually support rooms on top of one another -- that all had to be faked in some way.
So how could you swim underwater? The simple answer is, the surface of the water was a silent teleporter -- it might even have to be marked "water" -- and the "underwater" was actually a completely different place in the map.
Going upstairs was a different trick -- the fact that the game could handle two rooms, or "sectors", occupying the same space, so long as you couldn't see both at once. There was a lot of really creative level design involving staircases and the like to make it seem as though you had a two-story building, while never actually letting you see both stories at once.
If you want to get a really good idea of what the Duke3D engine was, find one of the secret levels -- the one with a big room in the middle, and a hallway ringing around the outside (kind of a donut shape) -- don't remember what it was called. I do remember that you could turn right three times, and end up in a different room -- there were four separate rooms (or "sectors") set in the same physical space.
Don't thank God, thank a doctor!