I was looking at the Unity 2022 changelog and got excited about the new options for importing PSD layers and it had me wondering why there wasn’t a feature for this with Aseprite.
Aseprite is arguably the go-to software for animated sprites for Unity games. It features a really nice tag system that allows you to name a set of frames in your animation. So you can have one long animation with parts being titled “Idle”, “Walk”, etc. When exporting to a sprite sheet you can also have it order the sprite sheet based on the tags, e.g. each tag gets its own row for the sprites assigned to it.
Turning a sprite sheet into animations in unity is tedious. For smaller things, it’s not that big of a deal but for bigger animations, such as top-down with 4 look directions, it’s a pain in the ass. The pain increases if you want to change the length of a given animation as you’d have to update every frame after that.
It’d be nice if Unity supported .ase files and their tag and layer systems in a future update.
Is this even necessary? There are at least one Aseprite importer on the asset store, plus at least one github repo that does it too… I haven’t used them but from their descriptions, it certainly sounds like they do most of the grunty work automagically. Is this not true?
I can confirm that none of them currently work. Most haven’t been updated since 2017.
I’m very surprised that aseprite isn’t fully integrated in to unity by now.
why are you surprised, unity is not supposed to be a pixel art engine, do you even understand how hard it is to make pixel art work in unity? just look at the frontpage of these 2d forums, the majority is people complaining that pixels arent working like they want (because guess what, unity was not created for pixel art)
have you ever gone to an rpgmaker forum and see people complain about:
- gap between tiles
- pixels flickering when character move
- pixels flicker when camera move
- help my pixels are warped
- pixel perfect camera not working
Aseprite has decent export functions to get the data to png files. Yep, it is additional effort and requires some organisation to keep track between aseprite files and the ones in your Unity project, but I personally find it manageable.
I make Pixelart games in Unity. I don’t think there’s a better game engine for Pixel art. The first 4 problems you list sound like pixel creep, which is a problem that has 1st party solutions. The fact that lots of beginner questions are being asked doesn’t really indicate to me that Unity isn’t a good tool for it.
https://github.com/talecrafter/AnimationImporter/releases ← This was the Animation Importer I used for the last year, but it’s stopped working.
https://assetstore.unity.com/packages/tools/sprite-management/auto-importer-for-aseprite-pro-174615 ← This one is good, but it crashes in 2021 when exporting to a standalone file which already exists, unfortunately. This makes it unacceptable for use in a collaborative environment in my opinion, since references to the produced assets will not be retained.
I really really don’t want to have to reinvent the wheel here. Seems insane to me that there’s no up-to-date aseprite importer, since I know a lot of people would happily pay for it, but they’re right-- even though there’s ~6 solutions I’m aware of, they’re all too out of date to work with newer version of Unity and the maintainers are AWOL afaict (I’ve reported bugs to them and even provided bug fixes I researched myself and none are responsive).
Thank you all for your feedback. I just want to add that I have captured what you have written here, as feature requests, so that we have it in our backlog of things to consider for future 2D toolset improvements.
Thanks! Fwiw, I ended up all-but-rewriting this one to make sure it can write to external files. The bugs seemed like just careless stuff indicating it might never have been tested, rather than a version mismatch. I’d think it wouldn’t be very hard for Unity to make an integration in one engineer-day or so (that’s how long it took me).
The fact remains, if y’all do make a first party solution, I’d be thrilled.
- #1 important thing imo is that it exports to external files for collaboration. Putting everything on the file context is one of those things that seems nice if you’re solo-dev, but creates mountains of bugs and inconvenience when you’re actually working on a serious project with other people.
- And, of course, that it exports animations and sprites reliably
- Sprite sheets should be structured deterministically (i.e., if I want to depend on the structure of the texture to integrate normals or emission maps, etc, I can)
- Remember my preferences for which animations are looping
- Everything else is gravy, keeping a default TextureImporter preset would be nice
I’m happy that you got it working again, and thank you for the additional info on what you would like to see in a first party solution!