Today, I concentrated on doing some documentation. I wrote a rough 9 pages of what I think is "to the point" and useful pieces of information for people who will probably work on this game. It's a great thing to narrow down your ideas on paper and really go to the essential of what your game is about. I'm also doing this mainly to know what I'm going to be working with when designing levels further down the road (mechanics and ingredients wise).
I spent quite a bit of time gathering references for animators as well. I know this shouldn't be my concern, but I felt like I needed to document this part simply to ease the conversation with animators. My take on documenting for animation was simply to break down all the types of motions that I need (i.e. Idle motions, Forward motions, Backward motions, Side motions (strafing and peaking for example)). Afterwards, I would detail in what state I need the animation to be in. So if the motion type is Forward I list all of the forward states: walking, sprint, walking while crouched (Forward meaning the player is moving). Then for each state I would take a capture of a game with that specific animation playing and upload it to YouTube as reference. The link to the video is then added under the specific animation state. The idea here is to create some kind of check-list to help animators organize their work and build before hand a few references so they can start to animate a little quicker.
I did a bit of stress testing of the camera motions that I'm incorporating into the game (head-bob, landing motion, etc.) and I found quite a nasty error. I can trigger the head bob while the landing animation plays which create a very ugly jump in camera. I'm working on doing a seamless transition between the two.
Another thing considering the camera movement. I smoothed the mouse look function. Not a complicated thing to do (it did puzzle me for a good hour but still... Not the most difficult I've done). Simply use a Finterp node and blend between two values: the rotation value of the controller the last frame and its destination. To get the destination value (what it will be the next frame) I take the horizontal mouse input value and multiply it with both a velocity variable and the delta time then add it to the current yaw value of the player controller. The current value is simply the yaw of the player controller at the current frame (without the mouse horizontal input value added). You then set how long you want to blend in between the two values and voilà ! I learnt this technique from a Unity function called "smooth_damp". Thought I'd do the same thing in UE4. The node at the end is "Set Control Rotation" and don't use two copies (one for the yaw and one for the pitch). Create a "make rot" node and feed it the result of your yaw and pitch. If you try to do it separately it's going to try to set the controller rotation rotation twice which will make your controller act super crazy (trust me I've been there).
See you soon ! (The next time I have a significant thing to share).