Inspiration

These… energy… reactor-things, first started out much like the cubes and buttons in valve’s Portal (2007), where to open a door a cube must be placed ontop of the button.

However, with no graphic artist on the team I had to scour the internet for art assets, and the failure to find a model suitable for our game led to some interesting improvisation.

The Hover Point

Any cube touching the triggerbox gets pulled toward the hover point that slowly moves up and down by lerping between two positions.

To get the ‘t’ value for the lerp (0 is bottom position; 1 is top position), I used an inverted lerp on the sine of time to remap -1 through 1, to 0 through 1, which is the range we want for our value ‘t’. The result is the hover point slowly going back and forth between the two specified positions.

Active Effects

To show the player that the button-thingy becomes active after recieving a cube, I added a set of effects. These include making parts of it glow bright, playing a particle effect and rotating the coils.

The coils also seamlessly resets their rotation after having completed a revolution, as well as pick up where they left of in the rotation should the cube be removed and replaced.

Activating Objects

Its not always we want the button to open a door, as we see in Portal where it is also used to move a platform, spawn a cube and change the direction of the funnel to name a few. Likewise, Afterimage’s buttons needed the same dynamic to choose outcome when activated.

Unity Events enables me to specifically choose which method to call on which object, which allows each button to have their own unique outcome when activated.

The end of the video above shows the script called from the button that handles the door movement. Saving the current progress and using it to calculate the start value for the loop makes for a smooth “in place” turn of the door; Rather than having the door teleport up or down to restart its movement whenever the direction would change.

Dynamic scale

I wanted a way to easily update and change the variables of the lasergrid such as the number of lasers, the distance between each laser and each laser’s width, without having to manually rescale the model afterwards.

Therefore I made use of the ContextMenu to create a method that could be called directly from the inspector. This method then calculates the needed lenght of the model to fit all lasers, and then goes from one end of the model to the other distributing the lasers’s origin points.

Dissolve Effect

I felt that just removing the cube instantaneously upon touching the laser wasn’t nearly dramatic enough. With the use of shader graph I managed to portray the laser’s hazardous nature in style.

The shader makes use of a simple noise block attached to the alpha to lay a map of pixel values between 0 (Black) and 1 (White). It then iterates over these pixels and checks if the value of the current pixel is greater than the alpha clip threshold to see if that pixel should be rendered. Changing the threshold over time via script gives the sought after dissolve effect. Adding a lit edge to it helps the effect look convincing.

The spirit’s path

The purpose of the spirit is to teach and guide the player throughout the game. The game was designed in order to test two different types of tutorials against each other, and the spirit is part of the type called “Example tutorial”.

I first tried to keyframe animations for the spirit but quickly found it difficult to get a smooth curve as the spirit made immediate sharp turns on each keyframe. I then recalled working with cameras on earlier projects where I used the Unity tool Cinemachine, and more specifically the dolly track.

A dolly track with a cart allows for other gameobjects to be set as children of the cart and thereby follow along on its journey. The track itself is made by designating coordinates and choosing which order they should be arrived at; the smooth curviture is then created automatically.

Sequencing the tutorial

An earlier version of this level had the whole tutorial shown at once. The spirit would start flying once around the button and then immediately continue on all the way through the entire sequence. However, our playtesting sessions quickly made it clear that too much information was being shown too fast.

To solve this I split the tutorial into different parts that with the help of the “Instruction Sequencer”-script are all be triggered and replayed in correct order and timing. Triggerboxes and interactable objects placed within the scene are used to start the next part of the tutorial whenever the player has progressed far enough, and is ready to see it.

Creating each part of the tutorial is done using Unity’s timeline tool which allows me to animate the values of multiple different objects and then via script have all the animations start playing collectively. I also make use of timeline signals which lets me call any method of my choosing directly from the timeline at the given keyframe. This is used to have the spirit swap tracks at runtime, successfully changing a value that can not be animated.

Player teleportation

The player can press LMB (Left Mouse Button) to save the current position, rotation and camera pitch. Pressing LMB once again then teleports the player back and applies the stored values.

Teleporting also converts the player’s current velocity into the forward looking direction, launching the player in whatever direction the player was facing when saving the position.

In an early version of the game a position could be saved while the player was in the air. I then discovered this could be used together with some jumps to get to any hight without the need of a pit to fall into first. The player could simply jump, save, fall down, then jump again and immediately teleport up while still moving upwards from the jump, save, fall down and repeat.

We decided that to save the position the player would need to be grounded since we felt all levels became comepletely broken by this newfound strategy.

Cube Teleportation

The cubes can also be saved and teleported in the same way by pressing RMB (Right Mouse Button), albeit without the velocity change.

To show the player that the cube did not duplicate itself when saving its position I made the copy of it transparent, but kept its lighting to still bring attention to it.

Each cube also has a reference to its image copy for the ability to remove the copy should the cube be respawned or destroyed in any way. A lingering image copy with no cube connected to it would only confuse the player and clutter the scene.