Hello,
On this dev blog, I wanted to talk about one of the Jira tasks I was assigned that took a bit longer than I anticipated and the way I ended up having to solve it.  That task was the camera movement/ability for the camera to follow the player squad as they traverse around in each of the chambers.  Normally this does not seem like the most egregious of tasks, at first glance, most of the time in Unreal Engine if you want the camera moving with the player, you would normally just attach it to the player pawn using a spring arm and call it a day.  Well, then why am I even using this issue as the topic of my dev blog this week? That is because our systems were designed in a way that the pawn that is being controlled is not one of the squad units themselves, but an invisible pawn that teleports based on the click location of the player. This was designed this way because the player is intended to control a squad, not an individual player, and the player pawn is supposed to represent an object in the world that our player units path towards and centralize their positions around based on the formation that is currently chosen by the UI. By attaching the camera to our player pawn in a normal way, the camera would teleport around with every mouse click, and I had to find a way to solve this dilemma without just reverting the game over to WASD camera scrolling. 

The way I first tried to solve this was by going to the same source file that controls how the squad moves to the player pawn, adding a function that goes into the array of player units, and attaching a camera to the first unit in that array. My theory was that by attaching the camera to one of the units in the squad and offsetting it to fit the perspective we were trying to achieve, the camera would just constantly move with the attached unit, and I would have nothing to worry about. I decided to attach it to the first unit in the array to eliminate the edge case where the unit with the camera dies, and the camera would have nothing to follow for the rest of the game. By attaching it to whatever is always deemed as the "leader unit" it would constantly update to an existing unit regardless of whether the squad got smaller (though maybe there might be a hiccup still or two).  Unfortunately, while this did allow the camera to follow the squad perfectly regardless of squad size, I never even got to see that hiccup happen because of another flaw with the logic I created. When a camera is attached to a pawn in Unreal with a spring arm, a player can move in many separate directions without actually turning the camera, but when a camera is attached to an actor, the camera will always rotate with the actor by default. Because our pawn was the click location, the units themselves all ended up being coded as actors that would move around based on the AI they were given in their behavior trees. This meant that when I attached the camera to the supposed leader of the squad, the camera would constantly jerk and rotate around because the unit itself would rotate around a ton as it was moving from location to location. This not only made navigation impossible in some cases, but it also was just hard to look at in other cases. 

So I scrapped that idea. The way I ended up ACTUALLY solving the issue was by making the camera its own separate actor which moved around on its own. Its positioning, I decided, would be based on the average position of all units that shared the same BasePlayerSquad type, which I would get by querying the current chamber for all actors of that type, putting their positions in an array, and then adding up those positions and dividing that total by the current size of that array. The camera would then offset itself based on that position, and the offset would be determined based on whatever perspective we wanted the game to be. The average position and the position of the camera would then finally be ticked every frame to make sure the camera did not stay still since it was no longer attached to anything anymore at that point. It ended up being an extremely simple solution, but it was not one I care to admit took me longer than expected to find just due to my innate nature to go down a rabbit hole when trying to make my original ideas work half the time.  There was still one issue with this solution that I had to solve though, and it was the fact the camera still jerkily rotated based on the rotation of the squad itself. To solve this, I actually mimicked a blueprint setting in Unreal that sets the camera to absolute movement, rather than following the rotation of the possessed pawn. I mimicked this by adding a part to the end of the function that resets the camera rotation back to its original rotation when it loads on begin play. By calling this every frame in the function as well, it ensures that the camera will only move, and if it ever tries to rotate, it will return to its original rotation every frame regardless of actor rotation. This improved the gameplay look substantially, and it definitely made me less nauseous and less like I was getting whiplash every two seconds upon just clicking a mouse button.