TOK Lighthouse Battleground (zenflow)#80
Conversation
## PRD Summary The PRD at `.zenflow/tasks/tok-lighthouse-battleground-5045/requirements.md` documents: **Core Problem:** The TOK coordination layer is ~80% complete (strategy, positions, role management, event tracking) but the execution layer is entirely stubbed out — bots never actually pick up orbs, attack enemies, or move to objectives. **6 Requirements identified:** 1. **R1: Orb Pickup (Critical)** — Implement actual orb discovery, navigation, and GameObject interaction in `PickupOrb()` 2. **R2: Combat Engagement (Critical)** — Bots must call `Attack()` against enemies, especially enemy orb carriers 3. **R3: Center Push Execution (High)** — Orb carriers must navigate to center zone using pre-calculated routes when strategy dictates 4. **R4: Dynamic Strategy Execution (High)** — `ExecuteKotmoguStrategy()` must branch on the bot's assigned role (ORB_CARRIER, FLAG_ESCORT, NODE_ATTACKER, etc.) 5. **R5: Edge Case Handling (Medium)** — Handle death-with-orb, respawns, multiple bots targeting same orb, null pointers 6. **R6: Logging & Observability (Medium)** — Detailed logs for manual test validation **Key finding:** The server-side scoring uses 3 concentric area triggers (6/4/2 pts per 5s), not the simplified 2-tier model in the playerbot data file. This is a minor data accuracy issue. **Files to modify:** Primarily `BattlegroundAI.cpp` and `BattlegroundAI.h`. The coordination layer files are reused as-is.
## spec.md Summary The technical specification covers the TOK execution layer implementation across **2 files** (`BattlegroundAI.cpp` and `.h`) with **6 functions** (3 reimplemented stubs + 3 new): **Functions**: | Function | Type | Purpose | |----------|------|---------| | `ExecuteKotmoguStrategy()` | Rewrite | Role-based dispatch (ORB_CARRIER, FLAG_ESCORT, FLAG_HUNTER, NODE_DEFENDER, ROAMER) | | `PickupOrb()` | Rewrite | Find unheld orb, navigate to it, call `go->Use(player)` | | `DefendOrbCarrier()` | Rewrite | Position near friendly carrier, attack threats | | `HuntEnemyOrbCarrier()` | New | Find and attack enemy orb holders | | `EscortOrbCarrier()` | New | Follow carrier in formation, assist combat | | `ExecuteOrbCarrierMovement()` | New | Center push when 2+ orbs held, defensive hold otherwise | **Key design decisions**: - All functions follow existing WSG/AB patterns already proven in the codebase - Uses `GAMEOBJECT_TYPE_FLAGSTAND` + `go->Use(player)` for orb pickup (same as WSG flags) - Leverages spatial query cache (O(cells)) for combat target finding - All coordination data comes from existing APIs (no coordination layer changes needed) - No database changes, no config changes **Delivery in 4 phases**: Orb Pickup → Combat → Escort/Center Push → Polish & Edge Cases
The plan is complete and correctly structured. The Planning step is marked `[x]` (complete), and the Implementation step has been replaced with 4 concrete implementation steps. Here's a summary of the plan: **4 Implementation Steps (mapping to spec's delivery phases):** | Step | Scope | ~Lines | |------|-------|--------| | **Implement PickupOrb + basic dispatch** | `PickupOrb()` full impl, `ExecuteKotmoguStrategy()` role-based dispatch, header declarations, temporary stubs for 3 new functions | ~150 | | **Implement HuntEnemyOrbCarrier + DefendOrbCarrier** | Combat engagement: enemy carrier hunting with priority targeting, friendly carrier defense with spatial cache | ~150 | | **Implement EscortOrbCarrier + ExecuteOrbCarrierMovement** | Escort formations, center push logic with route navigation, defensive hold, ROAMER role completion | ~180 | | **Polish, edge cases, build verification** | Null safety audit, edge case handling, logging completeness, HEALER_SUPPORT role, code style, final build | ~50 | **Key design decisions:** - Each step is independently buildable (stubs for not-yet-implemented functions) - All implementations follow existing WSG/AB patterns (PickupFlag, ExecuteEscortBehavior, ExecuteDefenderBehavior, etc.) - Only 2 files modified: `BattlegroundAI.cpp` and `BattlegroundAI.h` - All coordination layer APIs already exist — the work is purely execution layer - Verification at each step is "build compiles clean" since there are no automated unit tests for BattlegroundAI
Implement all 6 TOK functions with full orb interaction, role-based strategy dispatch, combat engagement, escort formations, carrier movement with center push logic, and survival retreat behavior. Includes comprehensive null safety, edge case handling, and logging. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
…fKotmoguScript Establish the lighthouse pattern by moving all TOK-specific runtime behavior (orb pickup, escort, carrier movement, hunting, defense) from the generic BattlegroundAI class into TempleOfKotmoguScript. BattlegroundAI now acts as a thin delegation wrapper via the new IBGScript::ExecuteStrategy() virtual method. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
Summary of ChangesHello @agatho, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the Playerbot module by fully implementing the execution layer for Temple of Kotmogu battleground bots. The primary goal was to make TOK the first battleground with 100% correct and dynamic bot behavior, serving as a 'lighthouse' or blueprint for future battleground implementations. The changes involve detailed logic for orb interaction, combat, movement, and strategic decision-making, all while adhering to a new architectural pattern that promotes reusability and maintainability across the Playerbot system. Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a significant and well-executed refactoring of the Temple of Kotmogu bot AI. The "lighthouse pattern" of moving battleground-specific logic into the IBGScript implementation is an excellent architectural improvement that will greatly simplify the implementation of other battlegrounds. The implementation of the TOK strategy is robust, featuring thoughtful bot behaviors like survival instincts and intelligent target prioritization. The code is clean, well-commented, and includes extensive logging. I have a couple of suggestions for minor improvements regarding code duplication and encapsulation, but overall, this is a very high-quality contribution.
| if (coordinator) | ||
| { | ||
| auto nearbyEnemies = coordinator->QueryNearbyEnemies( | ||
| friendlyCarrier->GetPosition(), TOK_DEFENSE_ESCORT_RANGE); | ||
|
|
||
| ::Player* closestThreat = nullptr; | ||
| float closestThreatDist = TOK_DEFENSE_ESCORT_RANGE + 1.0f; | ||
|
|
||
| for (auto const* snapshot : nearbyEnemies) | ||
| { | ||
| if (!snapshot || !snapshot->isAlive) | ||
| continue; | ||
|
|
||
| ::Player* enemy = ObjectAccessor::FindPlayer(snapshot->guid); | ||
| if (!enemy || !enemy->IsAlive()) | ||
| continue; | ||
|
|
||
| float dist = player->GetExactDist(enemy); | ||
| if (dist < closestThreatDist) | ||
| { | ||
| closestThreatDist = dist; | ||
| closestThreat = enemy; | ||
| } | ||
| } | ||
|
|
||
| if (closestThreat) | ||
| { | ||
| player->SetSelection(closestThreat->GetGUID()); | ||
| if (closestThreatDist > 5.0f) | ||
| BotMovementUtil::ChaseTarget(player, closestThreat, 5.0f); | ||
|
|
||
| TC_LOG_DEBUG("playerbots.bg", "[TOK] {} engaging threat {} near carrier (dist: {:.1f})", | ||
| player->GetName(), closestThreat->GetName(), closestThreatDist); | ||
| return true; | ||
| } | ||
| } | ||
| else | ||
| { | ||
| // Fallback: legacy O(n) enemy search near carrier | ||
| std::list<Player*> nearbyPlayers; | ||
| friendlyCarrier->GetPlayerListInGrid(nearbyPlayers, TOK_DEFENSE_ESCORT_RANGE); | ||
|
|
||
| ::Player* closestThreat = nullptr; | ||
| float closestThreatDist = TOK_DEFENSE_ESCORT_RANGE + 1.0f; | ||
|
|
||
| for (::Player* nearby : nearbyPlayers) | ||
| { | ||
| if (!nearby || !nearby->IsAlive() || !nearby->IsHostileTo(player)) | ||
| continue; | ||
| float dist = player->GetExactDist(nearby); | ||
| if (dist < closestThreatDist) | ||
| { | ||
| closestThreatDist = dist; | ||
| closestThreat = nearby; | ||
| } | ||
| } | ||
|
|
||
| if (closestThreat) | ||
| { | ||
| player->SetSelection(closestThreat->GetGUID()); | ||
| if (closestThreatDist > 5.0f) | ||
| BotMovementUtil::ChaseTarget(player, closestThreat, 5.0f); | ||
|
|
||
| TC_LOG_DEBUG("playerbots.bg", "[TOK] {} engaging threat {} near carrier (legacy, dist: {:.1f})", | ||
| player->GetName(), closestThreat->GetName(), closestThreatDist); | ||
| return true; | ||
| } | ||
| } |
There was a problem hiding this comment.
The logic for finding and engaging the nearest threat is duplicated across DefendOrbCarrier, HuntEnemyOrbCarrier, and EscortOrbCarrier. Each of these functions contains a version that uses the coordinator's spatial cache and a fallback version that performs a grid search. This repeated pattern could be refactored into a single helper function to improve maintainability and reduce code duplication.
Consider introducing a new static helper function, for example:
static ::Player* FindAndEngageNearestThreat(::Player* bot, Position const& searchPos, float searchRadius, ::Playerbot::BattlegroundCoordinator* coordinator)
{
// Combined implementation with coordinator and fallback logic
}This function would encapsulate the logic for finding the nearest enemy and initiating an attack (SetSelection and ChaseTarget), returning the target if found. The calling functions could then simply invoke this helper, making the code cleaner and easier to maintain.
| float GetOrbToCenterDistance(uint32 orbId) const; | ||
|
|
||
| /// Get orb position (uses dynamic discovery if available, falls back to hardcoded) | ||
| Position GetDynamicOrbPosition(uint32 orbId) const; |
There was a problem hiding this comment.
This function was moved from the private section to the public section. However, it appears to only be used by PickupOrb, which is a private method within this class. To maintain proper encapsulation and a clean public API, GetDynamicOrbPosition should be moved back to the private section of the class.
Documentation Validation Results
For detailed results, check the workflow artifacts. |
1 participant
Zenflow Workflow: TOK Lighthouse Battleground
Complete workflow configuration for Temple of Kotmogu - 100% correct & fully dynamic
Workflow Metadata
Workflow Name:
TOK Lighthouse BattlegroundDescription: Make Temple of Kotmogu the first 100% correct, fully dynamic battleground. This will serve as the template/blueprint for all 13 other battlegrounds.
Branch Prefix:
lighthouse-bg/tok/Project: TrinityCore Playerbot
Agent: Claude Code (for all automated stages)
Stage 1: Research TOK Data
Stage Name:
Research TOK Data (DBC/DB2/SQL)Agent: Claude Code
Depends On: None (first stage)
Instructions:
Stage 2: Create Perfect Specification
Stage Name:
Create TOK Perfect SpecAgent: Claude Code
Depends On: Stage 1 ✓
Instructions:
Stage 3: Fix GameObject & Combat
Stage Name:
Fix Orb Pickup & Combat EngagementAgent: Claude Code
Depends On: Stage 2 ✓
Instructions:
Stage 4: Implement Dynamic Strategy
Stage Name:
Implement Dynamic Tactics & StrategyAgent: Claude Code
Depends On: Stage 3 ✓
Instructions:
Stage 5A: Build Verification & Test Prep
Stage Name:
Build & Prepare TestsAgent: Claude Code
Depends On: Stage 4 ✓
Instructions:
Stage 5B: MANUAL TESTING PAUSE
Stage Name:
⏸️ PAUSE: User Manual TestingAgent: None (Human Task)
Depends On: Stage 5A ✓
Type: Manual Pause Point
Instructions:
Stage 5C: Log Analysis & Validation
Stage Name:
Analyze Test Results & ValidateAgent: Claude Code
Depends On: Stage 5B ✓
Instructions:
Stage 6: Create Transfer Blueprint
Stage Name:
Create Transfer Blueprint for All BGsAgent: Claude Code
Depends On: Stage 5C ✓ (PASS status required)
Instructions:
Workflow Settings
If Zenflow allows these configurations:
✅ Branch Strategy: Create branch per stage
lighthouse-bg/tok/stage-{N}-{stage-name}✅ Shared Memory: Obsidian Vault
C:\TrinityBots\PlayerBotProjectMemory\TrinityCore-Playerbot-Memory✅ Parallelization: Sequential (not parallel)
✅ Auto-commit: After each stage
[Zenflow] Stage {N}: {stage-name} - {brief summary}✅ Failure Handling:
✅ Notifications:
Expected Timeline
Total Automated Time: ~6-8 hours
Total Manual Time: ~30-60 minutes (your testing)
Total Workflow Time: ~7-9 hours
Workflow Success Criteria
To consider the workflow successful:
Result: Temple of Kotmogu is production-ready and serves as the blueprint for all other battlegrounds.
End of Workflow Definition