[RELEASED] Ninja Character - Dynamic gravity for characters & objects

[Xaklse]

Free on the Marketplace
Supported by the Epic MegaGrants Program!

.

.

I present you a Code Plugin for UE4, inspired by Epic's ArchVisCharacter. Contains six C++ classes, and an example map with blueprints. This plugin provides a Character, a third-person camera, a PhysicsVolume, and a Projectile that support any gravity direction determined by ten different modes.

.

.

Trailer

.

.

Walkthrough

.

.

This project started (2014) as a CharacterMovementComponent subclass with support for arbitrary orientations. After Epic's explicit interest on integrating this in the base engine, it evolved in a series of GitHub pull requests that improved the base CharacterMovementComponent, but never got any gravity-related improvements in.
This plugin completely supersedes other plugins that use my outdated and unpolished code that I shared with everyone for older versions of Unreal Engine.
Unsupported features include AI with navigation mesh based walking, and cloth geometry simulation.

.

.

Features:

• Character with support for any orientation and gravity direction.
• PlayerCameraManager that handles any arbitrary Character orientation.
• PhysicsVolume that overrides gravity direction for overlapping Actors.
• Projectile that follows gravity direction.
• 10 modes that determine direction of gravity, zero gravity supported too.
• Additional cheats to draw debug info.

.

.

.

.

.

How to use:

.

- Make sure you already have created a game project.
- Player controls are only handled by the example Character Blueprint, and require input bindings.
- Open the example level to learn how to use the new classes added by the plugin.

.

0. Install the plugin to the engine.

a. Open Epic Games launcher
b. Click on "Unreal Engine" section
c. Click on "Library" tab
d. Under "Vault" sub-section, search for "Ninja Character Plugin"
e. Click "Install to Engine"
f. Choose engine version and wait for installation

.

1. Enable the plugin in your game project.

a. Open project with editor
b. Edit > Plugins
c. Search for "Ninja Character"
d. Mark "Enabled" checkbox
e. Restart editor

.

2. In Content Browser, mark "Show Engine Content" and "Show Plugin Content" checkboxes in "View Options"

.

3. Add new input bindings (optional).

a. Outside the editor, go to your project's root folder
b. Open "Config" folder
c. Backup "DefaultInput.ini" file (if it exists)
d. In the editor, Edit > Project Settings
e. Click on "Input" section below big "Engine" word
f. Under "Bindings" sub-section:

- Add "Jump" to "Action Mappings", assign a key/button
- Add "MoveForward" to "Axis Mappings", assign keys or joystick axis
- Add "MoveRight" to "Axis Mappings", assign keys or joystick axis
- Add "Turn" to "Axis Mappings", assign mouse axis
- Add "LookUp" to "Axis Mappings", assign mouse axis
- Add "TurnRate" to "Axis Mappings", assign joystick axis
- Add "LookUpRate" to "Axis Mappings", assign joystick axis

.

4. Open the example level (optional).

a. In Content Browser, choose the "NinjaCharacter Content" path/folder
b. NinjaCharacter > Maps
c. Double click on "NinjaCharacterExampleMap"
d. Play the level (input bindings required), or simulate the level (ALT+S)

.

5. Open any level of your game project.

.

6. If you DON'T have your own Character Blueprint:

a. In Content Browser, choose the "NinjaCharacter Content" path/folder
b. NinjaCharacter > Blueprints
c. Right click on "NinjaPlayerCharacter_BP"
d. Asset Actions > Migrate...
e. Click on "OK" button
f. Choose your project's Content folder

.

7. If you have your own Character Blueprint:

a. In Content Browser, search your own Character Blueprint
b. Open it
c. File > Reparent Blueprint
d. Choose "NinjaCharacter"
e. In Content Browser, choose the "NinjaCharacter Content" path/folder
f. NinjaCharacter > Blueprints
g. Double click on "NinjaPlayerCharacter_BP"
h. Click on "Event Graph" tab
i. Copy nodes and connections you need (for player input) to your own Character Blueprint
j. In "Components" panel, select "NinjaPlayerCharacter_BP(self)"
k. Copy the changed settings you need to your own Character Blueprint
l. In "Components" panel, select "CharacterMovement (Inherited)"
m. Copy the changed settings you need to your own Character Blueprint

.

8. If you DON'T have your own PlayerController Blueprint:

a. In Content Browser, click on "Add New" button
b. Select "Blueprint Class"
c. Click on "Player Controller" button
d. Name it, open it
e. Change the "Player Camera Manager Class" setting to "NinjaPlayerCameraManager"

.

9. If you have your own PlayerController Blueprint:

a. In Content Browser, search your own PlayerController Blueprint
b. Open it
c. Change the "Player Camera Manager Class" setting to "NinjaPlayerCameraManager"

.

10. If you DON'T have your own GameModeBase Blueprint:

