Layered Sprites
Hello, world!
What I’d like to speak at you about today would be composite sprites, or multi-layered sprites! We thought it would be a really cool idea to have modular equipment for the player, but aside from just affecting stats, we want it to affect how the player looks himself. More than that, we were thinking it’d be cool if you could have your hat shot off, or if an enemy could steal your gun and you could watch it fly away (and maybe steal it back :D).
Implementing composite sprites also means we can have dynamic enemies and more interesting boss fights. We haven’t dealt with composite sprites in the likes of Vectorman and such yet, but I’m sure we will. It’d be neat to have large bosses with moving parts.
So we had to figure out how we wanted to do this. The beautiful thing about programming is that there is almost an unlimited number of ways to implement something. It’s also a bit of a curse. We found a couple of different ideas for doing things and kicked some of our own around a little as well, but settled on the equipment of the player being their own entities in and of themselves. We decided to have them be actual objects, so they could have physical properties and be affected by enemies and different situations.
One of the benefits of this is that we didn’t have to code a method of generating an entirely new sprite sheet for the player based on their current equipment. We can just grab the (X, Y) coordinates of the player and tell the equipment where to be from there. It’s actually a bit of a parent-child relationship. The player owns the equipment, so the player essentially tells the equipment where to be, and the player’s state defines the animations and such for the equipment, as well as the player itself.
The only major hiccup that we came across while trying to implement it, is that Impact kept deciding to draw the hat and coat behind the player. I almost tore my hair out trying to figure what exactly was going on at first. I wrote a couple of log statements for debugging it, and could see that the object was being instantiated. The hat was in the memory, but it wasn’t appearing! Well, that’s when I figured out it was drawing the pieces of the player in the wrong order. Impact has a property for entities called the zIndex. I changed the zIndex for each piece of the equipment and also for the player, but it was still drawing in the wrong order. Ugh. Well, not only did I have to specify the zIndex, but I had to tell Impact to sort the list of current entities by the zIndex. I called that sort function, but it still wasn’t drawing correctly. It turns out, I had to tell Impact to sort the entities by zIndex in between the update cycle, before the frame was drawn and before the next cycle began. Once I did that, everything was hunky-dory. Now it’s just a matter of cleaning things up and making it nicer to add new things in the future.
After getting the state machine and these layers of sprites lookin’ good, there’s some business things we need to take care of, so it might be a day or two before I’m chugging on the game again.
Tune in next week for another episode of 10000 Hours: A Deceitful Programming Extravaganza!
