Hey there! Happy New Year and welcome to Grobo progress in 2019!
In this post, I’m going to talk about the ledge animation and give some insight into my process of deciding when to iterate an animation, along with working through troubleshooting a certain issue involving sliding/jitter and playback problems so you can do things the smart way the first time if you’re making a game in Unity.
The purpose of the ledge is to be a hold state so people don’t go walking off edges while playing unless they really want to. We needed an animation where Grobo would be interacting with the ledge in some way, whether that was a teeter or something more curious. He couldn’t lean out too far for fear of causing confusion with the repulsion engine’s animation and he is positioned squarely on a tile, not over it.
My sense was that Grobo wouldn’t be “afraid” of hanging off an edge as he takes no fall damage and he’s secure where he stands due to his mastery of gravity, so his animation should not be a teeter as that implies apprehension. So instead, I created a roll onto his heels with a simultaneous look down.
The first version of the ledge looked like this before being colored.
This animation works in a vacuum, however, as is true with many things in this game, when properly sized, it was too subtle and too slow.
As a team, we brainstormed and decided to be inspired by Mewtwo’s ledge in the Super Smash Bros series.
Next, I made an exaggerated lean animation that I call the seal. In it, Grobo goes from standing at an angle to tilting nearly parallel with the floor. However, the seal had issues when implemented. His feet were sliding all over the place because Unity was centering the animation in the middle instead of at the feet.
Here’s what this animation was intended to be.
And here’s how it looked in Unity. Please note the shape of outline around the sprite. This is how Unity automatically cut it.
This is a problem we’ve encountered before in the gravity shift animation and we weren’t sure how to fix either then or at this point. I did all kinds of silly things to mitigate the problem without much success like messing around with the centers of the sprites and leaning Grobo out farther. It seemed that Grobo slid more when the back of his head went past his heels, but the weird pivot was still occuring and now he was leaning too far over the edge.
By now I was pretty frustrated. It was time to do some tests to figure out the root of the problem. I decided to try something that in hindsight was completely obvious and that Steven and I had discussed before, but hadn’t ever tried.
When making sprites in Unity, you can either let Unity do the work to your imported sprite sheet or you can set how the sheet is cut up yourself. We had been auto slicing the sheets.
Because each frame is irregular in height and width, so were the auto generated sprite boxes, which you can see based on the outline in the previous gif. All of these disparately shaped sprites were being lined up by their centers and this caused sliding as the center of the movement in the animation is not the center of each image, but the toes. However, even in a test environment with the pivot manually lined up at the toes, the animation still did the seal thing.
At this point, I realized that Grobo’s feet were not consistently in the same spot in every individual frame in the animation due to both error on my part in creating the sprite sheet and the fact that each auto sliced sprite was a different shape, something that isn’t a problem in animation software where your image exists in a fixed location at all times.
We did some testing to see if equally sized boxes would solve the problem. We noticed that Grobo was now jittering, as in, moving around at tiny increments in each frame, creating visual noise. However, it seemed like the pivots were beginning to come into line as he was sliding less. I was reasonably confident that a more consistently made sprite sheet and an equally sized grid would solve our problems.
Here is an example of a Unity generated grid with my poorly lined up sprite sheet.
In the end, the best way to mitigate the problem was to make certain that the tips of Grobo's toes, the only stationary portion of the animation, were lined up in the same place in each cell of my grid. The grid was set up based on the total width of my Photoshop image and how many sprites I wanted per row, plus extra room. I did this with snapping to guides. Then I had to set an identical grid in Unity. Unity can automatically generate these using numbers you input, which you will already have since you did this exact thing in Photoshop already. These individual cells then had to be manually positioned with Grobo’s feet in the bottom right corner. The reason for the manual manipulation of each cell is due to the fact that Unity creates all the cells abutted next to each other, which doesn’t line up with the actual sprite sheet.
Here is what my Photoshop setup looks like for this particular sprite sheet in the end.
And here it is in Unity.
After this laborious effort, the animation played back correctly. But it revealed to me that the seal had an error I had made that wasn’t worth fixing, so I redid the animation one more time. Now, we’ve got a working ledge.
So TL;DR? When your animation is playing back incorrectly in Unity using automatic sprite slicing and you’re cutting sprites for complex, orientation changing animations where the center of the the sprite is not the center of the movement, figure out how large of a bounding box you need based on your sheet, and manually set and align the sprite sheet to eliminate the sliding/jitter using grid slicing.
Thanks for reading and we hope you’ll join us next month for more Grobo info!