1. The Passive Event Processor (The Heartbeat)

In a web-based strategy game, the server doesn't run a continuous loop in the background (which would destroy CPU resources). Instead, it uses Passive Event Processing or Lazy Evaluation.

• Trigger: The logic only "wakes up" when a player interacts with the site (loads a page).
  
• The Fleet Loop: The processFleets() function scans the fleet_events table for any mission where the $arrival\_time \le NOW()$.
  
• Chronological Integrity: If multiple events happened while you were offline, the engine processes them one by one in the exact order they were supposed to occur. This ensures that if a player was attacked twice, the second attack calculates based on the remaining resources left by the first one.
  

2. The Attrition-Based Combat Logic
Your combat system isn't a simple "Who has the bigger number wins" mechanic. It uses an Attrition Model with a randomness factor.
The Power Formula:
Each ship's base power is derived from its structural integrity (total cost).
$$Power = \frac{Metal + Crystal}{1000} \times \left(1 + \frac{VIP\_Bonus}{100}\right)$$
The Combat Roll:
To prevent "perfect" predictions, the engine calculates a "Roll" for both sides:
$$Roll = Power \times \frac{rand(90, 110)}{100}$$
Loss Calculations:
Even the winner takes damage. This simulates a real battle where defenders fire back before being overwhelmed.

• Winner: Takes a percentage of losses based on the ratio of the defender's strength.
  
• Loser: Loses 100% of the fleet involved in the battle (unless a retreat mechanic is added).
  

3. Espionage: The Threshold Algorithm
The spying logic is a Differential Threshold System. It compares the attacker's Espionage Technology against the defender's level ($Diff = Attacker\_Tech - Defender\_Tech$).

The Counter-Espionage Risk:
The chance of your probes being detected and destroyed is calculated as:
$$Detection\% = (Def\_Tech - Att\_Tech) \times 10 + (Probes \times 2)$$
This forces a tactical choice: Send more probes for better info but risk losing them all.



4. Logistics: Priority-Based Looting
When a fleet wins an attack, it doesn't just grab everything at once. It follows a Priority Fill Algorithm based on the total cargo_capacity of the surviving fleet.

1. Metal First: Being the heaviest and most common, the cargo holds fill with Metal first (up to 50% of the planet's stock).
   
2. Crystal Second: If there is remaining room, the fleet takes Crystal.
   
3. Deuterium Last: As the rarest fuel, it is prioritized last in the standard looting sequence.
   

This makes Cargo Ships the "unsung heroes" of the game. Without them, your Combat Ships (which have low capacity) can win the battle but will return home empty-handed.



5. Architectural Performance
By refactoring the code into separate files (core/, views/, actions/), you have transitioned from a Monolithic Script to a Modular Engine.

• Memory Management: By using require_once, the PHP interpreter only loads the combat logic when it is actually needed (e.g., during a fleet event), rather than every time someone views the Shop or Overview.
  
• Database Scalability: Your use of Prepared Statements allows the SQL server to cache query plans. This significantly reduces the time it takes to process 100+ fleet movements simultaneously.
  
• Decoupled Frontend: Moving CSS and JS to the public/ folder allows the browser to cache those files. This means your server only sends raw data (JSON/HTML), which is much lighter than sending the styles every single time.