a. In Content Browser, click on "Add New" button
b. Select "Blueprint Class"
c. Click on "Game Mode Base" button
d. Name it, open it
e. Change the "Player Controller Class" setting to the PlayerController Blueprint
f. Change the "Default Pawn Class" setting to the Character Blueprint

.

11. If you have your own GameModeBase Blueprint:

a. In Content Browser, search your own GameModeBase Blueprint
b. Open it
c. Verify the "Player Controller Class" setting uses your own PlayerController Blueprint
d. Verify the "Default Pawn Class" setting uses your own Character Blueprint

.

12. In your level, Window > World Settings

.

13. In "World Settings" panel, change the "GameMode Override" setting to your own GameModeBase Blueprint

.

14. Play your level

.

[Basement Bob]

Hi. thanks for you hard work,

just wondering, the align character to floor really needs a lerp or something to smooth it out, at the moment it appears to be stuttering due to suddenly changing angle to match face below z axis.

Change over time from current angle under z axis to new z axis angle factoring in movement speed.

I'll have a play later, see if I can put something in, but currently between teeth extraction appointments so can't think straight at the moment, 2020

[Xaklse]

It's something that never bothered me... smoothing the collision capsule orientation is troublesome for character movement... it's difficult to explain if you don't test it... movement becomes "unreliable".
I always thought that it's better to smooth the skeletal mesh orientation, or use really smooth floor geometry.

Best wishes

[MadPolygon]

Thats really cool, wish Epic could add more flexible solutions like these natively so we didn’t have to find a hacky solution. Why hasn’t epic merged it into unreal engine yet? I could see this behavior be very desirable for alot of stylized projects? More flexibility and exposed elements would be great in future! Thanks again

[CreativeColony]

before buying I want to know whether I can use this in a game or not. I'd like to use it as a ability for a limited amount of time and that time run out player falls down and becomes becomes human

[Xaklse]

Thats really cool, wish Epic could add more flexible solutions like these natively so we didn’t have to find a hacky solution. Why hasn’t epic merged it into unreal engine yet? I could see this behavior be very desirable for alot of stylized projects? More flexibility and exposed elements would be great in future! Thanks again

Nope, Epic has no plans to merge this into Unreal Engine that I know, it's a feature that needs to be flawless, adds costs to maintenance, code logic is more complex, etc. You're welcome!

[Xaklse]

before buying I want to know whether I can use this in a game or not. I'd like to use it as a ability for a limited amount of time and that time run out player falls down and becomes becomes human

Yeah, you should be able to turn on/off each configurable checkbox through blueprints, let me know if you think there is something missing. BTW, the plugin is FREE.

[Xaklse]

Hi Xaklse

I had to make a local change to get smooth movement on the player for our project. Using a (quite big) spherical world seems to make the delta between old-new gravity directions too big to get a smooth transition .

Therefor I had to disable the return statement in ninjacharacter.cpp (which sets the control rotation).

Also added a rotator lerp in the movementcomponent (that still has the return statement a few lines prior).

