53 lines
3.0 KiB
Markdown
53 lines
3.0 KiB
Markdown
- [x] seperate "spawn velocity" into a seperate (optional) component
|
|
- [x] try dynamically spawned entities with save & load
|
|
- [ ] fix issues with multiple entites having the same name ??
|
|
- [ ] fix issues with system ordering
|
|
- [x] add sets for proxy-replacements
|
|
- [x] annoying camera movement : camera should be saveable as well
|
|
=> we need to be able to only save the camera position (and name)
|
|
- [ ] only spawn "new level" stuff when transitioning from menu to game ?
|
|
- [ ] put more thoughts into this
|
|
|
|
- [ ] rework how save-loading is triggered
|
|
- [ ] no hardcoded keypresses
|
|
- [ ] ability to choose what save to load ?
|
|
- [ ] take a look at bevy_moonshine_save
|
|
- [ ] move to system pipelines
|
|
|
|
- [x] split Blueprints into a seperate crate: perhaps bevy_gltf_blueprints
|
|
- [x] how to deal with states that are not defined as part of the plugin/crate ?
|
|
- [x] same issue for the assets
|
|
|
|
- [ ] support multiple main scenes in the blender plugin ?
|
|
- [ ] study possibilities of expanding the bevy & blender tooling side to define UIS
|
|
- likely using the blender data only as a placeholder/ directly replace in Python
|
|
|
|
- system ordering ?
|
|
load level => inject components => spawn blueprint entities/rehydrate => (loading) => replace proxies
|
|
OR
|
|
load level => inject components => (loading) => spawn blueprint entities/rehydrate => replace proxies
|
|
|
|
- perhaps it does make more sense to save ALL entities and not just the dynamic ones? mostly as we have the blueprints anyway, which should cut down on needed data ?
|
|
|
|
|
|
- different approaches for dealing with saving/loading
|
|
in particular the problem of entites that are defined as part of the level but can be despawned (items that get picked up etc)
|
|
|
|
Bevy side
|
|
* var 1 : spawn all entities completely, despawn those saveables that are not actually present in the save data but that have been spawned
|
|
* problems: needs correct ordering of systems otherwise the diffing above will not work
|
|
* pros: minimal save files, only bevy boilerplate
|
|
* cons: requires spawning potentially huge gltf files just to "peek" inside of them to know if they are saveable
|
|
|
|
|
|
* var 2 : save both saveables & unsaveables but only save the absolute minimal data for unsaveables
|
|
* problems: how to combine different filters into a single save file ?
|
|
* pros: easier diffing, more homogeneous handling
|
|
* cons: a lot bigger save file with mostly useless data
|
|
|
|
Blender side
|
|
|
|
* var 3 => CHOSEN OPTION : mark INSTANCES in advance as static/dynamic (ie saveable or not), thus this data would be present in the world/level and not inside the gltf data
|
|
* problems: would require adding custom properties to each instance in Blender (COULD be automated by 'peeking' inside the collection)
|
|
* pros: simpler, and this might be more "editor-like" where you would mark each item as static or not
|
|
* cons: potentially a lot of manual work / error prone |