profexorgeek
3326
6
3
My first rigging test before starting to use Spine. Animation in this tool was much slower, so we implemented Spine into FlatRedBall
My first animation test in Spine editor
A little more dynamic animation with a collision box to test collision bounds.
A slightly more complex animation including a sprite swap (the lid goes from closed to open) and more types of interpolation.
Bringing the Spine-based entities into the game engine to test perf rendering tons of them at once. This was our first test of integrating the runtime.
An end-to-end test of animations wired into the game: spawning, resting, movement, attack, damage, death. This proved that the runtime worked end-to-end locally.
Network integration started... Testing connection process across several clients. Making sure join state and chats come through the network properly. This is a networking library I built myself so I'm testing both the lib and the game at the same time.
Testing syncing of an entity across a host and a client after game is successfully started. Still crude but spawning, movement, and animations are synced between two clients.
blaghart
So say you load your sprites in and the game chugs. Where do you look first to address that? the sprite? the animation? or the engine rendering?
profexorgeek
There's a lot to this question. First, those aren't just sprites. They include sprites but they also have collision and other things. For example, in one of our tests it wasn't sprite rendering that slowed stuff down but colliding all of the objects against each other.
The way you find this is profiling. Basically you run the game while a special process looks at things like memory allocation, processor usage, and more. That will show you the most "expensive" processes, then you optimize!
blaghart
How would you optimize? would that be code specific or would it require altering the sprites/hitboxes to be smaller?