Shahin Mohseni | Gameplay Programmer

About

ParaSCI is an intense first person shooter starring a scientist infected by a bloodthirsty parasite. While gameplay demands relentless aggression, the technical project focuses on building modular backend architectures and dynamic UI systems to seamlessly drive these complex mechanics without breaking the core loop.

Project Info

Role: Lead Programmer

Team Size: 9

Time Frame: 3.5 weeks

Engine: Unity

Tags:

C#Unity

Introduction

My main focus for this project as Lead Programmer was creating the core upgrade system for the player, but also smaller things that needed to be fixed. Like handling the UI logic, managing dynamic tooltips, and linking together different systems built by the other programmers.

Before I started with the upgrade system, I knew integrating it with the parasite’s hunger mechanics would be a challenge. The sequence was demanding: it required pausing the game, updating player stats, resetting the hunger bar to 0%, and temporarily deactivating the parasite. I explained to the programming team that building this without a solid architecture would be a gamble, and we could end up just fixing edge cases during the entire project. But I told them it was something I wanted to work with to get a better understanding of how decoupled architecture works in Unity.

We agreed to try a modular approach, and if the implementation was too difficult, we would go back to a simpler, hardcoded stat system. I managed to make a robust base class using Unity’s ScriptableObjects , and we decided as a team to continue with our custom modular system.

Architecting the Upgrades

One of the most complex challenges I faced was successfully integrating overlapping features, specifically linking the parasite’s mechanics with the upgrade system. The upgrade sequence was demanding, it required pausing the game, updating player stats, resetting the hunger bar to 0%, and temporarily deactivating the parasite for a set duration.

To achieve this without breaking the core gameplay loop, I guided the programming team in utilizing design patterns and decoupling classes to build robust, independent systems. I built the core of the upgrade system using a clean, object-oriented approach driven by ScriptableObjects . By creating an UpgradeConfigBase class, we were able to define abstract methods for applying upgrades and fetching tooltip data. Specific upgrades, like fire rate or reload speed enhancements, simply inherited from this base class and defined their own logic.

Dynamic UI Tooltips and Player Communication

As we progressed, a major issue surfaced, it was difficult for players to understand exactly how an upgrade would impact their gameplay. The math which utilized a complex system where stats increased logarithmically with diminishing returns, was completely hidden from the player.

To solve this, I designed a dynamic tooltip system. I refactored the upgrade objects so they could calculate and “export” their future data to the UI before actually applying the changes to the player. The UI scripts then evaluated current player stats against base weapon configurations, presenting a clear, side-by-side numerical comparison (e.g., showing a stat change from 8 to 9) that felt smooth and responsive.

What I Learned

We struggled in the beginning of the project with integration bottlenecks and scope creep. After losing a team member early on, we failed to properly trigger a formal rescoping. We tried pushing forward with a dangerously ambitious beta build. We didn’t see it at first, but it had affected our workflow in a negative way. Because our programmers were building intricate systems in isolation for too long, linking them together late in development inevitably caused unforeseen conflicts. This made my bugfixing duties far more time consuming than anticipated.

Because we ended up in a situation like this, I learnt how important both planning and continuous integration actually are. Moving forward into future projects, I will strictly enforce our team’s “Foundations First” value to protect the Minimum Viable Product (MVP), and I will mandate a strict “design freeze” on core mechanics before implementation begins to prevent sweeping changes later on.

Working in Unity and building this architecture was a lot of fun, and I learned a bunch in this project. Establishing a modular architecture allowed me to efficiently link diverse systems. I actually learned way more by digging my way through shared troubleshooting and late stage conflicts to see how things break and how everything is connected, instead of just building systems in isolation.