I have seen games made with gdevelop that dont look pixel art, more looks like vectors, how do they do it?
They export a png with their art assets, and import it into a sprite.
GDevelop does not support svg directly,so any vector art will need to be exported in to a raster image format. That doesn’t require it to be retro pixel art, and many games use more modern style.
I do all my artwork in Illustrator (a vector drawing program) and then add texture to it in Photoshop, before exporting as PNGs for GDevelop. I also export a sequence of PNGs from After Effects for any animations I want to do. I optimise all my PNGs in a free app to get their filesizes down before importing to GDevelop. Free alternatives to Illustrator are out there.
It might seem sometimes that pixel art is mandatory for indie games and GDevelop but it’s not. You could, given the right tools, do all your artwork using photographs of real-world objects or clay models, posed in sequence (claymation). You could scan in sketches and have your game look like it’s taking place entirely on a sheet of paper and drawn roughly with pencil, charcoal or crayon. If you’re into digital painting, you could style your game around that and have it look like a painting in motion.
Any art style you can think of, you could have it in GDevelop, though you might have to think carefully about how to handle large backgrounds if you wanted those instead of using a tiled approach (I cut my background art into small pieces, all as one-frame animations in the same object). I’ve done some devlogs on YouTube (worriedpixels) showing my vector art style, if you wanted to see another example of that. All the best to you with your artwork.
been enjoying your videos, learned a couple of things, keep it up
I use Inkscape which is a free vector graphics editor. Then I export my art as a png as Silver-Streak said.
But one thing I was thinking, even if you don’t like doing your own art, you might look into a vector graphics editor anyway because a lot of the free art assets out there, the artists are kind enough to include svg files with the download. This means you can open them and modify them (check the copyright of course but most I’ve found are cc0 if they’re including the svg), change the color, turn the Kenney aliens into cats, w/e. Or at the very minimum, just open them and export them into a png with a size more suitable to your game if the raster image sizes offered don’t work.
“. . .though you might have to think carefully about how to handle large backgrounds if you wanted those instead of using a tiled approach (I cut my background art into small pieces, all as one-frame animations in the same object)”
Just wondering what kind of problems you might run into using large backgrounds, and why it’s more efficient for the engine if you divide it into smaller pieces?
Are you talking about exporting layers/elements of the scene from photoshop/illustrator/etc. and rebuilding the scene in the editor (that makes sense), or literally taking a large png and chopping it into tiles? Thanks!
Hi. I meant taking a large piece of artwork in Photoshop and using slices to export a series of smaller PNGs (like jigsaw pieces) and putting them back together on a layer in GDevelop (one object with multiple one-frame animations). Having a PNG of, say, 4000 pixels wide isn’t a good idea, so you chop it up into smaller rectangles instead.
Have a look at this thread, where CorianderGames talks about a large level he did for his game. He ended up chopping his Photoshop artwork into 32 x 32 pixels pieces to get the game to run well.
Don’t worry: that’s an extreme case because his artwork was particularly large. I’m using 300 x 300 ish pieces for the foreground art in my game and it seems to run nicely so far. I use a large tile for the parallax background - repeats horizontally only - and that seems to work well too.
Here’s some general image guidance from the GDevelop wiki. The second bullet point is particularly relevant to this discussion:
This one might be helpful too:
Thank you, I thought that’s what you meant, but I haven’t quite wrapped my head around why that loads faster, increases performance, etc.
I’ll study the resources you pointed out, and as always, I’m grateful for your knowledge and insight.
There’s a lot of hard math technical reasons, but at a super high level explanation:
Texures are uncompressed when loaded into GPU memory, meaning a 1000x1000 resolution image that is 32 bits color would be ~32 megabytes in GPU ram, or a 4096x4096x32bit image would be ~530mb of GPU ram.
With them being that large, they also cannot be “culled”. Most sprites/images are only rendered if part of them are on screen, freeing up memory and GPU bandwidth for other images. With an image larger than your screen resolution, it’s having to stay in memory much longer in addition to any other images.
With that large image cut down into 100x100 or 300x300 chunks, the chunks not currently visible in the camera are culled and no longer take up any GPU memory, GPU bandwidth (transferring the textures in/out of memory or processing them) or CPU resources. Most games do not make their backgrounds/worlds out of one large image. Hollow Knight tends to have ~100x100 to 300x300 chunks making up their map. Spiritfarer’s largest single sprite is under 500x500, etc.
These two things alone (texture size memory + culling) are only two of a few dozen reasons why larger images will cause lower performance, but they are the most impactful.
(To be clear, the above has nothing to do with GDevelop and is just how resources work in game engines and GPUs in general. Until very recently Unity had a hard cap of 4096x4096 for any resource, they’ve lifted that but still don’t recommend anything larger, although they do have some texture streaming options for 3D games, similar to Unreal Engine)
That’s pretty interesting, thanks.
I don’t think I fully understood why it’s a good idea to chop artwork into smaller pieces until Silver-Streak’s post above, so I’ve learned something new today too.
Wow, that’s about as clear and concise as it gets, thank you for the clarification. This is why I love this community!