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.
Your mom has a frictionless tube.
First post?
Regardless it's a lot better than quantum teleportation.
Well, back to rejecting software patent applications.
But... can they telefrag?
I just love the sound of 2 bodies trying to occupy the same space at the same time in the morning... or afternoon... or evening...
Don't blame me, I voted for Kodos
>>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."
Should be "Speedy thing goes in; speedy thing comes out."
I want to see the nautical version, Porthole.
You can't talk about Wikipedia's flaws on Wikipedia
Reading that article makes me want to play Portal through again.
--sigh-- at least it won't take long.
Life is like a web application. Sometime you need cookies just to get by.
Porting Portal's portal code?
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.
Are you fucking kidding? What's not completely obvious about this algorithm that should be Slashdot-front page worthy? I mean, it's fucking mind blowingly obvious, of course it keeps the velocity and translates it, how else could it do what it does? I can understand why it would be relevant to do a coding tutorial on the subject, but that's about as newsworthy as a Bresenham line drawing algorithm tutorial. TFS looks just like a "hey let's talk about how some super popular game is super awesome and post about it on a high traffic website".
You just got troll'd!
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
multi-hundred pound canon
Omnianism has loads of holy books, but I don't think even those collected amount to several hundred pounds.
Speaking of, whens he gonna put a new album out?
Are you talking about M.C. Escher who designed the crazy staircase house? Or David Bowie, who lives there?
The enemies of Democracy are
When it was ugly, buggy, and short?
Narbuncular Drop was a great student project showing off a new idea, and I'm glad it's still available to play with. Neglecting the gameplay polish, puzzle depth, and environmental detail improvements that went into Portal is, IMO, a gross error in judgment.
You forgot to end with "get off my lawn" =)
Your brain is not a computer.
Portal's physics go *way* beyond what the article implies.
Article basically says: it's not a simple teleport, direction of movement and momentum are preserved.
This is far too much of an oversimplification. Portal was probably a technically difficult game to code for - mostly due to collision physics. The problem is that something does not instantly teleport from one end of the portal to another. You can have an object on BOTH sides of the portal. This makes physics calculations very difficult, since you essentially have a single object of a small finite size, colliding with different objects across the room, affected differently by gravity, etc.
If I get the right gist from the developer commentary in the game, their solution was the CLONE the two sides of the portal in a mini physics-only environment and run the simulation there.
Definitely much more complex than the article.
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.
From a engine coding point of view, i fail to see how there's any difference.
In both cases, you have a vector attached to an object which describes how an object move :
- you can call it "trajectory" for shots
- you can call it "momentum" for portal
but technically it's just plain stupid "speed" vector. As in "derivative of the position" (= how the position is updated between each turn).
Eventually, if it's not a rocket, it will also obey to an acceleration (most of the time : gravity. But it can be buoyancy).
In both situation, all you have to do for any object entering a teleport, is simply change the current coordinate of the object, and eventually perform a transformation on the speed vector if both teleport end point aren't facing the same direction.
From a coding point of view portal doesn't introduce anything new for the physics that wasn't already done by any of all the multiple game that allow shooting through a portal or *jumping* through a teleport.
The new thing are the rendering engine (not all engine can easily render see-through portals - due to the way the work, Duke 3D's and Descent [portal based] and Wolfenstein and Doom [raycasting] could do them, but Quake 1 & 2 [BSP polygons] can't)
and the gameplay (before portal, teleporting thing other than the player was a fun by-product of how teleport work and can enable a couple of giggles. Portal in contrast has all its puzzle based around throwing object through portals)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]