In a platformer, the map is a sequence of movement decisions. A ledge asks the player to jump. A slope changes the pace. A low ceiling changes which actions feel safe. Editing the map means shaping that route, then making sure the art and collision communicate the same thing.
Here is a practical way to build one in SpriteShip.
Block out the route first
Start with the player's path through the level. Place the main ground, major gaps, and changes in height before decorating. A Terrain layer lets you paint broad masses quickly, then refine a landing zone or tunnel with a smaller brush. For side-view ground, choose a Material that makes the top surface easy to read.
Keep early tests simple. If a jump is hard to judge with plain terrain, adding more scenery will not fix it. Check the gap length, landing width, and the silhouette of the next platform.
The 2D level editor is where you paint terrain and keep the map editable as these shapes change.
Separate gameplay from dressing
Use Object layers for things like bridges, doors, hazards, and foreground details. Place them after the route works. Layer order decides what appears in front, while solid and collider settings help distinguish a physical obstacle from a visual prop or trigger.
Put the player spawn where a real playtest should begin. If the level has a one-way platform or an overhang, approach it from both directions in preview. What looks clear in an editor can feel ambiguous once a character is moving at speed.
Make slopes deliberate
A slope should support the movement you want: a climb, a descent, or a smooth transition into a jump. Paint the terrain shape, then check its contact behavior and the character's route across it. Visual styling can make the incline easier to see, but it does not decide how your game's controller should handle acceleration or jumping.
This is where reusable platformer terrain Materials help: you can change the ground's look while continuing to edit the path itself.
Preview, revise, export
Test a short loop: spawn, move, jump, land, turn around, and exit. Fix confusing geometry before adding detail. Then place the assets that establish setting and mood, and test again with the final layers visible.
When the route feels right, export your platformer map for the target engine. Keep the editable map as your source so another pass on jump spacing or terrain art does not mean rebuilding the level.
A good platformer map is readable at running speed. That is the standard to use throughout the edit.
Top comments (1)
spriteship team, "a good platformer map is readable at running speed" is the golden rule, and your point about separating gameplay from dressing is a universal software architecture truth.
in web dev, we call this separating core business logic from the ui layer. if the underlying collision/logic is flawed, no amount of visual polish will fix the user experience.
one sharp follow-up on the export phase: does spriteship generate a separate, data-driven collision mesh or json layer during export? having the target engine sanity-check the programmatic hitboxes against the visual tilemap is the ultimate safeguard against those "ambiguous at speed" edge cases you mentioned.
fantastic, practical breakdown. treating level design as a data pipeline, not just an art canvas, is exactly how you build reliable games. 🐯🎮