FISH! | Brayden Riddell

Overview

State

Published on ITCH.IO

View on ITCH

My Roles

Systems Designer

Technical Designer

UX Designer

Engine

Unreal Engine 4

Production

13 Single-Week Sprints

Team of 9

SCRUM/AGILE

Game Description

YOU ARE IN DEBT! Play as Gobey, an anthropomorphic catfish who’s lost all his shells in a game of go-fish. The holder of your debt, a raccoon named Meatball, now expects you to pay it back ASAP.

Travel from island to island, knocking out other bottom-feeders for their shells by smacking them with your handy fishing rod up close, or by yanking them around from afar. Then choose whether to risk your shells on gambling for upgrades, as you chip away at your debt and hook, line, and sink your enemies into the surrounding swampy waters!

Featured Contributions

Through the development of "FISH!", I was tackling a lot of different responsibilities such as being the team's only system designer, tech designer, and UX designer. Along with this, since our programmers were very specialized, I handled documenting, prototyping, and implementing all but 3 gameplay systems & mechanics.

Below are some of those features!

Intent

The concept of "FISH!" was developed bottom up, starting with the mechanic of fishing rod combat. As a result, this is the very first thing I prototyped to prove it's feasibility.

We wanted to play into the goofy-ness of the unorthodox weapon of a fishing rod while utilizing its practically. With this, we settled on three major usages: Casting a line+hook onto an enemy, forcefully reeling them in towards you (giving the option of going straight into melee or pulling them into the water), and a melee "bonk" to commit most of the damage.

Prototyping & Iteration

The melee attack was relatively simple, having a tie to the animation itself to decide when it's eligible to hit and deal damage.

Through messing around, I came up with a relatively simple implementation for the casting and reeling functionality. Having the hook act as a homing projectile, it flies to the targeted enemy and latches on. Before launching, a cable component is created tethering the hook to the fishing rod itself, replicating the fishing line. When the hook is successfully attached to an enemy, the player can reel the enemy towards.

With the functionality working, I focused on polish iterations such as the hook attaching to a socket on the enemies so that it moves with their animations and rotation, making the line more visible and fitting the art style so it didn't look too out of place (as the cable component normally does), and making sure the feel of using the fishing rod felt more snappy compared to the first prototype.

Initial Melee Prototype

Final Melee Implementation

Initial Cast Prototype

Final Cast Implementation

Initial Reel Prototype

Final Reel Implementation

Intent

Through development and testing, we realized that we needed to reinforce player motivation. While the game being a roguelike inheritably has an end-goal of clearing your debt, keeping your debt counter but loosing upgrades when you die, we found that players wanted more satisfaction through their mini accomplishments while they work towards a big over-looming goal.

This design problem initially was tough to solve because of our time constraints of being a semester long project. We had already wanted to add achievements just for fun, and we realized that this could be a fantastic solution towards this problem as it perfectly compliments one of our target player motivations of completionism.

Achievement Masterlist

Implementation

We came up with a lot of different achievements, some of which have tiers (for example, killing 10 enemies, killing 50 enemies, etc.). I wanted to make a very streamlined system for handling and implementing the achievements to keep it nice and clean.

I started with prototyping a simple handler event, which you can pass through a certain ID. Depending on the ID, it can easily point to the logic of checking if it should grant the achievement due to it's current conditions. I made the IDs via a data table to which anyone could add to or make edits to. This way, it's very scalable and easy to make a bunch of different achievements.

On the other hand, I wanted to make sure the feedback for achievements was very cohesive. I made a pretty streamlined menu for the achievements through the settings menu which displays all achievements and highlights the ones you have gotten. Upon getting an achievement, I made a pop-up notification. I wanted to strike a balance of being subtle, noticeable, and recognizable as to not disrupt gameplay, but make sure players know when they got an achievement. I accomplished this by having it in the bottom corner, having movement, as well as working with our sound designer to tie an audio cue for it.

Example

Achievement Popup

Achievement Menu

Intent

In order to feed into the rougelike player progression and motivation to get as far in the game as possible, upgrades play a vital part in assisting the player through the scaling enemy difficulty, as well as playing an integral part in the narrative of the game.

Manifesting the upgrades as a gambling machine invokes agency in the player, prompting them to choose between gambling their earned currency for vital upgrades to keep up with difficulty scaling, or work towards the end goal of paying off debt. However, I wanted to make sure to present some amount of decision making as well with the machine. This is reinforced by the visual emulation of a slot machine by spinning 3 rollers, but allowing the player to pick one of the three rollers when they are all landed. This allows for a balance between real gambling chance and player agency power fantasy through the stack-able upgrades.

To reinforce different aspects of combat power fantasies, we have the following upgrades:

Rod damage output
Line casting distance
Enemy currency drop
Total health refill

Upgrades Masterlist

Prototyping & Iteration

I started with prototyping an upgrade machine that visually emulated a slot machine. However, behavior wise, the player can choose between any of the upgrades each roller lands on. As seen in the first demo video, you can interact to roll and choose one of the four upgrades. To make the system scalable and dynamic, I had the generation of the upgrades on the rollers randomize, pulling from a data table with the upgrades and their information so that artists can implement art, and other designers can easily change other attributes and values for future balancing & polish.

Iterating upon this machine, I implemented the behavior with the model blockout, and made the machine cost money to use. Along with this, I iterated the roller generation to generate randomly with the exception of not having the same upgrade appear consecutively.

At this point, it wasn't very intuitive through a player experience lens. Through a lot of QA testing, I was able to identify some key components to improve the UX of the machine. In order to streamline the interaction with the gambling machine, I made tooltips for each of the rollers that displayed information about what upgrade it landed on, and streamlined it with the interaction system I had previously made so that instead of just whacking it, the player would be prompted to "E" to interact with the roller they choose. Along with this, I implemented a highlight post-processing effect so that the player was clear on which roller they were inspecting. To provide player feedback on if they didn't have enough money to engage with the machine, I added a simple flash effect to the required money text displayed on the bottom left.

Initial Upgrades Prototype

Midway Upgrades Iteration

Final Upgrade Iteration

Documentation

Download
Systems List

Retrospective

This was my first time actually really working in Unreal Engine. In so many ways I'm so glad that this was my first big project in Unreal, since I learned so much and had to solve problems very creatively. I got to experiment and play around with random things in the engine which I used to my advantage.

While this overall made me very proficient in Unreal, it was a major undertaking since I was the main person documenting, prototyping, and fully implementing systems and mechanics as well as implementing everything in general for tying together the game loop. It was unfortunate there wasn't much technical interdisciplinary work (for example a more stereotypical pipeline of prototyping as a technical designer and passing it onto a programmer for further implementation). Due to this I scavenged for any pipelines I could get, so we managed to facilitate code reviews which helped the technical team a lot in the end. Because I was so invested in systems and technical design and because of time constraints, I didn't get to flex a lot of UX design as much as I wanted to. However, I'm very glad I managed to focus on a few things such as the upgrade machine and UI elements in the game.

Overall, this was a very fun and goofy project to work on. This project singlehandedly taught me a lot about the engine, without which I wouldn't be as proficient. Additionally, I learned a lot about balancing many different roles and asks, as well as nailing down communication across all disciplines through meetings, meeting notes, documentation, and asynchronous communication.

Team Members