Swarming
AI random movement in a radius
Seeking player example
Patrolling in a path of points
Setting/doing ragdoll
Undoing ragdoll
Spawning new pawn
Possesing the new pawn
Normal
Heavy
Light
Ball
Bottle
Cube
Plane
I will address the more personal challenges of the project, which was my own personal lack of experience and knowledge in regards to UE4 Blueprints and UE4 in general. The first major hurdle of this project was delivering a packaged .exe file of our project's base mechanic (being able to transform and having unique movement for the objects). When we first imported our new character skeletal mesh and rig into UE4 it seemed to go incredibly smoothly, however when it came time to package the build we kept having it fail to compile with a seemingly unsearchable error code. What I ended up doing was reaching out to Professor Cookson to see if he would be willing to meet with me in order to tease out what exactly was causing us to have issues in packaging such a simple project file. He agreed to meet with me during his office hours and after stepping through everything for a little over an hour and a half Professor Cookson figured out the issue we were having was just that our new character was missing a root node in its skeleton. This was something I would have never thought to check due to knowing absolutely nothing about skeletal meshes and animation in general, after we figured out that was the cause of our problem we quickly took the character into Maya and added a root node for the skeleton and re-imported the character, to my relief the project then packaged without any problems.
Solutions -
There were a lot of challenges involved in this project, in my opinion the largest being my own lack of experience at the time of working on this project. Before I worked on this project, my only experience to working in UE4 was knowing how to make very basic Level Sequences (door opens, camera fly through, etc). This lack of knowledge and experience also led to other problems in trying to manage expectations of the Project and Art leads, in addition to feature creep during a majority of the project. On the technical side of challenges for the project, the major challenge of this project was handling how to deal with one character being seven total characters. Other technically challenges included how to handle doing basic AI, how to handle swapping between different forms for the main character, and how to make each object feel different in how they moved throughout the level. Our team also wanted the player to be able to stun the AI, have them ragdoll and then get back up again and resume their normal behavior. In addition to this the different humanoid forms of the main character took different amounts of damage from the same source which was another challenge later down the road that came up. There was also a steep learning curve when it came to delivering packaged .exe files for each project due date.
Challenges -
This was a 3D platformer game I made as part of a group project for Applied Game Design while attending SCAD. The main mechanic being able to transform the main character into six other forms in order to traverse the level.
Overview -
The goal of this project was to create a game centered around a unique mechanic. For our group we decided to have a character that would be able to change forms into specific objects in the level, in addition to two other humanoid forms (Each with unique characteristics). Since there are already games such as Prey which have the main character turning into objects in the level, in order to try and make our game different was the way in which each of the objects moved. Instead of having the objects sort of float or glide along the floor they would move as one would expect them to, for example the bottle would actually roll along the floor or the box would actually tumble end over end. The overall goal of the level was to escape from the clutches of a wizard that was holding you captive, with the ending part of the level be a boss fight with the wizard himself.
Summary -
As for my overall inexperience with Blueprints I ended up spending hours most days googling various problems I was having, watching YouTube tutorial after tutorial, or scouring over UE4 forum posts for answers to my questions. Looking back it was a good learning experience to basically throw myself into the deep end for learning Blueprints and UE4 as a whole, however it for sure lead to a lot of delays during the project or poorly implemented systems. For my initial experience going into the project I'm happy with what I was able to produce, though if I was going to redo this project there are a lot of things I would have handled differently (some of which will be talked about later on).
One of the initial problems I had was figuring out how to get the player to be able to change forms, initially I thought you could just swap out the mesh the character used and then have a separate movement system for each. I very quickly found out that was not possible with my knowledge of UE4, nor do I think it how something like that should ever be handled to begin with. Originally I was just spawning an entirely new pawn, which had the side effect of leaving the old "bodies" littered around the level and if the player swapped fast enough, could destroy the player controller before a new pawn was spawned. One of my classmates took the time to work with me in order to get a system working for spawning and possessing the new pawn while removing the old one the proper way.
Through the use of the Possess node in UE4 my classmate and I were able to create a reliable system for allowing the player to change forms at will during game play. As for the part of the blueprint that set the variables for "Character Spawn Index" and "Previous Character Index" were seven different series of nodes all doing more or less the same thing, with the only difference being what the "Character Spawn Index" variable was actually set to.
We had each form of the character mapped to a number key (We used 1-7) to determine which form the player wanted to change into, provided that they had unlocked that form while playing the level. So the above screenshot is just an example of what part of the whole system looked like. Due to handling it in this manner, we had to make an entirely separate blueprint actor that we placed in the level, but made it hidden, that was responsibly solely for swapping characters. In the effort to keep things simple for myself I also used this blueprint actor to handle the player's health rather than trying to keep seven different health variables all the same and updated when the player took damage in a different form.
For the objects that the player could turn into we wanted them to feel like the player actually was that object, which meant (at the time at least) using impulse and other physics nodes for the movement. This was something that while what I created worked, it something that could have be designed a lot better so that it felt more consistent and the player felt more in control. The quickest issue I found when trying to use impulse for movement was if the player simply held down a movement key for long enough and then could just get slightly airborne, they would get sent flying across the map. Or if the player succeeded in getting started moving from the beginning the longer they held down a movement key, the harder it was to control as the impulse kept adding to the player's character. Yet if it wasn't high enough to begin with, the player could never start moving at all. My attempt to fix these problems was to add impulse but at the same time subtract the amount of time the player held down a movement key, and then tweak the values until it felt more natural.
Lessons Learned -
Doing it in this fashion also lead to having the logic for if the AI detected the player within the same blueprint (Which was further complicated because I needed to have the AI recognize all seven forms the player could take). The downside of handling it this way in blueprints rather than a behavior tree was what I could have the AI do after spotting the player was very limited. Due to this I only had basic chase functionality built for the two different 'types' of enemies we had in our game.
Due to how I was handling player form transformation, I also decided to keep track of the player's health in the same blueprint. For our game the basic Gnome form and objects would take normal damage, while the smaller Gnome would take double, and the large Gnome would take half damage. In the case were we had a large amount of enemies swarming around the player when they attempted to get a key in order to progress through the game this is how I handled dealing damage to the player.
The idea here was to deal rapid amounts of ticking damage to the player until they got out of range of the enemies. The way I implemented it worked most times, however there were a few extremely rare cases in which it would not properly cancel itself when the player left the trigger volume causing the player to continue taking damage even when out of range.
Another major challenge of this project was the AI. We wanted two basic sets of enemies in the level, one that wandered around an patrolled an area and one that walked along a predefined path. While I succeeded in creating those two very basic AI systems, it was handled inside of the blueprint for the AI itself, rather than through a typical behavior tree.
Sadly I do not have the original project files or final .exe available anymore due to a hard drive crash.
Project File & Executable -
I learned a lot throughout this project, mostly about UE4 and blueprints as a whole given this was my first actual project using it beyond the basic templates. As for what I learned that I didn't have a chance to mention in the Solution section of this write up was about the proper way to deal with moving files into a UE4 project file. In the beginning our team was simply dragging and dropping folders via a file browser which at the start wasn't a huge problem, until we got further on into the project. By the end of the project there were missing references to files and links that all could have been avoided if we have properly used the migrate feature that UE4 has in order to keep links and references unbroken when moving files between projects. I know I spent quite a few hours before the final was due fixing broken reference links and paths so that our project would actually package. I also got first hand experience with "feature creep", where as the project went along other members of the team (myself included) kept thinking of other ideas for things we could add to make our project better. This in the end lead to many things not being completed or things that were didn't have proper testing time to refine them. This experience has improved my skill at explaining to other team members why while something may be a good idea, that we should not try to implement it. The ability for members of a team to manage the expectations and have a clear understanding of what is priority versus what would be a "nice to have", is something that I have found extremely important in my later group projects.
Our group also wanted to have the player be able to stun the AIs and have them ragdoll for a short period of time and then get back up to continue their patrolling behavior. This ended up being way larger of a challenge than I initially anticipated, which was only compounded by my lack of experience. After days of being unsuccessful with searching online for answers, I ended up seeking help from Mathew Wadstein during one of his YouTube UE4 help livestreams. After working with him we came up with a system that would save the previous world transformation of the enemy, turn off collision for the capsule and then simulate physics on the mesh. Then after a short period of time we would move the capsule back to where the mesh currently was, turn off simulate physics, reset the mesh transformations and then re-enable collision on the capsule and mesh. If we didn't turn off collision for the capsule the enemy mesh would always get stuck on the outside of it, leading to all sorts of collision and visual issues.
