Overview
Feeding Time was my first ever Game Jam project created for Jame Gam #30. Our team went into this jam as a learning experience for our upcoming year-long custom engine Sophomore project, and certainly got what we were looking for. I served as the Design Lead on this project, and as the main programmer, utilizing Unity and C# scripting. I worked to scope out the project, as well as designing the core gameplay loop, and all gameplay systems. This project taught me many valuable lessons in scoping and design leadership, as well as giving me good practice with System Design, UX Design, and implementation.
Core Gameplay Loop
When starting this project out, we knew that we wanted to make a game that revolved around a single, simple gameplay loop. I took inspiration from a mobile game called The Fishercat, which I had played as a kid. We decided we wanted to make a similar action-fishing hybrid game.
​
I knew when taking inspiration from this game that I wanted to iterate on its gameplay a bit. Because your only action is to shoot, it can make the gameplay feel static. ​​
Movement
​​I wanted to give the player more control and more to do while playing to better help them get into a flow state. By allowing the player to move, it lets positioning matter when shooting, adding another layer to gameplay.
On top of this, having to pick up your gears adds more complexity to this layer. This allows players to make more complex moment-to-moment decisions about where to shoot, how to position themselves, and when to pick up gears.
Developing Flow
Using Csikszentmihalyi's flow state model, this system creates an effect where the task difficulty is dependent on the player's skill. The difficulty of picking up the gears is dependent on how fast the player is firing, and how fast the player fires is dependent on how fast the player picks up the gears. The faster the player is firing, the more difficult it is to sustain that fire rate. This creates a system where the task difficulty scales with the user's capability, innately supporting the player entering a flow state.
Damage
​Another thing I did was create a velocity-based damage system. When players shoot a gear at a fish, the fish takes damage equal to the velocity of the gear, and then that damage value is subtracted from the velocity. This creates a nice effect where it makes each fish feel like it has weight to it. This also allows gears to pierce through weaker fish, letting players kill clusters of fish in a satisfying way.​
Rewards Screen
With the rewards screen, I wanted some practice designing something that takes the time to celebrate the player’s success, since this wasn’t something I’d had the opportunity to do before now. I decided the best course of action was to “slap” each fish that was killed on the screen, one at a time, and lerp up a total reward counter.
I also wanted it to be a bit ridiculous, especially after a good run. At times, some of the fish would end up outside the box, especially the “boss” fish that were found at the end of each stage. This was originally unintended, but I decided to leave it in since it added to the absurdity of it. I wanted it to give a bit of a “We need a bigger boat” feel, and I think this really helped with that.​
Lessons
The biggest thing I learned from this project is just how expensive content can be. The team as a whole spent a TON of time doing art assets for the fish and levels. While we were quite satisfied with the number of fish we could get in, it came at the cost of improvements to the core gameplay loop. Things like particles and screen shake would have added a lot more to the experience. Despite trying to avoid this from the start, we still fell into this pitfall. This lesson would serve myself, and the rest of the team well moving into our work together on Cobble: The Stone Forager.
​
I also had added a progression system into this game, which didn’t turn out to be as refined as I would have wanted. Because getting through the whole game took a while, and it was added in so late, there wasn’t enough time to test the system. I learned that progression systems in particular are definitely not something that should be added towards the end of a project.