Enter the Flixii Framework
In my last post I revealed that I was making a 2D sprite-based game in Unity. The challenge with that though is that the standard workflow for setting up sprites and animations in Unity is abysmal. I mean just truly time-consuming, and very brittle. Perhaps I should have just grinned and bore it? Well, of course not. Instead I came up with a solution to use Unity’s IDE as little as possible.
For the record, I’m hardly alone in severely disliking Unity’s approach to setting up sprite-based animations, and other developers have even solved this exact problem before me (to be used with AseSprite, specifically). However, I decided to roll my own solution for two reasons:
1. I was already familiar with ProMotion for creating sprite-sheets, and refuse to use another tool for level-tiles anyway, as it’s really just great at that. So learning how to use another (inferior in some ways) tool made little sense to me, and I would probably just confuse myself misremembering keyboard shortcuts, like when I switch from using Sublime to Visual Studio. (And I’m sure AseSprite is great in it’s own way, don’t send hate mail or dox me).
2. There’s zero promise of support from the developers of the AseSprite Unity tool.
So then it was settled! I would roll my own solution. But where to start? The first thing I did was reflect on how I knew Unity’s solution could be so much better: because it was just incredibly easy with Flixel’s FlxSprite class.
Compare the above code to Unity’s workflow: changing all the settings of each imported sprite-sheet manually, slicing up the sprite sheet by hand, then making a new empty animation, dragging each tile to the right animation, forgetting which tile you need to grab next because you’re not working with indexes but based off how the sprite looks visually which is very subtle one tile to the next, and then… doing it all over again for each sprite and all of their animations (oh and did you remember to delete every single transition animations, which are added automatically to the animation manager, even though they make zero sense for sprites?). Just throw me into the Abyss.
Instead of all that nonsense, I thought to do just one thing: port FlxSprite (and it’s parent) classes to Unity! It essentially would act as a wrapper, so that adding and playing animations would seem as easy as Flixel, while in the background it’s really just calling a bunch of MonoBehavior code. With that as my goal, I got right to work. Should be easy enough (Narrator: “It wasn’t”).
Considering how differently these “ported” classes would have to work under the hood (as you’ll very soon see), I was uncomfortable with calling this “Flixel for Unity”. Additionally, I wanted to actually rely on Unity’s components, and eventually add my own unique classes to the library to handle move states. I decided to come up with a new name for my endeavor. Thus, Flixii was born!
The first step to solve was not having to manually change the settings of every single sprite-sheet I imported, and to automatically slice up the sheet at import and not at runtime (which is essentially how Flixel works). In other words, the first step in creating the library was to accommodate for the differences between the two engines in a way the wrapper class just can’t fix. How I solved this particular issue I’ll expand upon in my next blog post.