044 | State - Part 2: Create State System

[Pedrohamoura-Git]

Information

Describe What Was Done

• Create State System responsible for processing and defining the character's state every frame.
• Create a Dead Handler responsible for defining the correct dead state.

---

Detailed Summary (AI Generated)

🤖| Summary

This PR introduces a new StateSystem in the game's ECS architecture to manage player state transitions and integrates it into the MatchScene. It also includes supporting handlers and types for managing state logic.

New System: StateSystem

• Implemented a new StateSystem in the file StateSystem.ts. Key functionalities include:
  • Validating and processing entity states (e.g., handling ALIVE_STATE).
  • Delegating dead-state handling to a dedicated DeadHandler.
  • Supporting checks for whether a player entity is alive via the isPlayerAlive method.

New Dead Handler

• Added a DeadHandler in handlers/dead/DeadHandler.ts to manage actions when the player's state is dead:
  • Resolves player state based on ALIVE_STATE values (e.g., DEAD, DEAD_NO_HEAD).
  • Updates player state attributes like inputAction and characterState.

Integration with MatchScene

• Updated MatchScene.ts to integrate the new StateSystem:
  • Instantiated StateSystem in initializeSystems.
  • Added stateSystem.update to the update lifecycle, enabling player state updates.

New Supporting Files

• Created new helper modules and type definitions:
  • state/types.p.ts: Defines types for StateSystem and its properties.
  • handlers/dead/types.p.ts: Defines type for DeadHandler properties.
  • handlers/dead/index.ts: Exports DeadHandler.
  • state/index.ts: Exports StateSystem.

Index Export Updates

• Updated index.ts within the ecs/systems directory to export the new StateSystem.

---

Evidence

⏪️ | Before - No death animation to show

⏩ | After

Gravacao.de.Tela.2026-03-10.212655.mp4

---

Rollback Plan

Revert from the branch.

---

↗️ | Click to See The Preview

[anatfernandes]

Suggested change

	constructor() {

Since the scene is not used within this System, I believe it's best to remove it from both the parameters and the validation. This keeps the code clean and avoids unnecessary dependencies.

[anatfernandes]

Suggested change

	if (!(entities instanceof Map)) {
	throw new Error(`Entities is not a Map: ${typeof entities}`);
	}

I don't believe adding this validation is necessary, as the system's typing ensure the entities is always valid

[anatfernandes]

Suggested change

	if (!state || !input || !animation || !sprite?.body) return;
	if (!state) return;

As Copilot pointed out, the system only depends on the state. Requiring additional fields would unnecessarily exclude simpler entities that might not need those extra components.

[anatfernandes]

Suggested change

	this.movementSystem = new MovementSystem();
	this.stateSystem = new StateSystem({ scene: this });

[anatfernandes]

Wouldn't it be better to call the StateSystem after applying velocity? This ensures the entity's state (like “walking”) is immediately consistent with its movement intent. Running it in this order avoids a one-frame lag between the actual movement and the visual state update.