Survival games can come in a large variety of themes, settings and time periods. Many of them, however, include items such as flashlights, generators, and such that require a power source. The MSGT gives player’s a portable power supply, that can be rigged up to be battery based and even rechargeable, depending on the designers wishes.
There are no special requirements necessary to consider for implementing the power system. Optionally, it can interact with the C_Manager-HUD component.
After adding the C_Manager-Power 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 power 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, then the player controller must have a C_Manager-HUD component attached and references must be set within the power manager. This is all automatically done with the Initialize function within the power manager if the components are attached to the controller.
|Number of Segments||This setting determines how many segments your player's power is broken up into. This, in effect, works like battery cells. If the setting is set to 5, then the player's power bar will be displayed with 5 distinct sections. If a recovery rate is set higher than 0, then the player's power will only ever recharge for that segment, and a fully drained segment will remain fully drained until a power recovery item is used.||5|
|Max Player Power||This defines the maximum amount of power that the player can have stored.||100.0|
|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).||20|
|Recovery Delay||This value, expressed as a number of seconds, determines how long a player must not be using power for before it will begin to recharge.||2|
|Recovery Rate||This value determins how much power, per second, the player will recover when not using power.||5.0|
Unlike many of the other survival systems in the template, which are passive systems, the power system is an active system, meaning that it only activates when the player does something, such as using a specific item or turning on a certain device. By default, both weapons and tools are set up with options to drain power on each use, and the included flashlight system also drains power whilst it is on (unless set to not do this). In some situation, it may be desired to call the power drain and recovery functions outside of these examples.
In order to add a power drain (ie. increase the amount that the player’s power is lowered every second), the function SetDecay, within the power manager, is used, with the amount wished to increase drain by input to the NewAmount float input. Similarly, to lower the player drain, this same SetDecay function is used, with a negative value connected to the NewAmount float input. Examples of this are pictured below. These examples are written within the SurvivalController in this case, and if you wish to call them from a location external to the controller, you will need to reference the controller in order to reference the power manager.
Other use cases might be singular consumption events, where an item is used and immediately consumes a portion of power. This can be achieved using the ConsumePower event, and power can be added back to the player using the AddPower event. Again, these examples are written within the SurvivalController in this case, and if you wish to call them from a location external to the controller, you will need to reference the controller in order to reference the power manager.
As power is a system that is only active when players are draining it, or during it’s recharge state, if your drain and/or recovery rates are quite swift, then it is recommended to have this system as one of the systems with a higher update frequency, as lower rates may result in slower or inconsistent feedback to your players and a less visually cohesive experience.