Cube
The first iteration had the cube being held in front of the character just like in the original Portal games. This however quickly became troublesome.
For example what happens when the character runs into a wall?
How does the character approach a button while holding a cube?
It also has to account for when the character is facing a nearby portal, having the cube correctly placed on the other side, and for when those portals then move.
To solve issues like these, the cube instead shrinks and is kept hovering up and down above one of the character’s hands. Aperture Science surely must have something that does just that.
One fix I did to avoid weird physics is denying the cube drop if there isn’t enough space for it to drop without colliding with something.
Buttons, Spawner & Door
To make the buttons easier to work with, I used events so that objects like cube spawners and doors can simply subscribe to one or more buttons directly in the editor.
Other details include a short cooldown to avoid spamming the button, removing the previous cube if a new one spawns, moving the button when pressed and changing color of the blue dots upon activation.
It was also visually important that the door’s open and close animations could change direction at any point without starting the next animation from the very beginning.
Platforms
To move actors ontop of the platform smoothly, the platform takes the difference of its current position and its previous, and applies that to all actors onboard the platform.
To drag the platform the player’s hand must be much closer to the next turn’s drag point than what the platform is. If the platform is much closer than the hand, the platform instead moves backwards to the previous turn. The drag point is placed further ahead of the actual turn point, as the platform would otherwise get closer than the hand when approaching a turn.
For the platforms to be easy to interact with, it is important that the player can grab hold of them anywhere on the mesh and not just on a specific point.
Water
Rather than instantly resetting the level whenever the character falls into the water, I wanted the cube to sink slowly and have the character play an animation for a short while. This gives the player enough time to realize what triggered the reset.
Without it, the reset would happen shockingly quick and may confuse the player.
It also explains why falling into the water should reset the level, showing that the character can’t swim.
To make multiple tiles of water of different sizes blend together seamlessly I used the absolute world position to modify their textures. This removes any stretches of the textures and makes waves carry on from one tile to another.
Checkpoints
This level in particular has an easy part (platform ride) that takes quite some time, followed by a quick and much more difficult part (momentum through portals).
Failing the difficult part would force the player to redo the easy and slow part, which quickly becomes frustrating.
I therefore implemented two checkpoints to allow players to keep the progress they have made, reducing the risk of rage quits.
The checkpoints can position the character, platforms and portals, as well as spawn and place cubes.