Description
This is a 3rd person role-playing game about reaching an escape platform while collecting items and avoiding NPCs that chase the player – and beating your previous completion times. ESCAPE was written in C++ (using Visual Studio) and developed in Unreal Engine 4.
Tools Used
Unreal Engine 4, Visual Studio, Photoshop, Illustrator
Highlighted Skills
Game Design, Level Design, Unreal Engine 4 Mastery, GUI Design, C++ Programming
Links
This document details my thoughts throughout the design and development of the mechanics, level, and gameplay
This link will take you to the project's online repository where you can see the source code
Project Reflection
This project was fun to work on as it was my first time really getting down and dirty and learning common gameplay programming concepts through first-hand experience and practice (C++). Each week, I learned a new concept, then applied it to my game. For simplicity, and so I could focus on gameplay programming, I used pre-made assets as much as possible (3D models, animations, sounds, materials, particle effects, etc.). I started with a blank C++ project in Unreal Engine 4 (no template). During the first week, I learned about rendering a character in the game world and setting up input keys to control its movement. I added this functionality to my game and added the ability to sprint by holding down Left-Shift. The next week, I learned about camera movement. I set up the camera so that you could toggle first/third person with a single keypress, zoom in/out by scrolling the mouse wheel, and rotate the camera’s view by either moving the mouse/cursor or pressing the arrow keys. In the third week, I learned about pick-ups – objects in the game world that, when interacted with, are picked up by the player and removed from the game world. I added collectible pick-ups to my game as a secondary objective for the player to complete (collect all the items). I also tweaked the pick-up code to create power-ups that give the player temporary bonuses (such as movement speed boost). Week four was all about artificial intelligence (AI). I learned the basics of how AI is addressed in Unreal Engine 4 with blackboards, behavior trees, etc. and I used this knowledge to create AI for my game that chases the player if they see them. The fifth week was when I took a break from learning new concepts and practices. I took this time to build my game’s level/map/scene. I strategically placed the player spawn location, pick-ups, power-ups, non-player characters (NPCs), and open/confined spaces to design the experience(s) the player would have. Finally, during the sixth week, I learned about UI and created menus (main menu, pause menu, help menu), the player’s heads-up display (HUD), and tutorial pop-ups that appear when the player encounters a new mechanic.
I learned so much throughout this project, I don’t know where to begin! I learned about the spawning of characters, character movement, camera management, interactable objects, AI and behavior/decision-trees, level design, and UI/UX design. Best of all, I learned how to handle all of this in C++. I also learned, through first-hand experience, the importance of playtesting (especially by individuals not working on the project) throughout the development process – long before the beta phase. With each new major modification or addition, I sent my project files to my brother for him to test and report back with any found bugs or issues. This enabled me to find and correct the issues that I may not have otherwise found.
Many of the issues I encountered during the development of this game were due to my lack of experience at the time. Almost everything I was doing was completely new to me, so tasks took much longer to complete than they normally would because I was constantly having to look up tutorials and dig through documentation. This included how to handle character movement, how to manage the camera(s), how to create and utilize AI, and how to handle UI in C++. One specific issue I encountered was how to go about cancelling or reverting a power-up’s effect on the player character after the power-up object had been destroyed. I learned that common practice is to leave the power-up object in the game, but disable its physics and hide the mesh, instead of destroying the object entirely.
As previously mentioned, I was receiving feedback from my brother and my peers throughout the development of this game. When someone gave me an idea for a change to make, I thanked them for their suggestion, thought about how the change would benefit the game or the players that play it, and thought about how difficult it would be to make the change. If I found that the modification was in reach and would improve the quality of the game, I made the change.
I improved this artifact after its completion by writing up documents to support it. First, I created a postmortem report that included a short description/background of the game, the tools I used to develop it, my development process, what went well, what didn’t go well, and my plans for the future of the project. Realizing that the post mortem report that I created didn’t provide as much information about my knowledge and skill level as it could have, I created another supporting document that details the thought I put into the mechanics and level design. This document describes the experience I was aiming to provide the player with, as well as my reasoning behind the layout of the level and placement of items, power-ups, and NPCs. While re-familiarizing myself with the project upon returning to it a year later, I realized I didn’t have a Win-Screen (or any feedback for the player when they win, other than a short audio clip). So, I added a win-screen that is displayed when the player reaches the escape platform and shows their completion time and number of items collected.