I’m a long time game developer (hobby mostly) and always on the lookout for cool new engines to try and perhaps even finish something occasionally.
No game engine is perfect, I know, and I’ve been into it since BlitzBasic at least, but I must say I really like Gdevelop so far. I like this lighter approach, reminding me of GB studio I use for my current smaller pet projects in addition to Godot which is my go-to for more complex ones.
I feel that Gdevelop has the real potential to hit that sweet spot I am looking for - simple enough not to bother you with reinventing the wheel every time you just want to try something and quite capable of creating 99% of anything that comes to your mind without the need to go too nitty-gritty just to get some basic stuff going.
Anyway, enough praise.
Gdevelop is not perfect, it is work in progress, I know. There are things that are a bit annoying and some things that do require some workarounds. But that is true with every game engine and I really don’t expect it will ever change. However. There is one thing that absolutely prevents me from delving more deeply into Gdevelop and that is lack of in-engine support for sprite sheets. I have worked in over a dozen 2d game engines and there is not one I recollect that does not support sprite sheets. Not one. This is such a basic quality-of-life feature that it didn’t even occur to me that a mature engine like Gdevelop would lack it. Whenever I find myself starting a Gdevelop project I realize I have to cut up all my sprite sheets, either self-made or found elsewhere, into a myriad separate little files I have to label and index somehow… I lose all willpower. It is just so much needless, boring, pointless work… I know there are “workarounds” and you can go through some third-party software, and have to follow some procedures… And then I lose even more enthusiasm. And when you have to change something? Oh boy…
I know that Gdevelop is great, I dabbled in it. I like what I see very much. I even tried to make myself persevere on that top-down adventure I’ve been working on in Godot and which I decided to port to Gdevelop in order to make it more enjoyable to work on so I can concentrate less on technicalities and more on content. And all is fine and dandy until I have to import a new character or change an animation. All the time and energy saved on less low level programming is now wasted on those laborious procedures to do some really basic graphics management stuff. I found myself hating the idea to try something new, to play around with graphics and animations because I cannot just import/update a sprite sheet with a button click or two, like in any other engine - and I chose Gdevelop in the first place exactly because I thought it would enable me to concentrate more on that kind of creative stuff!
So anyway. If I could change/add just one thing in Gdevelop, it would be in-engine support for sprite sheets to a minimum standard that is taken for granted pretty much everywhere else. Just look at Godot, Unity, GM Studio, GB Studio etc etc etc if you need pointers. If Gdevelop had just this one thing I would definitely use it for at least 90% of all my projects, no questions asked. I’d be on it like a fly on … I don’t really need 3D, I definitely don’t need AI, I don’t even need multiplayer that much; the one thing that I do need in every single project and all the time is sprite sheets.
So, these are my two cents. And I will not be “persuaded” or “explained to” how I don’t really “need” sprite sheets. You don’t “need” many things and you can “workaround” pretty much anything. You can make games in C with a notepad too, no problem. See my point?
Frankly, I see it as the biggest obstacle in wider adoption. Kudos to developers using Gdevelop, but I can imagine a vast majority of people like me, browsing around for new tools being completely put off by it. It’s like finding this great new graphics editor which does everything right and is quite advanced, but then you realize you can’t select more than one item at a time or there is no copy/paste…
I’d guess it carries on even in choosing it for education purposes. Imagine being a teacher and then realizing that the jaws of hell are about to open for you if some of your students get a bright idea to animate (gasp!) some of their game characters…
Really, I have no idea why this isn’t simply done because it is such a standard thing. Is it a matter of some kind of principle or deep conviction? I simply don’t understand the omission.
Funny thing is, as a guy who makes his own animations and graphics, I find the current animation support really useful, as I export most of my work into many PNGs with Adobe Animate. I don’t think that I would have stuck with Gdevelop if I had to import sprite sheets when I was starting, the current system just seems much more user-friendly. (For newbies)
But yeah, having this choice wouldn’t be bad, maybe an option to serve both sides. I understand why someone would prefer sprite sheets
In almost any other game engine you can use both - these are not two separate systems. Generally you just reference animation frames as either sprite1.png, sprite2.png or as spiritesheet.png(1) spritesheet.png(2) as just an abstract example. They are not mutually exclusive in any way.
You mention that you make your own animations and graphics in Adobe Animate. Frankly, that means you are way more graphically advanced than most who are into indie game development. Most people who are into hobby game development or are just learning just grab a sprite sheet from somewhere and stick it directly into their game engine of choice. Easier to handle, easier to get palette and sizes consistent, easier to edit in popular amateur software such as aseprite and many others. It’s basically the only way you do it with pixel art. Using separate files for animation frames is actually a more ADVANCED way of doing it, the way a PROFESSIONAL would do it, someone who works in animation industry and deals with much larger resolution graphics - and Gdevelop targets quite the opposite side of the developer ecosystem…
I worked in video production and did quite a few projects with extensive After Effects animations. Yes, that is how you do it when you export animations to send them to clients so they can stick it into Premiere or whatever. This is how graphical animation industry does it. But that is NOT how it is customarily done with computer games, especially in lo-fi indie game space. Just look at asset stores and sprite repositories - it is sprite sheets in vast majority of cases and very little folders with individual sprite frames. A programmer/developer instinctively thinks in terms of sprite sheets, an animator/graphic designer thinks in terms of frame sequences. And that is why almost all game engines support both seamlessly.
Paradoxically, simpler games, especially those which are of lower graphical resolutions tend to use sprite sheets while bigger ones using more graphical memory use individual frames so they can optimize texture loading etc. Gdevelop obviously and explicitly targets the lower end of that spectrum - the indie, the casual, hobbyist and education. There is no sense at all that you can’t handle sprites and graphics in a way that is THE standard in that space. As I said, when I was first looking at Gdevelop it didn’t even occur to me as even the remotest possibility that it could be a problem. It is that common, it is the standard. Again it’s like having a graphics application without, for example, hex codes for color, or no RGB color space only CMYK. Or inability to scale with nearest-neighbor algo. The only engine i can think of that DOESN’T have direct in-engine way to use and reference sprite-sheets is Unreal, THE most advanced engine created specifically for super high-end 3D. And even there you don’t have to resort to third-party software to cut the sprites up and can do it all within the engine itself. It is ridiculous, frankly, that sprite sheets are easier to handle and have more direct support in a dedicated professional 3D engine which isn’t even built with any kind of 2D in mind, than in a beginner/casual engine explicitly made for lo-fi 2D games.
Sprite sheet support is often brought up internally, but without success so far.
To give the team a better idea of expectations, in your opinion, what is the best sprite sheet implementation in other engines? And what makes it good?
I’d say it’s purely a matter of convenience. With a sprite sheet, you have the entire sequence of images on a single sheet, which makes it not only easier to organize and store, but also simpler to manage. However, as I mentioned in the other thread,
Even though sprite sheets are generally more versatile, it’s still better to have both systems available.
Sprite sheets aren’t usable (at least in GD) for high-resolution sprites, because for example, a sequence of 256px images can easily exceed 2K resolution.
Hmm, you can pick any… Unity, Godot, GM Studio… they all use pretty much the same principles. It is so ubiquitous and seamless that I rarely even pay any attention to it.
Load a sprite sheet as a graphical resource with its reference name (“mario.png” → “mario”)
Define the size of a frame by width and height, perhaps also offset and internal borders but that is rarely necessary. The engine assigns reference indexes to each frame starting from top-left as 0. (“mario(0), mario(1)” etc) as a simple array
now you can reference individual frames from the sheet like you would reference separate sprite files. Engines generally do not make a distinction - you can define a walking animation as “mario1.png to mario4.png” or “mario(1) to mario(4)”. If you want Mario to explode you can either define it as “marioexplode1.png to marioexplode4.png” or “mario(5) to mario(8)” or even “marioexplode(1) to marioexplode(4)” (from separate spritesheet “marioexplode.png” in example).
It is quite simple, really. Basically all animations are arrays of references to distinct graphical bits in memory, right? So there is no need to have each one of those bits load from the disk separately. That’s why the use of atlases is so ubiquitous. (a kind of reverse sprite-sheet, automatically compiled by the engine to merge disparate graphics into single file)
For super-basic example there is GB Studio, quite similar to Gdevelop in philosophy and free to use little engine for making GameBoy compatible games. Done by one guy in his spare time but quite good and usable actually. It is even based on JS and open source if you want to dig in. There are short tutorials on yt to check out how their sprite editor works (actually it’s an animation editor, but that’s how they call it). They have built-in animation presets for various genres of GB games which all use sprite sheets as default. And of course you can define your own animations from the same sprite sheet. In essence, a game object IS a sprite sheet there. When defining an object (“Actor” in their parlance) you start from a Sprite, which is usually a spritesheet with frames. You then define behaviors and which bits of it get played when.
But even there you can easily and seamlessly use individual sprite files instead because there is no real distinction - and there shouldn’t be because it is basically just a matter of referencing. At any point at runtime you can use actions to change the “sprite” (sprite file) of an object or reference a different frame from a sprite sheet, there is no real distinction except in referencing - as a simple named variable or a member of an array. I mean, even when you load separate graphics it all gets mushed up in computer memory anyway, right? Again, it is just a matter of referencing.
I asked because I was thought the option may differ from the apps, but it seems totally the same everywhere?
Yeah, so the offset is a nice to have, maybe there are more cool options ?
Nothing much really…
If you wish, check out how Godot does it. A Sprite2D node is just a texture and you can seamlessly define it as spritesheet by simply increasing the number of frames from default 1. In Godot you specify the number of vertical and horizontal frames in the sheet and the engine calculates individual frame size. In some other engines you specify frame size and engine calculates the number of frames. It doesn’t matter really.
The first frame (index 0) is used as default for thumbnail or if you do not wish to animate yet, but you can change even that in the node definition. The engine doesn’t make any distinction between sprites and spritesheets. An individual sprite file is really just a spritesheet with only one frame (which is default btw).
Later when defining animations you can add sprites from the spritesheet in any sequence you want. I guess you can even mix and match with other individual sprites or spritesheets… again it’s just a matter of referencing.
But Godot is quite a bit more advanced and open in what it does (and complex) than what I suppose Gdevelop wishes to be. GB Studio is, I feel, closer to Gdevelop’s level of complexity vs ease of use, so maybe you should check that out too. Both engines are free and very easy to come by, and there are plenty of video tutorials on yt for both showing how their sprite manipulation works. Imo Gdevelop’s way of working with sprites and animations should fit somewhere between the two. (Godot is more of a “whatever” and “do your own thing” and GB Studio leans to “this is how it is done, don’t make a fuss or you might break something” side - but both are perfectly fine really)
That being said, regarding offset - it is a quality of life thing and not crucial. It is in “nice to have” category. And the same goes for internal borders between sprites. Occasionally one stumbles on spritesheets, particularly older ones, or from external sources, where you get that kind of thing and it is easier when the engine “trims” the sheet for you. But it is not that much of a work to conform even such a sheet to a “clean” version with no offset or borders.
Individual sprites? Sure, add them and Defold automatically packs them into an atlas (and defines the position/rotation/x+y stuff) to save filesize/filecount.
Atlas/Spritesheet? Sure, define the position, rotation, and X/Y coordinates for each frame, and it treats it as an atlas.
Yeah, I just checked out Defold and it seems they have it really well done with a lot of thought put into it. Not surprising at all considering their engine grew out primarily out of mobile game development… and there asset optimization is of paramount importance.
Btw, if I can be permitted a digression? What are your thoughts on Defold? I’m getting quite tired of Godot’s little quirks and general fiddliness (at least that’s the way it feels to me). Defold seems quite a capable and solid little engine, and lately I’ve grown to appreciate robustness and a bit of no-nonsense approach in game dev…
Defold is the #1 engine I’d recommend for 2D game dev other than GDevelop.
It’s exceptionally mature as an engine, has a similar extension system to GD5, is extremely performant compared to basically anything I’ve seen in the 2D Space (both GDevelop, Godot, and any 2D engine I’ve seen besides maybe Raylib? which is more of a framework). It does have 3D support as well but is 2D focused.
If you don’t mind learning a scripting language (LUA), it’s the main thing I’d recommend checking out besides GDevelop. It is source-available but closed source, so if that matters to you keep that in mind.
I took a fast look in LUA language manual and what i can say, this language is like Basic and Pascal.
It could be intéressant i study Defold but i also should learn the editors and their logics.
A lot of work for me in perpective.
PS: the manual on LUA is well constructed and easy to read.