fishfolk/jumpy

Playable character select

erlend-sh opened this issue · 4 comments

Description

We've got a fair amount of unused vertical space in the character-select screen. How about when your character has been selected, your character will descend down unto a platform underneath, where you can run around and play with weapons we randomly spawn down there.

All fish will be in no-damage mode however. That's something we can play around with a bit more later, like upon hit we shift them into a ghostly ethereal form for a few seconds before respawn, stuff like that.

Screenshot 2024-03-28 at 18 41 01

Alternatives & Prior Art

https://duckgame.fandom.com/wiki/The_Lobby
image

Thoughts on technical details for this.

Right now we do this annoying thing to render the players inside of egui. We have egui setup only to render on top of the game, and that makes sense. That means, though, that it's not possible to render the game on top of the UI, like we do with the players.

To do it, we take all the player meta and we use it to create egui images that we manually animate like they do in the game, except inside of egui's UI space. It's essentially completely re-creating the atlas rendering, hat attachment, etc. which is not cool.

The "right" way to do it, which is not yet supported in bones, would be to allow you to specify a custom texture target for cameras, in bones. This would play extremely nicely, if we did it right, with bones multi-world setup.

That would allow us to create a bones world for each player in the player selection screen. Each world would have it's own camera rendering to it's own texture, the size of the player selection box.

This allows us to use all of the game physics, etc. that we want to enable in the character selection box.

To render it in egui, we simply paint the texture that the camera is rendering to the box, and we don't have to duplicate any game logic.


Other than multi-world, this is something that is mostly implemented in Bevy already. Multi-world might make things trickier to get the rendering right, but we otherwise just have to look into it and implement the camera render targets in Bones.

Linking #473 for some references / existing discussion on this sort of thing.

Oh gosh, I totally forgot that existed! I’ll merge these two together by reposting there.

@zicklag please repost your comment to #473