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
A well made 2D Flash version of Portal:
http://portal.wecreatestuff.com/portal.php
These two were my favorites:
http://www.mcescher.net/images/relativity.jpg (1953)
and
http://www.mcescher.net/images/houseofstairs.jpg (1951)
The code is a lie!
Ok, sorry...
When you shoot a mime, do you use a silencer?
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!
Yes no but not really. Vertical velocity is still vertical and horizontal velocity is still horizontal - just pointing in a different direction.
With Portal (and it's predecessor Narbacular Drop) you can enter a portal on the floor and pop out a portal on a wall - vertical speed seamlessly becomes horizontal speed. And that works at any combination of angles. Add to that collision detection mid-portal and you have something just a little more than what BZFlag offers.
Regarding the portals in Prey - I don't recall the portals being multi-directional but that game had a lot of funky physics in it so maybe I just don't remember. Also, the portals were all scripted in-place so they might have taken 'shortcuts' in the code to make them work.
=Smidge=
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.
Somebody using Ogre3D has been working on a portal like project for nearly a year and has made pretty damn good progress for somebody who was new to game programming:
http://www.ogre3d.org/phpBB2/viewtopic.php?t=37376
He also has a blog which seems quite lacking though.
This space is not for rent.
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
Dwarves on Discworld don't fight golems. They fight trolls. This is why the internet needs more dwarves.
If only we could fall into a woman's arms without falling into her hands
There's a fair amount of fake physics involved. Properly, the parts of the character on one side of the portal should have the gravity and momentum of that inertial frame, and as the character passes through the portal, the new frame should begin to act on the character. But the sample code in Gamasutra treat the character as a single rigid body.
It's a neat problem to make the physics correct as the character moves though a portal. It could certainly be done, even for ragdoll characters. From a gameplay perspective, it would drive players nuts. To make the gameplay tolerable, the designers of this game added a pseudo-force that tends to align the character with the local vertical. Otherwise, characters would have execute proper parachute landing falls when moving through a gravity vector change.
Character physics almost has to be fake. Trying to drive a real car via a game pad is very difficult, and trying to drive a human body via a game pad is worse.
multi-hundred pound canon
Omnianism has loads of holy books, but I don't think even those collected amount to several hundred pounds.
Portal exploits portal rendering technology - a technique for graphics optimisation which incidentally allows you to take a given map layout and provide a different subjective layout for the player. It's actually a fairly trivial problem to do the portals themselves, as most graphics engines these days should have portalling built in. All of the interesting physics comes in when they start making it work as gameplay, for example by giving portal entrances "push" or "pull" to steer players into and out of them. The article is a good description of how to make a game that behaves a bit like Portal, but it's got nothing to do with that game's actual physics.
No kidding!!! What do you say at this point?
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.
No kidding. The whole "frictionless tube" thing is just thinking too hard about it. Yes, instead of simply repositioning an object from point A to point B, you also take the normal of both holes and change the direction of the velocity. That's it. It solves the same problem and produces the exact same result without doing physics for a frictionless tube.
A polar bear is a cartesian bear after a coordinate transform.
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.
Started neat but quickly degenerated in to something all to typical with flash games: You have to have really fast reflexes and figure you the logic apparent only to the designer. Neat technically, but the gameplay needs work.
Didn't Asteroids have prior art on this..? :)
"Slow down, Cowboy! It has been 3 years, 7 months and 26 days since you last successfully posted a comment."
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 ]
+1, Touche.