Most of the interactable objects in our game needed to be animated in some sort of shape or form and I was mostly left in charge of that. The animations would need to be loaded in somewhere and managed and played for the objects being created. Some objects, such as the background non-interactables had their animations specified in OGMO editor, to be able to re-use the same class and play different animations with it, rather than hard-coding it. My teammate Radu was implementing animations for the Enemies, and even though it’s roughly the same task, we did it quite differently, his solution being “more correct” in cases where the problem is identical between our work. He used the Object Groups to load in the animations only once and start playing them. However, that also meant that he managed the animations from the Object Group as well, which is slightly inflexible, as it needs to generalise to all objects in the scene. My solution is (slightly) more costly, but was the most obvious way of loading the animations in, especially when they’re specified through ogmo:
Basically, the idea is to load the animations at object initialisation time and put them in the animation cache for re-use. However, trying to do that for each and every one of them would be incredibly wasteful, so I did a slightly less wasteful thing – try to use the animation, and only load it in if it’s not there already (loaded by another object). This means that we don’t know which object initialises the animation, but we probably don’t care either. The only implication is that it performs the check for all objects, whereas it wouldn’t need to if we did it in an object group.
Loading animations specified by OGMO would be tricky in an object group, but I should have definitely followed Radu’s approach and created object groups for the classes that use a common animation. Overall, it didn’t cause any issues in the short or long term, so I guess it’s not the most meaningful thing to stress about.
The one thing we did wrong, however, is hard-coding the animation names for the non-ogmo specified animations.
This really becomes difficult to track since it gets duplicated everywhere, and we should have definitely defined it as constants somewhere, as that would make it so much easier to manage if a folder name changes or something. This is a really good lesson for the next project and it’s one I already applied when it comes to playing audio in our game.
Godsend Programming #6: Level asset animation
Most of the interactable objects in our game needed to be animated in some sort of shape or form and I was mostly left in charge of that. The animations would need to be loaded in somewhere and managed and played for the objects being created. Some objects, such as the background non-interactables had their animations specified in OGMO editor, to be able to re-use the same class and play different animations with it, rather than hard-coding it. My teammate Radu was implementing animations for the Enemies, and even though it’s roughly the same task, we did it quite differently, his solution being “more correct” in cases where the problem is identical between our work. He used the Object Groups to load in the animations only once and start playing them. However, that also meant that he managed the animations from the Object Group as well, which is slightly inflexible, as it needs to generalise to all objects in the scene. My solution is (slightly) more costly, but was the most obvious way of loading the animations in, especially when they’re specified through ogmo:
Basically, the idea is to load the animations at object initialisation time and put them in the animation cache for re-use. However, trying to do that for each and every one of them would be incredibly wasteful, so I did a slightly less wasteful thing – try to use the animation, and only load it in if it’s not there already (loaded by another object). This means that we don’t know which object initialises the animation, but we probably don’t care either. The only implication is that it performs the check for all objects, whereas it wouldn’t need to if we did it in an object group.
Loading animations specified by OGMO would be tricky in an object group, but I should have definitely followed Radu’s approach and created object groups for the classes that use a common animation. Overall, it didn’t cause any issues in the short or long term, so I guess it’s not the most meaningful thing to stress about.
The one thing we did wrong, however, is hard-coding the animation names for the non-ogmo specified animations.
This really becomes difficult to track since it gets duplicated everywhere, and we should have definitely defined it as constants somewhere, as that would make it so much easier to manage if a folder name changes or something. This is a really good lesson for the next project and it’s one I already applied when it comes to playing audio in our game.
Related files
GCObjGround.cpp – https://drive.google.com/open?id=0B_BnvnFZLH7mUU4yR1hhTDlQOVE