Component Based Animations

While I have studied a bit of game development in my free time there are many facets that I have never touched. This, united with the fact that I am not a professional developer (even if I have worked for a bit in R&D at a big company, something that at times still happens), means that I often have to learn by improvisation.

Exekiel Facial Animation

Exekiel Facial Animation

Do not get me wrong: even if I naturally learn more and faster by direct experience, I firmly believe that you have to study – hard – to obtain a good level of skill in any form of craft, but there are certain thresholds that you need to overcome in different ways that only studying, unless you are a genius: one of them is by experience, another one is teaching what you have learned.

What does it have to do with animations? Well, I started working on WD knowing very little about animation, other than moving around object using parametric equations and what is a spritesheet. I knew that animations had to be reusable and that I wanted a way to avoid hard-coding them (of course you need to be able to define custom animations for mods). What I ended up with is a component based animation system, without even planning to use this pattern.

In a nutshell: every object that is drawn on screen is a Widget and every Widget has several components: Borders, Backgrounds and Animators. Every Widget contains a list of Animators that are executed at every frame. So for example you can add a “Flash” Animator and a “Shake” Animator to an object when it is hit, and you will see it flashing red and shaking a bit to show that the attack connected.

Exekiel Animations

Exekiel Animations

Once I have written the shake animation I can apply it to everything, for example to the user interface when your character is hit or even to the whole game view in case of an earthquake, or even use it in combination with a “Translation” Animator to create a trajectory for a particle.

On paper this is wonderful and, I daresay, even elegant, but is it good for our goal and for a videogame in general? This pattern can be inefficient if a lot of objects animate at the same time (like the particle I was mentioning) and it could lead to an inefficient use of memory (WD is written in C# with garbage collection, so creating and destroying a lot of objects can be quite expensive both memory-wise and CPU-wise). Maybe having a single Animator with an internal queue of registered objects would have been more efficient, and even more ordered, while keeping the benefits of the current approach. Of course, I can always refactor if it becomes unusable later on, but with experience I would have been more confident from the start, and eventually evade a problem that could bite me later during development.

What do you think about this way of dealing with animation? What are your experiences or suggestions?

Thanks for reading.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s