Allow several players to play a single level at the same time in multiplayer mode.

Acceptance Critera

• There is an option on launch to allow for a multiplayer game.
• This shouldn't complicate single player mode at all.
• Single player mode should remain the default.
• The is a dedicated screen for configuring the two player game. e.g. waiting for additional players to join the session.
• In multiplayer mode, there is an additional spacecraft for each additional player.
• Additional spacecrafts are controlled identically for each player from their respective remote systems.
• This should not have a visible impact on the game's snappy feel.

Design Suggestion

• use bevy_ggrs

Add serialisation for the level struct to allow the data to be saved and loaded to disk.

Acceptance Criteria

• Levels are losslessly serialised to json
• Levels are losslessly loaded from json
• The entry point for starting the game is loaded from some default level file rather than from hard coded default level code as it currently is.

Design Suggestion

Use serde?

There are additional weapons which the player can acquire. This would serve as a proof-of-concept for adding further weapon types going forward.

Success Criteria

• There is an additional weapon available to the player
• Weapons are gained from upgrades
• The new weapon should be more powerful than the default.
• The new weapon should change the way a player needs to play.

Acceptance Criteria

The rendered background of the level is defined in the level data.

Acceptance Criteria

The enemies you encounter are defined in the level data.

Currently the background and foreground colour fields in the Sprite component are totally when the sprite is rendered.

Acceptance Criteria

• Foreground and background colour fields of sprites are rendered to the main buffer.

Considerations

It would be nice to use "True Colour" by default for terminals which support it, with a sensible default for terminals which do not.

Some terminals don't support the Kitty Terminal protocol extensions. In these terminals we do not get key release events. This manifests in a bug where the player never leaves move / shooting state after a key is pressed.

In such terminals we must handle these states differently because we can't rely on key release events.

The fix should not compromise the state handling for terminals which do support the feature.

Add a screen which is the first landing page when the game is started. A new game can be started from here. This page will also be important as further features come later down the line, like settings, loading a previous game, etc.

Acceptance Criteria

• The page should be implemented using the preexisting ratatui widgets.
• The screen should include a "start" button
• The screen should include an "exit" button

Enemies can take on different forms and have different behaviours. This would serve as a proof-of-concept for adding further enemy types going forward.

Success Criteria

• The single enemy type is replaced with three different enemy types.
• The different enemy types should appear different (different sprites)
• The different enemy types should move differently.
• The different enemy types should introduce different threats to the player.

Add a state which to handle the "game over" state. Currently the game simply exits.

Acceptance Criteria

• The state should be entered whenever a level would end, either by beating the level, or by dying.
• There should be an easy escape from this state back to the title page.

Design Suggestion

• The game pauses
• An overlay is drawn on top of the level widget indicating the level has finished. "You Won", or "Game Over".

We use https://github.com/charmbracelet/vhs to create these in Ratatui

I'd caution against storing the image directly in your repo though as it tends to cause your repo to get bloated over time.
VHS has a publish command which is useful.

Add a sprite sheet feature to the existing Sprite component. This should allow for simple animations of sprites by adding a parameter which moves the frame of reference within an atlas.

For example, animating between the following two buffers every second.

!_!
>o<
!_!

and

i_i
<o>
i_i

Planets can be included in a level's background render.

Acceptance Criteria

• Planets can be procedurally defined and drawn (allowing to randomise the process)
• Planets form perfect circles rendered in ascii
• Planets have nice "planety" ascii textures

Upgrade entities can be picked up by the player to provide the player with bonuses. This story would serve as a proof of concept so that further upgrades can be easily added in the future.

Acceptance Criteria

• An upgrade is sometimes dropped my killed enemies.
• The upgrade temporarily increases the player's speed.
• The upgrade is only "alive" for a limited time.