Thirst System
One of the most common mechanics used to power survival games, thirst requires players to constantly seek out water to avoid eventual death-by-dehydration. Simple, but when implemented in meaningful ways it can have your players scrambling for every drop of water, trying to maintain body temperature to keep their thirst down, and more. Like most always-on mechanics, if implemented poorly it can hurt the gameplay loop considerably.
Setup
Requirements
The thirst system requires the player controller being used to have a C_Manager-Health component attached to it in order to function properly. Optionally, it can also interact with the C_Manager-Stamina component, C_Manager-HUD component and C_Manager-VisualFeedback component. It is also possible to have your player’s thirst level altered based on settings in the C_Manager-BodyTemperature component.
Initial Setup
After adding the C_Manager-Thirst component to your player controller, the component merely needs to be initialized properly. By default, this is all handled automatically in the included SurvivalController blueprint by the Initialize function, which is run on Event BeginPlay.
If attempting to implement the thirst manager in your own controller, you will be required to run the components function called Event Initialize on startup, parsing a reference to the player controller.
If feedback is desired on the HUD UI or vial the visual feedback system, then those respective components must also be attached to the controller and references must be set within the thirst manager. This is also true for the stamina manager if stamina limitation impact is desired upon player dehydration. This is all automatically done via the Initialize function within the thirst manager, assuming the required components are attached to it’s parent controller.
Settings
Setting | Details | Default Value |
---|---|---|
Disable System | This checkbox will disable the thirst system and is useful in testing/debugging scenarios. | False |
Max Player Water | This value determines what the maximum player water value can be. In most cases this should not need to be changed for survival game mechanics. | 100 |
Update Frequency | This value determines how many times, per second, this system updates. Higher values will result in smoother mechanics and nicer visual feedback results, but may impact performance (both locally and networked). | 5 |
Drain Rate | This value determines how much water the player will lose each second. | 0.2 |
Limit Stamina | If enabled, when the player enters dehydration mode (ie. zero water remaining), they will suffer a stamina penalty which will lower their maximum stamina value. | True |
Stamina Reduction | The size of the penalty applied whilst in dehydration mode. | 15.0 |
Dehydration Damage | This value determines how much damage, per second, the player will receive whilst in dehydration mode. | 0.018 |
Low Water Visual Effect | The visual effect (if any) used to indicate to the player low water values. Will come into effect when the player's water crosses the Visual Effect Threshold. | Fringe Intensity |
Visual Effect Threshold | Once the player's water drops below this level, the Low Water Visual Effect (if any is set) will kick in. | 20.0 |
Considerations
Whilst a higher update frequency will result in smoother visuals, both in the visual feedback system and on the HUD, it is important to remember that all of the survival mechanics need to update. In general, the more quickly a stat changes, the more frequently that system should update. Likewise, the systems that are more important to gameplay in your particular game should be given a higher update rate. As an example, usually, survival games have thirst drain a lot faster than hunger. It makes sense, then, to give thirst a higher update frequency than hunger.
Comments
So empty here ... leave a comment!