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

Gravity direction changes #3480

Open
4Denthusiast opened this issue Sep 7, 2018 · 2 comments
Open

Gravity direction changes #3480

4Denthusiast opened this issue Sep 7, 2018 · 2 comments
Labels
Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc. Topic: Physics Requests, Issues and Changes related to bullet, collisions, gravity, etc.

Comments

@4Denthusiast
Copy link
Contributor

This is based on how I intended to implement #3161, but as it's only part of that and has other uses, and other ways of doing that were discussed, it seems worth having a separate issue.

It would be interesting to have the direction of gravity change at different locations in the world. This would cause blocks to be rotated (e.g. plants could be supported by the block adjacent in the +x direction if that's locally down, and the rendering would be rotated), change physics and rotate always-upright mobile entities, like players. Use cases include:

  • Other world shapes, such as cubes or asteroid fields
  • Cavorite
  • I think someone mentioned a paper-mario themed mod as a possibility, although I've never actually played that so I don't know about it.

Architecturally, I am imagining this as a new interface, GravityManager or WorldRotationManager or something, which can be queried to return a rotation at any block-location, which is then applied whenever block rotation matters. If there are already block families, they are unmodified, and each member of the block family is rotated (so in some cases it may appear to be another). There would also be methods for things like finding what side of the adjacent block faces a given side of the current block, and so on, for convenience.

Although I think this would be cool to have, I've been hesitating because even when these features aren't in use, there would have to be lots of additional indirection, checking with the GravityManager trivial implementation before doing anything relating to block sides. I don't know how inefficient this would be, but it seems like it would come up a lot. Explaining this now makes me realise that much of this could be alleviated by having the trivial GravityManager override the default implementations of its methods and not actually use rotations. It's still possibly worth discussing, though.

@Cervator Cervator added Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc. Topic: Physics Requests, Issues and Changes related to bullet, collisions, gravity, etc. labels Sep 14, 2018
@4Denthusiast
Copy link
Contributor Author

An additional suggestion based on something @LadySerenaKitty said: make the gravitational field accessible as an arbitrary vector (for non-block things to use) in addition to a cardinal direction.

@Cervator
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Topic: Architecture Requests, Issues and Changes related to software architecture, programming patterns, etc. Topic: Physics Requests, Issues and Changes related to bullet, collisions, gravity, etc.
Projects
None yet
Development

No branches or pull requests

2 participants