Pre-Post-Mortem
|
This week concludes the series of blog posts about “Burn Witch, Burn!”. As such, I felt that a retrospective post is justified, even though the development process continues for another week. Being the lead coder in our group I’m going to focus on that aspect of the project.
Problems similar to the aforementioned would continue to arise throughout the project. Often, I’d find a quick fix to an issue and stick with it. Quick fixes quickly escalate, however. Soon I found myself refactoring old code every time a new feature was being added. The foundation laid in the beginning of the project was weak and required caution stepping forward. Reflecting upon the code, there is a clear boost in quality the further into the project a feature was added. At some stage I felt like I’d like to start over from scratch but the time table wouldn’t allow that. One atrocity I committed was to use if statements instead of a state machine for the enemies’ AI. It led to the implementation being effortless. The downside was unreadable code and complicating the interactions with other game objects. The lesson that I’m taking away is the importance of understanding the tools you’re working with. How do they relate to the tools you already know. What are their strengths and weaknesses. Going into the next project, I’ll ensure that I’m able to create a solid foundation for the game with the tools provided to me. In the end I’m glad I had the possibility to experience these shortcomings in a relatively small project, as it was still at a manageable level. I’m also happy with what our game has become, a lot of people seem to have enjoyed it.
 |
The project was my first in Unity and C#, resulting in some hurdles that had to be overcome, or dragged along to the finish line. In C++ the #include directive is used to bring a file’s functionality into your script. Transitioning into C# I found it difficult to separate code into multiple files. Due to the project being seemingly small scale, I proceeded with scripts that would hold all the required code for individual prefabs or game objects. During the creation process of the second type of enemy, a lot of code could be reused from the first enemy. I refactored the code into multiple “MonoBehaviour” scripts and added an “EnemyTypeXController” script to the different enemies. With no other knowledge of how to acquire access to the different scripts, I added all the behaviors to the game objects in the inspector rather than inside the scripts and got the components through Unity’s interface. The result was cluttered game objects and inefficient code. The solution would have been to use C#’s namespaces or partial classes.