My Contributions
Most of my work in the project is on gameplay behaviors. Notably, I worked on most of the different boat systems, such as the damage and paddleboards. This was my first year of college, and looking back, much of the code I wrote for this project fails to hold up after 3 more years of experience. That being said, out of all the student projects I've worked on so far, I think this one is a strong contender for being most fun. This was a great project to start my career with. It taught me vital lessons on what it meant to be a game dev. You don't need to be an excellent artist or programmer to make a good game, you just need to have passion and the willingness to learn. That being said, I have improved massively since this project. While I won't claim to be on par with senior developers, I will say that among my peers, I have always put more effort in to make sure that the code I write is effective, optimized, and maintainable.
While I'm not proud of my implementations, I think it is worthwhile talking about some of the things I made, and what I'd do differently if I were to remake this game. For instance, the first game mechanic I implemented was the paddleboards. These aren't too terrible, you walk up to them, you get a prompt to increase or decrease power, and pressing those buttons modifies a property inside the paddleboard behavior. The big issue I have with it is that most of this code was all located in the same file. If I were to remake it, I would consider adding a separate 'Interactable' script that is in charge of determining when the player is nearby, spawning/despawning the input prompt, and then calling a set function when input is provided. I think separating this system from the paddleboards behavior more closely follows the single responsibility principle and would've helped to make the code base more maintainable.
Lastly, I got the amazing opportunity to act as this team's producer, which mostly involved making sure the team was prepared for our meetings with the professors and making sure that our project would meet the submission requirements. Being producer on this team taught me a lot, as it's easy to avoid dealing with the burden of project management if it isn't part of your responsibility. One of the major lessons I learned was that task-tracking tools are so much more important for producers and project managers so that they can have a decent grasp on the current state of the project. Using these tools was something I struggled with early on, until I took this producer role. A second lesson I learned was about setting goals and assigning tasks. It was my job as producer to help guide the team towards our goal for this project. We decided early on that we wanted to ship to Steam, and so I needed to learn what the submission requirements were for both the class, and for the Steam page. We did end up delaying the Steam submission until after the summer in order to polish the game for a couple extra months, it was incredible to have first-hand experience with setting goals, milestones, and targets in order to make sure that we ship a finished game.
While I'm not proud of my implementations, I think it is worthwhile talking about some of the things I made, and what I'd do differently if I were to remake this game. For instance, the first game mechanic I implemented was the paddleboards. These aren't too terrible, you walk up to them, you get a prompt to increase or decrease power, and pressing those buttons modifies a property inside the paddleboard behavior. The big issue I have with it is that most of this code was all located in the same file. If I were to remake it, I would consider adding a separate 'Interactable' script that is in charge of determining when the player is nearby, spawning/despawning the input prompt, and then calling a set function when input is provided. I think separating this system from the paddleboards behavior more closely follows the single responsibility principle and would've helped to make the code base more maintainable.
Lastly, I got the amazing opportunity to act as this team's producer, which mostly involved making sure the team was prepared for our meetings with the professors and making sure that our project would meet the submission requirements. Being producer on this team taught me a lot, as it's easy to avoid dealing with the burden of project management if it isn't part of your responsibility. One of the major lessons I learned was that task-tracking tools are so much more important for producers and project managers so that they can have a decent grasp on the current state of the project. Using these tools was something I struggled with early on, until I took this producer role. A second lesson I learned was about setting goals and assigning tasks. It was my job as producer to help guide the team towards our goal for this project. We decided early on that we wanted to ship to Steam, and so I needed to learn what the submission requirements were for both the class, and for the Steam page. We did end up delaying the Steam submission until after the summer in order to polish the game for a couple extra months, it was incredible to have first-hand experience with setting goals, milestones, and targets in order to make sure that we ship a finished game.