Juju
Member
Why GameMaker's Animation System Isn't Designed For Artists
It should be pointed out that it's probably not intended for dedicated artists. Still, it's not good enough for Irkalla.
It should be pointed out that it's probably not intended for dedicated artists. Still, it's not good enough for Irkalla.
I've been working on something of a secret project for the last couple of months and it's about time I shared some of what I've learnt in the process.
It's undeniable that Irkalla has some very sexy art, the animations have weight and detail in spades; you can almost feel the servos moving! The aesthetic, and the way it's being expressed, is what attracted me to this project in the first place. The programming mentality here is necessarily a supportive one - I need to build tools and features that lets designer/artist Skydsgaard work his magic.
After building an MVP, it became very clear that the foremost priority was facilitating animations to bring each and every asset to life. I personally use GameMaker for its extraordinary production tempo - we can build games extremely fast. I'm a great believer in fail-early-fail-often and having the tools already in place to build half a game gets you closer to that high frequency iteration sweetspot. This does come at a price, however, and I think we all know what they are (*cough cough* room editor *cough cough*).
Whilst I built a working platformer with the requisite features in a couple of days, the default animation system simply wasn't supporting the fantastic work that my partner in crime has been producing. Animations were linear, almost static, and lacked temporal variation and detail. We're using Photoshop to put together the artwork and it allows for individual frame timings. Bringing that design environment closer to the game, allowing for subtle tweaks at any point in development without interrupting the flow, is absolutely essential.
Most GameMaker games tend to skew towards timing locked into the framerate due to its architecture; the image_speed internal variable is locked to the framerate because it works alongside a simple incrementer. Irkalla will run at 60FPS, naturally, but I'm wary of locking any timing to the framerate. It bit Hyper Light Drifter in the ass and it bit Nuclear Throne in the ass... as my mother told me, "Don't double up on other people's mistakes."
The animation system needed to accomplish three things:
- Allow for easy adjustment using human-readable configuration in an external file
- Be framerate independent
- Allow for custom timings per frame, and be able to attach other meta data to each frame
Yeah, it's a bit clumsy and requires more hand-inputting of numbers that I'd like, but GM supports JSON natively and it gives us the design space to implement absolutely anything per-frame in the future. Indeed, we've already used the metadata feature to attach the player's primary weapon to the character for pinpoint animation flexibility, even with swappable assets.
Here's a sample of the JSON (values liable to be changed at any time, by design!):
Code:
{
"spr_mc_l_hit": {
"gun y": {
"1": 21,
"2": 21,
"3": 21,
"4": 21
},
"gun x": {
"1": 13,
"2": 13,
"3": 13,
"4": 13
},
"delay": {
"1": 0.2,
"2": 0.2,
"3": 0.1,
"4": 0.1
}
}
}
We have access to the internal current_time read-only system variable, allowing us to read a millisecond-accurate time. You can also store the start time of each frame and use a roll-over error value as well, but I've found the start time method to be faster to program and faster to debug. Actually building this system requires some messing around with the internal system for traversing JSON (learn your data structures!) and is probably a bit too specific to be exciting.
Trying to bring the game engine closer to the design tools that people use (external or internal) is always worth it. Spending time on good workflow early on yields massive benefits when things get tense close to deadlines!