​
Project Overview
Team Size: 8
Development Time: May 2019 - August 2019
Platform: PC
Game Engine: Unity
Programing Language: C#
Role: Programmer
​
A short video explaining the project and my role in it
​
Project Overview
Stitches is a horror themed first person puzzle platformer where player must rotate the environment to solve puzzles. Each level takes place on the inside of a cube with various things that can be climbed on and interacted with. In addition to navigating in first person the player can shift their perspective to view the entire level from outside the cube. Here the player can select individual sections of the level and rotate them the way they would rotate a Rubix's Cube. Items attached to the walls/floors of these sections will rotate with them and can form new paths for the player. The game was created over the course of three months with a team size of eight people.
​
Responsibilities
- Create player movement system
-
Create sound manger
-
Create intractable objects
-
Create environmental interactions
-
Create dialog system
-
Make all systems easily modifiable by designers in engine
-
Document all systems thoroughly
The trailer for the game
A screenshot from the game's final level
Role
During this project I served as a programmer using the language C# in Unity 3D. I was one of two programmers on the team and focused on player interactions and back end systems. I created the sound manger, player movement system and dialog system among other features. I purposefully created all of my work to be as designer friendly as possible by giving them the ability to modify various values in engine. I took great strides to thoroughly document all my work so all members of my team could easily use all of the feature's I'd created.
Movement System
It was my job to create the player movement system. Early in development there was talk of implementing physics puzzles. Because of this I chose to use a character controller for our player as opposed to the typical ridged body. This was done to allow us more control over the physics interactions between the player avatar and other objects. The downside of this decision was that we did not have access to the unity physics system since our player did not have a ridged body.
​
I needed to create realistic gravity myself though code. To do this I fist used raycasts to check if the player was grounded. If it was not then each fixed update the player would be moved down by a certain increment. This increment would then be increased causing the player to fall faster until either they land or the max gravity increment is reached. A similar technique was used for the player’s jump except the player lost momentum the higher they got in it. This system helped to create realistic gravity with acceleration as opposed to falling at a static speed.
A short video showing the movement system and how it works
Interactions
It was my job to program a variety items in the environment that the player could interact with. These include objects the player could grab, buttons the player can activate and spaces the player can place objects to trigger events. Each of these objects had to be created in a way that they could interact with each other and the player.
​
For grabble objects I used a raycast that moved with the camera to detect if the player was in range and looking at the object. If they were then the player’s retractile would change and they could click to pick the object up. The object would then become a child of the player object and snap to a position that it would always be viable on camera. The player could then click again anytime to drop it. If the player was facing specific trigger areas when dropping the object then it would snap to that trigger.
​
Thought the level there were various buttons that either the player or an object could press. These buttons had to be flexible and allow for a variety of different events to trigger in different levels. To accomplish this I made a child object of the button with a trigger. In the button script I created a variable to keep track of the number of objects in the trigger. This variable started at zero and was increased by one whenever an object entered the trigger. It was then decreased by one every time an object left the trigger. As long as this variable was more than zero the button would be considered active. A boolean variable kept track of this status which other scrips could see though the accessor function and trigger necessary events.
​
This system drastically simplified the steps that it took to implement audio in engine. Before a designer would have to know exactly where in the hierarchy the object with the sound was and what its parent object is. They would then have to get the audio source from that object before they were able to play or modify the sound. With the manager they only to know the object’s name and the function they wanted to perform. The manager would automatically find the object in the hierarchy and grab its audio source. This reduced the amount of code need to stop, play and modify audio sources down to one line.
​
Sound Manager
I created a sound manager that allowed the sound designers to easily place audio in the level and play it at the desired time. While the manager is in the scene a designer only has to do is to attach an audio source with the sound to an object tagged “Sound”. The manager automatically grabs all objects tagged as sounds regardless of where they are in the scene or hierarchy. Though the manager sounds could be played, stopped, looped and have their volume changed.
​
​
A short video showing the sound manager and how it works
This project was a major turning point for me in terms of my time management. In the past on projects I had no set scheduled for my work and would simply do it when I could find the time. This not only lead to crunch but constant stress as the work loomed continually over my head. Knowing this was a issue I began meeting with a time management instructor and began working with him to better organize my time. In hind site this was possibly the best thing I have done in my recent career. Together we were able to put together a system for myself to organizing the times I would get work done and what tasks I would do during those times. In this system at the beginning of the day I would list all everything I wanted to get done and make a scheduled for myself. This would be done in a journal that I would then carry with me and would consult whenever I was unsure of what I should be doing. This not only reduced stress but also helped me to create work of a better quality. This also helped me build a better rapport with my team as I was able to successfully front load my work and free up any dependencies.
Reflecting
This was the first team project where my primary role was that of a programmer. In the past, while I had assisted programmers during crunch and helped to create prototypes, I was never one of the primary programmers. This forced me to be extremely honest with my team as their were many thins I just could not do and attempting them wold prove disastrous. In the past I had worried about appearing lazy so I would take on much more work than I could reasonably expect to do. However with this role I began estimating more time for my tasks as I assumed that additional research would be required for them. This lead to me having incredibly accurate sprint estimations and enabled me to complete all of my work on time each sprint.
The player could zoom out to rotate the environment.
By using the arrows they can get a view of any side of the cube
The Team
​
Jeffery Friedman
Designer/Product Owner
.jpg)
Julianna Zegarelli
Designer
Zachary Fugere
Designer
David Cary
Technical Designer/ Programmer
Savanna Gamache
Artist
Andrew MacDonald
Technical Designer/ Programmer
Ashley Corrado
Artist
