Jonathan Umar-Khitab

Project M is a first person parkour centric game that I am working on in between projects. It was born from my enjoyment of parkour both in games and in life drawing heavy inspiration from titles like Mirror’s Edge, and Human Heads cancelled Prey 2 from 2012.

The goal of of this project is to deliver a fantasy of parkour at a level that feels authentic to the experience in both actions and thought process. That direction drives the way each element of the game flows together. I want players to drive the same sequences they often see in movies and cutscenes. That is why the system I am working on is designed to empower players with the tools to do just that.

This game focuses on feedom of movement, and dynamic intuitive mechanics. If it makes sense then it should work. There are no fixed nodes, or explicitly defined exceptions that feel like they handcuff you to an arbitrary ruleset. The goal is in an implicitly designed system that feels believable to the player, and behaves according to their intentions.

The world is a playground, and you decide how to move through it. It should feel belivable. However the game is not about realisim. It’s about authenticity and creating a game that feels real and plausible.

The movement is one of the most important parts of the game. It is designed as an implicit player driven system that gives control at an action based level. Jumping, crouching, sliding, rolling, mantling. These are actions that players can control, and each action has variations that change the way they behave. High jump, short hop, Wallskid, short slide, speed mantle. As they make their way through the game, players have to fine tune the way they move around the world depending on the obstacles they encounter, and their own preference.

Each mechanic flows into the movement system, and reacts to the way players move giving a large amount of depth and complexity to relatively simple mechanics. However the most important part of the system is that it is flexible and dynamic, while being simplicstic forward facing. If a player thinks something should be possible, like a wall they can run on, or a ledge they can grab. Then that should be true.

When I approache designing mechanics for this game, the first thing I think of is how does it fit with everything else. How would I use it in a sequence that feels cool, special and different as a player. What would people expect to do with it? What is the idenity of this mechanic and the experience I need to capture?

I view my job as a designer as three fold; Find out what problem this mechanic solves. What experience does it contribute towards? Finally, I have to build it so that others can see why its cool and interesting.

Each mechanic is built individually at first, along with any sub features in isolation. On this project I tended to disable anything that is not critical to test with for two reasons. First, to focus on the mechanic and make sure it delivers on its fantasy. Secondly, to make it easier to track issues, especially once other features are reenabled that result in surprise interactions.

I wanted each mechanic to appear simple to the player. If I tell them they can climb, or wallrun it should feel self-explanatory, designed to feel natural to use and understand. However, to keep it simple, the implementation features a lot of complexity to support that promise. I put the burder of understanding the mechanic on the system, which allows the player to focus on playing.

It’s a player driven system where I tell the player this is the mechanic, and it makes sense in this way. If they believe a mechanic should then work in a certain way, the system is designed to support their that. I wanted to stay away from giving players exceptions that aren’t true. For example; You can wallrun on any surface you think you can, otherwise you should understand exactly why you cannot such as, the wall has obstructions that stop you from doing so.

For each of our key mechanics, I looked into what mastery looks like, and the different variations and influences that can affect it. This can turn a simple ledge climbing mechanic into a small minigame that creates a layer of subtle depth that can seperate players of different skills, creating a small level of micro engagment to kept players invested.

That is because there are many factors that can influence a mechanic like Ledge Climbing. How fast you approach the wall. How high or low is the wall? Are you falling or rising? How far away is the wall from you? Each factor can produce a different variation of results, especially in the level of sucess you can acheieve and extends to many of the other mechanics as well.

Mechanics to me are an opportunity to solve problems and allow players to drive the ability to solve those problems as part of the fantasy that they have opted into. Each mechanic is an opportunity to connect with an aspect of that fantasy, and ensure that they are the ones playing the game. Not the other way around.

To support my player driven design process, I had to build systems and features with the goal of supporting this behaviour. I built visualizers to track paths, detect obstacles, and movements. I’ve done engine adjustments to collision and movement to ensure that I was getting the right UX I wanted. This was important for things like jumping, wall collision, momentum and movement having a variety of hiccups that had to be addressed. Unreal’s infamous boucing off corners being a very important issue that had to be solved with custom logic for a game based around movement.

And of course, implementing systems to ensure the mechanic delivered the experience as intended. Ledge Climbing was a big time sink because it is all procedural and there are a lot of potential moving parts that need to be accounted for. A lot of systems for example use root motion, however I elected not to due to the requirements I had for the mechanic. I

I focus on building the right things I need to match my requirements. Systems like a custom camera movement rig, or a dynamic jump system ensure so that I am always making the right decision for the game, as opposed to being limited by the tools at my disposal. I want the game to behave a certain way and if it’s not there, that the only answer is to build it.

I approach designing levels revolving around whatever requirements or behaviours I want to explore or validate through its use. For levels, I have a specific set of goals, or an approach to ensure that they adhere to the overall direction of the experience that is being made.

First, a level needs to feel grounded. I didn’t want to have interactions that felt forced or didn’t make sense to a player. Part of being a parkour expert is finding your own path, and ensuring a consistent space allows both a player and designers mind to approach a space as an exploration in uncovering ways to build both interesting spaces for players to navigate through but also spaces that rewards exploration.

This mindset contributes to how levels should feel like a playground where you can look for different ways to reach your objective. Parkour is all exploration and finding a path that allows you to make your way past an obstacle. Some of these paths are easier, some harder. Some short, some long. But it should feel like you have found the path to reach your objective.

That why I like to ensure that there are always at minimum three different ways to reach an area. Players can find their own path, but it also enables players of different types to have more opportunities to find a path that matches their style. This is balanced against ensuring that each path feels organic, as opposed to be authored which can make an area difficult to design. However it creates a stronger and compelling enviornment that encourages players to engage in a way that feels like they are responsible as opposed to following a spreadsheet or pre-selected path.

Design

• Gameplay/Mechanics
• Level
  • Test Levels for Mechanics and Interactions
  • Playtest Levels for various purposes (Test Routes and variations in paths, Test Organic feel of Levels, Test Controls, Stress Test Mechanics)
  • Tutorial Areas
• User Experience (Feedback, Responsiveness, Accuracy, Haptics….)
• Controls (Keyboard/Mouse, Gamepad)
• Camera
• Playtest (Organize, Run, and Evaluate)

Programming (Blueprint 90% and C++ 10%)

• Gameplay Mechanics
• Locomotion Systems (Jumping, Wallrunning, Ledge Traversal, Rolling…)
• Camera Systems
• Collision Systems
• Shaders (Dazed, Radial Blurs, Colour Adjustments)
• Shooting Systems (Guns, Firing Modes, ADS, Bullets, Shield….)
• Animation Systems (State Machines, Conditions, Dynamic Movement transitions)
• Various Tools, detection, algorithims and gameplay supporting systems

Animation

• First Person Dynamic Camera Movemments (Impact, transitional, shakes…)
• First Person Authored Camera Movements (Action; Climbing, sliding, rolling…)
• Various transitional motions between character states (Crouch/Uncrouch…)

Audio

• SFX for Mechanics, and general feedback.
• Ambient Audio