The Captor's Home Postmortem

Introduction: This Post Mortem will be discussing my level, The Captor’s Home. The gameplay revolves around a player waking up trapped in a bedroom. They quickly learn that there are other prisoners. The player’s goal is to escape the house by any means necessary. There are three main paths the player may take to escape, each requiring specific items. There are also three optional objectives the player may complete. These include helping prisoners, reading journal entries, and collecting their belongings from a safe.

What Went Right

Personal Growth – I made it a personal goal to practice skills that I did not feel as confident in for this project. This included manipulating widgets and objects in new ways. This was a huge success for me, as I became much more confident in my ability to use these features. My understanding of widgets and their potential uses has greatly increased. They proved to be an excellent way to help the player interact with NPCs and learn more about the story of the level. I was able to find ways to equip a player with items when the animations are not available to me, as well as ways to use and drop these items.

Mechanics Research – Researching the concepts for my mechanics proved to be extremely helpful. It allowed me to properly explain what I was trying to do for my own mechanics. It was much easier to form a plan of action for implementing my mechanics, such as how I wanted the player to interact with them and what would happen when they did.

Level Blockmeshing – Creating the blockmesh was an enjoyable experience with this project. There was a major focus on non-linear gameplay. As a result, I was forced to think more strategically about how I wanted to use different mechanics and where. This was a great lesson in expanding gameplay across the level as opposed to a lot happening in one area and other areas having little to no gameplay.

Change of Genre – When I think of games I would like to design, my focus has always fallen heavily on RPGs and Survival Crafting games. While this level could arguably be considered an RPG as the player is a prisoner trying to escape, it leans more heavily on suspense and puzzle-solving. The player is never sure if the captors will return before they can escape or not. There are puzzles such as the safe and figuring out how to exit the building. There is no combat, and the player is not a uniquely strong character that grows in power as they play. This change helped to expand how I think about game design and creating levels for different audiences.

What Went Wrong

Game-breaking Error – This project presented me with my first game-breaking error. The level was unplayable, as the player was not able to move. This error inadvertently helped me in multiple ways. One of these was the improvement of blueprints as I searched for the problem code. Studying the blueprints one at a time closely as I searched for the mistake revealed many areas that could be improved upon, as well as some that were not functioning as intended. This allowed me to fix many other issues I was unaware of while seeking the culprit. This also proved to be a valuable lesson to not expect existing code to always play nicely with code added later. The error was found in existing code that needed to be written differently to work with the code that was added.

Uncooperative Game Items – My initial blueprints for various game items proved to be extremely faulty. Items would not act as expected when interacted with or when used. This forced me to examine my approach. I discovered new ways to manipulate game objects as a result. I also became more familiar with physics and collision. This was necessary because many items were made from static meshes I created and did not have built in collision. I learned how to add the correct collision to new meshes.

Difficulty Getting Player to Hold Items – This mechanic stumped me for some time. I was determined to manipulate the object in the level directly, picking items up and moving them or using them. Repeated complications with this helped me to realize how versatile the player blueprint can be. I learned that there can be many components added to the blueprint that players are not aware are even there. These components can be manipulated to help gameplay mechanics function as desired. In this case, all blueprints were able to be significantly simplified and functioned much better.

Awkward Player Controls – My initial setup for how the player was meant to interact with the game was excessively awkward. There were multiple buttons being used for a variety of different functions in the game. There was also an excess of text being displayed. I discovered how to reduce the interactions to three specific buttons based on the situation. This led to much smoother gameplay and understanding. The text was also able to be changed to more accurately match a given item and its status as opposed to always telling the player how to interact with the item.

Perforce Complications – I used Perforce for this project, and there was a point during development when Perforce stopped working for a time. This required me to refresh my knowledge of how to work offline and properly update the project in Perforce once it was running again. When working through the game-breaking error mentioned earlier, I also had to practice using Perforce to collect previous versions of project files that may have been compromised. In the end, the files that were switched were not the issue, but this still served as good practice for navigating Perforce and using some of its functionality to help.

Conclusion: This project was a lot of fun to work on and served as a great learning experience for me as a game designer. I practiced many skills that I have not used much up to this point in my growth as a game designer. My problem-solving skills were tested intensely as I strove to conquer the various challenges I experienced while creating this level. My understanding of various elements of Unreal Engine and its capabilities has also improved.