Devin Mihaichuk Loominescence Development Portfolio

In this project, I have worked alongside the technical development team primarily on menu design, save systems, document management, and QA testing. While I did perform more of a supporting role for this project taking smaller parts and assisting the rest of the technical team however I could, I still encountered many challenges and developed many skills over the course of this project that I would like to share.

Firstly, I want to go over my main contributions to the project outside of bug fixing and document management that being the save system and the menu control. For the save system, I have chosen to attach the tutorial I made in the form of a pdf if anyone is interested in the inner mechanics of how that works. I have also included below a diagram showing the mapping of the different menus I created and worked on throughout the process and how they interact with one another:

The goal was to make a menu that felt in line with the aesthetics presented in the game and make it easy to navigate based on the player's intuition of how things should occur. For the aesthetic, I worked with Naomi who made a lot of the 2D assets including the page designs, button designs, and custom font used in every menu. I also adapted the menus functionality and flow based on user input from our Alpha playtesting. From this playtesting I learned that escape is more of an intuitive key to press to pause than tab and changed it to escape instead (with these images being slightly outdated and showing tab as the way to get to the pause menu). We also got feedback about soft-locks caused by forced saves when leaving the game and an inability to delete save data for when a soft-lock occurred. To fix this, I made it so the exit button instead took the user to the main menu instead of saving and then leaving the game and allowed players to delete save data when loading a save file to solve each issue respectively. While the menu control and save system may have only been a minor part of the project and not the central focus, it gave me a better understanding of how to use Unreal Engine 5, how to better design UI for front-end development (which was helpful since I usually do primarily back-end), and how to structure playtesting questions so I can receive good feedback on what I needs to be improved.

For the challenges I faced throughout the process, many of the challenges presented came from my lack of knowledge and experience with source control when working in Unreal. In previous projects, I had also used GitHub for managing source control, but it had always been in the context of web development where comparing files and resolving merge conflicts had been much simpler. In Unreal, it was clear that it was a lot harder to resolve the conflicts without choosing one file or another and not pieces of both which meant we had to be very careful and mindful of what files we touched and what files were currently being developed. While this was spiritually taxing at times, it ultimately had me work closer with this development team than in teams past strengthening my teamwork and communication soft skills. This also helped me develop some hard skills with GitHub for when we needed to rollback our version or figure out what changes needed to be made to avoid a merge conflict in history. Another point of contention was with certain compile errors that were occurring because the project contained both Blueprints and C++ files. This led to a lot of confusion and frustration within my group as the project was inoperational on certain branches for developers until the compiling the project in Visual Studio or Rider before opening it in Unreal. While this was admittedly frustrating, it did give more insight into how files are compiled in Unreal and how to debug errors with the game outside of the inner workings and mechanics of the game.

For other starting developers who are working with a team in Unreal, I have some advice that I wish I had when I started this project and my main takeaways. Firstly, communication is key not only between the individual tech and art teams but also between teams. At the beginning of this project, the tech and art teams were very separate from one another and that definitely restricted what we could get done for progress checks like the Alpha. Later in the project when the teams were better coordinating with each other, progress was much faster and the team morale was a lot higher than it had been earlier. Another piece of advice to give is to keep in mind the checkpoints like the alpha and what you want to have tested before then. By keeping in mind when your alpha is and what your minimal viable product should look like, it is easier to hone in on what each person should focus on to allow for playtesting to go well. For our team, we lost sight of our minimal viable product and the approaching alpha date and were not able to test all of the features we had wanted to so making sure you keep those in mind is important. Finally, minding the scope of your project is also something that I wish I had focused on at the beginning of the project. While this project was fun to make and I am proud of the final product, this was definitely not the project to try and complete in a seven-week period with an engine I have never used before while being a full-time student. Even with the things that were cut from the final version, the scope felt massive especially when trying to wrap up the project at the end. If there is anything you take away from this post as a starting developer is to mind how much time you are given and if what you want the game to entail can be developed well within that time.

Lastly, I just wanted to say this was a great experience and I learned a lot not only about Unreal Engine, but also working with a team and the game development process as a whole. Thank you to everyone on the team for the amazing experience and I look forward to seeing what this project becomes in the future if it is picked up as an MQP.