Picking my hobby game dev battles for this weekend.
I really want to do some animation system stuff built on aseprite, but if I want all the fun hot reload support I need to figure out how to downgrade my aseprite version.
Steam let me pin to the previous release, which works with LDtk. LDtk has fixes incoming for some changes in recent Aseprite versions, but who knows how long it'll be before that all lands.
LDtk should be able to hot reload Aseprite tilesets
meanwhile Bevy can hot reload LDtk scenes
The next question is: will I be able to access the Aseprite animation clip data this way? I don't see anything in the APIs for this. I might need to load the Aseprite data twice, once in LDtk and once in the engine.
It seems as though the LDtk lib I'm using to load the level in Bevy is essentially just passing the .aseprite filepath directly along to Bevy. I think this means I can now go pick a separate crate that registers an asset loader for .aseprite files and bevy will just delegate to it.
If it turns out this is a dead end, my Plan B is to just use a placeholder graphic in LDtk, or no use no graphic at all (just a debug wireframe type thing to show the player spawn is fine), then manage the sprite completely separately in engine.
I think I will cut LDtk out of the loop here. It's going to simplify things to not have the cross-cutting compatibility concern between bevy+ldtk and bevy+aseprite and ldtk+aseprite.
Placeholders and wireframes are fine to see in LDtk, I don't need anything more for animated things.
Later, when I start developing art for levels, I can revisit as it'd be nice to have tiles reload. For players and mobs, etc it's not so important.
I need a kick in the butt to just dive in and make a mess. I'm having sort of a "blank page syndrome" situation because I hate the prospect of having to audition multiple libs.
It's a start, anyway. I'll try to build on this in a more meaningful way tonight.
I'm using that first pick - bevy_aseprite_ultra and the hot reloading will be a huge boon.
I cut all the player sprite data out of LDtk. I'm attaching the Aseprite data to the player spawn after the level loads. The existing code I had for moving the sprite from layer to layer seems to still work since the layers are all modeled into the bevy scene graph. 👏
If I can get the crouch and "up" animation clips wired up again, I'll commit this to the repo and start working on a more human-like figure for placeholder art.
After that, I'll be able to look at making a state machine for the player and using animation durations to drive transitions. Fun.
The video in my last illustrates a bug I noticed this weekend where if I jump a lot sometimes the player shifts to the right by 1 tile grid. I have no idea why.
I'm not going to fix it now, but I guess I should log it as an issue. I doubt it'll just fix itself. I do plan to refactor the movement code soon, and I can hopefully figure out what's going on at that time.
Oh I see. This is a problem where the colliders and "bumpers" around the player are intersecting and the code I wrote to self-correct in those situations is favoring a shift right for some reason. The left, bottom, and right bumpers are all activated here.
@onelson I recently decided to have another go at some game dev: so far I've spent most of my the time I allowed for that yak-shaving by trying and failing to get Blender to run on my ancient PC (it briefly shows a blank window before segfaulting)
Add comment