Usefulness of speed vs modularity/ likelihood of later refactoring, for prototyping

In beginning this project, there were a lot of considerations, as we were both learning the engine, and planning for the game. Routine tasks included those like figuring out what mechanics we should prioritize, but we also needed to figure out our workflow balance with C++ and blueprints, how the unreal animation system worked, and more. So, while I wanted to jump in and get mechanics playable in-game, so we could then test them and iterate quickly, I also felt that I needed to understand how organizing systems in blueprints compared to C++, when to code in animation and actor blueprints, and how to handle the player's state in all this, so that blueprints wouldn't become a mess of logic as we tried to add more features. However, after seeing the power of another teammate's prototype he was able to get in, I realized that my focus on modularity, and understanding the whole picture of how unreal systems worked together was not the most helpful goal at the moment. With his prototype for our main sword attacks, it boosted morale seeing previously worrisome systems working in-engine, and this also enabled teammates like the artists to see their work, such as sword models and swing animations, applied to a realistic context. Furthermore, the methods he used for creating the prototype helped expand my understanding of how some of unreal worked, even if some of the methods would be changed later. I did need to get some help understanding certain systems, but after that, and started in on my own prototype for the player parry, which I got working fairly soon after. There were iterations I needed to make, such as those that became clear after learning better unreal practices, but there were going to be iterations either way, and by having the prototype available for teammates to see and work with, it also enabled people like the character animator to iterate on character animations much sooner. Overall, getting a prototype up quickly jumpstarted the other pieces involved with that mechanic, and I feel like as long as I have a reason for why I am implementing a prototype a certain way, then I don't need to have the full picture of how other systems might work to start making one. And, after making the first prototype, the team can have the benefits of a live prototype they can test their assets on, rather than a prototype that is made later, which may require less tech side refactoring, but would allow for fewer opportunities for iteration on the mechanic, and the associated assets.

Importance of direct and timely communication for solving issues

Both with game features, and in the work situation between teammates themselves, there were a variety of issues the came up over the course of the semester. Sometimes they were conflicts about role responsibilities, and other times they were random yellow lines being drawn on the screen that never went away. However, big or small, and even though it seems simple in hindsight, most of these issues stemmed from a lack of prioritizing direct communication when solving issues. Of course, especially with disagreements, it can be difficult for people to directly confront the person, clarify their idea of the problem, and to talk with the other person about how to solve it. But, almost every time people were able to do this, the ambiguous issues that put a dampener on team morale suddenly we often cleared up by the end of the day. While it sometimes took time to discern what the exact problem is, working directly on a solution with the people involved made it so much easier than waiting till the problem could not be avoided, and it also gave people a chance to share their perspectives, and understand the intentions of both sides of a disagreement. This also eliminated false perceptions of a situation, when, for instance, one person thought the negative parts of an action were intentional, but the other person wasn't aware there was an issue. With this, some larger issues on our team were solved like this, but even fixing bugs was much easier to handle when, for instance, I found an issue with the enemies interacting strangely with my projectile prototype, and I made an effort to go to the AI programmer sooner, and ask for his take on why it may be happening. I usually try to do my due diligence in finding a solution before I bring another person in, but this sometimes takes a while, and it really does just get things done faster when you have multiple minds, and multiple perspectives on an issue. So, while I still intend to give things a look before bringing someone else in, think it's more valuable to get another person in, and have a chance to solve an issue in 5 minutes, than have one person struggle for an hour. And, in issues between people, the issue almost can't be solved without direct communication, so the sooner that can reasonably happen, the better.

Usefulness of strike-team check-ins

While somewhat specific, I found targeted group check-ins for the people involved with my parry mechanic to be quite useful in keeping ideas flowing, and improving the breadth of details of the parry we were iterating on. On my team, while doing regular in-person work, we were split into strike teams based on the features that we were working on, and in my case, I was seated with the character animator, another gameplay programmer, and our technical designer, as I focused on the parry prototype. This orientation helped us quickly resolve issues as they arose, and to check in with each other, but I realized that there were still other pieces of the parry that we hadn't developed much, like the VFX when you get a perfect parry, or the SFX to go with it. So, one day, I decided to gather our sound designer and VFX artist, in addition to the regular group, and have a quick discussion on what we wanted the parry to look like, from each person's perspective. And, with this focused, interdisciplinary check-in, we were able to both create new ideas collaboratively, while also ensuring overlooked areas were being considered. Then, coming away from that meeting, we had a much clearer idea of what we wanted to create, and actionable tasks to get there. I then followed up with another one of these meetings later, and it had similar benefits, while also allowing us to consider new challenges that had come up in testing. While I know team structures vary widely, and there may not be room to have this exact kind of meeting in the future, I think the small nature of the team in these discussions helped ideas to flow more freely, and with multiple disciplines present, coupled with the focus on identifying missing areas of polish/ consideration, the meeting was easily directed towards finding actionable items tasks for improvement. At the very least, I think it's important to check in and see what areas of a feature are being overlooked, and I also plan to test and see where else these kind of check-ins may be useful.