Proper camera logic, and new player movement limitations #62
Conversation
64kramsystem
force-pushed
the
limit_players_distance
branch
2 times, most recently
from
bcc0159
to
7ba5b3d
Compare
|
Ok, this is ready for review etc. Note that this logic has severe limitations. This is intentional; fully implementing the new camera logic requires extensive changes, which IMO should not be applied in a single PR. |
64kramsystem
changed the title
Setting the x value there is not necessary, and it's actually very confusing.
64kramsystem
force-pushed
the
limit_players_distance
branch
from
7ba5b3d
to
f166fad
Compare
|
Addressed all of them. Generalized the forward (right) limit to any number of players. Note that the limitation on the backward (left) behavior is not relative to the rightmost player position, instead, it's based on the boundary. This can make the distance grow more than wanted. This is intended, since the limitation logic will need to be updated along with the new camera logic. |
64kramsystem
force-pushed
the
limit_players_distance
branch
from
f166fad
to
c1d57fd
Compare
|
Extra note: I'm using a feature of the latest stable Rust ( |
This has also the side effect of simplifying the logic :)
64kramsystem
changed the title
|
Since nobody was looking, I've added the new camera commits 馃槵 馃槀 This now fully closes the first task of #29. |
|
Re-requested review, due to new commits with the new camera logic. |
Closes the first task of #29; the camera has now a proper logic, typical of beat 'em ups.
Boss-related logic is not yet implemented, since there are no bosses yet 馃槅