... | @@ -68,7 +68,7 @@ The gameplay framework currently consists of the following extensions: |
... | @@ -68,7 +68,7 @@ The gameplay framework currently consists of the following extensions: |
|
|
|
|
|
1. `BP_RWTHVRGameModeBase `
|
|
1. `BP_RWTHVRGameModeBase `
|
|
2. `RWTHVRPlayerState`
|
|
2. `RWTHVRPlayerState`
|
|
3. `BP_VirtualRealityPawn`
|
|
3. `BP_RWTHVRPawn`
|
|
|
|
|
|
**1. `BP_RWTHVRGameModeBase `**
|
|
**1. `BP_RWTHVRGameModeBase `**
|
|
|
|
|
... | @@ -77,7 +77,7 @@ The `BP_RWTHVRGameModeBase ` blueprint is based on the `RWTHVRGameModeBase` C++ |
... | @@ -77,7 +77,7 @@ The `BP_RWTHVRGameModeBase ` blueprint is based on the `RWTHVRGameModeBase` C++ |
|
It controls the flow of the application and handles new players and the corresponding default classes. **It is important to notice that it only exists on the server, not on any clients!**
|
|
It controls the flow of the application and handles new players and the corresponding default classes. **It is important to notice that it only exists on the server, not on any clients!**
|
|
The `BP_RWTHVRGameModeBase ` blueprint sets the following defaults:
|
|
The `BP_RWTHVRGameModeBase ` blueprint sets the following defaults:
|
|
|
|
|
|
- Default Pawn: `BP_VirtualRealityPawn`
|
|
- Default Pawn: `BP_RWTHVRPawn`
|
|
- Default Player State: `RWTHVRPlayerState`
|
|
- Default Player State: `RWTHVRPlayerState`
|
|
|
|
|
|
Additionally, it overrides the `InitNewPlayer` function to check for specific join options in the Join-Session string that new clients send to the server on initial connection. This happens when nDisplay nodes join a server. We need to identify those here to spawn a dummy spectator pawn for all the secondary nodes, and only a regular default pawn for the primary nDisplay node.
|
|
Additionally, it overrides the `InitNewPlayer` function to check for specific join options in the Join-Session string that new clients send to the server on initial connection. This happens when nDisplay nodes join a server. We need to identify those here to spawn a dummy spectator pawn for all the secondary nodes, and only a regular default pawn for the primary nDisplay node.
|
... | @@ -92,7 +92,7 @@ The `RWTHVRPlayerState` is a simple extension of [`APlayerState`](https://docs.u |
... | @@ -92,7 +92,7 @@ The `RWTHVRPlayerState` is a simple extension of [`APlayerState`](https://docs.u |
|
|
|
|
|
For now, it is set to the first two in case the GameMode notices a corresponding connection string for the connecting client, or in the Pawn in case of standalone mode or the latter two types.
|
|
For now, it is set to the first two in case the GameMode notices a corresponding connection string for the connecting client, or in the Pawn in case of standalone mode or the latter two types.
|
|
|
|
|
|
**3. `BP_VirtualRealityPawn`**
|
|
**3. `BP_RWTHVRPawn`**
|
|
|
|
|
|
As the Pawn is more involved, it gets its own [Pawn](#Pawn) section below.
|
|
As the Pawn is more involved, it gets its own [Pawn](#Pawn) section below.
|
|
|
|
|
... | @@ -107,13 +107,13 @@ Further resources on Unreal Multiplayer can be found in the [Multiplayer Network |
... | @@ -107,13 +107,13 @@ Further resources on Unreal Multiplayer can be found in the [Multiplayer Network |
|
2. `RWTHPlayerState`: There exists one PlayerState for each player, and they are replicated to all other players. Therefore, this class is perfect for syncing information that is always relevant to all other players. As an example, the base class is extended by a replicated `PlayerType` variable.
|
|
2. `RWTHPlayerState`: There exists one PlayerState for each player, and they are replicated to all other players. Therefore, this class is perfect for syncing information that is always relevant to all other players. As an example, the base class is extended by a replicated `PlayerType` variable.
|
|
3. `ClientTransformReplication`: In general, Actors/Components marked as "replicated", Unreal syncs basic things like their transform and attachment **from the server to the clients**. It does not sync transforms the other way round. If a player now modifies e.g. their pawn position, they only do this on their local machine. The `UClientTransformReplication` can be attached to your Actor to allow for Client-Side replication as well. It does this by simply sending an RPC to the server, asking it to modify the client position. This is then manually replicated by a UProperty marked as `ReplicatedUsing` to all the other clients. We're using a manual replication here for demo purposes and to save on bandwidth. Ideally, we would only sync Inputs instead of full transforms.
|
|
3. `ClientTransformReplication`: In general, Actors/Components marked as "replicated", Unreal syncs basic things like their transform and attachment **from the server to the clients**. It does not sync transforms the other way round. If a player now modifies e.g. their pawn position, they only do this on their local machine. The `UClientTransformReplication` can be attached to your Actor to allow for Client-Side replication as well. It does this by simply sending an RPC to the server, asking it to modify the client position. This is then manually replicated by a UProperty marked as `ReplicatedUsing` to all the other clients. We're using a manual replication here for demo purposes and to save on bandwidth. Ideally, we would only sync Inputs instead of full transforms.
|
|
4. `ReplicatedCameraComponent` and `ReplicatedMotionControllerComponent` are simple extensions to their base-classes that pretty much do the same thing as described in 3. Due to being in VR, we need to have some kind of client-authority, which is emulated in this way.
|
|
4. `ReplicatedCameraComponent` and `ReplicatedMotionControllerComponent` are simple extensions to their base-classes that pretty much do the same thing as described in 3. Due to being in VR, we need to have some kind of client-authority, which is emulated in this way.
|
|
5. `VirtualRealityPawn`: The Pawn contains some additional functionality that searches and attaches the CaveSetup actor on the server to the Pawn corresponding to the PrimaryNode. This is then implicitly replicated to all clients, including the SecondaryNodes.
|
|
5. `RWTHVRPawn`: The Pawn contains some additional functionality that searches and attaches the CaveSetup actor on the server to the Pawn corresponding to the PrimaryNode. This is then implicitly replicated to all clients, including the SecondaryNodes.
|
|
|
|
|
|
### Utilities & Fixes
|
|
### Utilities & Fixes
|
|
|
|
|
|
**1. Utilities**
|
|
**1. Utilities**
|
|
|
|
|
|
The `UVirtualRealityUtilities` defines a BP Function Library that can also easily used via C++. It collects various static functions to determine the state/mode of the currently running applications regarding VR hardware devices, such as:
|
|
The `URWTHVRUtilities` defines a BP Function Library that can also easily used via C++. It collects various static functions to determine the state/mode of the currently running applications regarding VR hardware devices, such as:
|
|
|
|
|
|
- `IsRoomMounted/Cave/Desktop/HMDMode`
|
|
- `IsRoomMounted/Cave/Desktop/HMDMode`
|
|
- `IsPrimary/SecondaryNode` regarding nDisplay
|
|
- `IsPrimary/SecondaryNode` regarding nDisplay
|
... | | ... | |