Blood Beach
DESCRIPTION
A horror-themed interactive visual novel set on the pier of a small town. You play as a fish vendor working in a shopping center while chatting with locals, managing relationships, and uncovering gruesome secrets.
Our team consists of around a dozen game developers (mostly students) of varying experience.
MY ROLES
Game Design
Programming
PROJECT TYPE
Freelance/Volunteer
ENGINE
Unity 6
GENRES
RPG
Horror/Mystery
Demo in progress
We have wrapped up development for the season and will be returning to this project later in 2025. The demo will likely be completed early next year.
Project Overview
In early 2025, a small group of college friends began development on a hobbyist game project: an RPG with horror and mystery elements. Production was being structured through a scrum flow comprised of weekly check-ins and seasonal development cycles. Close collaboration and frequent communication were also organised for sustainable and consistent long-term progress.
By the end of the first season (before I joined), a working prototype had been developed with basic functionality of the core mechanics implemented. Now, the team were looking to expand prior to beginning the second cycle. Impressed with this game's pitch deck, I got in contact with the project manager, joining the team at the start of the new season which began in June 2025.
Over the next 9 weeks I made steady progress on the tasks allocated to me while quickly adapting to the workflow and using my design intuition to constantly refine my work. I also attended weekly meetings, where I updated the team on my progress and received feedback from the project manager.
Fish Prep Minigame Overview
My primary contribution to this project has been the crafting of a side minigame which involves running a fish stall. For this minigame, the player must work to prepare fish and complete orders sequentially, earning in-game currency for each order completed. There are several types of fish that may be used in this minigame, and a variety of order types (fillets, steaks, etc.).
Minigame Layout
When I began working on the fish prep minigame, my first step was to construct a basic layout for the physical workstation using placeholder meshes. Doing so ensured I had a clear vision for the minigame moving forward and would be able to implement each feature in service of this wider vision.
I reiterated on the layout multiple times during development to make the setup feel more natural and less superfluous, while better suiting the final models as they were imported into the project. By the end, I had rearranged every element depending on what stage of the process it is used, with strong emphasis on vertical placement:
-
Ticket - this is the first thing the player looks at when starting each new order, as it tells the player what needs to be prepared. It is located in the top left-hand corner.
-
Raw fishes - transferring these to the cutting board is the starting point of the physical process. They are located across the top centre, directly above the board.
-
Cutting board - this is where the entire fish prep process takes place. Due to its strong importance, it is located in the centre of the screen.
-
Descaler/knife - these are used for the bulk of the fish prep process. They are located directly underneath the ticket, with the descaler on the left as it is always used first. It is also used less often than the knife thus is further away from the cutting board.
-
Trash - all unwanted fish parts (and failed orders) are discarded here. It is located in the bottom corner, isolated from the other interactable elements to minimise the chance of the player selecting it by mistake.
-
Butcher paper roll - this is always used in the final step of each order. It is located in the bottom centre, directly underneath the cutting board.
Note: the tutorial panel is a placeholder and will not be included in the final version. This space will likely be allocated to the menu and other major UI elements.
This final design helped make the minigame feel as intuitive as possible, allowing players to work from top to bottom without getting confused as to where any equipment is, while maintaining a natural flow of player movement throughout the minigame loop.
Prep Process Design
As per the initial brief, there were exactly 5 types of order in this minigame: raw fish, gutted fish, fillets, steaks, and cubes. These order types vary in complexity, and each order is packaged in butcher paper in the final step.
The exact process for each order type was originally unconfirmed in the brief, with my assumption being that each order type would be identical to the previous one while adding an extra step at the end. However, researching the exact steps that are taken in real life fish preparation taught me that this design would be inaccurate for several reasons. For instance, gutting is not a necessary part of the filleting process, while steaks are cut from the main body of the fish and not the fillets.
I ended up redesigning the set of orders to form a symmetrical 'tree' as shown below. Now, it flows out into multiple completion states following the descaling stage, making the overall process more practical and streamlined. Moreover, the branching paths add a new layer of challenge, as it is now possible to take the wrong action thereby messing up the order. This forces the player to stay focused and think carefully about each step rather than solely relying on muscle memory.
Pickup & Pivot Mechanics
Before programming the preparation process, I implemented a basic mechanic allowing the player to pick up objects by clicking on them. All collision detection was handled with raycasts projected from the mouse position. I integrated this mechanic into the minigame manager script early on, defining the full context for each piece of equipment (when it can be picked up, where it can be put down, etc.) in the manager.
Later during development, I produced a simple 'animation' script to enhance the feel of moment-to-moment gameplay during this minigame. This script could transition objects to invisible pivots, using linear interpolation to smoothly animate the visible object to match the respective pivot's position and rotation. I would end up using this script to handle the vast majority of object movement during the minigame:
-
Each spawned object (ticket, raw fish, package, etc.) is instantiated at a spawn point then transitions to another pivot.
-
Each grabbable object is pivoted to a certain start location by default, then to the cursor position when picked up. It is then pivoted to wherever it is put down.
-
When the knife is hovered over cuttable fish sections, it is pivoted to a specific angle to demonstrate the type of cut that can be made there.
-
A fish can be flipped over on the cutting board with right click, rotating the fish between 2 pivots: left-hand side and right-hand side. The purpose of this mechanic is to provide the player with access to both sides of the fish when removing scales and/or cutting fillets.
Minigame Management
I produced a central script to handle the fish prep process from start to end, integrating each process and completion state one at a time. First, I implemented the simplest order type: a raw fish. From there, I was able to prototype the descaling process as well, though I iterated on this stage multiple times once the scale meshes were completed. In the final version, the fish automatically rotates depending on the vertical position of the mouse, providing the player with a better view of scales along the fish's spine and belly. Because the scales are normally hard to detect against the fish's skin, I also set the skin to a transparent texture during this stage, making the scales much more visible.
Early on, the system as a whole was straightforward enough that the Update() method sufficed to handle all player input. This solution scaled poorly however, which became apparent as I tried to add more complex order types. Certain animations and even collision detection failed due to performance issues which were caused by the method making irrelevant evaluations (such as checking for scale collisions during the gutting stage). To address this, I had to separate the handling of player input relating to the fish prep process and allocated it to a coroutine, ensuring only evaluations pertaining to the current stage were being made. When no fish is being prepared, the coroutine is completely inactive.
The general player input (actions such as picking up the knife that can be performed no matter what stage of the process the player is at) was still being handled in the Update() method, though this was eventually changed to a more elegant alternative. This gave the script far greater control over context, minimising the amount of computing power spent on redundant collision checks thereby optimising performance during runtime.
Collaborations
While I was able to work on the fish prep minigame mostly independently, there was a strong collaborative component as well. I followed an iterative workflow where I thoroughly documented my weekly progress and regularly adjusted according to feedback.
Throughout development, I had to work in close collaboration with the 3D modellers and texture artists, and especially the project manager. I had to be clear and certain in specifying what models needed to be made while quickly integrating assets into the project once they were completed. I also had to design parts of the minigame with the other team members in mind, thinking ahead and making changes in advance whenever I felt it was necessary.
For example, the steak cutting stage was originally going to allow the player to make cuts in whichever order they wished. However, this would have added a substantial amount to the modeller's already heavy workload, and so I redesigned the steak stage to only allow the player to make cuts in order from head to tail. This compromise reduced the number of steak meshes that needed to be modelled considerably.
Next Steps
Our team finished development for the season in late August 2025, being set to resume progress later this year. While the fish prep minigame is almost fully functional as a standalone experience, it still needs to be further polished and integrated into the main game. Tasks I am currently expecting to work on in the next sprint of the project include the following:
-
Save system - I had previously pitched the idea of a central system for storing all save data across the game. The fish prep minigame would read from/write to this system when handling variables such as the quantities of each fish type in the player's stock and the currency amount.
-
Ticket order system - the current version of the fish stall minigame randomises each new ticket order. I am anticipating playing a role in designing how the ticket order system will work.
-
UI implementation - the visuals for the fish prep minigame UI have not been produced yet. I will be integrating these into the minigame when they are finished.
-
Dialogue system animations - the current version of the dialogue system lacks animation. This is something I have past experience with, thus I may end up creating a solution to enhance the dialogue visuals.
At this stage, I have become well accustomed to the workflow and development cycle of Blood Beach and am confident in my ability to work just as reliably over the next sprint.