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)
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.
From a more technical perspective, recent versions of PixiJS support spritesheets directly
It supports spritesheet data made by spritesheet.js (GitHub - krzysztof-o/spritesheet.js: Command-line spritesheet generator supporting Starling / Sparrow, PIXI.js, Easel.js and cocos2d) and others.
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)
I was actually thinking about sprite sheets last week (like I said, I am exploring what it means to work with asset animations).
The hypothesis that we have so far is: those who buy sprites online will get pre-made sprite sheets (CupNooble’s example found on the web)
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.
Hope that helps with some additional user perspective!
All the best,
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