Sort 2D sprites in 3D space

[erlend-sh]

http://andrewrussell.net/2016/06/how-2-5d-sorting-works-in-river-city-ransom-underground/

https://www.youtube.com/playlist?list=PLgPMWQb41awm62M5YE3zzAKyw5Odka6JR

https://github.com/conatuscreative

[zicklag]

@odecay @64kramsystem @edgarssilva I wanted to open discussion on this topic now because I'm wondering how far we want to go before we figure this out. It seems like it might be pretty important to do early.

Things like throwing items don't really make sense with our current 2D collision system, because if you throw the bottle in an arch it can go and hit fighters that are higher on the screen, even though it should technically be going up into the sky.

We'll need to position everything in 3D, and I think we will need to have 3D collision boxes for everything, including the players. The render position of the sprites on the screen will then be determined by a combination of it's y axis position and it's z axis position. Then we'd use something like the strategy described in @erlend-sh's links above for doing z-sorting of the rendered sprites.

I think fighter collisions will probably be simple enough, because it's just a square, but what will be more complicated is scenery. For example, if we have a car, we have to specify a multi-part 3D collision box for it, so that we have one section for the top of the car and the hood, etc. so you can jump up onto different parts of it. Specifying collision shapes for scenery might be an important role of an editor, and otherwise, we'll just have to deal with hot-reload combined with YAML definitions and debug rendering of the collision boxes.

Since rapier's 3D bevy plugin uses assumes you're using a 3D camera, and we are going to be using a 2D camera, we may also have to make our own rapier debug rendering system so that we can visualize the collision boxes in the space of our 2D rendering. We can do that simply enough with Egui, using the epaint API to render the debug lines.

---

I'm feeling like we should do this somewhat soon, before we get too stuck coding into a way that we are just going to have to un-do later, and I'd be find taking this on if nobody else wants to, but probably after getting #140 done ( which shouldn't be way to long from now ).

I'm wanting to try to get the foundations of the game nailed down so we don't have as many more PRs like #203 that kind of modify everything while other people are busy working on other parts of the game that are impacted by the big PR. Or at least I'd want to get those over with as soon as possible so people can keep adding feature in parallel.

But totally feel free to tell me what to do or that we have other ideas. Just let me know!

[erlend-sh]

Dropping this feature entirely is also a possibility. We are learning a lot of beatemup fundamentals in the process of building this game, and this feature is quite literally a next-gen addition that came in a much later iteration of the genre.

Should we hold off on it until a potential v2.0 post-publication? LF2 and similar games have plenty of fun to offer without this extra dimension.

[64kramsystem]

Dropping this feature entirely is also a possibility. We are learning a lot of beatemup fundamentals in the process of building this game, and this feature is quite literally a next-gen addition that came in a much later iteration of the genre.

Should we hold off on it until a potential v2.0 post-publication? LF2 and similar games have plenty of fun to offer without this extra dimension.

I think a minimum of 3D (or 2.5, or any term 😄) implementation is necessary. This is because characters move in a 3D space. Without a third dimension, we can't perform correct collision detection, which is a problem already now.

Simple example: when the flop is executed, if an enemy is a above the player, but still on the ground, it will be hit. This is because the flop is encoded as moving across the ground, rather than up (since the third coordinate doesn't exist).

[64kramsystem]

If LF2 is a beat 'em up with jumps (I need to check 😁), it must handle the third coordinate in some way (even if it fakes it, like disabling collisions while in the air).

It may be simple to implement in a basic way, so it's not necessarily bad, it really depends on how one chooses to implement it.

[edgarssilva]

Yes this seems like the big topic right now, if you want to take this on go ahead. If we want to delay this off as erlend said we could probably get away with working with a virtual y value.

So we have a Y-Jump that gets added to the real y before render and subtracted after render.

That way we can define that collisions only happen in the same y interval. Like intervals of 10y so the fighters don't need to be exactly the same height.

Not sure if that brings any unwanted problems.

[zicklag]

A virtual y would probably work easy enough for jumps and throws, but it might get more confusing once we add scenery that logically has a depth. Anyway, I'll check it out once I get the chance and see how an attempt at 3D goes. I don't think it will be way to hard, but I'll have a better idea after some testing.

[erlend-sh]

Maybe @tyt2y3 (F.LF) or @kazzmir (paintown) have some input here.