Beakrift v0.4

Create a complete, playable mobile game project called **Beakrift**.

## Technology

Use:

- **Godot Engine 4.7.2**
- **GDScript**, not C#
- A 2D project
- Portrait orientation
- Target platforms: Android and iOS
- Touchscreen as the primary input method
- Mouse and Spacebar as additional inputs for testing on PC

Structure the project from the start so it can later be extended with levels, enemies, bosses, power-ups, skins, different worlds, and additional game modes.

## Goal for the first version

The first version should closely follow the classic gameplay of Flappy Bird.

**Important:** Do not use any original graphics, sounds, music, fonts, source code, names, or other assets from Flappy Bird. Create only original, simple placeholder graphics. For now, the playable character should be a simple stylized bird.

The project and game must be named only:

**Beakrift**

## Gameplay

The player controls a bird that moves automatically from left to right through an endless world.

Technically, the bird can stay at roughly the same horizontal screen position while obstacles and scenery move to the left.

The bird is continuously affected by gravity. Every screen tap gives it a short upward impulse.

Supported inputs:

- Touch anywhere on the screen
- Left mouse button
- Spacebar

The flight controls should feel direct, precise, easy to understand, and difficult to master. Avoid floaty physics.

## Bird physics

Implement configurable values for:

- gravity
- flap_strength
- max_fall_speed
- rotation_up
- rotation_down
- rotation_speed

Keep these values in a central place so the gameplay can be tuned easily later. When the player flaps, the bird should tilt slightly upward. As it falls, it should increasingly tilt downward.

## Obstacles

Create classic pairs of vertical obstacles with a gap between them. They move constantly from right to left.

Properties:

- Random vertical position for the gap
- A constant gap size at first
- A constant movement speed at first
- Collision areas at the top and bottom
- Obstacles are removed automatically after leaving the left edge of the screen

Use object pooling or an equally clean approach where appropriate. Obstacles must be created by their own spawner.

Make all important values configurable:

- obstacle_speed
- spawn_interval
- gap_size
- min_gap_position
- max_gap_position

## Scoring

Award exactly one point whenever the player successfully passes a pair of obstacles. Display the score at the top center of the screen. A simple numeric display is enough during gameplay.

Also save the local high score using Godot's local storage, so it remains available after the app restarts.

## Game states

Implement a clean game-state structure with at least these states:

### READY

The game waits for the first input.

Display:

**Tap to Start**

The bird may hover slightly or have a small idle animation.

### PLAYING

The first tap starts the game:

- Gravity is active
- Obstacles move
- Obstacles spawn
- Points are counted

### GAME OVER

Game over occurs when the bird collides with an obstacle, touches the ground, or optionally touches the upper screen boundary.

After game over:

- Stop movement
- Show the score
- Show the high score
- Show a Restart button

After a short input lockout, a tap should also restart the game. Prevent an accidental immediate restart from the same touch that caused the collision.

## UI

Create a minimal mobile UI.

READY:

- Beakrift logo or text
- Tap to Start

PLAYING:

- Score at the top center

GAME OVER:

- Game Over
- Score
- Best Score
- Restart

The UI must work across different smartphone aspect ratios. Use Godot's Control system with anchors and containers instead of hard-coding fixed pixel positions everywhere. Respect the safe areas of modern phones.

## Screen

The game runs in portrait orientation only. Make the layout responsive, targeting roughly 9:16 while also supporting taller screens such as 19.5:9 and 20:9, including iPhones with Dynamic Island and Android devices with display cutouts. No important UI element may be clipped.

## Background

Use only original, simple placeholder graphics, such as a sky, clouds, ground, basic obstacles, and a basic bird. Do not copy or trace Flappy Bird graphics. Use simple Godot shapes, self-created primitive sprites, or neutral placeholder assets.

Optional: implement light parallax scrolling, with a slow background, obstacles at normal speed, and the ground moving slightly faster.

## Audio

Prepare an audio system for:

- flap
- point
- collision
- game over
- UI click

Use only self-created or neutral placeholder sounds. If suitable sounds are not available, create the audio structure with clearly named AudioStreamPlayer nodes first.

## Architecture

Do not throw the project together as a quick prototype. Create a clean, modular structure.

Suggested structure:

~~~text
res://
    scenes/
        main/
        player/
        obstacles/
        ui/
    scripts/
        core/
        player/
        obstacles/
        ui/
    assets/
        sprites/
        audio/
        fonts/
    data/
~~~

Create separate scenes at least for Main, Player, ObstaclePair, and UI. Separate gameplay responsibilities sensibly.

## Central game configuration

Create a central configuration for gameplay values, for example as a Godot Resource. It should be able to hold values such as:

~~~text
gravity
flap_strength
max_fall_speed

obstacle_speed
obstacle_gap
obstacle_spawn_interval

world_scroll_speed

difficulty_multiplier
~~~

Avoid magic numbers scattered across different scripts.

## Prepare for future extensions

The architecture must account for Beakrift growing substantially later. Future possibilities include:

- Multiple levels and worlds
- Different obstacle types and moving obstacles
- Enemies with their own AI
- Bosses and projectiles
- Health points and power-ups
- Coins, skins, unlockable birds, and upgrades
- Different flight abilities
- Missions and achievements
- Level selection
- Story or adventure mode
- Endless mode

Do **not** implement these features now. Structure the code so they can be added later without rewriting the entire foundation.

## Performance

The game must run efficiently on smartphones, targeting **60 FPS**. Pay attention to:

- Avoiding unnecessary nodes
- Avoiding unnecessary _process() calls
- Cleanly removing objects that are no longer needed
- Preventing memory leaks
- Avoiding unnecessary per-frame allocations

## Mobile

Prepare export configurations for Android and iOS.

Android:

- Portrait orientation
- Touch input
- Suitable stretch settings
- An initial app identifier such as com.beakrift.game

iOS:

- Portrait orientation
- Touch input
- The same gameplay presentation as Android

Do not add platform-specific gameplay logic unless it is essential.

## Development requirements

Work directly in the project and create all required files. If files already exist:

1. Analyze the project structure first.
2. Keep useful existing structure.
3. Do not replace working parts unnecessarily.

After each major change:

1. Check scripts for parse errors.
2. Check scenes for missing references.
3. Make sure the project starts.
4. Fix obvious issues immediately.

Do not stop at a concept. Implement the complete playable first version.

## Definition of done

The task is complete only when:

- The Godot project starts without errors
- The bird is controllable by touch, mouse, and Spacebar
- Gravity works
- Obstacles appear automatically with random gap positions
- Collisions work
- Scoring works
- The high score is saved
- READY, PLAYING, and GAME OVER states work
- Restart works
- The UI is responsive
- The game runs in portrait orientation
- Android is prepared as an export target
- iOS is prepared as an export target
- No original Flappy Bird assets or names are included

After implementation, start the project or run all available local checks and fix any errors found.

Then give me a short summary of:

1. Which files were created
2. How the architecture is structured
3. Which gameplay values I can adjust for fine-tuning
4. How to run the project locally
5. Which steps are needed for a local Android test build
6. Which steps will later be needed for an iOS test build

The current browser release is a web export. The original prompt also describes preparing Android and iOS exports.