Article Why GameMaker's Animation System Isn't Designed For Artists

[Juju]

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.​

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

The solution was, all together now, Javascript Object Notation and Per-Second Timing.

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!):

{
  "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
    }
  }
}

With thanks to YAL for his JSON Minifier that allowed me to build and format these without too much dicking around. You'll notice that the delay times - technically they're dwell times for each frame - are decimals. These are in the same units (seconds) as Photoshop so transferring data from one to the other is as simple, and error-averse, as possible.

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!

 

[seanm]

Very Hyper Light Drifter-esque aesthetic, I like it.
However, locking the framerate isn't what made people dislike HLD or Nuclear Throne, they disliked them because they were locked to 30fps.

But I'm not quite sure what you mean by running the game at 60fps while unlocking timings? If the game is locked to 60fps then the animations should also be locked to 60 fps. If I can play this game at 120fps because of delta timing, then yeah you'd have to delta time the animations as well.

So are you using delta timing for your game? If you are I'd like to know if you have an elegant solution for managing everything. Delta timing has always been too much of a pain for my to bother using in GM.

 

[Yal]

With thanks to YAL for his JSON Minifier

Thanks, I'm glad you liked it~
(Nah, just kidding, I just can't see someone abbreviate YellowAfterlife without pointing out we're separate entities... and afterlife is one word, anyway)

I might be a bit too retroy, but I kinda don't see why you would benefit from dragging real-world time into your game. Some games built around delta time on old systems ended up being possible to exploit in various ways because of it, or borderline unplayable on modern hardware that doesn't slow down things expected to be slowed down... Donkey Kong 64 being a prime example, where abusing the delta-time system to clip through walls is the main reason many exploits work, and some of the missions that relied on slowdown get so difficult when emulated in the virtual console the recommended strategy is to savestate-scum.

IMO, the main thing GM's graphics editors lack are layers, but if you can load in stuff made in GIMP or GraphicsGale, you can just ignore that flaw... you've got everything you need to display a crisp 2D sprite already. For irregular animations, I generally use state machines' counter variable to decide when to switch... I use so few of them that it's too much work adding in a whole system to handle them IMO.

 

[Adrien Dittrick]

Thanks, I'm glad you liked it~
(Nah, just kidding, I just can't see someone abbreviate YellowAfterlife without pointing out we're separate entities... and afterlife is one word, anyway)

I had the exact same reaction

 

[Juju]

they disliked them because they were locked to 30fps.

About 6 months-ish before the end, Beau and Teddy investigated swapping from 30 to 60. Turns out it was a huge amount of work... if they had built a more flexible animation system (amongst other things) then their workload would have been lessened.

I kinda don't see why you would benefit from dragging real-world time into your game.

I'm gonna quote myself here -"Trying to bring the game engine closer to the design tools that people use is always worth it." Photoshop uses per-second; my artist spends more time thinking about art and less about converting seconds to frames.

Going realtime also has other more niche flexibilities, not least being able to cope with bouncy framerates (we're planning a lot of post-proc effects and the AI itself is fairly hefty), but also slowmo effects. It's a production decision.

 

[seanm]

I would guess that the actual logic of the game was going to be much harder to change than anything animation related. Due to the way they scaled the game, some stuff would be basically impossible to do at 60fps, or would have looked much worse.
However, if they had used an entirely delta timed system, then none of that would have been an issue.

So again, are you making an entirely delta-timed game here? @Juju If you are I'd like to hear your approach, because deltatiming in GM is hella annoying.