Rail-Systems:
This guide will provide you with an expanded overview of how rail-systems work, give helpful tips and recommendations for their implementation, and show you how to set up a couple of varied rail-systems in video tutorials.
Detailed information on each of the parameters of a rail-system is provided in Section 4 of the documentation.
Overview:
What is a rail-system?
A rail-system linearly moves the player along a set path of predefined length and position while rotation is controlled by one of several options.
How do rail-systems work?
In order to properly set up a rail-system, it is important to know how they work. There are three major components of a complete rail-system in its most basic form: the MultiStateRailSystem script, the MultiStateMovementRailCap script, and the path which is composed of empty gameobjects serving as waypoints.
The MultiStateRailSystem script holds the core functions of a rail system while the MultiStateMovementRailCap script defines how the player “attaches” to the rail-system, and the path is, of course, simply a path. Rail-system dollies can also be added in. Dollies are simple components that move along a separate rail-system in response to movement of a “driving” rail-system. Rail-systems are extremely passive by design, a one-dimensional position value, between 0 and the rail-system duration, is provided to the rail-system by a “driver” and the corresponding world location along the path is returned. The rail-system also sends the position it was given to evaluate to a list of dollies so that the dollies can then slightly modify that value, evaluate the position along their attached rail-systems, and the dolly/rail-system cycle repeats until a rail-system without attached dollies is reached. For this reason, a single rail-system cannot be driven by two separate drivers.
Example using an improper dolly setup (Figure 1):
Step 1. The player provides a rail-system position that the rail-system evaluates.
Step 2. The player moves to the returned location.
Step 3. The rail-system sends the player-given rail-system position to an attached dolly.
Step 4. The dolly modifies the rail-system position according to its parameters.
Step 5. The dolly is attached to the original rail-system, and the dolly sends the modified rail-system position to the rail-system.
Step 6. The dolly moves to the returned location.
Step 7. The rail-system sends the dolly-given rail-system position to the same attached dolly.
Step 8. And the dolly continues to drive the rail-system and be driven by the rail-system until the application eventually crashes.
Example using a proper dolly setup (Figure 2):
Step 1. The player provides a rail-system position that the rail-system evaluates.
Step 2. The player moves to the returned location.
Step 3. The rail-system sends the player-given rail-system position to an attached dolly.
Step 4. The dolly modifies the rail-system position according to its parameters.
Step 5. The dolly is attached to a separate rail-system, and the dolly sends the modified rail-system position to the second rail-system.
Step 6. The dolly moves to the returned location.
Step 7. The rail-system checks if any other dollies should be driven, which, in this scenario, there are not, and ends the complete evaluation period.
The player, like the dollies, can drive rail-systems. In fact, it is the player, the MSCC script, that sets the whole process into motion since dollies are themselves driven. Therefore, the rail-system that the player directly drives is the primary rail-system and the rail-systems that are driven by dollies are secondary rail-systems. Both primary and secondary rail-systems are subject to the universal rail-system parameters, but secondary rail-system parameters do not apply to primary rail-systems and primary rail-system parameters do not apply to secondary rail-systems.
How does the player enter and exit the On Rails State?
The player is attached to and detaches from the rail-system using the MultiStateMovementRailCap Script. This component is normally implemented on the starting and ending waypoints, but this is not a requirement. The only requirement for the rail caps is that the rail-system that the player will be attached to is defined within the script’s parameters and the gameobject has a collider marked as a trigger. Keep in mind that the camera’s collision detection might detect the trigger if the layer/layer masks are set up improperly. The rail-system cap’s interaction is based on the player’s initial entry into the trigger’s bounds. Therefore, a single rail cap can both attach and detach the player from the rail-system. An interaction key may also be used to facilitate attachment and detachment within the bounds of the trigger.
How is rail-system animation handled?
When the player is initially attached to a rail-system, a custom animator trigger predefined by the rail-system is set. The animator’s OnRails bool parameter holds the player in the animator state until detachment. The animator’s RailExit trigger can be used to prematurely exit the animator’s state. This is usually triggered by a rail-system positional event. Animation speed can be driven by any of the velocity or magnitude parameters as required or it can be driven by the rail-system position alone by setting the animation speed to 0 and using the RailPosition parameter as the animation offset’s parameter.
Rail-System Tips:
-
Be aware of the rail-system’s Y value offset parameter as the normal player position usually aligns the path with the player’s head. This might not be initially apparent if there is a ground surface below the player.
-
When using the absolute position lock, you can use a small rail cap and a larger move-to trigger directing the player towards the rail cap to minimize snapping.
-
Positional events can often be used in place of triggers, providing a cleaner player experience.
-
A rail-system dolly can serve as the player’s look at target.
-
The MultiStatePlayerInput script has parameters that can smooth transitions in and out of rail-systems.
-
Latch and Unlatch events can be used to enable and disable colliders
-
It is often better to use two completely separate rail-systems, disabling and enabling them through latch and unlatch events, for forward and backward traversal between two points instead of a single system.
-
The default camera collision script can be disabled while interacting with the rail-system then re-enabled automatically.
-
The grounded Animator state will still function normally if the animator enters the state while interacting with the rail-system, and the grounded substate can even be changed, as well, using a trigger or positional event.
-
Setting the rail-system player rotation speed parameter to 0 will prevent the player from rotating.
-
Rail-system dollies can be or do just about anything as long as it doesn’t interfere with the gameobject’s position.
-
Transitional animations can be used and are recommended when using rail-systems.
-
While using the provided IK system, Ik weight is still ultimately determined by the animation’s weight curve.
-
Rail-system caps used for attachment should ideally be kept as small as possible.
(Figure 1.)
(Figure 2.)
What’s new with Update 1.1:
Variable latch positioning:
The player will now be able to calculate a latch point as a percentage of the distance between two reference transforms, compared to the original hard-set latch position, which may still be used as desired.
A variable latch position can be used by following these steps:
-
In the MultiStateRailCap Parameters, set the “latch type” parameter under the “latch position” settings to “calculated position”.
-
Define the latch position range. The position parameter is the lowest range value, and the end position value is the highest range value.
-
Define the two reference transforms. Note: these can be your starting and ending waypoints in many situations.
Camera Direction Calculation:
The rail-system direction may now be aligned with the camera’s direction when driving the primary rail-system through key input.
Camera Direction can be enabled via the following steps:
-
Open the primary settings of the MultiStateRailSystem parameters of your primary rail-system.
-
Set “Enable Camera Based Direction” to true.
-
Note: Camera Based Direction uses the starting and ending waypoints to determine the direction. This means that rail-systems with complex paths may not support camera-based direction.
Rail-Systems that do not use uniform distance calculation now support positional events.
Rail-System Remote Sampling and Latching:
What is Remote Sampling and Latching?
Remote sampling and latching allows the player to latch onto a rail-system from a distance by first blinking to the rail-system latch point. This can be used with both set and variable latch positioning. The blink animation, speed, and distance settings can all be controlled for each individual rail-system cap. The player may also use this method to transition between separate primary rail-systems.
