Examining Portal's Teleportation Code 278
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.
Physics is Phun (Score:4, Interesting)
A well made 2D Flash version of Portal:
http://portal.wecreatestuff.com/portal.php [wecreatestuff.com]
M.C.Escher has good OLD examples of the concept: (Score:4, Interesting)
http://www.mcescher.net/images/relativity.jpg [mcescher.net] (1953)
and
http://www.mcescher.net/images/houseofstairs.jpg [mcescher.net] (1951)
Re:bzflag? (Score:3, Interesting)
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=
My big question (Score:5, Interesting)
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.
Portal Physics 101 (Score:5, Interesting)
Re:Portal (Score:5, Interesting)
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.
The physics is actually fake. (Score:4, Interesting)
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.
They omitted what Portal actually does. (Score:4, Interesting)
Re:Portal Physics 101 (Score:4, Interesting)
Re:Portal (Score:5, Interesting)
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.
Actually not obvious (Score:1, Interesting)
The article talks about the easy part, and not the hard part. If you listened to the game's commentary (or just tried using your brain, maybe) turns out it's not obvious at all.
For instance, how do you handle mechanics where an object can collide with something while it's half-way through the portal? Or two things that are half-way through a portal colliding with each other? How do you write graphics for something that can display an object in two places, two environments at once, as well as see-through holes to different parts of space?
Re:The physics is actually fake. (Score:3, Interesting)
Technically, the force of gravity should also pass through the portal, providing a smooth transition of forcesm, not a discontinuity. That would be interesting, but I think less fun. The way that the direction of gravity changes abruptly as you move through a portal is part of the charm.
Not a tube, direction doesn't actually change. (Score:1, Interesting)
His programming may certainly work to duplicate the effect of the Portal, but the physics portrayed by the game world are a little different.
First, it's not a tube, it may have an effective 'depth' of Zero. It certainly doesn't exceed 1cm at the worst case. Find a spot in the game with a corner, you can arrange things so you can see yourself from both Portals. It's very apparent at that point that their is either no 'depth' to the Portal, or it's so small you really can't perceive it in the game.
Second, objects passing through do not change direction. Their direction and velocity are the same as when they entered. To an outsider, it appears as though they change, but that is an illusion. Just remember that the Portal is a connection through space. Relative to the object passing through, it hasn't changed direction, rather everything else changed location. As far as it's concerned (or her, if you really want to stress the game character)a simple continous vector was followed. Though it may have been a ballistic or falling arc, and the forces of gravity may have shifted direction, the subject was simply following a basic newtonian trajectory through the local spacetime. (A spacetime with a doorway or wormhole in it.)
Like I was saying, the authors coding of the software to duplicate this effect was fine, but it's not the same thing as the physics it represents in the game. After all, even our most complex simulations of reality take very liberal and unrealistic shortcuts to make things happen that do not represent the physics involved.
(It's like someone watching original Star Trek and proclaiming that the Transporters use a photon based array transfer because I can see the Christmas lights they used in the transporter pad...)
Re:Portal (Score:3, Interesting)
well, i used to spend a lot of time creating custom maps in DN3D's build program, so i know how much of a pain in the ass it is, and the wide variety of hacks that are often employed--but isn't this true with every game engine? unless you can actually model the natural laws of physics, you're going to have to use hacks to fake most of it.
i know that Quake was a huge improvement over DN3D--for one it didn't use 2d sprites--but i still think it's a much bigger jump from Doom to Duke Nukem 3D than it is from Duke Nukem 3D to Quake. i just remember the first time i played Duke Nukem 3D, dropping down from that vent shaft in Hollywood Holocaust at the beginning of Episode 1: L.A. Meltdown, it totally blew my mind how "realistic" this game was. having only played games like Wolfenstein and Doom before this, it was completely amazing to me that i could actually look around in any direction i wanted to using the mouse (including up and down). and when i discovered that you could actually climb onto the buildings, walls, tables, etc. and interact with the environment so freely (especially with the jet pack) rather than being restricted to set paths or hallways, it was like a door to a whole new world of virtual reality was opened to me.
there are a lot of games that would be better classified as 2.5D than Duke Nukem 3D--for instance Crash Bandicoot, which although fully 3D graphically, still limited player movement to a fixed 2D "track." i mean, in Duke 3D you could actually have aerial deathmatch battles with the jet pack and literally fly over or under the other player. so the vertical layering issue is strictly limited to the map engine, and inside every "room" you had a fully 3d environment.