philip eriksson

Why did I make this?

For this 8-week project, I was inspired by Counter-Strike Sources' bunny hop gamemode and Dying Light.I wanted to achieve a high-paced game feel by creating this player controller from scratch in a custom C++ Engine. The engine was originally built from scratch for a school game project.

Features

• 8 directional movement
• Varying speed depending on where you look
• Jump
• Crouch and crouch walk
• Sliding and slide jumping
• Landing assist
• Step-up
• Mantling
• Zipline

Pre-production

The goal of the pre-production phase was to establish a clean working environment. I began stripping away every movement component that I could find and set up my own interface. This was to ensure I had full control of all the systems, and nothing remained of the previous third-person system that had existed before.I chose to implement a state machine architecture to handle all movement. By establishing specific logic for every state, I could create a modular system that is easy to debug and further extend. This structure allowed for smooth transitions and prevented states from accidentally interfering with each other.

To get an accurate visualisation of how well my project will be, I need to define my metrics very fast and make them stick for the rest of the project. I spent significant time comparing with Dying Light to make sure everything felt similar, but faster.During our latest group project, I spent time to create a jump that feels satisfying and very light to use as it was focused on a 3D platformer. That meant I could just modify that code and implement it according to my metrics. I had to alter some functionality to fit the genre of my specialization.

First iteration of running, walking and jumping

First camera preset on landing

With headbob

Without headbob

Headbobbing

This was important to implement as soon as possible, as it could have affected the way I had to tune every feature in the project. It was also crucial to receive feedback on this feature, as head bobbing can cause motion sickness if not executed properly.My first iteration used a sine wave to produce a consistent vertical motion, as well as a cosine wave to produce the horizontal motion. The combined result of these motions was later applied to the camera as an offset to its original position.

The first issue I had was when the character stopped moving, the head bob would just abruptly stop. This caused the head bob curves to instantly reset and made it look jarring and unnatural. I tried resolving this by using a lerp on my timer to make it go down to zero, but it made no greater significance to the feel.Instead of resetting the timer, I added a weight to the curves to smooth out the transition when the head bob activates and deactivates.

I was pleasantly surprised by how simple the code was to implement to give such a meaningful effect.

Alpha phase

During this sprint, I made myself a player gym that was attuned to the metrics of my specialization. I could then start implementing a first draft of the features and transition my camera to the correct state.The first feature I started working on was the dash ability. I find it to be fun to use in any first-person game, as it also has one of the more satisfying camera movements. With the help of a GDC talk about jumping, I could adapt the existing math formula to support a translation over a distance which would give me the desired responsive movement.Using the same formula, I could efficiently implement similar features, such as the slide and the landing assistance. Landing assistance is the result of a roll feature. Due to the uncertainty of being able to implement animations, I decided to cut the roll and add landing assistance as a motion sickness-friendly option.

This was also the time when I implemented camera transitions depending on states, so every state would have its own variables for the camera and its movement. This is something I had to refactor from my preprod phase, as its implementation was not compatible with the future structure of the project.

First iteration of dash

Polished version of dash

Slide with the same math formula as dash

First iteration of crouch

Visual representation of raycasts when mantling

mantling

Beta phase

In the beta phase I spent some time polishing my core features, but I knew I also wanted to enhance the overall second to second experience of the movement. The first thing I wanted to implement was mantling, which allows the player to automatically climb over ledges within reach. The second thing I thought of was some kind of grappling hook or zipline, which I figured would be a fun addition to the movement kit.

I wanted mantling to be a safety net for the player, making sure that you can always make a jump that you just couldn't reach. There are a lot of traps when you start to implement a mantle. You have to be certain that you are able to mantle, which requires multiple checks. You have to check if a ledge is nearby, if something is currently above you that could prevent a mantle, and lastly if the position you want to end up in is safe to stand on. As shown in the image above, I do four checks to make sure it is safe to climb. The first raycast is from the hips and in your forward direction, making sure you are close to climb, then I check far above your head, so you are not hitting anything while climbing up. The third ray checks downwards to give you a position that you want to translate to, and lastly, a raycast upwards from that position, to make sure that you are able to stand or land in a crouch when you climb upwards. ( temp text, vill formulera bättre)

For the grappling hook, I really wanted to capture the feel of Dying Light 1. instead of a swinging hook, I implemented a "zipping hook" where you move from your original position, to the anchor point. The hardest part about the hook is making sure it feels natural and is in check with the current flow. If the hook brings you within range of a ledge, the mantling logic takes over automatically for a smooth transition from zip to climb.

Zipline hook with the ability to be canceled

Zipline hook with auto mantling

Closing phase

The closing phase was centered around polish and visual feedback. Without proper visualisation, the movement and flow can feel disconnected.For the larger portion of the project, I worked with next to no feedback. To improve the game feel, I collaborated with an animator, who provided animations that I could implement in my state machine. This tied everything together and made the movement come to life.Besides tuning animations to match my features, I spent time tackling bugs and improving on every camera preset. With the visual feedback now available, I can also tune every feature to ensure it provides a satisfying experience. I also dedicated the remaining time to documenting and reflecting on the progress of making a first-person controller.

Gameplay featuring slide, zipline and running animation

* visa gameplay med animationer*

gameplay med animation