I Prompted Meta Muse Spark 1.3 to Build an AI Bot Arena Shooter — Real A* Pathfinding and Cover AI in 736 Lines

I gave Meta's flagship model Muse Spark 1.3 our spatial intelligence benchmark: build a complete 3D top-down arena shooter with AI-controlled bot opponents in a single HTML file, featuring cover obstacles, line-of-sight raycasts, and differentiated bot behavior profiles.

Running in xhigh reasoning mode, Muse Spark 1.3 delivered 736 lines of clean, self-contained Three.js code (37.0 KB). On round one, the bots navigated obstacles smoothly using an actual 42×42 cell A* search grid, but a logic disconnect prevented the enemies from pulling the trigger on the player. When prompted to fix the firing routine, resolve edge-case obstacle snagging, and add difficulty tiers, the model produced Bot Arena—a genuinely tactical top-down shooter where bots dynamically calculate raycasted shadow zones to duck behind walls when their HP drops.

What I asked for

I ran the standard Test 5 prompt from our hands-on benchmark suite:

You are an expert Three.js game developer.
Create a complete 3D top-down arena shooter with AI-controlled bot opponents in ONE SINGLE HTML FILE.
IMPORTANT:

Output ONLY one file: index.html
All HTML, CSS, and JavaScript in this single file, no external assets, no frameworks.
Use Three.js from CDN.
Must run by double-clicking index.html.
ARENA:

A bounded 3D arena with at least 4-5 pieces of cover (walls/obstacles) the player and bots can hide behind and shoot around.
Top-down or isometric camera.
PLAYER:

WASD movement, mouse-aim, click to shoot projectiles.
Health bar and a visible ammo/cooldown indicator.
BOT AI (this is the core test):

At least 3 bot opponents with basic AI: they must path toward the player around obstacles (not walk through walls), take cover when low on health, and shoot back when in line of sight.
Bots should not all behave identically — vary at least one behavior parameter (aggression, accuracy, or reaction delay) between them.
Round ends when all bots are defeated or the player dies, with a "Play Again" button.
Report specifically on bot pathfinding quality: do they get stuck on obstacles, path realistically, or just beeline through walls?

Round one: smooth movement, pacifist bots

On the initial generation, the visual presentation was sharp: an illuminated dark-blue sci-fi arena with glowing cyan barrier pillars, casting directional shadows, and smooth mouse-aimed crosshairs. The bots used real grid search to route around pillars instead of clipping through geometry.

However, the bot weapon controller had a state bug: while the bots tracked the player and oriented their weapon barrels, their weapon cooldown timer never triggered projectile spawning. The player could casually walk up to all three bots and pick them off without receiving incoming fire.

Initial Test Pass: Bots Navigating Obstacles but Failing to Fire Projectiles

Round two: the prompt fix

I supplied the exact feedback:

ask to add difficult level also why enemy not shooting player fix that also i saw bot stuck sometime check optimize it

Muse Spark 1.3 rewrote the bot state machine. It connected line-of-sight raycasts directly to weapon projectile dispatch, added string-pulling path smoothing to prevent bots from snagging on obstacle corners, and built three full difficulty levels (Easy, Normal, and Hard). On Hard difficulty, the model even dynamically spawns a 4th hyper-aggressive bot named Viper.

This is Meta Muse Spark 1.3's post-fix output. Click Start Game to begin. Move with WASD, aim with your mouse, hold left-click for auto-fire, and press R to reload.

True A* Grid Search with String-Pulling Smoothing

Most LLM coding tests attempt "pathfinding" using naive vector math: bot.pos += (player.pos - bot.pos) * speed. The moment an obstacle appears between them, the bot gets permanently stuck against the wall.

Muse Spark 1.3 went significantly deeper. It subdivided the arena into a 42×42 cell binary collision grid (GRIDN = 42, CELL = 1) and executed a complete 8-directional A* search (findPath()) with diagonal corner-cutting prevention:

// no corner cutting across diagonal obstacles
if (d >= 4) {
  if (blockedGrid[cz * GRIDN + nx] || blockedGrid[nz * GRIDN + cx]) continue;
}

After extracting the cell path, it ran a string-pulling raycast pass (hasLOS) that collapses zigzagging waypoint paths into direct lines when intermediate sightlines are clear.

Combat Action in Normal Mode: Orange Heavy Bot Firing Projectiles as Player Takes Cover

Tactical Cover Behavior: Raycasted Shadowing

The most impressive subsystem is findCoverPoint(). When a bot's health drops below 35%, its state machine shifts from attack to flee_cover.

Rather than running in random directions, the algorithm evaluates candidates positioned 2.2 units behind each of the six 3D obstacle pillars:

// Good cover = candidate spot where player CANNOT see the bot
var blocked = !hasLOS(px, pz, c.x, c.z);
var dBot = Math.hypot(c.x - botX, c.z - botZ);
var score = dBot + (blocked ? 0 : 25);

Wounded bots actively peel off combat, dash behind the nearest pillar that blocks the player's direct line of sight, and crouch behind it until their attack timer resets.

4 Distinct Bot Personalities and Difficulty Scaling

The prompt asked for bots that don't behave identically. Muse Spark 1.3 defined four distinct bot classes with varied attributes:

• Ranger (Red): Sniper profile. High aggression (0.95), pinpoint accuracy (0.05 spread), rapid reaction time (0.35s), 100 HP.
• Heavy (Orange): Frontline juggernaut. 150 HP, slower movement (4.3 units/s), wide spread (0.16), and heavy 16-damage projectile blasts.
• Ghost (Yellow): Hit-and-run skirmisher. Fast (6.6 units/s), low health (80 HP), prefers closer ranges (7 units), and prioritizes cover breaks.
• Viper (Purple): Unlocked exclusively on Hard mode. Ultra-fast (7.0 units/s), hyper-aggressive (1.0), and attacks with relentless flanking.

Pressing 1, 2, or 3 toggles difficulty on the fly, dynamically modulating bot reaction latencies, projectile dispersion, and damage multipliers.

What Impressed Me

1. Genuinely Competent AI Math: Implementing a full A* search with 8-direction cost checks, occupancy grid quantization, and line-of-sight string-pulling in a single HTML file without relying on external pathfinding libraries is exceptional.
2. Dynamic Tactical Awareness: Bots do not blindly charge. When you break line of sight, they navigate around the corner. When they take damage, they retreat behind obstacles.
3. Audio-Visual Feedback: Muzzle flashes, projectile trails, blood splatter particles, ammo counter bars, and red screen vignettes upon taking damage make the game feel like a polished arcade prototype.

What Needs Work

• First-Pass Weapon Binding: The round-one pacifist bot bug—where pathfinding worked but weapon triggers didn't dispatch—shows that models need to verify complete input-to-output event chains before finalizing one-shot code.
• Bot-on-Bot Flocking: While bots avoid arena walls and the player, bots occasionally overlap each other when converging through narrow choke points.

Honest Assessment

Try It Yourself

You are an expert Three.js game developer.
Create a complete 3D top-down arena shooter with AI-controlled bot opponents in ONE SINGLE HTML FILE.
IMPORTANT:

Output ONLY one file: index.html
All HTML, CSS, and JavaScript in this single file, no external assets, no frameworks.
Use Three.js from CDN (https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js).
Must run by double-clicking index.html.
ARENA:

Bounded 3D arena with 5-6 obstacle pillars providing cover.
Top-down camera with mouse-aim crosshair.
PLAYER & COMBAT:

WASD movement, click to shoot projectiles, magazine reload (R).
Health bar, ammo indicator, damage screen vignette.
BOT AI:

At least 3 bot opponents with distinct profiles (Ranger, Heavy, Ghost).
8-directional A* grid pathfinding around obstacles.
Raycast line-of-sight checks for shooting and diving behind cover when low on HP.
3 selectable difficulty levels (Easy, Normal, Hard).

FAQ