Sprite sheets allow users to pack a game with less individual files, as well as make use of sprite sheets availiable in many asset stores without having to slice them all up. Also, programs like Aseprite and Texturepacker allow companion json or xml files to specify information about each sprite on the sheet (name, region, anchor, which animation group it belongs, etc.)
right now, the closest GDevelop has the “sprite sheet animations” extension by arturo, so the developers acknowledge the need for the tool, but any kind of sprite sheet manipulation or organization of the animations/sprite groups needs to be done externally.
Core support for sprite sheets allowing visualization of animations, boundaries and other information in the object details (like we do with standard sprite objects) would be beneficial and more intuitive than the current solution (that kinda mixes two similar concepts that are used for different applications)
Hey ouraf!
I’m researching everything that has to do with animation management (importing, replacing, editing etc…).
Can I ask: do you generally use mainly purchased assets from the internet, or do you animate your own assets (aka export the pngs, importing them to the engine)?
I’m not proficient with 2d art, so most of the time I use assets I got in bundles from humble, fanatical and itch.io and (just for testing purposes, of course), sprites from older games available on spriters-resource.com
In many cases the sprite sheets are already prepared for another engine’s specifications (like RPG Maker, for example), so it has an easy to identify pattern.
Unity and Godot have built in tools and wizards to separate individual sprites in sheets and group then in animations. It’s one of the few features I couldn’t find in GDevelop by default.
I imagine the technical ask would require an UX panel for sprite objects that allows them to auto detect sprite boundaries from the sheet (or allow the user to manually define them) and use them for respective animations, then use spritesheet.js to generate the data json, then use that for rendering in Pixijs.
Alternatively you could have something that just autosplits spritesheets for users as a shorter term solution, but while spritesheets don’t have a huge benefit for performance, they are important for html5 hosting optimization on places like Itch.io which has filecount limits for uploaded html5 games. A spritesheet splitter would not eliminate this problem, while a texturepacker and spritesheet support would eliminate this problem.
Interestingly, from a quick google a lot of engines generate atlases (spritesheets) on their final build, but only support individual images during dev. Defold and CT.js both support atlas generation but not direct spritesheets (Defold has some workarounds using tilemap atlases, ct.js does not accoeding to their documentation)
And those who create their own art export frame by frame (since they animate frame by frame). -Which the app handles at the moment-.
When I produced animated art for video games I exported them frame by frame, but the developper used a solution to create sprite sheets to improve performance (we were making educational video games optimised for limited technologies).
Therefore, importing a sprite sheet even when the art has been made custom is a possibility too? (I need more data from user’s experience on this). If it does improve performance, might be another question…
If we get enough user input and the feature makes it to development, the engineers would have to think of a technical solution to evenly cut a sprite sheet (since not every element has the same size).
As Silver said, working with sprite boundaries is tricky because getting one extra pixel on the frame cut would mess the whole animation (thanks Silver-Streak for the documentation!).
I’ll keep an eye on this conversation to read future comments on the matter.
Wanted to add to the conversation to say I disagree that those who create their own art export frame-by-frame by default. Honestly, I would say the contrary which is why most major and small engines that support 2D (Unity, Godot, Construct, etc.) allow the importing of Sprite sheets. I’m not an expert artist by any means, but I try to create my own pixel art for important resources. I use Aseprite and prefer Sprite sheets by a wide margin as it just helps keep my projects cleaner and more organized. Here’s an example of a walk cycle with 16 frames.
The organizational benefits are immediately obvious - especially for detailed animations with many frames. Having all of these files really clog up the resource manager in GDevelop as well which is a major pain as there is no project manager with folders.
If you have dozens of multi frame animations it makes the resource manager frustrating to navigate as you’re scrolling at best dozens if not hundreds of files that are all part of the same resource. Having all of those files bundled into a single character sprite sheet with all animations would be SO much cleaner.
Last note is on performance. Advantages here seem immediately intuitive. Just as a quick example take a look at the screenshot below. The file size containing all frames of the walk cycle is 23kb while the sprite sheet itself is only 5kb. The exports are all from Aseprite from the same file with the same resolution and file format. Only difference is how it is exported in a single sheet. While file size doesn’t necessarily equate to performance the reduction of nearly 500% for each animation cycle (23kb → 5kb) will undoubtably help with loading times when scaled to a large release game. I would say super important for GDevelop considering that all resources front load when a game is started from my understanding. Not an expert here either, but those are my observations.
The performance part is a bit more nuanced than file sizes, though. Individual files weight more because they include more general information (name, file type identification on the header, size info, etc). This adds some padding.
On the other hand, the size of the image chunks loaded into memory also influence performance, specially on mobile devices.
That part is very complicated and there are dozens of other optimization strategies before getting there, but the technical part and implementation may make this argument moot.
Reduced number of files on the project, flexibility when dealing with your asset sources and better asset management are motives enough to consider this request IMO
Hello. I think it should be an alternative option, because in my case, for example, I design all my objects, use several programs and export the animations in one frame per file. The sprite sheet in this case would not work for me.
I have many folders full of frames like this
I agree with TamaraErica, and my folders look the same. Spritesheets could be a useful option for some users but please don’t replace existing functionality. I prepare all my animations using After Effects, and then I export a series of PNGs that I then fine-tune in Photoshop. If GDevelop switched to spritesheets entirely, I would need to spend an age putting all the frames into one big file, spacing them precisely, because there is no automated way of doing this in AE. Also, for those who aren’t doing pixel art it’s less straightforward to space things ie. shapes that have smoothing/antialiasing instead of sharp edges. And if I decide to change one small thing in my animation, like the colour of an NPC’s eyes, I would have to do the entire process all over again. Makes me feel stressed out just thinking about it
Also, I currently construct my scene artwork in Illustrator and Photoshop, as a large piece of artwork. I chop it up into small chunks and piece it back together on GDevelop by having one spite objects with multiple one-frame animations. A spritesheet for this would need to be thousands of pixels wide and high.
Hold on. No one asked to remove the standard way of working with animations. just like Godot, Unity Unreal (even with how little they care about 2d) and just about every other engine that supports sprite sheets works with individual sprites in one way or another.
Only very specific examples (RPG Maker and SRPG Maker) are chained to sprite sheets for certain objects
I just made a post about this. I’m an artist who finds an absolute need for this feature to be a core part of GDevelop’s continued brand of being easy to use. I have so many animations in various packs that it’s pretty unrealistic for me to ever slice them all up into individual PNGs to be put on their store or used in-engine.
100% agree. While I see there are folks who export as individual frames, by developing the engine around this 1 process alienates many others who work in sheets or even GIFs (game maker studio allows GIFs to be uploaded which are then turned into PNGs). The clutter created around having every individual frame take up real estate in the UI is not ideal. As great as the movement into 3D is and I get it, y’all wanna put more stock in that, I feel pretty left behind as a 2D artist who now has to take 60 animations with avg 6 frames per animation in 30-40 different skin tones and put them all as individual PNGs to make it work. I think this engine has the potential to be even better than what it is. But as a 2D pixel artist, it’s really hard to justify wanting to be a part of the asset store with things needing to follow a specific naming convention for a 3rd party program to make my spritesheet work, so now I’m doing 2 or 3 extra steps for something that other engines have built in.
Maybe I’m missing something here, but are we talking about organization? Or simply importing? We can import spritesheets directly through Piskel and it’ll convert the cells into individual images for us / into an animation for us within Gdevelop (so long as the cells are uniform in size/you don’t have uneven cell sizes in your sheet)
integrating sprite sheet handling with within game development engines with GDevelop would smooth the process of managing the animation and sprite group enhance workflow and user efficiency.
Imagine i do not like orange units their color need to say bye bye
Normally i would need to edit EACH image separately
But when i have spritesheet i can do this
What you see here is i cut all orange units from the image and make new layer
Put them on that new layer (when exporting layers will auto merge into one layer)
Just so i by accident do not mess with units that i do not want to edit which could have same color
And i pick color i want to adjust and bam
Now i could pull exact same trick to for example change shape of glasses of each unit that have glasses
Or color of glasses
Or even remove them at all
I could go on and on over what kind of advantage spritesheet gives us
But if any1 need better argument then i doubt anything will convince you
Now imagine how it would look like if i need to do it for each separate image for each frame of animation
Does that sound like fun?
