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.