SekiroLike3D

Cinevva's analyzer read this game's design doc and its source, then wrote the brief below. "Make your own" hands it to the game creator as your opening message, so you start from a real spec rather than a one-line idea.

Create a browser-based third-person 3D sword-combat prototype titled “SekiroLike3D.” Use Three.js-style rendering with a perspective camera, a dark near-black page background, a cel-shaded/toon visual treatment, soft shadows, warm directional sunlight plus cool rim lighting, and green atmospheric fog. The playable scene is a small grassy arena/park on a flat 40x40 ground plane, with several stylized low-poly trees around the perimeter and a small faceted grassy hill/platform toward the left/back side. Keep the world simple and uncluttered, with the player and enemies clearly visible in the center of the arena.

The player is a stylized humanoid Warrior character holding a sword, loaded as an animated 3D character model. Start the player near the front of the arena at approximately world position (0, 0, 5). Use a third-person follow camera initially positioned behind and above the character, looking toward the combat area; allow mouse look through the third-person controls. The player can move with WASD at a brisk movement speed, jump with Space using gravity, sprint with Shift, and use Space while falling to glide upward slightly at the cost of stamina. Keep the player constrained to the ground during ordinary movement. Use the character’s idle and run animations, and use sword attack animations for attacks.

Place two animated skeleton warrior opponents in the arena: a normal dueling skeleton around (0, 0, -7), and a shielded/defensive skeleton around (5.5, 0, -3). They should use toon-shaded materials, cast shadows, face and pursue the player, and use walking, idle/combat, sword slice/chop, and shield/block attack animations when available. Enemies automatically chase the player until within roughly 2.8 world units, then attack on a cooldown. Their attacks have a windup and only hit if the enemy is close enough and facing the player. The shielded archetype attacks more slowly and sometimes uses a block attack; frontal sword strikes against its guard cause only a small posture increase, while other successful strikes cause a larger posture increase.

Make posture the core combat mechanic rather than conventional health damage. The player and each enemy have posture values from 0 to 100 that slowly regenerate while not broken. The player attacks with E or the on-screen ATTACK (E) button. An attack should have a short windup, check for enemies within about 3.8 units in front of the player, spend a small amount of stamina, create a bright gold slash effect, emit yellow spark particles, and cause subtle camera shake. Ordinary hits increase the target enemy’s posture; once it reaches 100, stagger/break the enemy and show the deathblow opportunity. If the enemy is already broken, a close-range attack performs a DEATHBLOW instead of another ordinary strike.

The player parries with Q or the on-screen PARRY (Q) button. During a short parry window, if an enemy attack lands, negate the normal player posture damage and instead inflict a large posture increase on that enemy (an even larger increase against the shielded enemy). If the player is hit without successfully parrying, reduce player posture substantially; when the player’s posture reaches zero, mark the player as broken, turn the player posture bar red, and recover after a short stagger period with partial posture restored. The enemy’s broken state should briefly stagger/back away, play a hit/stagger animation, produce a stronger burst of sparks and camera shake, and automatically recover after several seconds with partial posture unless the player executes a deathblow. A deathblow should play the enemy death animation if available, create a larger slash and spark burst, briefly slow time/hit-stop and shake the camera, flash “DEATHBLOW!” in large glowing red text near screen center, then respawn/reset that enemy after roughly two seconds so the prototype remains continuously playable. Include a keyboard R quick-respawn action for any dead enemy.

Add lightweight combat VFX: gold translucent plane-like sword slash arcs that rapidly enlarge and fade, bright yellow point-like sparks affected by gravity, hit-stop/slow-motion on deathblows, and camera shake on impacts. Do not add elaborate effects beyond these visible combat feedback elements.

Build a fixed HTML HUD over the canvas. At the top-left show a bordered horizontal teal POSTURE bar and beneath it a blue STAMINA bar. At the top-right show a bordered horizontal red ENEMY posture bar for the nearest living enemy. The bars should update continuously; make the player and enemy posture bars red when their posture is broken, otherwise use teal for the player and red for the enemy. At the bottom center show a dark translucent instruction panel reading approximately “E: Attack   Q: Parry   WASD: Move   Shift: Sprint   Space (fall): Glide   Mouse: Look.” Above it show the hint “Close range + attack when red = Deathblow.” Put two touch-friendly dark rounded buttons at the lower-right, labeled “PARRY (Q)” and “ATTACK (E).” The center-screen “DEATHBLOW!” label should normally be invisible and fade/flash in only during an executable deathblow. Keep the interface minimal, with no score, inventory, map, or extra health display.

Use a clean, compact arena composition and anime-inspired cel shading: toon gradient materials on the warrior, skeletons, grass, hill, and trees; warm sunlight from above/front-right; cool blue fill/rim light; fog that softens the distant trees. Ensure the game begins after the player and both skeleton models finish loading, starts the animation loop, and remains an interactive combat sandbox with continuously respawning opponents.