Hey!
I once mentioned on github that I would tell more about my Portal game project on Defold - well, this is the moment).
When I was getting familiar with the Defold API, especially for working with buffers and render targets, the first thing I tried to do was render a virtual camera view into a texture and apply it to a mesh. I didn’t bother with correct mapping of rotation angles, projection, etc. Just did it and forgot.
Six months later, I came across this “development” again. I saw it and thought: why not do it more properly, as it is done in the Portal game? So that when you look into the portal, it feels like you’re looking through a window, not at a texture. So, after 2 months of occasional work, here we are)
Computer games are smoke and mirrors. The implementation of Portal’s mechanics perfectly illustrates this. Using the laws of Euclidean spaces, we need to create a sense of non-Euclidean space. How do we do that? With a set of tricks, of course! The main ones are:
-
Portals. These are simply oval meshes on which we render virtual camera views. The standard solution for this sort of thing is to use a stencil buffer. The original Portal is no exception: it uses a number of techniques to achieve the desired effect (stencil buffer + render targets + BSP occlusion). This allows you to keep performance at a high level. In my case I use only stencil buffer - it is enough for a small project for now.
-
Twins. See the screenshots.
The box is standing inside, so it’s protruding from both portals. But there’s only one box?! For the player - yes! But technically it has a copy that is completely dependent on the original box. And sometimes the original also depends on the copy (when, for example, a player passing by the copy pushes it - then the copy transmits a signal and impulse to the original).
The player model also has its twin. Look at the dark line running through the entire body, it shows where the copy and the original meet.
- Passing through portals:
a) Teleportation. Yes, it’s that simple. You have to calculate the new position and direction correctly to maintain the smooth transition effect. It’s pretty simple when it’s “vertical portal” to “vertical portal”, and a bit more complicated when we mix “vertical portal” and “horizontal portal”, but still not rocket science
b) Walls and floor. To get a smooth transition, we need to teleport at the right moment. Specifically, when we cross the plane of the portal. Walls and floor will definitely prevent us from doing this. There are several ways to accomplish this task. I went the simple way: I disable collision of the object (player or box) that is in contact with the portal trigger. This method has its pros and cons, but it’s good enough for prototyping. Anyway, we won’t need construction tools to make a hole in the wall
And there are a whole handful of such tricks: how to rotate the player’s camera correctly if the portals are in different planes; how to save the movement speed and “pushing” the player out of the portal, etc.
You can see what’s implemented so far in this video:
Special thanks to @astrochili and @aglitchman for the tools and libraries they make for the community. Many things I’ve learned from studying their work, and some of them I’m using in this project:
Kinematic Walker - became a jumping off point for the Portal Walker.
Trenchfold - allows you to use the handy 3D level editor Trenchbroom.
Scene3D - a great set of techniques and examples.
UPD. Reuploaded video in better quality
