Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Game Over screen (or Player death handling) #59

Closed
thombruce opened this issue Oct 20, 2023 · 2 comments · Fixed by #103
Closed

Game Over screen (or Player death handling) #59

thombruce opened this issue Oct 20, 2023 · 2 comments · Fixed by #103
Labels
core New feature or request ui Inputs, menus and the like
Milestone

Comments

@thombruce
Copy link
Owner

With the introduction of enemy AI in PR #58 the player ship can take damage and will despawn if it runs out of health. This causes several systems to panic:

  • Enemy targeting
  • Indicator system
  • HUD elements

Anything essentially that is querying for information about a .single() player entity.

These could be changed to .iter() or could be wrapped in conditionals (better) and this would seem to resolve the issue, but...

Well, for one, it sort of still makes sense to show the present location; currently this is determined relative to the player - we should see if this can be maintained such that the location persists after the player is killed.

Enemies should just use a conditional, and will eventually have other behaviours introduced that they perform in the absence of knowledge of a player.

The speedometer... can either be hidden or it could flash "ERROR" or "DEAD" or something.

All of that should be done to establish the sort of patterns we want to have in place for the future. That should be done first.

THEN... we make all of those changed redundant (for now) by introducing a "GAME OVER" pause state. The system changes are immaterial for the time being; but do them first so that we aren't just introducing the game over screen as a band aid - it might be removed or altered later, so that the world goes on even after the player dies (i.e. the GO screen is an active state rather than a paused one and you can see enemies salvaging remains and leaving, etc.). Because the universe does go on. You aren't the centre of it.

@thombruce thombruce added the ui Inputs, menus and the like label Oct 20, 2023
@thombruce thombruce added this to the v0.0.16 milestone Oct 20, 2023
@thombruce thombruce added the core New feature or request label Oct 20, 2023
@thombruce thombruce mentioned this issue Oct 21, 2023
5 tasks
@thombruce
Copy link
Owner Author

Death handling is now done, making the Game Over screen less of an urgent necessity.

The game no longer crashes on player death.

However, we should still handle the event of the player's death with a game over screen and allow the player to navigate back to the main menu.

@thombruce thombruce modified the milestones: v0.0.16, v0.1.0 Oct 21, 2023
@thombruce
Copy link
Owner Author

Should be easy enough to simply respond to the player's destruction by moving to a GameState::GameOver in a next_state parameter.

The GameOver state could initially just continue to the StartMenu state. When our UI systems are more complete (see #34 #88 #32 ) we should be able to show game stats...

We currently don't record any such stats. Consider adding an issue for that (player kills, XP gained, money earned, time survived, etc.)

@thombruce thombruce added this to Verse Nov 6, 2023
@thombruce thombruce moved this to Inbox in Verse Nov 6, 2023
@thombruce thombruce moved this from Inbox to Todo in Verse Nov 6, 2023
@thombruce thombruce moved this from Todo to In Progress in Verse Nov 8, 2023
@thombruce thombruce mentioned this issue Nov 15, 2023
5 tasks
@github-project-automation github-project-automation bot moved this from In Progress to Done in Verse Nov 15, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core New feature or request ui Inputs, menus and the like
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant