Streamlined Usage of OpenKCC Through KCCMovementEngine Abstraction

Goal: Simplify the direct use of KCCMovementEngine

Use Case: I created a test scene and Unity Package that has a simple character that simply attempts to move in a direction on the XZ axis

As as starting point, I’d like to be able to use the KCCMovementEngine API alongside a simple KCCConfig to make it so the AI agent moves in each of the cardinal directions while making use of OpenKCC under the hood

See the picture below for the “Intended Behaviour”

• While using the KCCMovementEngine and an Appropriate KCCCOnfig, I expect the character to walk up the stairs when moving on the X axis and to be blocked by the walls while moving in the Z axis
• I also expect the character to fall off the last step of the stairs and start descending if gravity is enabled at the KCCConfig or KCCMovementEngine level

It would be interesting if I could then swap the KCCMovementEngine for a KCCMoleEngine, enabling the character to run Up the walls like the mole would be able to, without changing any code, but I understand if this would also require a swap in KCCConfig as well

Below shows my current test case, where the AI Agent is instructed to desire a velocity of 1 along the X axis, and my non KCC solution simply moves the transform to the calculated position each frame.

• This naïve implementation simply causes the agent to phase through objects

The sample package that I will provide to you demonstrates how I created this script and includes commented sections that demonstrate how I would like to replace my naïve implementation with OpenKCC’s Collision Solving.

Here is a snippet of how the code currently works and it includes an example of how I’d like to replace my naïve implementation with an OpenKCC API Call

    void FixedUpdate()
    {
        // 1. Get Desired Velocity from Input Source
        Vector3 newVelocity = testInputDirection * testSpeed;

        // 2. Make Arbitrary Modifications to Velociyt Based on Character State
        // newVelocity = speedBoost ? newVelocity * 2 : newVelocity;

        // 3. Apply Movement to Character based on Calculated Velocity
        ApplyMovement(newVelocity, Time.fixedDeltaTime);
    }

    void ApplyMovement(Vector3 velocity, float deltaTime)
    {
        // 1. Temporary, Non Collision Based Solution
        transform.position += velocity * deltaTime;

        // 2. Ideal Solution Using OpenKCC, Benefitting from Collision and
        // Gravity Settings of the KCCMovementEngine and its IKCCConfig
        /*
        // _movementEngine.ApplyMovement(deltaTime, transform.position + velocity, true);
        */
    }

Overall I want to greatly expand on this manual usage of the “mid-level” abstractions of OpenKCC, and I hope that this could be a decent starting point.

[nicholas-maltbie]

I think I feel content with the new version of the api.

Closed PR #142 to overhaul the api and significantly improved documentation, testing, and exposed api parameters to make the newer version more accessible.

I opened a PR to update the project version to 1.3.0 and will create a release once we have PR #150 merged!

If you have any other suggestions or comments let me know. We can always follow up in a future patch or release as well.

[nicholas-maltbie]

I wrote up the basic document and made a PR #138 for it. The start of the document basically describes why this is needed. Right now the API wants to satisfy a bunch of different stakeholders and it’s doing too many things poorly. For most scenarios you won’t want to modify that parameter from it’s default. So, let’s make the default the right setting in the first place and let the user override it if they want to.

Another thing to consider is constraints on player movement. If the player starts climbing something or holding onto a ledge their movement is now constrained to fewer axes. While if the player is flying in 3D space, their movement has no constraints at all.

here is the list of scenarios: https://github.com/nicholas-maltbie/OpenKCC/blob/nickmaltbie/api-requirements/Documentation/manual/kcc-design/kcc-user-stories.md#scenarios and the design proposal: https://github.com/nicholas-maltbie/OpenKCC/blob/nickmaltbie/api-requirements/Documentation/manual/kcc-design/kcc-user-stories.md#designing-an-api

If you or anyone else has any suggestions, feel free to leave them in this issue.