Can AI Build a 500-Enemy Horde in Godot?

The prompt

Build one mechanic for a top-down survival game in Godot: a horde of melee enemies that finds its way to the player and never gets stuck. Make it 3D, seen from a high, angled camera that shows the whole arena; Tab switches to a closer camera that follows the player, and back. This pass is a grey-box in the clean look of the reference pictures: build everything from primitives, with a capsule with a clear front for the player and a smaller capsule for each enemy, and don't download or generate 3D models. The pictures show the look and the idea; where a picture's layout differs from these words, build the words. Build one walled arena about 48 metres wide and 28 deep, with west at the left of the screen and north at the top. A wall down the middle splits it into a west room and an east room, and that wall has two openings: a doorway 2 metres wide near its north end and a gap 5 metres wide near its south end. The enemies spawn in the north-west corner and the player starts in the middle of the east room. On the straight line from the doorway to the player's start, put a U-shaped wall about 6 metres across with its open side facing the doorway, so anything that walks straight at the player from there ends up in a dead end. Scatter a few pillars and crates in both rooms. The player runs with W A S D in screen directions at about 6 metres a second and has no attack: the game is to stay alive. Each enemy is about 0.8 metres wide and runs at about 4 metres a second, and it hits the player when it is next to him. Show the player's health, how many enemies are alive and how long he has survived; at zero health show his time, and R starts again. The horde is the point. However many there are, every enemy has to reach the player by a way it can actually walk: around the U, through whichever opening gets it there sooner, never stopping against a wall or a corner, never passing through a wall, a crate or another enemy, and never queuing at the doorway in a jam that does not clear. When the player goes to the other room they come after him by the new shortest way, not through where he used to be. When they reach him in the open they close in around him from every side instead of lining up behind one another. And it has to hold with a lot of them: the keys 1, 2, 3 and 4 clear the horde and spawn 10, 100, 300 and 500 of them, and with 300 it should still run at 60 frames a second on this PC, measured with v-sync off. For testing only: F2 turns god mode on and off, so the player takes no damage, and F3 turns on a debug view that draws the navigation data you use on the floor (the mesh, the grid or the field) and, for up to twenty enemies, the route each one is following. Both are off by default. Make every key above an input action so it can be pressed by name: move_up, move_down, move_left, move_right, camera_toggle, restart, horde_10, horde_100, horde_300, horde_500, god_mode and debug_view. So the playtest can count them from outside, put the player in the group player, and keep one node in the group horde with a method enemy_positions() that returns a PackedVector3Array holding the position of every living enemy, however you draw them. Nothing else yet: no weapons, no pickups, no waves, no menus and no sound. The look comes in a later pass, so keep the scenes and scripts easy to build on. Run and test the game only through Flockbay's tools: flockbay_play, flockbay_run_headless, flockbay_script_errors, flockbay_game_input, flockbay_game_get, flockbay_game_set, flockbay_game_screenshot, flockbay_last_run and flockbay_stop. Don't start Godot from your own shell, and if one of those tools can't do something you need, say exactly what was missing in your handover. Playtest it yourself and hand it over when you think it's done.

What was judged

In the video