3
\$\begingroup\$

recently I was playing The Stanley Parable, and noticed that there are several impossible spaces in the game - in this example, a pair of pillars in the middle of the room, which from each side appear to open onto a long corridor between them, which would have to cut the room in two if it were present in the same space.

I hadn't seen this in a game since the Marathon Trilogy. The marathon games used a 2.5d engine that due to a quirk in its programming allowed for non-Euclidean geometry. I was not aware it was even possible with fully 3D engines until I played The Stanley Parable. How does it work? how would I do that in Unity 5?

\$\endgroup\$
1
  • \$\begingroup\$ Is there a typo in the title? \$\endgroup\$
    – Evorlor
    Commented Sep 9, 2016 at 23:53

2 Answers 2

6
\$\begingroup\$

For engines without native portal features, these types of spaces are usually created using invisible teleportation volumes.

The level author creates two or more exact copies of the area, with subtle changes between them. Each one matches what the player should see from certain positions in the space, and is internally consistent within itself.

Then, when the player crosses a threshold in one space, they're invisibly teleported to the modified copy. (And vice versa)

Diagram of the teleportation trick

Diagram by Reddit user spotpilgrim.

In the simplest case, there's some space we can stand where we can't see the parts that change all at once - say we have to go through a U-shaped corridor in between. This section of the space is the same in both copies, so when the player teleports, they can't immediately tell anything happened - it looks like they're moving through a single consistent space. It's not until they get around the corner that they spot something that shouldn't be there, based on their memory of what was actually a different room.

Note in the Stanley Parable example they made the pillars thick, and put big obstacles to walk around to control your line of sight, so you can't actually see between the pillars/into the corridor until you're right in front of it, and from there you can't see the room behind that it would have to be cutting through. The filing cabinets form that "U-shaped corridor" so there's no way to spot where exactly they teleport you between copies of the room.


In trickier cases, we can actually see into one version of the space from the other, and can't hide the contradiction behind carefully placed props. So, we have to do a little extra magic:

  1. We take the aperture through which we should see the other space (the doorway for example) and cover it with a special object that acts like a greenscreen in film special effects. When we render this part of the scene, the greenscreen object writes a mask into our stencil buffer, so we know which parts of the image need the other version composited-in.

  2. Next, we work with a modified copy of the player's camera (in an engine like Unity, we'd literally copy the camera - in other environments we might just layer an extra transform onto our camera matrix), placing this copy in the alternate version of the room, in the exact position & orientation corresponding to the player camera's viewpoint in their version of the room.

  3. We render the alternate room from this camera's perspective, writing only onto pixels of the framebuffer marked by our aperture greenscreen. This lets us selectively replace just that part of the image with whatever we want, and so we can show a corridor far too deep to actually fit into the space available in the first version of the room, or a twisting portal that leads back into the room it came from, from a different direction.

Here is a tutorial walking through how to implement such a portal system in Unity's Universal Render Pipeline (URP).

Now if the player can modify the space - say, taking/moving/dropping objects, painting or bullet-pitting walls, etc. - you'll need to exercise caution to update both copies, lest any area they share show a telltale pop as the player crosses the teleport threshold. Physics objects also need some special handling in case they interact with objects on both sides of a teleport. And any game with guns/lobbed/line of effect abilities needs to consider teleports in the path of such actions. Lighting & shadows crossing the threshold need careful attention too, to avoid showing the seam.

All of this gets a bit nitty-gritty. If you have an idea for a particular game scenario you want to create with impossible space, give it a try, and if you get stuck feel free to post a question describing in detail what you're trying to do & how - we'll be able to help fill in the missing pieces.

\$\endgroup\$
0
3
\$\begingroup\$

Stanley Parable runs on the Source engine, which is a portal-based engine.

In a portal-based engine, not all sections of the game exist in the same 3d space. Every zone (room) has its own 3d space and the zones are connected through portals. But these portals don't necessarily need to be on the outer wall of a zone and the two sides of a portal don't even need to have the same orientation. This allows some weird tricks. In the video above there is a portal between the two columns which leads to a completely different hallway. Usually map designers try to avoid doing this to not confuse the player and not break their suspension of disbelieve. In TSP, however, the developer intentionally wants to confuse the players and subvert their expectations, so he abuses it quite shamelessly.

Another Source-based game which showed what you can do with portals is the aptly-named Portal. They didn't actually need to do much to implement the portal physics. They just used what the engine was already able to do natively and built a game mechanic with it.

But the Unity engine doesn't work that way. The whole scene exists in the same 3d space. So when you want to create a non-Euclidean level in Unity, you need to cheat a bit. A possible option is to add and remove level geometry from the scene when the player isn't looking and literally switch out parts of the level depending on where the player is positioned.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ From my recollection of the dev commentary on Portal, I don't think they were using primarily native portal features. I know they needed to make a custom physics solution for managing physics objects straddling a portal, and custom rendering solutions for drawing portals-seen-through-portals to great recursive depths. So I think the paragraph about Portal the game may be misleading here. \$\endgroup\$
    – DMGregory
    Commented Sep 9, 2016 at 11:52
  • 1
    \$\begingroup\$ After doing a bit more searching, it looks like Source's linked-portal-door entity that does these tricks was actually created for Portal 2, rather than being a native feature of how the Source engine works normally (although there are indeed engines that do this natively - like the Segment & Build engines powering Descent & Duke Nukem 3D respectively, if I recall correctly) \$\endgroup\$
    – DMGregory
    Commented Sep 9, 2016 at 12:57
  • \$\begingroup\$ Portal-based visibility calculation is not sufficient to render these portals. \$\endgroup\$ Commented Dec 6, 2017 at 4:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .