I want to create a sandbox parkour prototype to increase my knowledge of movement systems. I will be using Unreal Engine 4 and Blueprints or C++, maybe both. These are the main features I want to implement:

• Wall Climbing/Vaulting
• Wall Running
• Landing Roll
• Crouching
• Sprinting
• Jumping
• Sliding (Crouch while sprinting)
• Grapple (throw to a grappling asset and swing)
• Parachute/Glider

And here are some that I would like to do but are kind of on the back burner at the moment:

• Power-ups (ex. jump boost)
• Audio (wind, steps, ambient sounds/music)
• VFX (to help indicate/exaggerate speed)
• UI (speed tracker, indicator for grapple)

My current plan is to create a state system for all of these. Here's some pseudocode I whipped up in like 5 minutes to show my train of thought:

SET_CHARACTER_STATE_PARENT { 
	CONSTRUCTOR { 
		movement speed = walking speed as default 
		camera height = head level 
		gravity = default gravity 
	} 

	SET METHOD for movement speed 
	GET METHOD for movement speed 
	SET METHOD for camera height 
	GET METHOD for camera height 

	// This way I can use this for a jump boost and the glider/parachute 
	SET METHOD for gravity 
	GET METHOD for gravity 
} 

// Follow this more specialized idea with almost every state 
SET _CHARACTER_STATE_SPRINT { 
	INHEIRIT SET _CHARACTER_STATE_PARENT 
	SET movement speed 
	SET camera height 
} 

SET _CHARACTER_STATE_GRAPPLED { 
	// To create a swing motion 
	DRAW circle using length of grapple as radius 
	FOLLOW arc 
	// To not allow the character to move unrealistically 
	APPLY gravity to velocity vector 
} 

WHILE (GRAPPLED) { 
	GET velocity vector 
	WHILE (input directional key down) 
		UPDATE velocity vector 
}

I will also need a system to detect when the player can grapple (i.e., LOS of the grapple-to-object, and range).

Any tips, ideas, or opinions would be greatly appreciated!

Never done any movement system, but this looks a little too fast to me.

You list a number of movements, but I doubt you can all do them together. I'd suggest do each one separately, then check afterwards how they compare and/or how to go from one move to a different one (if you desire that). I use a rule here: If I don't know how to build a system I want it's too complicated at this time, I must start with something smaller (a subset), or something simpler (eg a simpler motion first before a more complicated motion).

With sufficient complicated systems in my experience you will always start at the wrong end the first time (and possible even more often). Finding the core problem that must be solved first takes a few false starts. Note this isn't wasted time, you learn from all false starts, and that knowledge is needed anyway after you covered to first core problem.

As for “good”, good is a nice high level notion that sounds very positive but in fact means very little. Quantifying good is quite impossible, also its meaning is not universally shared. Ask 10 people for a good system, and you get 10 different answers all likely different from your notion of good.

Instead try to find testable quantifiable properties to that you want. “testable” is useful for writing tests. setting a goal value helps in deciding how you design is doing, is one design better than another design? in what way? why?

Last but not least, these properties help in driving you towards the goal. You can engineer on needed CPU time, you cannot engineer on “good” as it lacks hooks what needs changing.

I agree with Alberth, this sounds like a really challenging problem, depending on your fidelity requirements. In fact, I think this is one of the most challenging problems in game development. I wouldn't even attempt it as a lone developer. Ever wonder why indie games rarely have AAA-level character animation and are often designed around that limitation? This is why.

Assuming your game is 3D and you want to animate the character and have their movements be physically realistic, you would need at the minimum:

• System for skeletal animation. This is easy and probably built into UE.
• A large set of animations for all actions you want to perform.
• Inverse kinematics system which you need so that player hands and feet are in the right locations. This system would alter the animations so that the foot and hand bones are as close as possible to the desired positions. Not easy to implement, maybe UE has something built in?
• System for identifying potential hand holds and foot positions from world geometry. These get passed into the IK system. You could either tag the geometry manually so that only certain edges can function as hand holds, or have an automatic system to identify hand holds (much more difficult). For foot placement, you probably want to identify surfaces that are close to horizontal. I'd try tracing rays at the ground below player to identify candidate foot locations with best surface normal.
• Control system which manages the various states that the player can be in. This system also triggers animations to start playing, gets the hand and foot positions and passes them to IK system. This system should take as input some high level description of player movement (i.e. which buttons are pressed), and update current state to best achieve the desired movement, given any constraints (e.g. must wait for current animation to finish playing). This could become really complex if you have a lot of actions and states.

You may also need to integrate this with the physics engine in some way so that the movement of the player seems physically realistic and doesn't violate laws of motion. This could get really complex. You would need to switch between kinematic animations and physics dynamically, or have physics bodies be controlled indirectly by animations in some way (using constraints). Something like this is used in AAA games these days, but it's not easy (as in it might take an expert with PhD years to get it working robustly). There may be some middleware available to do this (Havok?), but it won't be cheap.

I think the first step would be to start with a basic capsule character controller. Then, add the animations and state controller so that the correct animations play as you move around on a flat plane. Then, make the transitions between animations smoother by blending between them during transitions. This is all pretty basic stuff. The next big leap would be to integrate the IK system so that feet are always flat on the ground, even if there is a slope. Next, you would want to get the feet to land at positions you choose, and then add the system to find good foot positions. At this point, we are still doing basic stuff that is found in most modern games with character animation.

Only once you have all of the above working 100% should you even attempt to add the parkour aspect.