Postmortem

Witch's Brew was an ambitious project. It had many moving parts, and I was working in a game engine I was unfamiliar with, using a coding language I had only dabbled in once or twice.

Frankly, it went better than I expected. My goal of creating a endless puzzle game was fulfilled, and the difficulty level being rather difficult is what I had aimed to achieve; something that would give players a challenge, and one that would force them to think. I also think I was successful at creating a cohesive atmosphere. While the visuals all can be accredited to Misha, it was my first time creating all the sounds in a game from scratch. I have very little experience with sound design, so I was worried I wouldn't be able to match the quality of the game in terms of sound. Coming up with what to record and recording it was easy; my brother has a pseudo-sound recording studio, so I was able to get high-quality sound clips. I did have some difficulty in balancing the sounds. I didn't have a good idea of what was too loud, and so, I ended up having to go back to edit the volume of almost all my clips because they proved to be too quiet. Additionally, I think the background music was executed well for it being only the second bit of music I've composed. Though, I wish I was able to create a longer melody; I think it gets repetitive at times, but I was struggling to lengthen it. Perhaps I can look into adding a bridge next time.

I could definitely improve on internal organization. I wasn't thinking too much about organization beyond naming my game objects and scripts (and even then, the naming convention wasn't consistent. As such, in the later stages of development, I had some difficulty finding certain objects and where certain scripts were. Within the code itself, I also could've added more comments, to make navigating my code in later development faster. Additionally, I need to remember to think about resolution from the start. I had plenty of difficulties with scaling and resolution when it came to the final build, and it caused a lot of stress. At first, my game would be cut off because it was too big, and then, after fixing the scaling, some of my animations and code would break. In the end, I just kept the game bigger than I liked resolution-wise.

My key takeaways that I will take to the next game is organization and planning ahead. Planning ahead with things such as resolution could save me a lot of headaches later. Creating test builds to make sure my resolution and scaling works before going and doing a lot of work would help a lot, so I would still be able to fix things. Since I didn't do that for this project, by the time I noticed the resolution issue, it was too late to fix. Additionally, better organization will help me navigate through everything better. Keeping a naming convention will help with file conflicts (I had some issues with sounds because of conflicting names), and organizing similar objects together (such as potion-related objects) will help me find things easier later in the development process.

Lastly, I want to share my thoughts on Unity, as it was my first time using it for a full game.

Honestly? I love it. I love it more than Godot! I think the game object system feels more intuitive than Godot's node system, and since C# and Java are very similar, I took to the coding like a duck to water. Unity has a lot of features that feel more intuitive than Godot, such as the built-in scene switcher, and how you can keep game objects active even when their original scene is unloaded (which is what I used to keep the music in the different menus consistent. I also find the button system very nice. I didn't have to create a code for each button to work; I could just simply link it up with the built-in OnClick() commands.

There are lots more I could talk about when it comes to what I like about Unity, but I'll leave it there for now.

I look forward to creating another game using Unity!