Do you think this will have a huge impact on performance eventually? If so, what would you recommend to smoothen out the (rotational)movement? Using camera lag smoothens it out a little, but not entirely (and we rather don't have much lag on the camera)


NinjaCharacter.cpp line 223:

if ((LastAxisZ | NewAxisZ) >= THRESH_NORMALS_ARE_PARALLEL)
{
//return;
}

NinjaCharacterMovementComponent.cpp line 5380:

// Abort if angle between new and old capsule 'up' axes almost equals to 0 degrees
if ((DesiredCapsuleUp | CurrentCapsuleUp) >= THRESH_NORMALS_ARE_PARALLEL)
{
return;
}

//// Take desired Z rotation axis of capsule, try to keep current X rotation axis of capsule
const FRotator NewRotation = FNinjaMath::MakeFromZQuat(DesiredCapsuleUp,
UpdatedComponent->GetComponentQuat()).Rotator();
const FRotator CurrentRotation = FNinjaMath::MakeFromZQuat(CurrentCapsuleUp,
UpdatedComponent->GetComponentQuat()).Rotator();

if (!bRotateAroundCenter)
{
float PawnRadius, PawnHalfHeight;
CharacterOwner->GetCapsuleComponent()->GetScaledCapsuleSize(PawnRadius, PawnHalfHeight);

// Rotate capsule around the origin of the bottom sphere
const float SphereHeight = PawnHalfHeight - PawnRadius;
const FVector Delta = CurrentCapsuleUp * (SphereHeight * -1.0f) + DesiredCapsuleUp * SphereHeight;

FRotator RotationLerp = UKismetMathLibrary::RInterpTo(CurrentRotation, NewRotation, GetWorld()->GetDeltaSeconds(), 4.0f);

// Not using MoveUpdatedComponent to bypass constraints
UpdatedComponent->MoveComponent(Delta, RotationLerp, true);
}

nonetheless, nice work on the update!! Especially the new debug options are really useful!

Huge performance impact? It depends on how much processing time you can spend on character movement, which is rather heavy. How many ninja characters do you have in your game?

It's better to avoid smoothing the invisible capsule orientation and smooth the visible stuff (skeletal & camera); or make the capsule smooth with more complex logic that involves recalculation of floor-normal/capsule-axis, avoiding time-based logic.

What's the size of the planet sphere you have? (To test with)

[Frank Post]

Hi
We actually don't want to put a firm number on the amount of players (yet). That'll mostly depend on overall performance we get, but we're hoping to get in the range of 16-24 (online multiplayer).

I wasn't really a big fan of the time-based lerp myself, as posted above. Didn't think of smoothing the mesh/camera in stead of the capsule, that's a good idea, thanks! I rather avoid the capsule axis/floor calculations then, since I guess that's the biggest hit on performance.

The world we currently use is 170 units in diameter, which isn't awfully big, yet big enough to make the gravity rotation noticeable.

[Enraged91]

Xaklse

Two things I noticed that may be a bit of an issue for me.

Firstly it doesn't appear to work with aimoffsets as the character is usually looking in the wrong direction when upside down or sideways and such.

Secondly it doesn't appear to work properly at higher speeds. When I upped the speed of the rotating platforms for instance and added multiple directions the character goes flying off. I'm intending to use this for spaceships that can move while the character is inside so it creates a bit of trouble.

Any ideas for how to solve these issues? I'd greatly appreciate any advice.

[CambrianLogistic]

Hey Xaklse,




We've ran into an issue when packaging our build for Android.

NinjaPhysicsVolume.h(28) : LogCompile: Error: An explicit Category specifier is required for any property exposed to the editor or Blueprints in an Engine module.

NinjaPhysicsVolumeSpline.h(26) : LogCompile: Error: An explicit Category specifier is required for any property exposed to the editor or Blueprints in an Engine module.




What adjustments would you suggest to complete the packaging process? This is our only issue with the packaging process for our title. We don't want to make an drastic changes as this was a last minute addition as we are still learning more and more about the plugin.




Kind regards and big thanks in advance Xaklse!

[Xaklse]

Two things I noticed that may be a bit of an issue for me.

Firstly it doesn't appear to work with aimoffsets as the character is usually looking in the wrong direction when upside down or sideways and such.

Secondly it doesn't appear to work properly at higher speeds. When I upped the speed of the rotating platforms for instance and added multiple directions the character goes flying off. I'm intending to use this for spaceships that can move while the character is inside so it creates a bit of trouble.

Any ideas for how to solve these issues? I'd greatly appreciate any advice.

I never used AimOffset myself, is there any Epic example project that uses it?
I will try to reproduce the platform issue and see if a solution comes to mind.

.

Hey Xaklse,
We've ran into an issue when packaging our build for Android.
NinjaPhysicsVolume.h(28) : LogCompile: Error: An explicit Category specifier is required for any property exposed to the editor or Blueprints in an Engine module.
NinjaPhysicsVolumeSpline.h(26) : LogCompile: Error: An explicit Category specifier is required for any property exposed to the editor or Blueprints in an Engine module.

What adjustments would you suggest to complete the packaging process? This is our only issue with the packaging process for our title. We don't want to make an drastic changes as this was a last minute addition as we are still learning more and more about the plugin.

Kind regards and big thanks in advance Xaklse!

Leaving the reply here for others:
Just add ,Category="NinjaPhysicsVolume" to the lines the packager is mentioning (subtract 1 to each number), it will work.

UPROPERTY(VisibleAnywhere,BlueprintReadOnly,Category="NinjaPhysicsVolume")

[Frank Post]

We're also using camera offsets, but (so far) didnt notice a problem. Are you using the ninja camera manager in the controller? I forgot that once myself, and caused some issues with gimbal locks and weir rotations.

the gravity updates after the delta between old and new gravity directions gets exceeded. I can imagine if the physics get calculated while that delta isnt exceeded, it could cause physics to misbehave. Could try attaching the player to the ship, so it becomes a child object. although not sure if that causes other issues

[ksimpson1986]

Hi, I noticed an update today for your plugin. Do you have any changelog notes for this update? I was just curious of any new changes. Thanks!

[Xaklse]

Firstly it doesn't appear to work with aimoffsets as the character is usually looking in the wrong direction when upside down or sideways and such.

Could you please verify what Frank recently posted?

We're also using camera offsets, but (so far) didnt notice a problem. Are you using the ninja camera manager in the controller? I forgot that once myself, and caused some issues with gimbal locks and weir rotations.

.
.

Hi, I noticed an update today for your plugin. Do you have any changelog notes for this update? I was just curious of any new changes. Thanks!

It's just a minor update, v1.02.25:
- Fixed game packaging with this plugin.
I also forgot to remove a test map & character blueprint that slipped in. Next time it won't happen