Moving in is a narrative focused point and click visual novel with silent hill-esque exploration where the environment/world reacts to the choices the player makes. The player assumes the role of a shapeshifter that replaces a shut-in that recently passed away, and must ultimately fool the friends and family of their host in order to fully replace them.
Credits
Theo Ruefli (Gameplay Programmer, Gameplay Designer)
Jack Pederson (Gameplay Designer, Production)
Kath Wick (Gameplay Programmer, Narrative)
Arman Akhmetov (Audio Designer, Composer)
Saadet Tutumlu (2D Artist, Technical Artist)
Technologies Used
Built in Unity with C#, with Maya, Clip Studio Art and FL Studio used for Asset Creation
The gameplay cycle is broken up into two sections, the first being an exploration info gathering segment where the player explores the apartment of their host in order to learn more about them as a character and the world they inhabited.
The second section involves meeting friends and family members of the recently deceased, where the player engages in conversation and must use previously gained knowledge to deceive and convince them of their normality.
As a large part of Moving In revolves around the story telling, one of the ways that we decided to drip feed narrative to the player was through the interactable script.
The interactable script is a self contained reusable/modular asset that when attached to any 3D object in the scene allows it to be interacted with.
When hovered over, the object lights up, and when clicked on brings up a description textbox automatically populated with dialogue directly pulled from a text file attached to the script.
It contains the functionality to advance dialogue, close and display different dialogue depending on how many times it has been interacted with.
When designing this system, I aimed to make it as easy as possible to work/interact with, so that the rest of my team could focus on making their own work as great as possible without needing to reserve time and concentration for the implementation into our game.
I created several customizable/drag & drop fields including:
A text file to pull dialogue from.
An audio file to play as text appears
An option to hide the object when the scene loads unless a certain flag/checkpoint has been reached by the player
Customizable text color.
Another way that we decided we wanted to communicate our game’s narrative to the player was through having them be able to converse with our characters 1 on 1.
The dialogue controller handles all the dialogue functionality during the conversation segments of the game.
The system contains the logic for the back and forth questions and answers that appear during gameplay.
Similar to the interactable script, when designing and implementing I kept the amount of components that the rest of my team had to interact with low as well as simple to work with to let them focus on creating new content. During the process of designing this tool, I sought feedback from my teammates on improvements they needed on a weekly basis.
The controller comes with several customizable/drag & drop options such as:
Dialogue color.
NPC audio.
NPC dialogue file.
NPC sprites.
What scene to go to next.
One system that was crucial to get right was our camera system. It is the primary way that the player is able to view our world, interact with it, and a means that we can curate the player's perception of our game.
The camera system is in charge of moving the main player camera to different prepositioned locations when the player enters an area.
I designed this system with both simplicity and user experience in mind by creating modular, reusable widgets that can be physically moved around/resized in the engine. Adding a new angle as simple as positioning both components, connecting them to each other and adjusting the options in the inspector.
Each camera module/component includes:
A positional stand-in widget to adjust the position/angle of the camera
A resizable trigger area to tell the system to move the camera.
The option to have the camera follow the player instead of just remaining static.
One large feature that we wanted to include in Moving In was the ability to track a player’s progress and to have the game and characters within the world react to their decisions.
The flag manager is a static/singleton system that tracks flags/checkpoints the player has reached
Their personality traits based on their previous decisions
The scene that they are currently at in the game.
It has several functions that allow values to be altered or retrieved.
The system is designed in such a way that it is easy to add additional functionality without it interfering with previous code.
Included useful debugging tools/messages to make debugging as smooth as possible.
Early on in planning and development, we knew that we wanted a way for the player to be able to retain their progress between play sessions, since it is a feature commonly seen in other visual novel titles.
The save system is in charge of writing and reading all data that is relevant to save to an external file.
The save system records current player flags/checks, their current personality traits and the last scene they were in.
Designed the system to be both simple to use and easy to call from anywhere in the project, while also remaining easily scalable.
Data is stored in a text file to make it easier for non-technical teammates to work with