Refactor world/ #74
Labels
No labels
0. Imported
1. Bug
1. Clean-up
1. Feature
1. Improvement
2. Deliverable
2. Epic
3. Duplicate
3. Invalid
3. Need investigation
4. Assets
4. Birb Core
4. Debug
4. Dependencies
4. Inputs
4. Lang
4. Scenes
4. Screen
4. World
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: epervier/epervier-old#74
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The world system is an important part of the scene system, but have a lot of issues
What would be nice:
{x=1, y=4, z=3}
) instead of each position taking a slot, which should unify a lot of API{h=1,w=3,d=4}
).world.physics:setGravity(z, -4)
).Later possibilities :
Having a "utils.position" could be nice, with stuff like. Maybe an utils.dimensions would be usefull too ?
Those API would also be added in the Point/Point3D classes:
This would affect the GUI too, moving it to the position API
Same for assets, now I think about it... Maybe it should be done for 0.7.0 then ?
Maybe even the "position" of an actor should be handled by the hitbox system ? An actor would just be a collection of hitbox tied together, which would allow to refactor them a lot, with then some elements added on top of that (like a sprite system, etc)
It might be even be interesting to "fuse" the hitbox and physics system in a "body" system that would handle
Maybe a "no-hitbox" mode would be interesting for gfx and stuff like that.
Incrémental steps:
Other things
Future evolution it'll help
List of definitions
World-level
Object-level
( More stuff will be available to gizmos and collectibles, but that'll be for later )
Maybe that it would be nice to make some aliases to easily create actors, like
Which would need something like
Changes:
-> Keep a mixin for handling speed/position instead of a sub-object for the moment.
-> Keep the current hitboxes system where all hitboxes are relative to the parent.
-> Extract the hitboxes manager into a separate class too, it'll make the physics mixin a bit simpler
Would be a good occasion to remove every deprecated API (like the sprites API)