Menu

Portal

Home / Projects / Portal

Portal

A portal remake in OverLord
Overview

For our graphics programming course we received a C++ engine and added key features to it as we went on, see engine topic for more information. For the end assignment we had to create a full game. I chose for portal because I loved playing both the portal games and I was really eager to tackle the portal mechanic.

I wanted to make this portal mechanic awesome! However, the project had fixed requirements and harsh deadlines. Because of this I had to stop being perfectionistic and prioritize other elements of the game. In the end I was happy with the result for the actual assignment, but I did not feel like I was done with this project. It was a lot of fun to work on this and I still wanted to fix my portal's oblique projection and tweak the fysics of teleportation. So, I did! I spend a part of my vacation on this and the results will be described and shown further down in this page.

The Engine

The game was made in the OverLord C++ game engine. An engine that is created by our teachers Matthieu Delaere The base of the engine was provided and with guidance I added key features to this engine in order to support the full game at the end of the road. , Brecht Kets and Thomas Goussaert.

The engine renders using DirectX11 API and the physcis run trough the PhysX API. Since maintaining the engine and adding the features was our own responsiblity, I've learned a lot about using these API's and the core fundamentals of an engine. The engine did not come without bugs so this made it very interesting to find a solution yourself or find a way to work around it.


The game

Portal snapping:

Spawning a portal on the wall itself is easy. However, another issue reveals itself when implementing this feature. What if the player shoots on the corner of a wall? What if the first portal overlaps with the second portal? This issue had to be addressed and so I made a function that snaps the portal to a valid location if possible. When this is not possible it plays a sound for feedback and spawns a particle effect at the shot location letting the player know this location is not valid.

To check if a portal is past the wall boundary I take the bottom left and top right corner of both the wall and the portal. This can easily be done by the locations and transform vectors. Next up, I take a dot product and depending on the result I know if the portal needs to be adjusted or not. This is hard to explain in text so let me show you in code:

In the video example displayed here you can see the snapping in action. No matter what rotation the wall has, the portal will always snap to a proper location or spawn the particle effect indicating the location is invalid.

Portal teleportation:

This feature came with multiple problems to solve:

How do I let the player walk trough the wall?
For this I had to add an extra trigger collider to the portal. This would notify me once the player is about to enter the portal and will temporary remove the walls collision.
How do we keep the player his velocity?
I Simply have to carry over the current velocity and let my character controller handle possible gravity.
How do we rotate the player according to his new portal spawn?
Get the rotation of the new wall and check the difference with the rotation of the original wall, then add this difference to the players rotation.
When do we teleport the player?
For this I once again made use of the dot product (see img). the result can accurately tell me once the player has passed the wall.

What will be the exact new location when triggering the teleport?
I got very close to solving this issue but didn't quite make it in the end, there is still a small offset during the teleportation. This offset is minimal but enough to make the player realise something happened, this unfortinately destroys the illusion.

Here you can see the teleportation very slowly:

Portal Rendering:

This part really kept me busy for a while. In order to render the portals I had to create new virtual cameras and add them to the render loop. Due to persistant memory in the graphics card, a custom engine and an overall lack of previous experience on graphics programming this was quite the challenge.

I had to create new virtual cameras for each of the of portals. These cameras store their own render target. In the render loop the portal cameras get rendered before the players camera, why will become clear in a minute. These portal cameras render the scene and ignore everything behind the portal to save resources. When it is done rendering, it will store this information into the rendertarget. When the render loop arrives at the players camera it will render the scene like normal. When the portal shader is getting rendered it will now use this previously stored rendertarget as a 2D texture of the scene. The pixel shader can now simply sample from this texture to color in the pixels of the portal.

Portal HLSL shader:


Game menu:

For the menus I made simple buttons that you can give a texture for unselected and selected status. Then all you have to do is give it a function to execute when the button is clicked.

Here you can see an example for opening the controls menu, in this case a lambda made more sense then to create an actual function:

CMAKE Build

After finishing this project I thought it would be the perfect opportunity to work with CMAKE in order to create a build and a downloadable. I created a CMakeLists.txt in all the folders of my project. These CMakeLists files give instructions on how to bind and handle all the files and libraries. With just some simple commands in the command line I can choose to create a debug or release build, ZIP or downloadable exe file.

Conclusion

It was definitely more challenging to make the portal remake in the OverLord engine compared to other engines like Unity or Unreal. I believe this challenge had a great impact on my engine understandment. I also learned countless of other small things that I wouldn't even be thinking about if it wasn't for the lack of functionality in the engine. I really enjoyed working on this game and loved figuring out the portal mechanic.

The tools I got to use while working on this project: Overlord, Mixamo, Adobe premiere pro, FMOD, CMAKE and visual studio.

Some funny results


Credits

The animations used came from Mixamo. I also used Mixamo to rig the character.

The models and texture all came from free to use assets on sketchfab.com (EG: the character).

The game design came from Valve.

The engine was created by my teachers, for more details check 'The Engine' information block up above.