Bulk import animations and frames

[LuniMoon]

Hello y'all, The core team is evaluating the implications of re designing the asset animation panel (how to add, manage and edit animation frames). Informed by the feedback received on the forum topic, we're taking a big chunk on UI tweaking for the panel's timeline, but there is one functionality in which we'd like your help: importing pngs in bulk in the Sprite dialog. 🚀

Description

----- Topic on the forum https://forum.gdevelop.io/t/bulk-import-local-animations-and-frames/44593/5

What we've found thanks to the feedback shared by DasBilligeAlien, Rasterisko, and ZachjuKamashi is that adding pngs per animation can be time consuming. Today, the system forces the user to import numerous frames into one animation status (animation 1, animation 2...) at a time. This is great to add 2 or 3 new frames to a single animation, but this way of functioning isn't efficient for users who'd like to import frames into multiple animations at once.

Solution suggested

We want to allow users to be able to import pngs in bulk and automatically categorise them in different animations:

"Must-haves": (Mandatory scope of the solution):

• Users should be able to import their local files

• The system should be able to work with different naming conventions. _Indeed, when we're Contributing assets to the GDevelop Asset Store , the technological solution demands a specific naming convention. The problem is that artists are not always following these rules, OR their animation softwares export with a completely different naming convention (often starting frames with "00" instead of GDevelop's "1")._

• The system should be able to recognise if the animation has only 1 frame or more, and categorise them accordingly. We've observed that animations can have from 1 (used to manage backgrounds, environments, or GUI status) to more frames (traditional frame by frame animation). Here's an example of animations with a single frame:

"Nice to Haves": (Optional scope for the solution. Extras)

• The system could be able to pre-fill the name of the animation on the dialog
• The system could be able to set the animation frame time (.json files if they exist)
• The system could be able to define if the animation is looped or not (.json files if they exist)
• User could be able to import using public URLs

Design notes for implementation:

• We encourage developers to ask artists of all levels (from beginners to experts) with different art softwares (ToonBoom, Aesprite, etc.) to share their files to identify naming use cases (animation status and frames). You can start on the "Asset Store submission tag" and ask around on the Forum or Discord.

• The ideal UX would be: Add a new object -> Select object type -> Add an animation -> importing in bulk for the object. Schema for reference:

• The core team will focus on importing more than 1 frame per animation (Walk, Run, Jump...) for small corrections or animation tweaking. So you don't have to add this to your backlog.

• Prioritise and use GDevelop's pre-existing components (see the library here)

• The core team is working on slowly updating the UI. If you have specific questions, contact @LuniMoon for input.

[arthuro555]

It would be good to also add a way to import animations from a sprite sheet. Many formats, such as the pixi sprite sheet format, allow to define the different animations present within a sheet, and many experienced gamdevs from other engines are used to the flow of creating their animations as a sprite sheet directly, or composing the frames into animations through a tool that exports them as a sprite sheet with animations. Allowing to import animations from such a sprite sheet would ease new users from other engines in by allowing them to use the same workflows they are confortable with, and more generally allow users to compose their animations with other tools if they find them more confortable to use & just use the exported animations in GDevelop directly.

[LuniMoon]

Agree. I haven't add it to the list of requirements because I am still collecting input on that.

The quick poll (not representative in any way, but at least gives us an idea) says that we still have more frame by frame animation than spread sheets (there's still the question about who produces what, on which kind of context):

BUT I'm still digging because we have that feature request on the forum, so there is clearly something here.

Anyway, for now I would focus on single file import while we define the problem space (and implementation complexity) for sprite sheets. As soon as I have "conclusive input" I'll create the issue with the list of requirements.

[arthuro555]

I think this poll is kind of a "self fulfilling prophecy" if that makes sense:

• Since GDevelop's current flow is frame-by-frame, users of GDevelop will be seeking tools and assets that integrate well with that flow - Frame by Frame animation, not spritesheets
• Since GDevelop's main marketing has been mostly driven towards beginner game devs, experienced game devs would likely not be using GDevelop or just toying around with it and not have joined the discord. Experienced developers are the ones most likely to know of other flows and that are susceptible to see the lack of spritesheet support as a dealbreaker.

I know many gamedevs that are interested in GDevelop - it's fast for prototyping, it's lightweightness, its accessibility to game designers and artists, its productivity etc. are very intereting for non-beginners too. That potential userbase, although it is currently not very representative of our actual userbase, is in my opinion not to be ignored. If we work towards making GDevelop more adapted for everyone, including experienced gamedevs, GDevelop could gain a lot of users, and a larger portfolio of great games built with it.

Maybe you could try to post those (and other) polls onto broader game dev communities to get insights into the needs and wishes of the general audience (and potential users that we are missing out on) rather than the existing users? (i.a. HelperWesley's Fireside, Games From Scratch, Goodgis's discord server...)

[LuniMoon]

That is completely true. That's why I want to scratch this subject: The who produces what under which context applies to what you mention: if the tool doesn't support X, then people will do their best to work with Y, because X is not supported... which could make advanced users perceive the tool as "for prototyping only". As you can imagine, that's a parallel subject/discussion that I follow when it pops... (there is nothing wrong to be a "prototyping tool". The question is "what makes a prototyping tool a kick ass prototyping tool?"). As we also want to support advanced "not only prototyping" usage.

What I am trying to say is (because we're leaving the "Bulk import" subject):

• Yes, the frame by frame might be a consequence of not supporting sprite sheets (that's why I want to see qualitative input on the forum topic. Mattcc made a great contribution).
• Yes, we want to support exports and usage that can be found on advanced development
• We're starting optimising on the problem area what we know, to later add the scope that we're still scouting. (I've mentioned the topic on Discord to make it visible so the conversation happens on that topic).

[Silver-Streak]

Honestly, a "perfect world" solution would be GDevelop's format for sprites in exports/builds to always be some kind of sprite atlas/spritesheet via both of the following:

• Sprite assets get converted to a spritesheet (if not one already) upon build, regardless if they were originally frame by frame or not.
  • This helps out true beginner devs who aren't aware of spritesheets with slightly better final filesize, and helps reduce total filecount for places like itch.io which have hard limits.
• Spritesheets are supported in someway via the IDE for Sprite Objects. Whether that be a UI that slices the spritesheet into many files (This seems like a bad idea, but it is an idea 😄 ), or just outright spritesheet support in general where there is a UI that allows you to designate which sprite for which animation.
  • This helps for people that already have spritesheet assets from places like itch.io, or make them in Aseprite, or outright experienced devs porting their games from other engines.

[LuniMoon]

Update: A discussion is going on in the forum about sprite sheets and frame by frame. I encourage future readers to head to that topic for an updated version. End of february 2023: users seem to export their animations mainly frame by frame.

Indeed, a solution that integrates both (importing frame by frame and/or sprite sheets) would be great, but we still have to find a way to slice the sprites evenly without having to be too technical (aka an 8 year-old kid could do it).

Until then, the bulk import's scope will apply to frame by frame only.

[D8H]

Solution suggested

We want to allow users to be able to import pngs in bulk and automatically categorise them in different animations:

"Must-haves": (Mandatory scope of the solution):

• Users should be able to import their local files

  • The system should be able to work with different naming conventions. _Indeed, when we're Contributing assets to the GDevelop Asset Store , the technological solution demands a specific naming convention. The problem is that artists are not always following these rules, OR their animation softwares export with a completely different naming convention (often starting frames with "00" instead of GDevelop's "1")._

• The system should be able to recognise if the animation has only 1 frame or more, and categorise them accordingly. We've observed that animations can have from 1 (used to manage backgrounds, environments, or GUI status) to more frames (traditional frame by frame animation). Here's an example of animations with a single frame:

Importing frames of an animation is already possible in one go:

Importing animations (or even objects) automatically could work by detecting repetitions in the files names to guess object names. It only works if the object has several animations. For objects with only one animation a specific separator must be given by users or they would have to fix the names manually if it's not cut correctly. But, I guess objects have often several animation or are a still image so it should be fine.

[iondiode]

Does this work with the asset store? it doesn't appear to in a recent version, shift-click, or ctrl-click all seem to add just a single frame at a time. It would be great if we could do bulk import from the asset store.

[D8H]

Does this work with the asset store? it doesn't appear to in a recent version, shift-click, or ctrl-click all seem to add just a single frame at a time. It would be great if we could do bulk import from the asset store.

No, it's easier to get a full object from here:

[iondiode]

@D8H Thank you!

[LuniMoon]

@D8H I am closing this issue because the solution that you implemented for frame import resolved this request. 👍