Okay, let's start building this track and field game. We'll begin with the basic structure, the start screen, mode selection, and the first event: the 100 Meters Dash.

We'll use HTML for the structure, CSS for basic styling, and JavaScript with the Canvas API for the game logic and rendering.

This sets up the core game loop, state management, input handling, rendering, UI updates, and the first event (100 Meters Dash) with basic player/CPU logic and scoring.

To Play:

1. The game starts showing the player selection screen.
2. Press 1 or 2 on your keyboard.
3. The mode selection screen appears. Press Enter for Normal Mode or Shift for Practice Mode.
4. The 100m Dash instructions appear. Press Enter or Shift to start the race.
5. Player 1: Rapidly alternate pressing the Left Arrow and Right Arrow keys to run.
6. (If 2 Players): Player 2: Rapidly alternate pressing the A and D keys to run.
7. The race ends when all runners cross the finish line (around x=750).
8. Results (time and points) are displayed. The star ★ indicates a score over 999.
9. Press Enter or Shift to proceed (or retry/skip in practice mode).

Currently, only the 100m Dash is implemented. We can add the other events following a similar pattern. The scoring for the 100m dash uses the provided table with linear interpolation. The CPU aims for a time that yields around 900 points.

Okay, let's add the Long Jump event. We'll create the event logic, scoring, and integrate it into the main game flow. We'll use the Space bar as the jump key ('B').

Changes Made:

1. longJump.js:
   • Created a Jumper class to handle individual player/CPU logic (running, angle setting, jumping physics, landing, fouling).
   • Implemented basic physics (constant acceleration run, projectile motion jump with gravity).
   • Used Space bar (JUMP_KEY) for initiating the jump.
   • Added simple CPU logic (runs near max speed, jumps near the line with a random angle).
   • Included foul detection (crossing the line before jumping or landing outside the pit).
   • Added basic rendering for the runway, pit, foul line, and jumper.
   • The LongJump class manages the overall event state and the jumpers. Currently, it handles only one attempt per event.
   • Added handleKeyPress and handleInput to the event class to manage jump key presses and potential continuous input like angle adjustment.
   • Added canStart method.
2. scoring.js:
   • Added scoreTableLongJump with plausible distances and points.
   • Created calculateScoreLongJump using the calculateScoreValueBased helper function. It handles fouls (0 distance) correctly.
3. game.js:
   • Imported LongJump and calculateScoreLongJump.
   • Added the "Long Jump" event entry to the this.events array.
   • Modified the update loop slightly to pass input to the active event even before it officially starts (EVENT_START) to allow for things like angle setting.
   • Modified handleInput to allow the active event to potentially handle a key press first via activeEvent.handleKeyPress.
   • Modified startEvent to pass the ui object to the event constructor.
   • Modified render to pass the ui object to the event's render method.
4. input.js:
   • Ensured Space is mapped correctly and prevented default browser action.
   • Modified handleKeyPress logic slightly to better integrate with the game state and event-specific key handling.

Now, after the 100m Dash, the Long Jump event will load. Follow the on-screen instructions (run, adjust angle with Up/Down arrows if P1, press Space before the line to jump).*

You are absolutely right! My apologies. I added the call to this.activeEvent.handleInput(this.input) in game.js to allow events like Long Jump to react to continuous input (like holding arrow keys for angle), but I forgot to add the corresponding (even if empty) method to the HundredMeters class.

Let's fix that by adding the missing handleInput method to hundredMeters.js.

This adds the empty handleInput method to the HundredMeters class. Now, the call this.activeEvent.handleInput(this.input) in game.js should work correctly for both the 100m Dash and the Long Jump events without causing a TypeError. I also adjusted the 100m finish time calculation slightly for better precision.

Okay, you're right. Simultaneous jumping isn't realistic for Long Jump, and it should definitely have multiple attempts. Let's refactor the LongJump event to handle 3 attempts per player, taking turns.

This requires significant changes to the LongJump class logic to manage turns, attempts, and individual player states.

Key Changes:

1. longJump.js:
   • State Management: Introduced separate JUMPER_STATE and EVENT_STATE enums. The event now manages whose turn it is (currentPlayerIndex) and the overall flow (STARTING_TURN, PLAYER_ACTIVE, TURN_OVER, EVENT_OVER).
   • Turn Logic:
     • prepareCurrentTurn(): Resets the current jumper and displays instructions. Auto-starts CPU run after a delay.
     • startPlayerRun(): Called when human player presses Enter/Shift to begin their run.
     • update(): Only updates the currentPlayerIndex jumper. When their attempt finishes (jumper.attemptFinished), it records the result and moves to TURN_OVER.
     • handleKeyPress(): Handles starting the run (Enter/Shift in STARTING_TURN), proceeding to the next turn (Enter/Shift in TURN_OVER), and passing the jump key (Space) to the active jumper.
     • recordAttemptResult(): Stores the numeric result of the attempt and updates the player's best distance.
     • advanceTurn(): Increments the player index, handles wrapping around, increments attempt counts, checks if the event is over, and calls prepareCurrentTurn() for the next valid turn.
   • Data Storage: jumpersData array now tracks currentAttempt, bestDistance, and individual attempts results for each jumper.
   • Jumper Class: Added resetForAttempt() method. State transitions are more granular.
   • getResults(): Now iterates through jumpersData to return the bestDistance achieved by each player over their 3 attempts.
2. game.js:
   • State Handling: The EVENT_START state is now more of a loading state. The active event manages its internal state transitions (like starting turns). The EVENT_RUNNING state signifies the event is actively processing turns/actions.
   • Input Handling: handleInput now prioritizes letting the activeEvent.handleKeyPress manage input first. This is crucial for the turn-based logic. It also checks if an event's internal state change necessitates a game state change (though this isn't strictly needed with the current structure).
   • Event Lifecycle: startEvent loads the event. handleEventFinish is called when activeEvent.isFinished() returns true (i.e., when the event's internal state becomes EVENT_OVER). It then uses activeEvent.getResults() which provides the best jump from all attempts.

Now, the Long Jump event should correctly implement 3 attempts per player, taking turns. The CPU will also take its turns automatically.

Okay, let's add the Shot Put event. This will involve setting power and angle using timed key presses, similar to some classic track & field games. We'll stick with the 3-attempt, turn-based structure.

Changes:

1. shotPut.js:
   • Created Shot class for the projectile physics.
   • Created Thrower class:
     • Manages states (READY, POWER_METER_UP/DOWN, ANGLE_METER_UP/DOWN, THROWING, etc.).
     • Handles THROW_KEY (Space) presses to progress through states.
     • Updates power and angle meters based on state and time.
     • Initiates the Shot throw when angle is set.
     • Updates the Shot object during THROWING state.
     • Calculates distance upon landing (simple horizontal distance for now, needs sector check for proper fouls).
     • Includes basic CPU logic to simulate key presses aiming for target power/angle.
   • Created ShotPut class:
     • Manages turns, attempts, and event states like LongJump.
     • Uses Thrower objects.
     • Renders the throwing circle and sector lines.
2. scoring.js:
   • Added scoreTableShotPut with estimated distances and points.
   • Added calculateScoreShotPut function.
3. game.js:
   • Imported ShotPut and its scoring function.
   • Added the "Shot Put" event to the events array.

Now, after the Long Jump, the Shot Put event will load. Use the Space bar three times: once to start the power meter, again to lock power and start the angle meter, and a final time to lock the angle and throw.*_

You've hit a classic scope issue! The EVENT_STATE constant is defined inside shotPut.js (and likely longJump.js too) but isn't exported, so game.js cannot access it directly.

The Game class shouldn't need to know the specific internal states of an event anyway. It should rely on the event's public methods like isFinished() and its ability to handle input.

Let's fix game.js by removing the direct checks for the event's internal EVENT_STATE and simplifying the game state transition. We'll transition from EVENT_START to EVENT_RUNNING when the event successfully handles its first relevant key press.

This adds the Shot Put event, following the same turn-based, 3-attempt structure as the updated Long Jump. It includes the power/angle meter mechanic using the Space bar and basic CPU simulation for that mechanic.

Okay, it seems like the CPU logic in shotPut.js might have a flaw preventing it from taking its turn correctly. The structure is similar to Long Jump, but the interaction with the timed key presses for power/angle adds complexity.

Let's refine the CPU activation and simulation logic within shotPut.js. We'll add some logging to help diagnose if this doesn't fix it.

Key Changes in shotPut.js:

1. Thrower.resetForAttempt: Explicitly sets the initial cpuKeyPressTimer for the first delay and resets cpuActionStep to 0.
2. Thrower.handleHumanKeyPress: Created a separate method for human input to avoid confusion with CPU simulation.
3. Thrower.update (CPU Logic):
   • The timer (cpuKeyPressTimer) now only runs when the CPU is in a state where it's waiting to perform the next action (READY, POWER_METER_UP, ANGLE_METER_UP).
   • When the timer expires, it calls simulateCpuAction.
4. Thrower.simulateCpuAction: (Renamed from simulateCpuKeyPress)
   • This method now directly changes the thrower.state based on the cpuActionStep.
   • It calculates and sets the cpuKeyPressTimer for the next action step.
   • Added logging to track which step is being simulated.
5. ShotPut.handleKeyPress: Now calls thrower.handleHumanKeyPress only if the thrower is not a CPU. It correctly handles starting the human player's turn and advancing turns after completion.
6. ShotPut.update:
   • When it's the CPU's turn (eventState === STARTING_TURN && thrower.isCPU), it immediately sets the eventState to PLAYER_ACTIVE. This allows the Thrower.update method to run.
   • The Thrower.update method itself now manages the CPU's internal timer and state changes via simulateCpuAction.
7. Logging: Added console.log statements at key points in the CPU turn logic (resetForAttempt, simulateCpuAction, state transitions in ShotPut.update, advanceTurn) to help trace execution if problems persist.

This revised logic separates human input handling from CPU action simulation more clearly and ensures the CPU's internal timer controls its actions after the initial turn setup. Give this a try; the CPU should now perform its actions based on the calculated timers.*

Okay, let's implement the High Jump event. This event introduces the concept of a progressively higher bar and elimination based on failed attempts. We'll maintain the turn-based structure with 3 attempts per height.

Changes:

1. highJump.js:
   • Created Jumper class with states for running, jumping, clearing, landing.
   • Implemented basic physics (constant run, vertical impulse, gravity).
   • Added simple bar collision detection during descent.
   • Created HighJump class:
     • Manages turns, attempts per height, and player status (active/eliminated).
     • Tracks current bar height (currentHeightM) and converts to pixels for rendering/physics.
     • Handles height progression (advanceTurn logic checks if bar should be raised).
     • Implements elimination based on 3 total consecutive failures across heights.
     • Renders the runway, pit, bar supports, and the bar itself.
2. scoring.js:
   • Added scoreTableHighJump based on the provided data.
   • Added calculateScoreHighJump function. Modified calculateScoreValueBased slightly to allow linear extrapolation above the highest table value, as high jump scores often exceed listed benchmarks.
3. game.js:
   • Imported HighJump and its scoring function.
   • Added the "High Jump" event to the events array.

The High Jump event now functions with the core mechanics: players take turns attempting the current height, the bar raises after a round is complete, and players are eliminated after 3 consecutive failures. The scoring reflects the highest successfully cleared height.*