The Interaction

I must admit that I encountered some challenges in identifying an effective interaction technique. The default technique is very intuitive, as it maps the controller position and rotations on the interactable object. After brainstorming for some time, I came up with the idea of incorporating doors as a means to progress in the parkour and unlock the next section.

Therefore, I used the package Interactive Physical Door Pack. The included scripts had to be modified to the specific use case in the parkour. Specifically, modifications were made to the rampmover.cs script and the gridmover.cs script.

The script rampmover.cs necessitated adjustments to the code in order to enable control of the ramp via the left thumbstick. To do this, it was necessary to obtain information about the thumbstick. Subsequently, the thumbstick’s input was integrated into the rotation angle calculation. Initially, challenges arose with the rotation angles, which were specified in quaternions. Following extensive research and the verification of all calculations, these issues were resolved.

void Update()
{

    Vector2 input = OVRInput.Get(OVRInput.Axis2D.PrimaryThumbstick);
    
    Quaternion rampRot = RampObject.rotation;
    rampRot = rampRot * Quaternion.Euler(-(input.y * 0.75f), 0f, 0f);

    RampObject.rotation = rampRot;
}

The script ‘gridmover.cs’ was modified to allow for control via the right thumbstick. Consequently, the thumbstick’s input data was collected and integrated into the grid movement calculation. Constraints were imposed on the range of movement. Specifically, if the grid is closed, it will not move down further, and if the grid is open, it cannot be moved up any further.

 void Update()
 {

     Vector2 input = OVRInput.Get(OVRInput.Axis2D.SecondaryThumbstick);
     Debug.Log(input.x);

     Vector3 newPos = new Vector3(GridObject.position.x, GridObject.position.y + (input.y * 0.25f), GridObject.position.z);
    Debug.Log(newPos);
    if (newPos.y < 25f && newPos.y >= 11f){
        GridObject.position = newPos;
    }
 }

The subsequent concept, pertaining to real-life scenarios, involved the restriction of the ramp and grid’s range of movement to ensure its maintenance within a reasonable limit. Specifically, if the ramp is closed, it should not rotate any further into the gate, and if the ramp is open, it cannot be opened any further. Analogously, if the grid is closed, it should not be moved down any further into the ground, and if it is open, it cannot be opened any further. Additionally, the grid should only open if the ramp was fully opened beforehand. The specification of these constraints for the grid was uncomplicated, as evidenced by the code above. An analogous approach to the movement of the grid was adopted for the ramp, but with regard to the angle. Nevertheless, upon testing in the game, the observed angle of the ramp varied. Thus, it was impossible to determine an absolute upper and lower limit. Consequently, the proposed constraint on ramp movement, in conjunction with the requirement that the ramp must be opened prior to the grid, was ultimately rejected on the basis that it could not be successfully implemented.