Game Design|Programming|Audio
Game Design|Programming|Audio
Intro
Box Voyage is a weird puzzle light adventure game inspired by analogue pocket toys where the player character must complete their government mandated vacation in a box.
Box Voyage is a point and click adventure in the same way that GNOG or Windosill
is a point and click adventure rather than Deponia or Day of the Tentacle. We focused on different inputs and interaction a player can do in our game and use easy fun as a reward. Much like in GNOG, the goal of each room is to "complete" it. The player knows that they've done this when sparks and confetti shoot out of the room. We used easy fun and tactile game feel to guide a player towards the fun in a room. Interactions are simple and inspired by old analog pocket toys and developed to be as tactile and simple as possible.
Each room is a contained vignette meant to represent a different room on the cruise
ship. Each has it's own unique puzzle and interactions. Some of the puzzles are grounded like winning at all the games in the arcade while others are more surreal like turning off the sun on the bow of the ship. Changing rooms is done by rotating the box 90 degrees and a new room appears using impossible space. We gave the player as little direction as needed so that they have room to experiment and figure things out for themselves.
Game Details
On this project I worked closely with the rest of the design team and with the
programming team. I was the point person to bridge the gap between the two teams. I worked to keep the project moving as smoothly as possible by being able to answer questions about technical scope and design intent. Additionally, I developed a tool called the Player Focus Determiner (or PFD for short) to help other designers track player behaviors in the game. This increased workflow and became crucial to doing QA during lockdown when we couldn't do it in person. The tool tracks where the player’s cursor is on screen when they give input and what type of input they give. We can then use this information to see what a player’s thought process is when completing a puzzle and what elements in a room they’re drawn to first.
In addition to this, I assisted in developing the rooms from concept phase all the way
to implementation, testing, and iteration. I was responsible for producing and implementing all the audio in the game.
I also did many of the animations in the game. Of these, I am most proud
of my work with the inverse kinematics systems used on the robot arm in the final room. In the short example below, you see that I am only animating 2 points, a target, and a pole. This lets me animate the arm better and faster. I only have to worry about 2 points and it looks more "real" by nature of the IK system. While animation is not my strength, problem solving is. I used my tech skills to improve the quality of this animation
My Involvement
Early
Development
The game was originally part of a long project based class
called Capstone. We start with a small team of developers. The teams are formed by themselves. In other words, the school is not in charge of building teams, the developers are. Our team consisted of 1 artist with an animation background, 1 other designer with a background in content design and systems, a producer specializing in business and project management, a programmer with a comsci background, and myself (systems design, audio, programming, tool making).
We were required to make 3 different prototypes. We ended up
making 5 because we felt that the 3 we made could use more exploration. Our team moved fast because many of our team members are multi-talented and we had all been using Unity for a while. While part of our team was working on one prototype, another part would be working on another prototype. We would usually have at least 2 of the prototypes being developed at the same time. Having 2 devs that can go off and program on their own allowed us to do this.
Start of the process
The initial concept for this game was the player character works
at area 51 right after roswell. The player is given different contraptions they have to disassemble. When I pitched this my team was very hesitant and almost killed the concept. I knew the problem wasn’t the concept itself but how I failed to present the idea. I asked if I could make a short prototype where I would on my own do all the art, audio, design, and code. They agreed as long as I could get my other work done and gave me a deadline of 4 days. I ended up making the prototype, a very rough one, and they started to see the vision for the game. The player had to figure out how to open a device with the scroll wheel, take off a face plate, connect a wire, and open the device which turns out to be a safe. They liked the core idea of experimenting, a focus on easy fun, puzzle-like mechanics, and influences from puzzle boxes and analog pocket toys. However they disliked the context so we ditched that. We went through a few ideas before the other designer, Dakota, landed on a cruise ship. We went with this because it’s a contained space, and has a bunch of different rooms we could theme puzzles around.
Below is a gif of the original prototype
Prototyping
We developed the prototype further with the whole team and
made 1 puzzle in 2D with the whole team and then presented it to a few other teams to get feedback. Using that feedback, we then went ahead and built a demo.
Gif of the 2D prototype below
_gif.gif)
A huge part of the development program at Champlain College
is Demo Night, then cuts that same night, and then drafting following soon after that. These are immovable dates. We set a development schedule that allowed for 1 week to prototype mechanics of a puzzle, develop audio, and make art and then an additional week to implement the audio/art, test, and iterate on the design. We figured we could get an opening sequence tutorial and then 3 rooms of the game. The biggest impediment we encountered was the bottle neck of design. Our development leaned a bit on waterfall style development. Because of this, the rest of our team couldn’t move until design was done. To combat this, we front loaded as much design work as possible. Despite this, we lost a lot of time in the first sprint which resulted in us rushing the opening sequence of the game, cutting the last room, and removing a lot of content from the second room. For demo night, games are supposed to be 10 to 15 minutes long. Most of our play times were in the 7 to 11 minute range.
Developing the Demo
The way the demo played out was the player would go through the opening
sequence into the first room where they had to launch a receptionist’s hand onto a bell, which would cause a suitcase to pop out from behind the desk. They would open the suitcase which would give them a map and enable them to move to other rooms. They would at some point pass by the club room as there were only 3 playable rooms in the game. On the club door there is a sign that says come back later. Players would then go to the next room which is the front deck where there’s a winch. If player’s rotate the winch it changes the time of day. Turning the time of day to night lets the player open the club door and finish the demo.
We had very limited time and resources available to us at the
time. We needed to add another part to the puzzle in the first room. We couldn’t get new art as that would take too long so whatever we did had to be using art that we already had. We decided to add a code lock on the suitcase. The code would be the hour hand number the clocks in the reception room change to when you hit them. This used no new art and only needed us to change a few animations, add a world canvas and some cylinders to suitcase for the lock, and write code that just checks if the code is right. This small change got us comfortably into the 10-15 minute range for Demo Night.
Below is a video of an early verision of the game which was played at Demo Night
Fixing The Problem
New Team
After cuts, roughly half the teams were left. The members of the cut teams were put on the teams that got through via a draft. We got 8 new very talented new team members that had the skills we needed in order to get our game finished
On previous projects that expand with new team members, the
biggest issue I have encountered is integrating the new members onto the team. There was often an unintentional division between the original members and the new guys. To fix this, our first time having the whole team together we just ordered pizza to the work labs and played video games for an hour. While many of us already knew each other, this time was valuable for helping us actually learn how to interact with one another and become better friends and colleagues.
The other, and usually bigger problem, I’ve encountered is, there
was rarely a process in place to get the new members into their positions to help development. To fix this, before cuts and Demo night, I made an onboarding package for new members. That way if we went through, we were prepared to onboard members and get them up to speed with the project. The package included: The most recent build of the game, the Unity project, a short document with general information every dev on the team needed to know and more specific information for each discipline, and a sailor hat. The new members were given this package before we had a 1 week vacation so they had time to go through it. When they got back they were all ready to work on our game and we started work right out of the gate. This saved us time and gave us good momentum into developing the next part of the game.
On Boarding
One of the reasons we wanted to go forward with this game is
that it lent itself very well to the iterative process. We would make individual puzzles and polish them. We would only move on to newer puzzles when we were wrapping up previous puzzles we felt were done or nearly done. This meant that towards the end of development, if we were running out of time, we could just cut unfinished rooms. Unfortunately, things did not end up that way. The guidelines we were handed for development had a schedule for how content was to be added to the game. All content had to be implemented into the game by a certain date even if it was rough. Past this date, no new content was allowed in, only polish was allowed. This took the wind out of our sails significantly. A great and rewarding part of game development is finishing a part of your game and seeing it function and look complete or close to complete. Because of this schedule, we couldn’t get those periodic morale boosters. We remained in this style of development for about a month until, after a few conversations with our functioning executive producer, we learned we didn’t actually have to adhere to the schedule as closely as we initially thought.
Going To Pax
Around this time, we also found out that we were going to PAX
which really lit a fire under our asses to get moving. We had gotten our feet under us but a new challenge was on the horizon. If you’re reading this soon after I wrote it then you will already know what I’m talking about.
Covid 19
After PAX we went on a week long break. One of the
programmers and I assigned ourselves a few small tasks to do just so we could catch up a bit because we were still a little behind of where we wanted to be. On one of the last days of the break we got an email. Our break was extended by a week. A few days later it was extended by another week. Then we were told we were going to resume work but remotely.
By this point, the other leads and I were scrambling to figure out
what this meant as far as development. To make up for not being able to see each other in person we set up google hangouts and group work sessions. To compensate for more difficult communication, we focused on making clearer channels of communication between disciples. We also started a new policy where individual devs were responsible for getting features done and one of the lead devs was responsible for making sure the task was done up to a certain standard. Some of our devs were out of state when this information came to them and were not allowed back to their hardware. Our supervisor Edmar arranged for those devs to have hardware and software sent to them. One of our Programmers, Nick, was visiting family in California and was not allowed to leave. He packed to be staying for a week and had to make due staying there for a month. While I’m proud of how quickly our team was able to organize, stay calm, adapt, and communicate, this event was a dramatic set back.
Our Reaction
What I'm Proud of
One of things I’m most proud of that I did for this project was the
Player Focus Determiner. It was an add on to the game that ran that records where a player gives input in each room. We could then use that information to make a heat map and see how a player’s attention moves around a room. It started before the Covid lock down. Before lockdown, it was deemed to be taking too much of my time from other work. We were moving towards scrapping it so I could focus more on audio and implementing content. However, due to the lock down, our QA resources were almost completely eliminated. Because of this, PFD’s development was continued in order to get information about what players were doing in the game without relying on self reporting.
The way it works is it generates a unique user ID code if there is
none existing in PlayerPrefs. As the player completes puzzles and gives inputs in rooms, PFD records when and where the cursor was when input was given and what room it was in. When the player ends their play session, this information is uploaded to google drive. Later, we can download it in editor mode. The information is displayed as dots over laying the rooms. We use this information to get a better understanding of what was going on in the player’s head. Most importantly, we use it to see if players are paying attention to and interacting with the parts of the puzzle we want them to interact with.
PFD
Animation
The other thing I’m most proud of on this project was animating
with the IK system we had. I have a little experience animating but I am by no means an expert. I was tasked with animating the claw hand in the final room of the game. I took on this job because I felt like I had a clear idea of how I wanted the arm to move and how I was going to do it. We wanted it to look fluid and a bit sinister. I animated the arm using inverse kinematics. The only points that I am moving using Unity’s animation engine are the individual claws, the IK system’s target (where the IK is going to try and point to), and the IK system’s pole (where the “slack” of the arm goes towards. Between these very few points I was able to get a result I was satisfied with.
Team Members
Design Team
Josh Forchheimer
Lead audio/tech design, tools programmer, assistant gameplay programmer, assistant animator
Dakota Williams
Product owner, team lead, lead designer, systems designer
Tim Carbone
Tech designer, systems designer
Garrett Harriman
Puzzle designer, systems designer
Programming Team
Walter Hill
Technical lead, systems programmer, tools programmer, graphics programmer
Nick Eckstein
Gameplay programmer, systems programmer
Alex Hubble
Gameplay programmer, systems programmer
Vedant Chaudhari
Gameplay programmer, systems programmer
Art Team
Isaac Mills
Art lead, animator, VFX artist
Michelle Lee
Environment artist, prop artist
Celina Tong
Environment artist, prop artist
Production Team
David Carlos
Production lead, marketing
Mitchel Zaza
Producer, project management
Brett Schwartz
Business consultant
