Skip to content

FPS with enemies: navmesh pathfinding, and theme slots for both submitted starters - #1097

Merged
4ian merged 20 commits into
Starter-Submission-FPS-With-Enemies-And-Camera-Switchingfrom
claude/awesome-knuth-vaoj1s-fps-enemies
Oct 23, 2026
Merged

4ian merged 20 commits into
Starter-Submission-FPS-With-Enemies-And-Camera-Switchingfrom
claude/awesome-knuth-vaoj1s-fps-enemies

Conversation

@4ian

@4ian 4ian commented Oct 19, 2026 •

Copy link
Copy Markdown
Contributor

Changes to the starters of #1076, to merge into its branch (Starter-Submission-FPS-With-Enemies-And-Camera-Switching). The branch started at the former head of #1076 (8c58260f); the rewritten #1076 branch, rebased on the latest main, is merged in, so the diff only has the commits below.

The enemies of the FPS with enemies walk with a navmesh

The enemies used the grid pathfinding, with invisible obstacles (PathfindingObstacle) along the platform. They now walk with navmesh pathfinding (NavMeshPathfinding). The navmesh is built from:

  • the ground, the platform and its ramps, which are walked on;
  • the pushable boxes, which are only obstacles (the navmesh follows them when they are pushed).

The state machine is unchanged, and so are the vision raycast and the restart when an enemy collides with the player:

  • Patrolling: the enemies walk to the player, or to a random place, on the navmesh. A random point near the player is at the height of the player, who can be on the platform; a random point inside the ground box is on the ground.
  • Chasing: the enemies run to the player on the navmesh too, instead of being pushed toward the player with forces. So they go up a ramp to reach the player on the platform. The path is only updated when the player moves away from where it ends. Updated twice per second, the path kept switching between the two ramps (both about as far away), and the enemy went back and forth behind the platform.
  • Physics body: while the navmesh moves an enemy, its physics body is kinematic: the player bumps into it without pushing it, and touching the player is the collision of the physics bodies, as in the submission.
  • Shot: as in the submission, a shot enemy is thrown back by the impulse at the impact, and tumbles: the new "Body type" action of the 3D physics (Add an action to change the body type of 3D physics objects 4ian/GDevelop#9270, merged) makes its body dynamic right before the impulse.

The invisible obstacles and their texture are removed.

The "Body type" action needs GDevelop 5.6.285 (the release after 5.6.284): an older GDevelop doesn't know it and would skip it, and a shot enemy wouldn't be thrown. So the database now asks for GDevelop 5.6.285 or later for the examples using it (scripts/lib/ExampleGDevelopVersion.js, instead of 5.5.220 or later for the other 3D physics examples): an older GDevelop shows "Download the latest version of GDevelop to check out this example!". The gameplay tests of the CI use the latest build of GDevelop's master, which has the action (built at 14:52 UTC on 2026-10-20).

Before the action was available, the enemies used a dynamic body without gravity, without the collisions with the static objects and 100 times heavier, whose settings were restored, and the behavior deactivated and activated again, before the impulse: this is replaced by the action.

Screenshots: an enemy chasing the player up the right ramp:

chase

Theme slots

Both starters get a theme-slots.json, and every theme applies to both (checked with checkStarterThemeSlots and applyThemeToStarter):

  • FPS with enemies: like the FPS starter (ground, walls and obstacles, pushable boxes, gun, sky), with the enemies as character.enemy.
  • Camera monitoring: the walls (env.wall), the tiled floor (env.ground.tiled) and the furniture (env.crate, as it uses the texture of the pushable boxes of the other starters). The security cameras, the glass, the room areas and the light placeholders keep their look.

Also

  • The skybox of the FPS with enemies uses the standard cube orientation, like the other starters (Update examples skyboxes direction to be standard cube #1069): the same images as the FPS starter, and "top": "Z+".
  • The FPS with enemies gets its own project UUID. It had the one of the FPS horror starter.
  • The ground, the walls and the pushable boxes of the FPS with enemies are in a World folder.
  • The extensions of the FPS with enemies are updated to their latest versions: SpriteMultitouchJoystick 1.9.2, MousePointerLock 0.3.1, ParticleEmitter3D 3.2.1.
  • The README of the FPS with enemies is one paragraph describing the game, the enemies and the gun included: its first paragraph is the description the AI uses to choose a starter.
  • The events of both starters are unfolded, except the groups (which can stay folded).

Tests

Three tests are added to the FPS with enemies:

  • a shot enemy is thrown back by the impact and tumbles;
  • a patrolling enemy walks toward the player;
  • an enemy that sees the player chases and catches them (the collision of the physics bodies restarts the scene).

They test what a game made from the starter keeps. They don't check how the physics body is set (kinematic while walking, dynamic when shot) or the height of an enemy above the ground. A test of an enemy going up a ramp to the platform was removed, since a game will change the level.

The two tests of the submission get a 120 s timeout: they render at 1280×720, which takes about a minute in the software renderer (60 s was just too short on a slower machine). All 5 tests pass with node scripts/run-gameplay-tests.js and the latest build of GDevelop's master (the one the CI uses). Checked apart: walking into a standing enemy, the player is stopped. ExampleGDevelopVersion.spec.js checks the version asked for an example using the action (in a scene or in an extension), and for the other examples; jest, tsc and prettier pass.

The two tests of the camera monitoring starter get a 120 s timeout: they timed out on CircleCI (35 to 50 s for their 170 frames, against the default 30 s). They render at 1280×720 with a spot light casting shadows and the CRT and glow effects of the camera view, which are slow in the software renderer of the CI. Both pass.

The "3D FPS with enemies Expanded" of #1087 is built from this version of the starter.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj

HelperWesley and others added 10 commits October 6, 2026 16:41
The first of the two games being submitted.

An FPS game, set in normal global lighting, with enemies in the scene that pathfind towards the player, but rush towards the player if they see the player.
A starter game where you switch between cameras, with a VCR style overlay, static, and dark lighting.
The old gameplay tests didn't include the enemies.
Updating the 3D boxes in these starters with upscaled textures and a tile scale property to match those textures.
Like the other starters (#1069), and give the starter its own project UUID
(it had the one of the FPS horror starter).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
The enemies used the grid pathfinding, with invisible obstacles along the
platform. They now walk with navmesh pathfinding (NavMeshPathfinding), on a
navmesh built from the ground, the platform and its ramps (walkable), and the
pushable boxes (obstacles only, it follows them when they are pushed):
- patrolling, they walk to the player, or around, on the navmesh;
- chasing, they run to the player on the navmesh too (instead of being
  pushed toward the player with forces), so they go up a ramp to reach the
  player on the platform. The path is updated when the player moves away
  from its end (both ramps being about as far, a new path could take the
  other one every time);
- their 3D physics body is kinematic (moved by the navmesh, it still
  collides with the player);
- a shot enemy falls over before disappearing (it was pushed by an impulse,
  which a kinematic body doesn't take).

The invisible obstacles are removed. Tests are added: a patrolling enemy
walks toward the player, an enemy that sees the player catches them, and an
enemy goes up a ramp to catch the player on the platform. The tests of the
submission get a 60 s timeout (they render at 1280x720). The extensions are
updated to their latest versions.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
…theme slots

FPS with enemies: like the FPS starter, with the enemies as enemy
characters. Camera monitoring: the walls, the tiled floor and the furniture
(textured like the pushable boxes of the other starters); the security
cameras, the glass, the room areas and the light placeholders are kept.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
They render at 1280x720 with a spot light casting shadows and the CRT and
glow effects of the camera view: in the software renderer of the CI, their
170 frames take 35 to 50 s, more than the default 30 s.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
While an enemy walks, the navmesh moves it: its physics body (dynamic, as in
the submission) is deactivated, and it is activated when the enemy is shot,
to take the impulse at the impact of the submission. A shot enemy is thrown
back and tumbles again, instead of falling over.

Touching the player, which was a collision of the physics bodies, is checked
with the distance between the player and the enemy.

A test checks a shot enemy is thrown back and tumbles.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
@4ian
4ian force-pushed the claude/awesome-knuth-vaoj1s-fps-enemies branch from 919b18b to 8593eb3 Compare October 19, 2026 15:47
The previous change deactivated the physics body of a walking enemy, so that
the player could walk into it, and touching the player was checked with a
distance. The body now stays: while the navmesh moves it, it has no gravity,
doesn't collide with the static objects (mask 1: the ground, the walls),
which the navmesh keeps it on and away from, and is 100 times heavier, so
that the player bumps into it without pushing it. Touching the player is the
collision of the physics bodies again, as in the starter. When it is shot, it
gets its density, the gravity and the collisions back (deactivating and
activating the behavior creates the body again with them), and takes the
impulse at the impact.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
…ples using it

The 3D physics "Body type" action is not known by GDevelop 5.6.284 and
before, which would skip it. An example using it asks for GDevelop 5.6.285
or later, instead of 5.5.220 or later for the other 3D physics examples.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
The FPS with enemies uses the new "Body type" action of the 3D physics:
an enemy moved by the navmesh is kinematic (the player bumps into it
without pushing it), and becomes dynamic when it is shot, to be thrown by
the impulse at the impact. It replaces the dynamic body without gravity,
without the collisions with the static objects and 100 times heavier,
whose settings were restored, and the behavior deactivated and activated
again, before the impulse.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
They render at 1280x720, which takes about a minute in the software
renderer: 60 s was just too short on a slower machine.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
The ground, the walls and the pushable boxes are in a "World" folder.

The tests no longer check how the physics body of an enemy is set
(kinematic while walking, dynamic when shot) or its height above the
ground, and the test of an enemy going up a ramp is removed: a game made
from the starter changes the level, and these would break. The tests
check that a shot enemy is thrown back, and that the enemies walk to the
player and catch them.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
The first paragraph of a README is the description the AI uses to choose a
starter: it now describes the game and its map, without how to edit the
terrain and the scattered models, or the credits of the CC0 assets.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
@4ian
4ian added this pull request to stack #1100 October 23, 2026 15:46
@4ian
4ian force-pushed the Starter-Submission-FPS-With-Enemies-And-Camera-Switching branch from 8c58260 to 0e7d88f Compare October 23, 2026 15:46
Its starters are the same as before, rebased on the latest main: the
conflicts in the FPS with enemies and the camera monitoring are resolved with
the version of this branch, and the texture of the invisible obstacles, which
nothing uses, stays removed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wa8uKpYuQrYqGYnqGCsquj
@4ian
4ian removed this pull request from stack #1100 October 23, 2026 15:53
@4ian
4ian merged commit 977fd4c into Starter-Submission-FPS-With-Enemies-And-Camera-Switching Oct 23, 2026
1 of 3 checks passed
@4ian
4ian deleted the claude/awesome-knuth-vaoj1s-fps-enemies branch October 23, 2026 15:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants