Okay, let's start building the foundation for this game. We'll begin with the basic scene setup, a player representation, WASD movement with two speeds (using Shift for the faster speed), a basic jump, and camera controls using OrbitControls as a placeholder.

This sets up:

1. An HTML page (index.html) with an import map for Three.js and basic instructions.
2. CSS (style.css) for basic page layout.
3. A main script (main.js) initializing the Three.js scene, renderer, camera, lighting, and OrbitControls. It also creates instances of the InputHandler, PlayerController, and World.
4. An InputHandler.js class to track keyboard inputs (WASD, Shift, Space).
5. A PlayerController.js class representing the player with a capsule mesh. It handles movement based on camera direction, applies gravity, and performs a basic jump. It includes logic for two movement speeds (walk/run via Shift).
6. A World.js class to create the ground plane and a simple test platform.

Next steps would involve implementing the custom camera controls (Arrow keys), more complex jump mechanics, collision detection with the platform, and the various attack/action moves.

Okay, this is a significant undertaking! We'll structure the project with multiple modules to handle input, player logic, camera control, actions, guns, and the world environment.

This implementation will provide the structure and basic logic for most features, but many aspects (like detailed animations, precise collision, gun models/effects, vehicle physics, UI menus) will be simplified or represented by placeholders due to the complexity.

This comprehensive setup includes:

1. main.js: Initializes everything, runs the main game loop, handles pausing.
2. InputHandler.js: Manages all key presses, releases, and hold durations. Includes callbacks for specific key events.
3. PlayerController.js: The core player logic with a state machine (PlayerState), movement physics (walk, run, roll, air control), gravity, basic collision detection (ground raycast, AABB for platforms), rotation, and placeholders for all actions (jump types, attacks). It delegates complex action logic to ActionManager and gun logic to GunManager.
4. World.js: Creates the ground and several platforms (including a gap and a high ledge) and manages a list of collidable objects with pre-calculated bounding boxes.
5. CameraManager.js: Replaces OrbitControls. Handles camera following, rotation (Arrow Left/Right), zoom/tilt (Arrow Up/Down) with limits and smoothing. Provides helper functions for player movement based on camera direction.
6. ActionManager.js: Handles the logic for multi-key actions (double jump, high jump, rolling jump, smashing dive, uppercut, guided jump) using timers and state checks. Manages action durations.
7. GunManager.js: Manages gun equipping, cycling (I, J, K, L), holstering (holding keys), firing (W), and displays a placeholder gun model. Includes basic bullet firing logic.
8. UIManager.js: Updates the simple text display for the current gun and player state.
9. index.html: Updated with more detailed controls info and divs for UI display.
10. style.css: Basic styling.

This forms a much more complete, albeit still simplified, foundation for the game described. Many areas like collision response, animation integration, precise action timing/effects, and UI menus would need further refinement.

Okay, a gray screen usually points to a JavaScript error preventing the scene from rendering or an issue with the camera setup. Let's add some checks and refine the code slightly.

One potential issue is in ActionManager.js where checkActionState uses a fixed 1/60 instead of the deltaTime. Let's fix that and add some basic error handling and logging to main.js.

Key changes:

1. main.js:
   • Added console.log statements during initialization.
   • Wrapped renderer initialization and component initialization in try...catch blocks with error messages.
   • Wrapped the main animate loop content in a try...catch block to catch runtime errors and pause the game.
   • Added a check for excessively large deltaTime.
2. ActionManager.js:
   • Passed deltaTime to checkActionState and used it for decrementing the timer.
   • Added more checks in handleJumpPress to ensure double jumps only happen from valid states.
3. PlayerController.js:
   • Added checks for valid constructor arguments.
   • Wrapped player mesh creation in try...catch.
   • Initialized playerCollider Box3 immediately.
   • Improved setState logic with distinct "State Exit" and "State Enter" sections for clarity and flag management.
   • Refined handleInputAndStateTransitions to prioritize action/gun states and handle ground/air transitions more cleanly.
   • Improved applyMovement friction logic and added specific handling for aiming/firing/ducking states.
   • Refined updateRotation to handle aiming/firing lock correctly.
   • Improved checkCollisions:
     • Uses raycast origin slightly inside the capsule base.
     • Prioritizes raycast for ground detection.
     • Improved logic for landing on platforms vs. hitting walls.
     • Uses predicted Y position for ground check to prevent sinking.
     • Adjusted horizontal collision resolution logic (still basic, but slightly improved).
   • Ensured updatePosition applies velocity after collision resolution.
   • Added checks in action trigger methods (like jump) to prevent re-triggering while already in that state.
   • Adjusted spinAttack logic to capture stateTimer before the state change for guided/highest jump checks.

Now, run this version and check the browser's developer console (F12) carefully. Look for:

• Any red error messages.
• The console.log messages from main.js to see how far the initialization gets.
• Any errors reported by the try...catch blocks.

This should help pinpoint where the process is failing.*

Okay, let's remap the firing key from 'W' to 'E'.

Changes made:

1. InputHandler.js:
   • Changed the fire getter to return this.isKeyPressed('e').
   • Removed the !this.isGunKeyHeldLong() check from the moveForward getter.
   • Removed 'w' from the general check in isGunKeyHeldLong.
2. index.html:
   • Updated the control list text to show "E: Fire Gun".
3. GunManager.js:
   • Minor adjustment in fireBullet to originate the bullet based on the player's forward direction and position rather than the placeholder gun mesh's transform, which gives more intuitive aiming.

Now, pressing 'E' should trigger the fire input, and 'W' will only be used for moving forward.*

Okay, errors during movement often happen if calculations involving vectors (like direction or velocity) result in invalid numbers (NaN - Not a Number) or if an object reference is unexpectedly null or undefined.

Let's add some checks and logging, particularly around vector normalization and camera direction retrieval, as these are common culprits when movement input is involved.

Key Debugging Changes:

1. main.js:
   • Clamped large deltaTime values to prevent physics explosions after pauses or slowdowns.
   • Added a check to skip frames if deltaTime is zero or negative.
2. CameraManager.js:
   • Added checks in getForwardVector and getRightVector to prevent normalizing zero vectors (which results in NaN) and provide fallback directions.
3. PlayerController.js:
   • applyMovement:
     • Added checks for NaN in the camera vectors retrieved from CameraManager.
     • Added a check (lengthSq() > 0.001) before normalizing moveDirection to prevent normalizing a zero vector.
     • Added a check before calculating targetRotationY using atan2.
     • Simplified friction application (removed the complex perpendicular velocity part for now, as it might be unstable).
   • updateRotation:
     • Added checks for NaN in targetAngle and the quaternions before calling slerp.
   • checkCollisions:
     • Refined ground check logic using predicted Y position.
     • Improved platform/wall collision resolution logic (still basic AABB push-out, but slightly refined).
     • Ensured ground snapping happens correctly.
   • updatePosition:
     • Added a check for NaN in the final velocityDt before adding it to the position. Reset velocity if NaN is found.
   • Action Methods (rollingLongJump, spinAttack): Ensured new THREE.Vector3 instances are created when getting world direction to avoid modifying shared vectors unintentionally.
4. GunManager.js:
   • Refined logic for when the FIRING state can be entered and how it transitions back to AIMING or movement states.
   • Adjusted checkGunState to be less aggressive about enforcing AIMING state when the player is moving.
   • Fixed bullet animation loop to capture initial direction and added basic cleanup checks (though a proper manager is still recommended).

Run this version and check the console again when you try to move. The added checks and fallbacks should hopefully prevent NaN errors or log more specific information about where things are going wrong.

An infinite crash loop is serious and often points to an error that happens every frame, possibly related to physics instability, invalid calculations recurring, or incorrect state management.

Let's try the following:

1. Add a safety break in the animation loop: Prevent the browser from completely freezing by stopping the loop after several consecutive errors.
2. Simplify Collision Response: Temporarily revert the horizontal collision response in checkCollisions to a very basic "stop velocity" to see if the more complex push-out logic was causing instability.
3. Add more detailed logging: Log values just before potentially problematic calculations (vector normalization, atan2, slerp).
4. Ensure Camera lookAt is valid: Add a check to prevent lookAt if the camera position and target are too close.
5. Refine Bullet Cleanup: Use setTimeout for the placeholder bullet removal for better reliability than the nested requestAnimationFrame.

Summary of Changes:

1. main.js:
   • Added consecutiveErrors counter and MAX_CONSECUTIVE_ERRORS.
   • The animate loop now cancels requestAnimationFrame and sets isPaused = true if the error limit is reached, preventing a hard browser freeze.
   • Added logic to potentially restart the loop when unpausing if it was stopped due to errors.
2. PlayerController.js:
   • checkCollisions: Replaced the horizontal push-out logic with a simpler version that just sets the corresponding velocity component (X or Z) to zero if moving towards an intersecting object horizontally. This is less physically accurate but potentially more stable for debugging.
   • Added more console.log statements (commented out by default) in applyMovement and updateRotation to trace values.
   • Added more isNaN checks for velocity components.
3. CameraManager.js:
   • Added a check in update to prevent calling camera.lookAt if the camera position and the look-at target are extremely close, which can cause NaN issues in the camera's matrix.
   • Pre-allocated more vectors (_lookAtTarget, _desiredPosition, _desiredOffset) used within the update loop to potentially reduce garbage collection pressure slightly.
4. GunManager.js:
   • Modified fireBullet to use setTimeout for scheduling the bullet's removal, which is generally more reliable for time-based events than nested requestAnimationFrame.
   • Added tracking of active bullet timeouts (this.activeBullets) and a basic cleanup method.
5. World.js:
   • Added a check in addCollidable to warn if an invalid bounding box is created (e.g., for a mesh with no geometry or scale).

Now, when you run this:

1. If the game crashes, it should pause itself after 10 consecutive errors, allowing you to inspect the console without the browser freezing completely.
2. Check the console very carefully for the sequence of errors leading up to the pause. The added logging and checks might reveal NaN values or specific error messages related to collisions, rotations, or camera updates.
3. The simplified collision response might prevent the crash if it was related to the push-out logic. If the game doesn't crash now (but horizontal collisions feel 'sticky'), it points towards the previous collision response being the culprit.*_

Okay, let's introduce a water mechanic. We'll define a water level, add a SWIMMING state, and modify controls and physics when the player enters the water.

We'll use a simple Y-level check for water detection and add a visual plane to represent the water surface.

Plan:

1. World: Define waterLevel and add a water plane mesh.
2. PlayerState: Add SWIMMING.
3. InputHandler: Add getters for swimUp (Space) and swimDown (Q).
4. PlayerController:
   • Add swimming physics properties (buoyancy, water drag, swim speeds).
   • Detect water entry/exit in update or checkCollisions and transition state.
   • Modify applyGravity for buoyancy when swimming.
   • Modify applyMovement to handle swimming controls (WASD horizontal, Space/Q vertical).
   • Disable ground-based actions (jump, punch, etc.) when swimming.

Key Changes:

1. World.js:
   • Added waterLevel property.
   • Added createWaterSurface method to add a semi-transparent blue plane at the waterLevel.
2. InputHandler.js:
   • Added swimUp (Space) and swimDown (Q) getters. These keys now serve dual purposes.
3. PlayerController.js:
   • Added SWIMMING to PlayerState.
   • Added swimming physics properties (swimSpeedHorizontal, swimSpeedVertical, buoyancy, waterDrag).
   • Added isInWater flag.
   • Added checkWaterStatus method called in update to detect water entry/exit based on playerMesh.position.y and world.waterLevel, setting the SWIMMING state accordingly.
   • Renamed applyGravity to applyGravityAndBuoyancy. It now checks for the SWIMMING state and applies buoyancy force counteracting gravity, otherwise applies normal gravity.
   • Modified applyMovement:
     • Checks for SWIMMING state at the beginning.
     • If swimming, applies horizontal movement using swimSpeedHorizontal and water drag.
     • If swimming, checks input.swimUp and input.swimDown to modify velocity.y towards swimSpeedVertical.
     • Applies waterDrag to velocity.y as well when swimming.
   • Modified checkCollisions: It's now skipped if the player is swimming (to prevent unwanted ground snapping when underwater).
   • Modified updatePosition: Failsafe floor check is skipped if swimming.
   • Modified Action Triggers (jump, punch, spinAttack, etc.): Added checks at the beginning of most ground/air actions to return immediately if this.state === PlayerState.SWIMMING, effectively disabling them in water.
   • Modified jump: Added logic to allow a weaker jump out of the water if near the surface.
   • Stored player material in this.playerMaterial to change its color when entering/exiting water.
4. ActionManager.js:
   • Modified handleJumpPress and handleDuckPress to simply return if swimming, as the vertical movement is handled directly in PlayerController.applyMovement.
5. GunManager.js:
   • Added checks to prevent cycling guns (cycleGun) or firing (update) while player.state === PlayerState.SWIMMING.
   • Modified holsterGun to not force IDLE state if the player is swimming.
   • Modified checkGunState to return null if swimming.
6. index.html: Updated control list for Space and Q.

Now, when the player's base goes below y = 0.5, they should enter the SWIMMING state (turning blue), WASD will control horizontal movement, Space will move them up, Q will move them down, and most other actions will be disabled. Gravity will be counteracted by buoyancy.*

Okay, let's adjust the world layout and refine the swimming controls according to your new specifications.

Plan:

1. World: Split the ground into a grass half and a lower "seabed" half. Place the water surface only over the seabed half.
2. InputHandler: Change swimDown (Q) to do nothing in water. Add diveSink mapped to , and V.
3. PlayerController:
   • Modify swimming movement in applyMovement to use diveSink for downward movement, respecting the depth limit. Remove swimDown (Q) logic.
   • Ensure Transform (1) is disabled when swimming.
   • Ensure Q has no effect when swimming.

Key Changes Summary:

1. World.js:
   • createSplitGround replaces createGround, making a grass plane on +X and a lower seabed plane on -X.
   • createWaterSurface now creates a plane only covering the -X side at waterLevel.
   • Platforms repositioned for the new layout.
2. InputHandler.js:
   • Removed swimDown getter.
   • Added diveSink getter mapped to , and v.
3. PlayerController.js:
   • Added diveSpeed property.
   • Added MAX_SWIM_DEPTH constant.
   • checkWaterStatus now also checks if the player is in the water area (position.x < 0).
   • applyMovement (Swimming): Uses input.diveSink to apply downward velocity (diveSpeed), respecting MAX_SWIM_DEPTH. Removed swimDown logic.
   • applyGravityAndBuoyancy (Swimming): Added check to prevent applying buoyancy if actively diving at max depth.
   • checkCollisions is skipped entirely when swimming unless near the seabed.
   • Added checkSeabedCollision for simple collision detection with the seabed when swimming deep.
   • handleTransform now explicitly checks for SWIMMING state and returns.
4. ActionManager.js:
   • handlePunchPress and handleSpinPress now just return if swimming (the dive input is read directly in PlayerController.applyMovement).
   • handleDuckPress and handleDuckRelease now just return if swimming (Q does nothing in water).
5. index.html: Updated controls list to reflect changes for Q, ',', V, 1, E, and Guns in water.

Now, the world should have a distinct land and water area. When in the water area (x < 0) and below the water surface (y < 0.5), swimming controls activate: Space swims up, , or V dives down (up to 8m below the surface), Q does nothing, Transform does nothing, Guns cannot be cycled or fired.