Go Back

About

Dreamline is a two-player competitive fishing game created for children aged 8 to 12. Players aim to catch a greater number and higher value of fish than their opponent. The project focuses on accessible, learning by doing mechanics by utilizing only two primary controller buttons.

Project Info

Role: Gameplay Programmer

Team Size: 9

Time Frame: 4 weeks

Engine: Unity

Tags:

C#Unity

Introduction

This is a deep dive into the development of Dreamline, a two-player competitive fishing game designed for individuals aged 8 to 12. The primary objective of the game is straightforward: each player must try to catch a greater number and higher value of fish than their opponent.

During this project, our group prioritized a learning by doing approach and focused on creating easy to understand mechanics. Because we had to create the game specifically for the Xbox Adaptive Controller , we immediately discarded everything else on the controller apart from the two primary buttons. This decision reduced the project’s scope and ensured we had sufficient time to develop a game that was both intuitive and polished. Here is a look into my specific technical contributions to the project, focusing on UI architecture and modular gameplay systems.

Teaching Mechanics Through UI

One of my primary goals was to ensure players could grasp the core mechanics before the game even began. To achieve this, I proposed and designed the menus so they could be picked up in the exact same way as the fish, allowing players to naturally learn both movement and the hooking mechanic. This approach not only introduced the controls seamlessly but also aligned perfectly with the overall fishing theme of the game. I built this using a clean, object-oriented architecture, starting with a base abstract class that contained all the default functionality. This base class also defined an abstract method, OnInteract, which allowed all derived classes to implement their own specific behaviors. For example, the player select script extended this base class to handle selecting a player color and starting the game, keeping the logic clear, organized, and concise.

Creating a Modular Player Effects System

The player effects system underwent several redesigns during development. The initial implementation relied on a large switch statement on the player to trigger effects, which was neither clean nor easily extensible. I spent a weekend exploring alternative solutions and ultimately chose to implement the effects using ScriptableObjects . This refactor made the system highly designer-friendly, allowing the design team to create new effect variations, such as unique sound profiles for each fish type, without needing a programmer to modify the code.

Because most effects had an associated duration, I created another abstract base class to handle the default functionality, allowing each specific effect to override the Apply and End methods to define its own behavior. I then developed an EffectManager responsible for executing the effects and ensuring they did not overlap unless explicitly permitted. To prevent game-breaking behavior, like exponential speed increases from stacking movement boosts, the manager simply resets the effect’s timer when it is reapplied. Finally, I built an EffectTrigger class that holds a list of these timed effects and notifies the player when a caught fish carries effects that need to be executed.

What I Learned

Building Dreamline was a highly informative experience that helped me achieve my primary goals: strengthening my teamwork skills and deepening my knowledge of the game engine. Having not previously worked on many projects with a group of this size, I emerged feeling much more confident in my ability to collaborate effectively. Technically, my engine knowledge improved significantly, for example, I learned how efficient and straightforward it is to load assets directly from the resources folder.

However, the game-jam like pace of the project taught me a valuable lesson about technical debt. Due to time constraints and rapid mechanic changes, our initial backend system architecture was not extensible, and we failed to document or comment our code as we developed it. This created challenges for other programmers trying to extend the system and forced us to spend a considerable amount of time refactoring later on. Moving forward, I would dedicate much more effort to thoroughly planning backend architecture to make systems dynamic, rather than relying on hard-coded components that limit flexibility.

Read more about Dreamline on itch.io

Developed by Shahin Mohseni, using Svelte. Visual direction inspired by the portfolio of Tomas Wallin.