Mobility 4.0
Laying a strong foundation to begin our path to the complex secondary layers of Awaken Guardian gameplay and mechanics.
Walk – Run – Sprint Blend
Tight command of when you want to run or walk.
Walking and Running
Handled by Left Joystick input.
While straight forward in concept the function of shifting from Idle to Walking to Running is a vexing one to make “just right”. Because the game will rely on perception and detection, walking is as much a necessary feature to have precise control over as running.
The way I believe we can really maximize our control on the matter is to configure a handful of various layers of influence on the final motion of the unit.
Input
Firstly, using the joystick to move currently just adds force relative to how close to 100% you are in pushing the stick. I think the better way to do it is to take the direction input like we always do, but use the normalized value (0-1) to dictate the target movement. Where we want the character to accelerate to, then remain at until our input changes. This means that rather than getting faster and faster until you hit the max velocity (just slower if you’re holding the stick gently), you’re instead dictating the arrival velocity, say at a hasty walk (about 45%).
By segmenting the input and velocity, this allows us to implement extra factors/layers to the calculations we use to get the unit to the speed we need.
Velocity
Now that the velocity is in isolation, we can now make the unit animations match the current velocity, instead of the current input. This allows for a more seamless transition between Idling, Walking, and Running. We can add a small Idle dead zone, to prevent the unit from walk animating even though they are moving a few pixels at a time. Then we can blend towards Walking, then blend towards running as the velocity of the unit builds. As I indicate earlier in this doc, it’s imperative that we find a balance between tight controls and this unit velocity/acceleration.
Animation Speed Blending
An additional layer I wanted to explore, as it doesn’t seem fully realized by just blending between Walk and Run, is that either in the blend tree or programmatically we need to make the movement animations transition from “Slow Walk” to “Full Walk” to “Slow Run” to “Full Run” and into the sprinting. This will contribute to the seamlessness, as well as strengthen the players perception of their input translating to set intervals of the total max velocity capable of their current unit with their current stats.
Sprinting
Hold Circle to engage.
I’m not completely sure how the Sprint will differ from the walk – run blending. In Dark Souls, there’s a brief hang between holding Circle and the unit beginning to sprint. In Awaken Guardian that is managed by an actual timer, while it may be that in DS it’s the acceleration building until you’re actually at sprint speed.
Because the game is more oriented towards platforming, exploration, and athleticism, it seems to me that it may be better to make the [Hold Circle] into Circle Down. Tapping circle causes dodging, but if you put a threshold wherein it doesn’t count as a tap anymore, then you can hold circle and begin the sprinting acceleration instantly, while preserving the functionality not to run for 25 seconds and then end your run with a roll.
Additionally it seems like what you’d do is while holding circle, the value of the joystick normal is inconsequential. You simply are setting “Beyond Max Speed in this direction”.
Sprint would interrupt Crouch.
Lock-on and Aim Tank Control
Directional movement while maintaining rotation towards target.
A fairly standard interpretation of this common 3rd person system. Upon locking onto a target unit, or entering the Aim state, your character rotates towards the target direction but maintains their movements in all directions. This time by walking backwards and forwards, strafing left and right, and the combinations of those to move in the diagonals.
While in tank controls movement speed should be slightly reduced while strafing (90% total speed), and more reduced when retreating (75% total speed).
While aiming, there should be a more significant drop in speed no matter the direction, as you’re taking careful attention to your aim. Focused. While still reducing speeds for retreat.
In Dark Souls 3 there’s a particular effect wherein while locked on with your weapon away you remain in ‘freemove’ until you pull out your weapon for the first attack. This allows you to move at full speed in any direction while maintaining camera lock and relative direction. This also occurs while you’re in tank controls and you hold sprint to evade or escape. This allows for the granular control of lockon and sparring combat, while allowing an easy break to get out and away at full speed. Very intuitive, I didn’t even notice till my 3rd playthrough.
Crouch Movement
Stealthy counterpart to basic Walk > Run free movement.
Another simple interpretation of a fairly common mechanic. Pressing in the Left Joystick engages a crouch. This reduces your speed and makes you visually smaller, reducing your volume and visual detectability. Your max crouch movement speed should be no more than the full walk when you’re in freemove.
Crouch movement will also need to layer with lockon and aim tank control movement. There will be a crouch idle, crouch walk, and crouch walk tank directions.
Dodging, jumping, sprinting, and damage will break crouch and return you to freemove, or knockback or whatever other state you enter from the interrupt.
Swimming
Basic freemove variant. Lets cover our bases.
Because there is swimming functionality in the catlike tutorial I figure we might as well implement it along with everything else. There will be few swimming instances but I feel it makes for a good cover of all possible terrains and regions.
Swimming should disable many input features such as crouching, jumping, rolling, aiming, attacking/ranged/spells.
Originally, the only water I intended to include were things like rivers. If you fell into the river you’d instantly be swept away by rapids and spawn at a beach down river, sustaining massive drowning damage.
I feel that implementing swimming would not make things much more complex. It would allow us to include calm water to the environment, use pools of water to prevent jumping or any other exploitative level breakers, and put the player in vulnerable positions where they would have to swim across, say a pool, while vulnerable to the onslaught of arrow fire from the enemies at the other side.
We would include rapids areas like originally intended, and that would encapsulate all the benefits and complexities of implementing the catlike swimming.
We will need a swimming idle, and swimming forward animation.
Dodge/Roll
Sharp burst of directional movement with invulnerability frames. Weight dictates distance traveled.
Exactly like Dark Souls, we want to have a responsive and intuitive roll. While holding any direction, when you engage a roll you will move in that same direction. If there’s no input direction, tapping roll will engage a retreat towards unit backward.
The best way I’ve seen to implement this, is to have a rolling animation, but to tie it with a curve in order to create a trajectory of varying speeds. Fast through the air, a slower hang when you catch the ground, then a medium follow-through as you roll back to your feet and complete the roll.
Your stats would then dictate the distance you’ll travel based on your current weight, as well as DEX and STR scaling.
In-air and Fall Control
While unrealistic, in-air control is a standard tool for allowing more forgiving and tight controls over your character.
The very small force allowed in-air should provide ENOUGH control to land where you originally intend to, considering 3D platforming can be a real son of a bitch sometimes, while still feeling more rigid and “physics” based in the sense that obviously you can’t actually move in air once you’ve left the ground.
This in-air force will also influence your jumping trajectory allowing the player the ability to jump upwards to a platform, but to then be able to slink over the lip of the edge and catch the ground above. This will streamline the platforming and control of the character during highly acrobatic segments of the gameplay.
Directional Jumping
Joystick input directs the angle of the initial leap. Continued joy input in air adds minor force to influence trajectory.
The concept of directional jumping is definitely open to some serious scrutiny and adjustment. It seems like it would be an intuitive and strong contribution to the “tight controls” concept I’ve been pushing this entire document but we won’t know until we try.
Conceptually, as you push the left joystick from Normalized 0 to 1, you would be changing the jump trajectory from an upward “high jump” gradually to a horizontal “long jump”. This would make it so that as you run towards the edge of a cliff and jump off to reach the other side of a gap. You would, as anticipated, leap forward to span the gap. Not rising particularly high, but leaping long and far.
Likewise, if you put no joystick input when jumping, your character would leap straight up, putting all their force into height. If you were to lightly kink the joystick over and engage the jump, you’d have a jump arch that is somewhere inbetween, allowing you to go up and forward and varying degrees.
These jump arcs would then be influenced by the in-air controls, pushing the trajectory in any horizontal direction by a small margin. This, as was said above, allows you to jump to the general vicinity of where you’re aiming but then adjust in air to properly meet your intended mark each time.
If you push forward into a long jump, you’d gain a tiny bit more distance because of that added control.
If you pull away in that same long jump, you’d pull away from your trajectory and reduce the distance traveled.
These two forces, of jump trajectory and in-air control should grant tight, accurate control to the player to accomplish any exploration and navigation puzzles in the game environment. Precision should come with practice.
Wall Jumping
Once, after jumping, can jump upwards from wall.
Building upon the ease of jump control and environmental navigation is the need to remedy poor jumps, and add one additional layer of exciting navigation.
When the unit jumps against a non-climbable wall, the unit should latch onto the surface for a brief second. From there you can simply timeout the latch and fall to the ground, OR you can click jump once more and do a high jump from there. With the added in-air control, this would allow you to jump a gap with the long jump, catch the wall of your target destination, then thrust yourself up and onto the ledge which is as high as it was far from your original launch point.
This gives a semblance of a “parkour” feeling of control, while mitigating the unbelievable complexity a fully functioning parkour system must need to feel fluid and accurate.
In addition, this allows us to still utilize unit weight to reduce jump distance (forcing you to drop items or adjust your inventory), while preventing player pain. While a light dexterous Guardian may span a gap with ease, an encumbered stocky Guardian would fall short, catch the wall below, then leap up to the same gain. This would also give good indication of your weight impacting you, and allow us to make “low weight max distance” gaps and ridges that weed out certain meditations or low leveled players. Forcing adaption and compromise in navigating the game world.
Wall Climbing
Climbing on special designated climbable surfaces.
While wall jumping is oriented towards non-climbable surfaces, wall climbing is intended for the surfaces that are obviously meant for climbing. Using the catlike coding tutorial I feel we have a strong basis for the most part. Most of the function will simply need to be done in the animations.
Some aspects to note would be the need to identify the moment in which you crest the ridge of the top of the climbable surface and play an animation for that specific action.
Additionally, many controls will be disabled. Attacking, rolling, aiming.
Jumping might be fun, to leap up the surface like wall jumping. Just always latching back onto the surface and being able to jump again. (Depleting stamina causes hunger.)
In Dark Souls, holding sprint would also make you climb ladders faster. That might be an option to do as well.
Likewise, it would probably be ideal to have a “drop” button to completely disengage from the wall and plummet.
Another note would be that, perhaps we can add a boolean value to the climbable surface to lock the unit movement to up and down. This would allow us to implement ladders or narrow climbable surfaces with minimal additional development.
Slippery Surfaces
Low-friction surfaces. Muddy hill, ice, monster slime.
Building off the idea that we can identify climbable surfaces, would we be able to indicate low friction surfaces? Slippery.
This is a non-essential feature but I felt I should mention something about it, if it would be a stupidly simple implementation.
I figure it’d give a fun edge to a winter environment, signature of Zelda games.
Additionally, it can serve to make interesting “one way” points wherein you slide down a muddy hill or can’t get out of a slimy spiders den cave and must go into the region to find a way out.
Depending on the angle I figure we may want to have a “sliding too fast to do anything” state wherein you can adjust your direction, but you can’t aim or attack or do anything meaningful until you hit the end of the slide. This contrasts with the idea of a simply slippery icy surface that takes a bit more juice to get moving on.
I would like to discuss this further. Overall we won’t be lacking without. But it would add more environmental tools to our belt to make more varied and engaging environments.
Moving Platforms
A necessary element for adventure-like level development.
Elevators. Nuff said.
Platforms imbued with magic that float and move around. Even more than nuff said.
Legend of Zelda Ocarina of Time floating bean plant platforms that take you to unreachable locations…
Megaman Iceman level appearing and disappearing platforms but with the added twist of moving places too…
Adding even more surreal perspective bending features to the local gravity mechanic. Twirling in 3D while moving around and going to the wall or ceiling of the level…
Bayonetta combat level sequences on exploding debris flying through the air…
Levers, scales, and other gravity based platforms/terrain.
Weighted switches?
Local Gravity
From Mario Galaxy and the Catlike Coding Tutorial. A strong conceptual feature for ethereal “dreamy” spirit environments and dungeons.
This in conjunction with moving platforms and the rest of the world development would contribute a great deal to the spirit planes aspects of the game concept. Entering dreamscapes and entering domains ruled by powerful spirits would be deeply expanded by making them surreal and inconsistent with the bounds caused by earthly physics and perspectives.
I would like to implement this already in the Lodge of Dreams dungeon, as well as where you meet Elder Elk in his domain to seek guidance on your journey.
Knock Back – Forced Trajectory
A necessary prerequisite before building on the combat systems. Currently called Launch()
Launch()
The knockback system is something we REALLY need to lock down. I’m not absolutely sure how this all translates, nor am I particularly clear on how it’s done in other games. Especially with Dark Souls, as it works in conjunction (?) with poise.
As far as “I” have designed. Each attack would have knockback details. This allows us to have differing effects from something like an uppercut, to things like a home-run swing from a club. The uppercut would knock you high into the air, without much distance. While the home-run would strike you far.
I feel this could easily be met with 3 values. Height, Distance, and Stuntime. If not stun, then constrained to the animations I detail in the diagram.
One of the significant aspects of the knockback is to position enemies in front of your next attack, or in a more varied context position them further from your next attack to make combat more considered. With committed attack animations, like in Dark Souls, your unit often steps forward an amount based on the intensity of the attack. If the target enemy does not get knocked back from the hit, then you will either press unnaturally close to them with the following attack, or you’ll pass by them altogether. This means that, in most cases, you’ll need to knock the enemy back about as far as you will be stepping forward in the next attack.
Greater attacks, and finishing combo attacks would be the types of attacks that launch the enemy farther than a following attack would land, because they are emant to be a great deal more impactful visually and gameplay wise.
Knockback severity could be set by the specific attack with an ENUM, so that we know what sort of knockback we’re trying to deliver in any attacks. This means that if we had a giant with a tree as a weapon, even if you have a lot of defense and can mitigate lots of the damage, you’d be swept off your feet and launched away.
I’m not sure however, if poise is intact would you not get launched? Would the launch be reduced by one? This is something we need to better understand by the end of the knockback implementation.
Likewise, how will the player slide against the surface if taking air doesn’t keep you in the air for the duration of the launch.
There will need to be an “In Launch” animation that reflects the type of launch, followed by an “On Launch Land” animation that finalizes the launch and transitions back into freemove.