CAGD 370 - Postmortem

 Postmortem

Development Successes

One part of the development that went well was learning to problem solve on my own by doing research. As much as I did reach out to my teammates or instructor for certain questions, I also employed the strategy of researching the problem beforehand. I consulted many tutorials and forum posts in order to resolve many of the issues I encountered. This is not to say consulting my teammates was not helpful, but it does save some time when you can problem solve on your own.

Another aspect of development that went well was learning how to budget time to work on this project. I would set aside hours of certain days and let my teammates know beforehand. This was helpful because it forced me to work at that time and avoided merge conflicts.

Development Failures

One part of development that didn't go as well was communication. I won't name names, but I often found that one teammate consistently left us in the dark as to how far they were as well as to when they were going to work on the project. This made the development process very uncertain because we weren't sure when things were getting done. I appreciate the work that they did do, but it's important to keep others informed.

Another aspect that went wrong was merge conflicts. This wasn't a major problem, but happened often enough to cause some annoyance. To avoid this, we scheduled certain times to work on the project so that we weren't both working on the same file at the same time. Communication faltered a bit at the end which led to some merge conflicts, so it's important to keep others updated.

Example of Merge Conflict

Lessons Learned

One of the lessons I learned is how important communication is to work effectively on a collaborative project. Keeping others in the loop reduces uncertainty and creates an idea of where the team is at in terms of progress. It's also important to seek out help if you cannot solve the problem by yourself in a timely manner.

In terms of hard skills, I've also learned much about visual scripting and execution flow. It took a little bit to get back into the swing of things which is why the first sprint or two was lackluster on my part. I've also learned a lot about inheritance which was very useful for saving time and storage.

Example of Visual Scripting

Redoing from the Beginning

The first thing that comes to mind is creating base gel projectiles and gel pads that would allow the process of customizing the children to be streamlined. As it is now, they are all customized, but have the same attributes within their blueprints. Overall, this just made the process take longer since I was copy pasting the same code across three blueprints. 

Another thing I would get across in the beginning is that the design phase should've ended after sprint one. We should not have newly created annotated maps two weeks before the project is due. Art also should not have been as big of a priority as it was since we didn't have the proper tools and time to implement it. I think more time needed to be spent in Unreal to really get the mechanics down and then we could've transitioned into creating polished art assets. If we had more people, I would gladly say we should have a dedicated art team, but getting the mechanics to feel smooth and implementing a proper UI should've taken priority with our small team. This is not to say that the work done was not quality, but the time spent on it may have been misplaced.

Going Forward with "Gel With It"

If I were to continue developing for the game, the first new feature I would implement is to have the sticky gel deal damage to enemies. The sticky gel has long since not been utilized and its place in the game uncertain. Making it deal damage to enemies would give it use as a sort of combat gel. The sticky gel had many identity issues and does not serve a true purpose even in the final build. Its biggest use is to slow down the player if they are moving too fast since it resets velocity to zero.

Another feature I would adjust is having the bounce gel bounce the player based on the normal it's placed on. As it is right now, it launches the player up the same amount even if it's stacked on top of each other. If the bounce gel could be used to launch the player based on the wall or floor it's placed on then the utility of it would increase immensely. I imagine a scenario where the player needs to use them to bounce from wall to wall in order to reach the other side.