Life Counter Reset After Correct Answers
Explains how to reproduce, fix, and test a timed puzzle defect where correct answers incorrectly reset the life counter to full.
Overview
This article explains a scoring defect in timed puzzle modes where the life counter resets to its full value after a player submits a correct answer. The defect makes it impossible for a player to fail a session, because every correct solve restores lives that were previously lost.
Who should read
This article is relevant to:
What you will learn
After reading, you will understand:
- Product engineers and developers who own the puzzle or quiz scoring logic
- QA engineers writing test cases for timed game modes
- Operations or support staff who need to identify whether a reported issue matches this defect
- How the life counter is expected to behave
- Which conditions cause the reset
- How to reproduce and confirm the defect
- What the corrected behavior should be
Key concepts
Life counter
The life counter tracks how many incorrect attempts a player has remaining in a timed puzzle mode. Each incorrect answer decrements the counter. When the counter reaches zero, the session ends in failure.
Score state
Score state refers to the stored value of the life counter at any point during a session. The state changes only in response to specific events:
Score state
- An incorrect answer reduces the counter.
- A correct answer completes the current puzzle and advances the game.
- A correct answer does not change the life counter.
The defect
Expected behavior
| Event | Life counter effect |
|---|---|
| Correct answer | No change |
| Incorrect answer | Decrement by one |
| Life counter reaches zero | Session ends in failure |
A correct answer must never:
- Increase the life counter
- Reset the life counter to its full value
- Interact with the life counter in any way
The only event that modifies the life counter is an incorrect answer (or a session reset initiated by the player or system).
Defect behavior
When the defect is present:
| Event | Life counter effect (defective) |
|---|---|
| Correct answer | Reset to full value |
| Incorrect answer | Decrement by one |
This makes the timed mode effectively unlosable for any player who can answer at least one puzzle correctly between mistakes.
Root cause
The defect originates in the answer evaluation handler. When a correct answer is submitted, the handler contains a reset branch that restores the life counter to its initial value. This branch is either:
- Explicitly present in the correct-answer path, or
- Shared between the correct-answer path and the session-reset path
The most common cause is a shared code path. If the same function that resets lives on a new session is also invoked when a correct answer is processed, the reset occurs on every successful solve.
Reproduction
Prerequisites
To reproduce the defect, you need:
- A running instance of the timed puzzle mode
- A player account that can start a session
- Two or more puzzles available in the session
Steps to reproduce
-
1
Run reproduction
Start a new timed puzzle session.
Confirm the life counter shows its full value.
Submit an incorrect answer.
Confirm the life counter decrements by one and is no longer full.
Submit a correct answer on the next puzzle.
Check the life counter. -
2
Confirm repeatability
Repeat steps 3 through 6 to confirm the reset occurs on every correct answer, not only on the first one.
Expected result: The life counter remains at the reduced value from step 4.
Defective result: The life counter returns to its full value.
Verifying the fix
After a fix has been applied, rerun the reproduction steps. The correct behavior is:
- Start a new timed puzzle session.
- Confirm the life counter shows its full value.
- Submit an incorrect answer.
- Confirm the life counter decrements by one.
- Submit a correct answer on the next puzzle.
- Confirm the life counter is unchanged from step 4.
Additionally, verify these edge cases:
- Answer correctly multiple times in a row. The life counter must not increase at any point.
- Lose all lives without a correct answer in between. The session must end in failure as expected.
- Lose one life, answer correctly, then lose another life. The counter should decrease from the original value to zero across the two failures, unaffected by the correct answer.
Implementing the fix
-
1
Locate handler
Find the code that processes a submitted answer and determines whether it is correct or incorrect. This is typically in the scoring or game-state service.
-
2
Remove reset
Inspect the correct-answer path. If it contains any call that resets or restores the life counter, remove it. The correct-answer path should contain no life counter logic at all.
-
3
Verify shared path
Confirm that the session-reset function is not called from the correct-answer handler. If the correct-answer path and the session-start path share a common helper that resets lives, separate them so that only session initialization calls the reset.
-
4
Add regression test
Add a test that exercises the reproduction steps above. The test should assert that the life counter is unchanged after a correct answer.
Step 2 — Remove the reset from the correct-answer branch
A concise required fix might look like:
function handleAnswer(state, isCorrect) {
if (isCorrect) {
// Advance to the next puzzle.
// Do NOT modify the life counter here.
return advancePuzzle(state);
}
// Decrement lives only on incorrect answers.
state.lives -= 1;
if (state.lives <= 0) {
return endSession(state, "failed");
}
return state;
}
Step 4 — Add a regression test
An illustrative test:
test("correct answer does not restore lives", () => {
let state = startSession({ lives: 3 });
state = handleAnswer(state, false); // incorrect
expect(state.lives).toBe(2);
state = handleAnswer(state, true); // correct
expect(state.lives).toBe(2); // must remain 2, not reset to 3
});
Troubleshooting
The life counter still resets after the fix
Likely cause: The reset is being invoked from a shared code path that was not fully separated. Another handler may also be restoring lives on puzzle advance.
Check: Search the codebase for all references to the life counter reset value or the initial life count constant. Confirm each reference is only reachable from session initialization and not from the correct-answer path.
Resolution: Trace the call stack from handleAnswer when a correct answer is submitted. Identify every function invoked and confirm none of them touches the life counter.
The life counter increases by a partial amount
Likely cause: A different bug where lives are added rather than reset. This is a separate defect from the full reset described in this article.
Check: Inspect whether the life counter is modified anywhere other than the incorrect-answer branch. Look for increment operations or restore operations that add a fixed number of lives.
Resolution: Do not treat this as the same defect. Follow the same diagnostic approach — identify every call site that modifies the life counter — and confirm which events should and should not affect it.
The session never ends in failure, even with no correct answers
Likely cause: The failure condition is evaluated only after the puzzle is answered, and the life counter may be checked before it is decremented, or the zero check is comparing against the wrong boundary.
Check: Verify that the failure branch is reached when lives reach zero on an incorrect answer.
Resolution: Confirm the ordering:
state.lives -= 1;
if (state.lives <= 0) {
return endSession(state, "failed");
}
If the check happens before the decrement, the session may fail one life too early or never fail at all, depending on how the boundary is compared.
Scope and limitations
This article covers the specific defect where a correct answer resets the life counter to its full value in a timed puzzle mode. It does not cover:
- Life increment mechanics in non-timed or practice modes, which may intentionally behave differently
- Purchase, reward, or bonus life systems that legitimately add lives
- Session restart or retry mechanics that reset lives by design
If your mode intentionally restores lives through another mechanism — such as a consumable item or a time-based regeneration — confirm that the mechanism is only triggered by its intended event and not by correct answers.
Related
- Game state and session lifecycle for timed puzzle modes
- Test coverage for scoring and failure conditions
- Debugging shared code paths that mutate session state
Was this article helpful? Thanks for your feedback.
Ready to build your first automation?
Get started with Octacer and transform how your team works.
Schedule Consultation