SNAPSQUATCH

SNAPSQUATCH is a local-multiplayer arcade action game where players compete to take the best wildlife photos in a setting inspired by Yellowstone National Park. It was made over the course of 16 weeks by a team of 10 people during my senior year gamedev capstone class. I was mentored by AAA developers at Iron Galaxy where they provided weekly feedback and advice on making the game.

  • Role: Gameplay Programmer & Co-Producer

  • Team Size: 10 People

  • Development Time: 16 weeks

  • Development Period: January 2022 - May 2022

  • Platform: PC & Mac

  • Engine: Unity

Contributions:

  • Created the main photo capturing mechanic which included scoring, displaying, and identifying photos

  • Designed the poster, the trailer, the itch.io page, and the weekly patch notes

  • Coordinate team milestones, presentations, and deliverables along with the other co-producer

 Trailer

Summary

Over the course of 16 weeks I had the responsibility of being co-producer and gameplay programmer. As co-producer I focused my time on keeping the team organized and documented with agile development. This included creating patch notes, aggregating feedback, and conducting A-B testing. While programming I worked on the main photo capturing mechanic. The process began with collaborating with the designers to create the first version of it, then constantly iterating on that mechanic with weekly improvements.

The Idea

The main gameplay mechanic of SNAPSQUATCH is taking photos of wildlife. I wanted to challenge myself and took the reins on that system. To start I worked closely with the designers to create a first rough draft of what we wanted out of the camera. After I got the initial design specifications, I looked at New Pokemon Snap and the Slaparazzi mini game from Super Mario Party, which gave me a foundation to start coding.

The Photo Mechanic

For the photo mechanic I first started by breaking down the problem to smaller parts that could be tackled in weekly sprints. The first task was attaching a camera to the player and getting it to take a photo of what is in front of them. To do this, I made sure everything in front of the camera was rendered and I could get the planes from the frustum of the camera. After that, I had to evaluate the photo. Using a mix of raycasting, checking with a list of all animals in the level to see if they are in the bounding box of the camera, and a collection of custom formulas we were able to identify everything in the photo and score it. Scoring took the bulk of the work as we wanted it to be dynamic and fair to the player. To help figure out the intricate coding system I developed these photo panels which held detailed data about the photo. This would update in real time as we were playtesting in order to make the scoring feel fair.

Iteration

With the panel made we can now score a photo based on multiple factors and that’s when the real work started. Through player feedback we learned that we might not have scored fairly. One example of this is how many animals are in the photo. The original way we scored it was that the animal with the highest score would be the starting point for the player then we add up the score for the rest of the animals at a lower rate. So if the highest scoring animal is 500 points and the second animal is 300 the player's score would be 650. This worked great until players found out that the only photos that scored high is one with many animals. To fix this we decided to cap it so you will only get the score of the three highest scoring animals.

Scored too Low

Scored too High

Scoring

The biggest debate over scoring from our team was in regards to if scoring should be additive or multiplicative. At first we set penalties for the players' score if the photo looked bad. This resulted in even good looking photos to be scored harshly and be penalized. After player feedback we switched over to an additive score where if an animal is blocked by a tree we would subtract some points. This resulted in photos that looked bad to still be scored high. In the end the best solution was a mix of the both. We would add points if the animal was the perfect distance away from the camera and we would use a penalty multiplier if the animal is too far or too close.

Takeaways

Working on this camera mechanic was the highlight of my college career. It allowed me to challenge myself with new coding techniques. It presented problems that required unique solutions. It highlighted everything I learned before with playtesting and getting player feedback. I might have written the code but without constant iteration the game would have been less successful. 

Co-Producing

This group has been the most diverse in terms of discipline and peoples indenites. Going into this project I knew that we had to start communication off on the right foot and stay organized. For the first month of the project, we started online and I implemented a speaking order when we were in meetings to avoid talking over each other. It went designers, artists, then programmers in order by first name. We divided the work between programmers by splitting the project into three distinct parts: the main camera mechanic, animal ai, and ui/miscellaneous. Even though we weren’t working on the same code, we wanted to maintain consistent code reviews. To implement this we started off with standardization for code, comments, and formatting. This included using camelCase for variables, and making sure all functions and classes have headers. When working with the designers on the scoring, it was a constant back and forth with us engaging ideas, implementing and playtesting it, then going back to check if that improved the scoring system. We often started with white boarding and drawing it out before coding it. Other responsibilities I had were creating promotional material like weekly patch notes, the poster, and the trailer. By ensuring effective communication and teamwork we were able to stay within scope and on schedule. 

Scored Perfectly

This video is a deep dive into my thought process when creating the scoring system.