Best practices for building non-pixel-art 2D side-scroller levels

[split valley]

I’m working on a 2D side-scroller game in Godot 4 and I’ve run into limitations with TileMapLayers.
For hand-drawn (non-pixel) art, it’s hard to define a clear tile-based workflow for an artist.
In practice, it often feels much more natural to build levels by freely placing Sprite2D assets in the scene.

One concrete issue is overlapping visuals. A single TileMapLayer does not allow tiles to overlap, so achieving this requires duplicating the same assets across multiple TileMapLayers.
This feels architecturally wrong, since the same art has to be repeated and kept in sync across layers.

I understand that this could be avoided by designing tiles in a way that does not require overlapping.
However, with this type of hand-drawn art, it becomes difficult to split assets into clean, uniform tiles.

If the middle section of a floor is meant to be repeatable and randomized, the edge pieces would naturally need to occupy less space and follow stricter rules.
From my perspective, this also creates additional friction for artists. Instead of simply drawing a few floor variations that could be layered or combined freely, they would need to carefully design tightly constrained tile sets, which feels unnecessarily complex for hand-drawn art.
Because of this, I’m considering building levels from larger Sprite2D chunks (sprites with collision authored together), but I’m unsure how well this approach scales from a performance perspective.

What are the best practices in Godot 4 for building hand-drawn 2D side-scroller levels so they don’t look like a mechanical tiled pattern, while still remaining performant?

[sour frost]

If you have tile-like things you can place, then consider finding and exploring Multimesh2D stuff. I know there's a plugin that actually does this thing where it can take a bunch of Sprites you've placed, and build them all into a multimesh, dramatically reducing draw calls (it can 'undo' this when you want to edit again, too). I even took it apart once and incorporated it without using the actual plugin part. Though, I don't recommend doing that. I was just doing it for funsies.

I've read some literature that suggests the engine already does some optimization for non-overlapping things that share the same texture, but Multimesh2D is a way to be solidly sure you're optimizing.
Screenshot of the plugin you can find by typing multimesh in the search bar in the AssetLib:

Good idea to click "View Files" and inside the git repo, find and read the readme.

[hasty tundra]

You might want to take a look at SmartShape2D

it also has a link to a decent video talking about using it to help offset levels design rather than an approach to an all in 1 tool to replace all your needs

[warm dirge]

Multimesh is a good idea but on its own is sort of a non-answer unless you're doing procedural scattering or data-driven instancing. What's needed here is a tool to take human-designed set pieces consisting of many small brushes (a quad with a texture region) and bake them to a multimesh instance. It doesn't really exist yet as a plugin that I've been able to find. I'm curious too what other people are doing for 2d level design of this nature (Ori, Rayman, etc non-grid/tile 2d environments). SmartShape is a neat tool but still not quite what OP is after I think

[split valley]

Thanks, that makes sense.
I agree it’s not a perfect fit for this kind of level design.
I’m still experimenting and trying different approaches to see what actually works in practice.

[sour frost]

That is what the plugin I mentioned above does, in fact.

[warm dirge]

I took a look at that script, and that might work for a bunch of the same~~ texture~~ image? I couldn't figure out how to work it shrug
I'm working on a design and bake tool that actually does what @xen is looking for

[sour frost]

I was doing some tool a bit ago that was intended to allow the kind of terrain painting that Terrain3D offers but for 2D (Though, I was doing per-pixel resolution and leveraging a chunk-loading system for it). My idea for that was, if you already have the splat data in channels in four layered textures, you can add onto the shader with whatever effects you want that will only affect specific layers as-selected. I got pretty far on it before just deciding to use Terrain3D and make a 2D setup with it. lol

This reminds me of that effort, but I'm pulling for you to get further and can't wait to see what you come up with!

[warm dirge]

well it already works, I just want the design tools to be a lot nicer, the UI needs a lot of love

[warm dirge]

This sounds complex; I'm just using a custom shader to get different uvs per instance, so you can effectively put a setpiece together as one multimesh as long as its all from one texture atlas

[sour frost]

It's only about that level of complexity, honestly. I might just put it up somewhere if someone wants to pick it up and work on it, tbh. It's really not that complicated. I just got tired of my brain doing donuts in the parking lot of ideas I was having instead of actually making progress.

[split valley]

Did you start doing this because you were inspired by a problem I ran into, or did it just happen by coincidence?

[warm dirge]

It’s an idea I had thought about for a while when I couldn’t find a good level editor that did what I wanted. Then seeing your question inspired me to start working on an addon

[past canyon]

If I'm not mistaken, TileMapLayer has an option that lets you divide one atlas into multiple parts with different levels of collisions, meaning you can overlap graphics. And it's not really that hard to do

[warm dirge]

Yes but you can’t arbitrarily rotate and scale those pieces, and you’re still working on a grid.