Unity Character Controller Samples

The OnlineFPS Sample is a demonstration of a fast-paced, client-predicted online first-person shooter (FPS) game. It is implemented using DOTS Netcode to handle networked gameplay and client-side prediction.

To understand the specific implementation details of this sample, refer to the following specialized guides:

• Building & Playing: Instructions on how to compile and run the sample.
• Game Management: Details on how game states and sessions are handled.
• Input, Character & Camera: How player input is processed and how the character and camera systems are integrated.
• Weapons: Implementation details for the weapon systems within the networked environment.

Prefab weapons (e.g., RocketLauncher, PlasmaGun) spawn projectiles as ghost prefabs that handle their own movement and collision.

Simulation Flow

1. Spawning: WeaponsSimulationSystem runs a PrefabWeaponSimulationJob. For each event in the WeaponProjectileEvent buffer, it spawns a projectile prefab on the server and as a predicted prefab on clients.
2. Resolution: ProjectileClassificationSystem resolves predicted-spawned projectile ghosts on clients with the authoritative server ghosts once they arrive.
3. Movement & Collision:
   • ProjectileSimulationsJob serves as the base job for movement and collision.
   • Specialized jobs like ProjectileBulletSimulationJob (for plasma) and RocketSimulationJob (for rockets) extend this logic for specific projectile behaviors.

The GroundMoveState is responsible for standard grounded movement logic within the Platformer Sample. It manages several key behaviors:

• Movement Types: Handles regular walking, sprinting, and jumping.
• Surface Detection: Detects "sticky surfaces" (allowing the character to walk on walls) and "friction surfaces" (such as ice).
• Rotation Adaptation: Automatically adapts the character's rotation to match the orientation of detected friction surfaces.
• Jump Grace Times: Implements JumpBeforeGroundedGraceTime, which allows a jump input to be registered slightly before the character actually touches the ground, ensuring more responsive controls.

Transition Logic: Typically, the character transitions into this state when they are grounded and not performing other specific actions like crouching.

In the Platformer Sample, AirMoveState is the state responsible for handling standard air movement, air jumping, and detecting ungrounded walls (which is a prerequisite for wall-running transitions).

Key features include:

• Air Movement & Jumping: Manages standard physics and input while the character is airborne.
• Wall Detection: Detects ungrounded walls to facilitate transitions into wall-running states.
• Jump Grace Time: Supports a 'coyote time' mechanic via JumpAfterUngroundedGraceTime. This allows a jump input to be registered slightly after the character has left a grounded surface, treating the character as if they were still grounded for the purpose of the jump.

Transition Logic: Typically, the character transitions to AirMoveState whenever they are not grounded and are not performing any other specialized aerial actions (such as wall running).

If your character only rotates around the world up axis, you can reduce bandwidth by synchronizing only the Y euler angle instead of a full quaternion.

To implement this:

1. Add a prediction system that runs in the PredictedSimulationSystemGroup before the PredictedFixedStepSimulationSystemGroup.
2. Reconstruct the character's LocalTransform.Rotation from the Y euler angle.
3. Ensure this reconstruction happens before any other system uses the rotation (e.g., before OrbitCameraPrePhysicsSystem if using a third-person character).

Gravity in this sample is managed via a combination of components and systems rather than standard physics engine gravity.

• CustomGravity: A component placed on entities to receive gravity calculations.
• GravityZonesSystem: Calculates spherical gravity for entities within a SphericalGravityZone or applies global gravity via GlobalGravityZone to those not in a specific zone.
• Character Integration: Because the character is not a dynamic body, it does not have its velocity modified automatically by the GravityZonesSystem. Instead, the character must manually add the calculated gravity to its KinematicCharacterBody.RelativeVelocity within its state updates. The character should also orient its rotation to point towards the opposite of the custom gravity's direction.

To reduce the number of ghosts being synchronized, you can merge the Player and the Character into a single entity if your game design does not require switching controlled characters or destroying character entities independently of player data.

If you merge them, you should also optimize your Player systems to access components directly on the same entity rather than performing lookups to find the associated character entity.