Gamer-XP
commented
1 year ago I had to implement my own solution for this at some point. Animation events are too, but not being able to adjust timings for each frame is the worst part for me. I made my own application for that at some point in the past, written on ancient language called Delphi Pascal. Found a link on the way-back machine from the old forum: https://web.archive.org/web/20160107164542/http://gmc.yoyogames.com/index.php?showtopic=664239
Right now I have it work with GMS2, but it's kinda buggy and I don't feel like updating it because the language is super outdated and hard to work with. If anything - I'd like to rewrite it from scrach on C#.
Anyhow, if we can have similar built-in solution - that will be awesome. So, in addition to what you said it should also have:
- Separate timings for each frame
- Ability ot add extra data on each frame. Like define points, hitboxes, maybe play sounds. In my solution, Each point and hitbox groups got unique name so you can find them later at runtime.
stuckie
KormexGit
Is your feature request related to a problem?
Currently, a lot of animation control has to be done with math. You either need to write a function yourself, or use one of the popular community functions. Examples include: animation_end, sprite_on_frame, sprite_hit_frame, and constructors for animating multiple sprites on one object. There's also no way to specify that an animation should NOT loop at the time you play it. You have to check if the animation has ended and tell it to stop animating manually. Adding more direct animation control should make animation handling easier for beginners and advanced users alike.
While some of these things can be handled with sequences, having to make a bunch of sequences just to control your animations would lead to asset bloat pretty quickly.
Describe the solution you'd like
TL;DR version I'd like to see more animation related functionality built in. Such as animation_end, animation_hit_frame, a way to play multiple sprite animations at once on a single object, an easier way to play an animation once without looping, and a version of broadcast messages that's instance specific rather than global.
Long version I'd like to see something similar to the functions GM already has for skeletal animations, but for regular sprites. For those not familiar with the skeleton functions, there's ways to do all the things I listed in the TL;DR above with just a single line of code each.
Here's some examples of what sort of functions I'm imagining. The track system here is a ripoff of how the existing skeleton animation functions in GM work.
animation_play(sprite, [loop]) This would basically be the same thing as doing sprite_index = some_sprite, but with an optional argument to tell it whether to loop the animation or not. Having a way to tell the animation to run backwards or ping-pong would also be nice. It could be part of the track system, where using any non-ext animation function would default to track 0.
animation_play_ext(sprite, track, [loop]) This would play the animation on a specified track, allowing you to have multiple sprites animating at the same time on one object. You could play one sprite on track 0 and another on track 1, and each sprite would increment whatever this system's equivalent of image_index is independently.
animation_end() This is a common one that's passed around the community. It returns true when the currently assigned animation has ended. It does the exact same thing as the animation end event, but you can call it anywhere in code, making it much easier to use in things like state machines.
animation_end_ext(track) Same thing as animation_end, but it checks the animation on a specific track.
animation_on_frame(frame) This would return true when the current sprite is on a specific frame. It would work in a way that gets around any issues with the fact that image_index floats.
animation_on_frame_ext(frame, track) Same thing, but for tracks.
animation_hit_frame(frame) This would return true on only the first step that an animation reaches the specified frame. It would not continue to return true if the animation is on that frame for multiple steps in a row. Useful for any code you want to only run a single time per animation loop.
animation_hit_frame_ext(frame, track) Same thing, but for tracks.
An alternative (or addition) to the on_frame and hit_frame functions would be to add event frames to sprites. These would be like broadcast messages, but NOT global, so they can be instance or track specific. They could be added in the sprite editor, or in code using a new function. Each event would have a name, and multiple frames could have events with the same name. So, you could do something like give a sprite an event on frame 5 called "Spawn Hitbox". Then, the code for using that event frame would look like
Describe alternatives you've considered
The track system and event frames would presumably take time to implement, so if those can't be done any time soon I'd still like to see things like the animation_end and animation_hit_frame functions be built in. For making an animation not loop, an alternative would be to make the playback mode on sprites actually change how the sprites play in-game, and not just be for preview purposes.
If the new runtime is already planning to change the animation system, then I'd like to see the functionalities I've listed in the new system.
Additional context
No response