top of page
  • Writer's pictureDaniel Bellido Chueco

Player Control set up

Back to ArmaX! After a month since "Habemus GDD" was published, some unforeseen events have happened that have hindered the development of my Final Year Project but the day has come and there is finally an update.

It is by no means a playable demo; it has been able to develop quite a bit but it has started and a positive dynamic is entering, which is the most important thing.

What contents have been implemented in this first phase of production?

  • The main character.

  • different stances (stand, crouch, and prone).

  • animations for each stance.

  • basic movement for each stance.

  • Camera control.

  • Aiming camera.

  • Gamepad.

  • A test level.

The main character is currently a placeholder downloaded from the mixamo website and although aesthetically it fits the theme and genre of the game, it may be replaced in the late stages of production.


At the moment, the main character has three stances, each running a series of animations according to his stance. These stances are stand, crouch, and prone and for each stance, a 1D blend tree has been created that mixes various animations depending on the value of the "input magnitude" parameter.



The standing tree has four animations: idle, walk, run, and run. On the other hand, the crouch tree and the prone tree have two animations, one representing the idle animation and the other playing the forward movement animation. Each stance has a different movement speed.



Regarding the camera control, the Cinemachine package has been chosen since it is a tool that speeds up the work and provides quite good results. At the moment, the scene has two cameras: a freeLook camera that is the one that is used the most and a virtual camera that is used exclusively when the player wants to aim.


The freeLook camera is a camera that rotates around the player (actually it rotates around an empty game object called a target located on the player's neck) and allows one to observe the entire character and a wide field of vision. While the virtual camera is a camera fixed on the character's shoulder where the player can only see themselves from the waist up, offering a more focused field of vision towards what the player has in front of his eyes (zoom). This camera is activated only when the player holds down the aim button while disabling the freeLook camera. The most notable thing about this virtual camera is that the player can change the position of the camera over the left shoulder and the right shoulder to ensure that the player feels more comfortable choosing which side they prefer to use.


This last camera is not fully implemented as the aiming animation and the weapon is not implemented and the player cannot yet move this camera to explore the environment while aiming.


In addition to these two cameras, it is planned to implement an extra first-person camera when the character is confined in small spaces like ventilation ducts thus not affecting the player's vision.



Added to all this is the player movement, which consists of a script that not only allows the player to move, but also controls and communicates with other components such as the animator, character controller, and an additional capsule collider that has been added in the player's head to detect headshots in future updates. This script contains the function Move() which consists of a vector3 variable named direction. The parameters of this vector3 are floating variables that receive input from the horizontal and vertical axes for the X and Z axes, leaving the Y axis at zero, and allowing it to move along the X and Z axes in a three-dimensional plane.


After that, a clamp is applied to the direction variable so that it returns a value between 0 and 1, thus obtaining the input magnitude that is multiplied by the maximum speed. Therefore, the value of the input magnitude that the script sends to the Animator is obtained and from the Animator, it is decided which animation should be applied based on the magnitude.


To finish and get the player to rotate about its Y axis and move towards the direction in which it is rotating, as long as the magnitude of the direction is greater than 0.1, a target angle is calculated by calculating the tangent of the X direction and the Z direction which will then later be multiplied with the Vector3.forward and stored in the MoveDirection variable. This variable will be normalized and multiplied by speed and time to achieve the desired result.



This function is called in each of the different stances of the character since each stance has its function that applies different maximum speeds and also changes other parameters like the position, radius, and height of the capsule collider.

On the other hand, the handling of the stances is managed by another function called AnimationStateControl() that manages each stance through booleans and returns the value of these booleans to the Animator component.


In the next update, I will try to add much more relevant and polished content, since it is necessary to have a demo ready by the 15th of December. By then it would be nice to have some kind of AI implemented but before taking that step it is preferable to finish implementing most of the player mechanics and have smooth gameplay.


What are the next milestones?

  1. Expand character gameplay mechanics:

  • Jump over obstacles.

  • Climb walls and ladders.

  • Move stealthily through the walls.

  • Take cover with walls and obstacles.

2. Improve and expand camera control:

  • add an extra first-person camera (for ventilation ducts).

  • move properly while aiming.

  • adapt aiming animation in the aiming camera.

3. Improve test-level design.

  • Add meaningful obstacles

  • Climbable walls and ladders

24 views0 comments

Recent Posts

See All

Comments


bottom of page