Extract as a set of small librairies instead of a whole integrated engine ? #89
Labels
No Label
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 Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: epervier/epervier-old#89
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
Think about what is useful or not, it'll also make tinier the project (and more manageable). What would be nice also would be to drop some code that would be better handled by external libs (like knife, etc)
-> epervier/assets
-> epervier/menus
-> epervier/utils
...
There is the question if each should have their own project or not. For the world system it would be useful, maybe for the menu ? Not sure for other.
Possible list
-> epervier/world (maybe separate in two type of world ? But a lot of modules would be duplicated, so...)
-> epervier/assets
-> epervier/screen
-> epervier/menus
-> epervier/datas
-> epervier/save
Should datas and save be separated or the same modules ?
Maybe we should divide world into as set of "world utils" and worlds and make the world the thinest layer possible around bump2D/bump3D/maps ?
Features that would be dropped/replaced:
epervier/screen.lua
-> Fuse CSCreen with my screen module
-> Add most of the code of the transition system inside screen
-> Makes transitions just some data blocks and the code part be handled more in the screen librairy