Ferrous is a student program at University of Toronto. By creating a single-player game, our goal is to build an attractive adventure game.
Ferrous is an extraordinary adventure puzzle game that immerses players in a world where magnetism reigns supreme. With its captivating gameplay mechanics, intricately designed levels, and an array of challenges that evolve in complexity, it promises an unforgettable journey that hinges on the creative use of magnetic abilities in an ever-expanding and visually stunning world. Get ready to unleash your magnetic potential and embark on a thrilling robotic adventure like no other.
A key feature of the game lies in the ingenious ways players can employ their magnetic prowess to interact with the environment. In this magnetic adventure, players can effortlessly attract (pull) or repel (push) these objects to surmount obstacles, explore the surroundings, and advance through a multitude of meticulously designed levels.
During the process, the biggest challenge revolved around code merging, leading to dysfunction and confusion in the game scenes. This culminated in a broken scenario, preventing us from presenting at the Game Design & Development Club's testing session.
In response, I advocated for a comprehensive review of our content, taking the lead in discussions. I proposed to establishing a standardized process for task assignment and code merging. Our approach involved splitting tasks into modules, ensuring one person worked on game scenarios at a time, while others focused on different, non-intersecting code modules such as UI, Gameplay, and SFX, allowing parallel coding. Meanwhile, there is also a "blocked" section to check out blocked tasks so that we can help on the team member together. Trello was employed for task allocation across modules, providing clarity on each teammate's responsibilities.
During development, we often need to reuss scripts. If a script is responsible for fixed inputs and fixed outputs, then it can be easily applied. However, if a script usually receives different inputs and triggers different outputs, but its core detection content is the same, and we still apply the previous script to hard-code it, it will generate a lot of redundancy. This problem was not emphasized in the early stages of our development, which made it necessary for the programmers to copy and rewrite the same script every time there was a new level design. This move wasted a lot of our time and caused us to do a lot of redundant communication.
So, I proposed refactoring the scripts at a later stage and using unityevent. for example, in this example of detecting the opening of a door, the developer can now pass the script that opens the door by inheriting from the baseswitch class and then modifying the onactive property. In the script that detects when the level is reached, it can take any number of switch inputs so that we can customize the level as we like. At the same time, we can also customize the output at will, such as opening doors, triggering organs, etc., which saves us a lot of time.
Click it: Ferrous-itch.io