Omeyocan
Puzzle Game
for 2 months around May 2023
Team: 5 game designers, 2 artists
Tools: UE5 | Confluence | Git
Skills: Technical design | Puzzle design
Right from the pitch, this project promised to be a technical challenge, especially as we didn't have any programmers. As the team member with the greatest affinity for prototyping, I took charge of the main mechanics: the portals. The whole early part of the project was devoted to producing proofs of concept to ensure that the prototype would look good. There are plenty of resources on the Internet for doing Portal-like effects, but in our case with portals that change gravity, are placed in advance and with the game on UE5, the tutorials didn't apply. So we had to deconstruct the logic elements to find our own solution adapted to our constraints. Here's a video of the first conclusive tests:
To develop these portals, we had to start from an empty Blueprint and build a new controller for the main character. We needed to change gravity, which doesn't work well with Unreal's default characters. We also had to take into account various scenarios, such as the slopes that our collider capsule had trouble handling, or player assistance to avoid unintentional falls and allow players to easily stand at the edges of platforms and observe their surroundings.
For the portal logic, we simply teleport the player from one portal to another as it is crossed. The more complex part comes from the fact that teleportation must preserve the player's relative position, relative rotation and velocity to ensure that portal passage is as smooth as possible. What's more, as the portals are placed against walls, the player can momentarily pass through them, which can lead to the player getting inside the floor just as they're about to arrive. Here's the first video made with the portals in operation:
Note that visualization is not yet fully integrated. The visual part of the portals was done by another member of the team, using cameras that display their rendering on a texture. As we have many portals - and not just two - the rendering calculations become very heavy, which explains the video where most of the visuals are disabled. We had to work together to optimize all this and disable portals that were too far away or not in view. I finished the project by making the save system, the menus with localization in four languages and some puzzle design, which I'll mention below.
We chose to focus solely on the mechanics of the portals for our experience. The game is scheduled to last around five minutes, and we preferred to use this time to focus our attention on portals that work at their best. For this reason, the whole team contributed to the level design by making suggestions. As we only had one LD object, preparing puzzles for our game proved to be very challenging, especially given the surreal nature of the proposal, which required us to think puzzles in several dimensions.
For my part, most of the levels I made were kept in the game, namely the tutorial rooms from 0:35 to 2:35 and the final room from 4:15. The rooms in between were made by fellow students, as were the introduction and conclusion scenes. For the tutorials, I followed the puzzle design based on twist levels to help understand all the interactions. For the later levels, I concentrated on placing decoys for the player and highlighting visually impressive spaces in the manner of Escher's stairs. As we only had the portals, it was crucial to find richness in the levels elsewhere than simply in their resolution.
