Core Concepts Executables

🧠 KLEP Executables: The Action Units of the System

In KLEP, executables are the building blocks of behavior. They are active components that drive the system forward, interacting with keys and locks to produce meaningful actions. Executables can be sensors, actions, routers, or goals, each serving a unique role in KLEP's architecture.

---

🔍 What Are Executables in KLEP?

An executable in KLEP is a modular component that performs actions when specific conditions are met. While currently implemented as a MonoBehaviour in Unity, the design philosophy of KLEP is framework-agnostic, allowing for portability to other environments, including embedded systems and microcontrollers (MCUs).

🧠 Why Use MonoBehaviour in Unity?

• Unity Integration: By inheriting from MonoBehaviour, executables can leverage Unity's update cycles, event systems, and editor tools.
• Object-Oriented Design: Treating behaviors as objects allows for dynamic assignment, easy debugging, and visual management in Unity's Inspector.

---

🔍 Looking Ahead: Implementing KLEP on Embedded Systems

• The current KLEPExecutableBase serves as a prototype for a more abstract design, where executables could be simple structs or function pointers in lower-level languages.
• By abstracting core methods (Init, Execute, Cleanup), KLEP could be adapted to run on MCUs, like Atmel or ESP32, for hardware-based AI systems.
• This could enable tiny AI agents on IoT devices, robots, or custom hardware, providing reactive behaviors without needing a high-level game engine.

---

💡 Example Use Case:

• A Unity-based game might use MonoBehaviour executables to control NPCs, while a microcontroller could use a stripped-down version of KLEP to control physical actuators or manage stateful behaviors in a robotic system.

🔑 Four Types of Executables:

1. Sensors:

   • Generate keys based on input from the world.
   • Examples: Detecting an enemy, sensing a door state, listening for a player input.

2. Actions:

   • Modify the world based on available keys.
   • Examples: Opening a door, moving a character, triggering an animation.

3. Routers:

   • Convert keys or key data into other keys or key data.
   • Examples: Transforming a detection key into an attack key, adjusting key properties based on environmental conditions.

4. Goals:

   • Organize other executables into logical sequences.
   • Can manage sub-goals, creating hierarchies of behavior.
   • A goal can trigger other goals, enabling complex behaviors like multi-step plans or dynamic prioritization.

---

🚦 Lifecycle of an Executable:

When an executable is added to a neuron, it goes through a specific lifecycle:

1. Initialization:

public virtual void Init() { /* Override for custom initialization */ }

• Called when the executable is added to the neuron.
• Override this method to set up initial values or establish connections.

---

2. Event Registration:

public virtual void RegisterExecutableEvents(SLASHBridge bridge) { }
public virtual void UnregisterExecutableEvents(SLASHBridge bridge) { }

• The SLASHBridge is an event-driven architecture (EDA) used in KLEP.
• Executables can register to listen for or broadcast events, promoting modular and decoupled systems.

---

3. Update and Execution Cycles:

💡 Update Cycles:

public virtual void ExecutableUpdates() { /* Called every Update cycle if part of the neuron */ }
public virtual void ExecutableFixedUpdate() { /* Called every FixedUpdate cycle if part of the neuron */ }

• These methods run every frame (or fixed update) when attached to a neuron, allowing the executable to perform continuous actions, such as tracking an object or polling for input.

---

🚀 Execution Cycles:

public virtual void Execute() { /* Executes if all locks for execution are satisfied */ }
public virtual void FixedExecute() { /* Executes during FixedUpdate if locks are satisfied */ }

• These methods only fire if the executable's locks are satisfied.
• Execution is conditional, allowing fine control over when actions can occur.

---

4. Validation and Execution Control:

🔑 Validation Check (CanValidate):

public virtual bool CanValidate(HashSet<KLEPKey> heldKeys) { }

• Purpose: Determines whether an executable is desirable to fire under the current conditions.
• Method: Evaluates LocksToValidateThisNode to see if all validation conditions are met.
  • Desirability Logic:
    • Example: Reloading a weapon may be desirable if:
      • The ammo is low (AmmoCount_KEY exists and is below a threshold).
      • The agent is in cover (IsInCover_KEY exists).
      • The enemy is not too close (EnemyProximity_KEY does not exist).
  • Outcome: An executable can be valid (i.e., desirable to execute) but still not ready to execute due to physical constraints.

🚦 Execution Check (CanExecute):

public virtual bool CanExecute(HashSet<KLEPKey> heldKeys) { }

• Purpose: Determines whether an executable can physically execute once it is considered valid.
• Method: Evaluates LocksToExecuteThisNode to ensure all execution conditions are satisfied.
  • Feasibility Logic:
    • Example: Reloading a weapon can physically execute if:
      • The ammo is not already full (AmmoCount_KEY is less than max).
      • The player has ammo available (AmmoAvailable_KEY exists and is greater than zero).
  • Outcome: An executable can be valid but not executable, allowing fine-grained control over AI behavior.

💡 Example Scenario: Reloading a Weapon in a Game: 🧠 Validation (Desirability) Check:

- Ammo is low: AmmoCount_KEY < 10.
- Agent is in cover: IsInCover_KEY exists.
- No immediate danger: EnemyProximity_KEY does not exist.

- If all validation conditions are met, reloading becomes desirable.
- The agent will prioritize reloading, but only if execution is possible.

🚦 Execution (Feasibility) Check:

Ammo is not full: AmmoCount_KEY < MaxAmmo_KEY.
Ammo is available: AmmoAvailable_KEY > 0.

If all execution conditions are met, the agent can perform the reload action.
If ammo is already full, the reload action remains desirable but not executable, preventing wasted actions.

✅ Key Takeaways:

Validation (CanValidate): Is it desirable to execute this action?
Execution (CanExecute): Is it physically possible to execute this action?
The two-tier approach allows KLEP agents to make smarter decisions, avoiding unnecessary actions and prioritizing behaviors based on both desirability and feasibility.

---

5. Cleanup:

public virtual void Cleanup() { /* Called when executable is removed from the neuron */ }

• Unlike IsComplete(), Cleanup is for tearing down state when an executable is removed from the neuron, not when it completes its action.
• Use this to unsubscribe from events, clear states, or reset properties.

---

🧠 Key Fields in KLEPExecutableBase:

1. Locks for Validation and Execution:

[SerializeField]    
public List<KLEPLock> LocksToValidateThisNode;      
[SerializeField]
public List<KLEPLock> LocksToExecuteThisNode;  

• Validation locks determine if the executable is valid to fire.
• Execution locks determine if the executable should fire at that specific moment.
• Provides layers of control, allowing complex behavior management.

---

2. In-Tandem Execution:

public bool InTandem = true;

• Controls whether an executable can fire alongside others in the same frame.
• In-tandem executables are always executed if VALID and can EXECUTE, while non-tandem executables are subject to agent selection.
• Useful for background tasks like updating UI elements or checking sensors.

---

💡 Attraction and Decision Making:

public float CalculateAttraction(HashSet<KLEPKey> elements) { }

• Evaluates the attractiveness of an executable by combining its locks' attraction values with matching keys.
• Helps the KLEPAgent prioritize actions, choosing the most attractive option when multiple are valid.

---

✅ Conclusion:

• Executables are the action units of KLEP, handling everything from sensor data collection to executing complex goals.
• Their lifecycle is well-defined, from initialization to cleanup, with built-in support for modular event-driven systems.
• The distinction between validation and execution provides fine-tuned control, enabling adaptive AI behavior without manual intervention.