Development Overview

The design requirements of this project were open ended with no set genre, theme scenario or environment. To avoid developing an idea from a completely blank slate, I designed a research survey for respondents to rank their top games and narrative genres. The results were then refined using data from Google Trends to look for the most searched genres during the past year. From this data, the following design statement was created; “physics based mechanical puzzles, with an action-adventure world, featuring some platformer elements” contained within “A soft sci-fi narrative, set on another world, with some fantasy elements.”

The logic pipe fix actor is activated via a blueprint interface which is triggered by the player pressing the use key while looking at the actor. Using a flip flop, the pipe can be fixed or broken with the according logic outputs triggered (the logic outputs are configured similar to the Source Engines Logic IO system in Hammer). The pipe fixed state function toggles the visibility and collision of the fixed and broken pipe meshes. Later in development, the toggle will be replaced with a physics interaction where players can grab a pipe and take it to any socket they please.

When observing play testers, I found that they naturally interacted with the pipe to fix it and let the water flow into the tank. However, they didn’t realise they could also break the pipe to let the water flow down its original channel to complete the puzzle. Using a show don’t tell method could be used to teach the players that pipes can be moved, placed and removed. In an early level, pipes could disconnected by a physics force requiring the player to fix them before progressing. Later this can be expanded by there being a pipe that needs to be moved from one socket to another.

The fluid tank is a child actor of the logic system allowing it to be connected to the fixable pipe using the logic functions. The function 1 on function is used to fill the tank if it is not full or currently draining, this simulates water being connected to the tank. Conversely, function 1 off disconnects the water connection. The tank is drained when the use blueprint interface is messaged, this also calls the tanks logic outputs and, after a delay, fills the tank again if it is still connected to a water source. The proposal shows the tanks fill state through a simple text renderer which is updated when the tank is filled and drained.

Play testers didn’t realise that the tank had filled up when they fixed the pipe, this was due to a lack of visual and auditory information that was left out of this prototype. As development continues, the tank could be made from glass to allow players to see the tank filling and draining, in addition to adding audio cues communicate the tanks state. I did observe that players naturally followed where the pipe led once they had fixed it.

The prototype was successful with the players citing that the fluid simulations offered a different puzzle solving experience. Players enjoyed the puzzle, all were able to solve it with only two instances of players not noticing the tank filling up eventually requiring a pointer. Players were interested in the direction the project was heading and impressed by the fluid simulations.

Early in the level, the player is taught how button valves and pipes work. First, I have tried to draw the players attention to the button valve by making the top glow and making a hole in the cave to let light sunlight cast onto it. After the valve is opened, the water flows and the wooden platform begins to move. After a delay, the physics pipe is ejected from its socket with an audio cue and a physics force. Now the water is visibly pouring out from this missing section of pipe and the platform returns to its original location, all this communicates with the player that the pipes powering the platform are broken. The player will see the broken piece next to them and the gap in the pipe and bring the two together, fixing the water flow making the platform move.

During play testing, the players understood that the water made the platform move and that the water was no longer flowing over the water wheel because of the broken pipe. Some players found the pipe disconnecting and being forced out by the water amusing.

All the pipes physics interaction logic is handled by the physics grabbable class. This class uses a blueprint interface which is messaged by the player looking at an actor and pushing the use key. If the player is not currently holding a physics object, physics and collisions are disabled on the grabbable mesh and the current location and rotation of the mesh are stored. The current location and rotation variables of the mesh are used to interpolate the mesh to the players grab point. When the player pushes the use key with an an object grabbed, the meshes collision and physics are enabled. To allow the player to throw objects with a mouse flick, the current location of the mesh is subtracted from its previous frame location creating a direction vector, this vector is multiplied and added to the meshes physics with an add impulse node.

Play testers found the physics interactions to be smooth and responsive also sighting that it was fun to throw pipes and other physics object out of the way if needed. Players thought it was visually appealing to see the physics objects interpolate into the players grasp instead of snapping.