Sashimi Slammers

Platform:
Windows PC

Engine:
Unity

Language:
C++

Tools Used:
Unity3D, Maya, Photoshop, Monodevelop

Duration:
10 weeks

Completion:
Beta Complete

Team Size:
3

Role:
Concept, design, prototype, model creation, rigging, animations, FX creation, prop and texture placement, lighting

Pitch:
Fight your opponent fish off the chopping block by flopping and flipping each other into the deep fryer.

Overview:
A game in which you control a fish with a physical fish controller. For this game, we were limited to quick gameplay (about 30 seconds to a minute) with only being able to use two buttons. Made for DePaul’s Game Modification Workshop class with two other programmers.

Please see below for design documentation, playtest reports, as well as our thought process behind creating the game!

Sashimi Slammers Gameplay Demo

Sashimi Slammers Design Documentation

Game Board and One-Day Prototype

My quick mock-up of what our game board could look like during our pitch to the teacher and class. The cutting board was the playable space, and the two fryers on the sides were the goals in order to get a point. We also had a unique idea of showing our score on the knives. We also thought about having a pile of fish in the back and when you died, one would get removed and put onto the board.

Our very first prototype done in about one day. We had very basic fish, a gameboard, and goals / win condition (the deep fryers). Controls were also simple, X to move and Shift to attack for the left fish and Comma and Slash for the right fish. Obviously these controls were changed when we iterated because it was too clunky, awkward on the keyboard and we wanted a nice game feel.

Clunky but Playable:

Our first prototype (as well as a few updates to it) was super clunky at first. We originally had squares as fish since I had not made the fish model yet. This was to test how the movement felt with force being the driving factor in how the fish move.

We debated a lot about how we wanted movement to work. One idea was basically doing math to calculate how the fish would move when the player hit the move button. There were a few issues with this:

Having fish move a set distance would look awkward as real fish would slide slightly since they are a bit slippery, especially if they are flipping in the air towards a specific direction
This would promote slower game play with incremental movement, which goes against our goal of quick game play sessions
It would be much harder for us to iterate later on if the game lasted too short or too long as we would have to edit the math instead of the game board

After going through our ideas, we decided to try force movement for the prototype. It looked terrible, but actually played pretty well. When presenting to the class the first week, not only did they like it, but our teacher did as well. He basically said we achieved what we pitched to him and that our scope was so small that we could actually spend the majority of our time polishing our game (and that is what we did).

Testing out animations in-game. Hit detection was still buggy as this was our second prototype. I liked how these animations looked as they were all very smooth. The only bad part was that the animations were quite slow. Unity allows us to modify the speed multiplier inside of their animation editor so we can easily speed up or slow them down.

Maya animation shown to students during first class session to gauge how fish movement would look like. We later changed this to more of an “inch worm” style since spamming the move key would look weird with that animation.

First iteration of the fish attack animation. There was a long pause at the start of this animation that later simulated input delay, but I removed that so the game felt more responsive.

Playtesting Reports and Iteration

One of the most important aspects of creating a game is getting feedback from others. It is easy to make something, play it, and say “this is the best thing ever” but then wonder why no one plays it. You thought it was amazing, but it turns out no one liked it or there was a fundamental flaw with your design. This is why you get people to play and give you feedback so you can iterate on your design to make it the best possible one. It is very rare to have something amazing the first time and not have to work on it to improve it.

For our play tests, we got players to answer a few non-leading questions to sort of point us in the right direction and to answer our research questions we had about our game. We wanted to figure out if the controls worked and were not clunky or confusing since our prompt was to have only two button controls. We wanted to make sure that this part of the game worked well and felt polished. Our other research question was about game play time since we wanted quick rounds in our game of about 30 seconds to a minute. For the most part, people felt that the game play time was about right. When designing our final level, I made sure to keep the same board length since that directly relates to the game play time and the time needed to keep hitting a fish into the fryer.

Our last question was just about having fun. It is always important to keep iterating on your game to improve mechanics and make it just like the design doc or concept art, but while that is necessary, you should always be aware of how fun your game is. If people are not having fun, they will most likely not come back to play more, and if money is in the question, that means less profit. During our sessions, most players were communicating to the other player as well as talking about what they were doing and smiling. This was super helpful in gauging the fun factor of our game because if they stopped smiling or talking, we can see what part of the game that happened and do some digging to see what was wrong.