Hi everyone,
I’m making a mobile game (Android, Construct 3) and I want to implement a life/energy system that regenerates over time. I need advice on a proper design, especially considering that the player can change the device time.
What I already have and how it works now
I have “life packs” (energy).
For example, a maximum of 5 packs.
1 pack = 3 HP in a level.
As long as there is at least 1 pack:
the player can enter a level;
inside the level they have 3 HP (hearts). On HP loss I already:
handle respawn at checkpoints,
or full level restart (if there is no checkpoint).
When the player completely fails the level (i.e. spends all 3 HP):
1 pack is consumed;
if there is still ≥ 1 pack left → the player can play again (or respawn from a checkpoint – this is already implemented);
if packs reach 0 → the player cannot play anymore, level buttons are blocked.
Already implemented:
Global variables lifePacks and MAX_LIFE (e.g. 5),
Consuming packs on death (both with and without checkpoint),
Blocking level entry when lifePacks = 0,
Saving lifePacks to LocalStorage,
Test buttons/keys to increase/decrease packs (+ / -) to debug the mechanic.
What I want to add
Time-based regeneration of packs:
If lifePacks = 0, then every N minutes (for example, every 10 minutes) it should:
restore +1 pack,
until it reaches the maximum (MAX_LIFE, e.g. 5).
Optionally, regeneration could happen as long as lifePacks < MAX_LIFE, not only at 0 – the main idea is the time-based energy system.
Time should pass even when the game is closed:
Time must continue even if the game is not running.
Example: the player spends all packs, closes the game for 30 minutes, then opens it again:
the game should detect that 30 minutes have passed,
and grant, say, 3 packs (if 1 pack = 10 minutes).
All this must persist between sessions:
On game startup I need to read:
how many packs are left (lifePacks),
when the next pack should be restored (or when the last pack was consumed),
and recalculate the current state based on the elapsed time.
Main requirement — protection against device time change
I don’t want the player to:
set the device clock forward,
launch the game,
and instantly get a full pack of lives.
So:
I cannot rely only on Date.now() / device time.
I want to validate against server/network time:
either via some public time API (HTTP request),
or via my own backend (Firebase, PlayFab, my own API, etc.).
I’m interested in:
What scheme is considered more or less standard for this?
Store the time of the last life consumption,
or the time of the next restoration (nextLifeTime),
or a queue of timestamps (if several packs are consumed in a row)?
On app startup, how do you correctly calculate how many packs to restore:
based on server time,
respecting the maximum (MAX_LIFE),
and behaving predictably when the server is temporarily unavailable (e.g. temporarily trusting local time with extra checks)?
Technical context
Engine: Construct 3.
Platform: Android (mobile game).
Already using:
LocalStorage to save lifePacks,
Browser.ExecJS("Date.now()") to get time (currently only for testing),
global variables and Functions for life logic.
Questions
What time-based life regeneration scheme would you recommend?
What exactly should be stored: time of last consumption, time of next pack, number of “pending” packs, etc.?
At what moment do you start the timer – on the first pack spent from full, on each consumption, or something else?
What’s a good way to rely on server time in a mobile HTML5 / Construct 3 game?
Are there convenient ways to get a “trusted” time (via HTTP request to a time server or some external service)?
Has anyone done this via Firebase / PlayFab / a custom API?
Are there any ready-made plugins/extensions for Construct 3 for this mechanic?
Something like an “energy / lives system” or “server time / NTP time”, so I don’t have to reinvent the wheel.
Maybe there is an addon that already implements a time-based lives/energy system, ideally using some kind of server time?
I’d really appreciate any examples, links to plugins, code snippets, or just a description of your approach.