A platform that blends into the background—the player misses the jump. Green spikes instead of red—the player steps on them and is surprised. These are not control errors; they are architecture errors of the 2D location. We design architecture so that visuals and gameplay work as a single mechanism. Our experience: 5 years in game development, over 30 projects. We guarantee compatibility with Unity 2022 LTS and Unreal Engine 5. Every location passes QA for readability and colliders.
Effective 2D location design requires careful planning. 2D location architecture is about designing the space where gameplay will occur: where colliders are placed, how depth layers (parallax) are arranged, how tiles join without artifacts, and how the player reads movement direction and danger zones without additional hints. Let's break down key aspects using examples from real projects. In this article, we'll examine layering, tilemap, and readability through specific cases from mobile and PC games. You'll learn how to avoid common mistakes and speed up development. We also focus on 2D level architecture to ensure gameplay flow.
Proper Layering for a 2D Location
A modern 2D location consists of many rendering layers. In Unity, these are Sorting Layers + Order in Layer; in Godot, CanvasLayer with z-indices. A typical structure:
- Background (BG): static sky, distant mountains—minimal parallax or static
- Far Parallax: slowly moving distant objects (0.2–0.4× camera speed)
- Mid Parallax: midground (0.6–0.7×)
- World Layer: gameplay space—platforms, floor, walls with colliders
- Character Layer: characters, NPCs, enemies
- Foreground: decorations in front of the character (0 parallax or 1.1–1.3× for reverse effect)
- UI: interface above everything
A common error in layer order: the character renders behind foreground trees when it should be in front. This is fixed in 30 seconds in settings, but is often only discovered during final level testing. Unity layering must be set correctly.
Avoiding Artifacts at Tile Seams
For tilemap locations, the key is tile connection rules. Unity Rule Tile automatically selects the correct tile based on the presence of neighboring tiles of the same type. A properly configured Rule Tile eliminates visual artifacts at seams—inner corners, transitions between surface types. Rule Tile works 3–5 times faster than manual tile placement.
A frequent problem: tiles are drawn with incorrect dimensions. A base tile of 16×16 px at scale 1.0 should give exactly 1 unit in Unity (if 16 PPU—pixels per unit). Mixing tiles with different PPU in the same scene causes "floating" objects—they don't align visually.
Collision tiles vs visual tiles. In complex locations, colliders should not exactly match visual tiles. Grass on top of a platform is a visual element; the collider runs along the bottom edge of the grass layer, not the top. This gives the feeling that the character stands "on the grass" instead of "on a box." TilemapCollider2D + CompositeCollider2D combine tile colliders into one mesh—important for performance with many tiles.
Why Location Readability Is Critical for Gameplay
The player should understand within 1–2 seconds where they can go, what is dangerous, and where to move next. This is a location architecture task, not UI.
Silhouette rule. Platforms are read as separate objects through contrast silhouette. Dark platforms on a light background, or light on dark—but not identical brightness. If a platform blends into the background, the player misses jumps—not due to imprecise controls, but visual confusion.
Color code for hazards. Spikes—warm colors (red, orange). Acid—green. Lava—red-orange. Electric traps—yellow/blue. This is a genre convention, and breaking it without a clear reason is a mistake. Players know these rules from other games.
Guiding lines. Parallax layers, lighting, and object placement create "sight lines" that guide the player. A coin trail leads to a bonus zone. Brighter lighting at the end of a corridor indicates the goal. This is an architectural solution, not a UI element. Visual navigation is enhanced by these guiding lines.
Workflow Steps
Work Structure for a Location
- Reference and mood board—analogues from genre games + unique style elements.
- Blockout—rough geometry layout with colliders, gameplay test. No final art.
- Layer scheme—define number and type of layers, parallax coefficients.
- Tileset design—tiles considering Rule Tile rules, PPU, sizes.
- Art pass—final graphics, lighting, atmospheric effects.
- Polish—animated elements (grass, water), particle effects, ambient sounds.
- QA—test colliders, test readability on different screen resolutions.
Typical Mistakes During Blocking
- Forgetting to set correct layer sorting—rendering artifacts.
- Using one PPU for all tiles but importing sprites with different resolutions—objects "float."
- Not leaving a gap between colliders for smooth movement—character gets stuck at seams.
Tile Resolution Comparison
| Tile size (px) |
PPU |
Size in units |
Application |
| 16×16 |
16 |
1×1 |
Retro, pixel art |
| 32×32 |
32 |
1×1 |
Mobile 2D |
| 64×64 |
64 |
1×1 |
HD-oriented games |
| Location scale |
Timeline |
| One screen (tilemap, 3–4 layers) |
3–7 days |
| Multi-screen location (scrolling, 6–8 layers) |
2–4 weeks |
| Biome/thematic set (tileset + several locations) |
4–8 weeks |
What's Included
When you order 2D location design, you receive:
- Documentation of the layer scheme with parallax coefficients;
- Configured Rule Tile for the tileset;
- Colliders considering gameplay and readability;
- Final art pass with lighting and atmospheric effects;
- Readability test on target resolutions.
Contact us to evaluate your project and suggest the optimal architecture. Get a free consultation. Typical pricing starts at $500 for a single-screen location. These techniques are essential in 2D game development.
2D Art and Animation
We have encountered projects where 2D graphics accounted for 70% of the build size. Optimization started with replacing frame-by-frame with skeletal animation. But it's not just about converting sprites to Spine — you need to properly design the rig, atlas packing, and texture format. Our service is a full 2D cycle: from concept art and illustrations to final Spine animation optimized for mobile platforms.
A mobile game with 200 character animations takes up 800 MB just for textures. Google Play rejects the APK due to size. Meanwhile, half of the animations are variations of the same movement with minor differences. This is a classic problem for teams that chose frame-by-frame animation where skeletal animation provides a better result at a fraction of the size.
Our team creates 2D graphics and illustrations for games of any genre — from pixel art to realistic styles. We work with Unity, Unreal Engine, and Godot. Every animation is performance-checked: FPS budget, draw call count, texture size.
What's Included in the Service
- Concept art and illustrations — characters, environment, UI elements, promo
- Sprite animation — frame-by-frame in Aseprite with palette and frame optimization
- Skeletal animation — Spine (professional license), DragonBones for budget projects
- 2D effects — particle-based (Shuriken, VFX Graph) and shader-based (Shader Graph for URP/HDRP)
- Atlas optimization — TexturePacker, Unity Sprite Atlas, platform-specific compression (ASTC, ETC2, DXT)
How Skeletal Animation Reduces APK Size
Spine (Esoteric Software) is the de facto standard for skeletal animation in 2D games. Skeletal animation is a method where movement is defined by bones and vertex weights rather than entire frames. In Spine, a character animation with 15 animations takes about 2 MB, while frame-by-frame takes 10 MB (5 times more). Alternatives include DragonBones (free, fewer features) and the native 2D Animation package in Unity (convenient but weaker than Spine in tools).
The return on investment for a Spine Professional license is achieved when creating 15+ unique animations — each frame-by-frame would cost several times more in time and size. When scaled to a large number of animations, the savings on a single project can be substantial. Contact us — we will calculate the savings for your project.
When is Skeletal Animation More Effective than Frame-by-Frame?
| Criterion |
Skeletal (Spine) |
Frame-by-frame (Aseprite) |
| Data size |
Small (bones + weights) |
Large (frames as images) |
| Blending flexibility |
High |
None |
| Expressiveness |
Depends on rigger |
Full artistic freedom |
| Production time |
Long rigging, fast iterations |
Each animation from scratch |
| Suitable for |
Characters, UI, creatures |
Pixel art, unique style |
The rule that works in practice: if a character has more than 15 unique animations — Spine is more efficient in size and iteration time. If the project stylistically requires frame-by-frame (pixel art, rotoscoping, cartoon style with deliberate artifacts) — Aseprite.
Mesh Deformation in Spine is one of the key features. The character bends organically, clothes fold, cheeks puff up. Workflow:
- In Spine, create a mesh on the sprite (Tools > Mesh > Edit Mesh)
- Assign vertex weights to bones (Weights mode)
- Set the number of vertices based on the desired deformation detail — more vertices = smoother deformation, but higher computational cost
Path Constraints — a bone follows a curve. Used for tails, hair, tentacles, ropes — any elements that need to bend organically.
IK Constraints in Spine work through a two- or three-bone chain. For limbs this is essential: the animator moves the IK target (hand position), and the shoulder-forearm-hand chain is set automatically. Without IK, animating limbs in FK takes twice as long.
Spine Integration in Unity
The official Spine-Unity runtime is paid (included in the Spine license) and actively supported. Components:
-
SkeletonAnimation — main component for animation
-
SkeletonMecanim — integration with Unity Animator Controller (useful for reusing Mecanim logic)
-
SkeletonGraphic — for Canvas/UI (rendered via CanvasRenderer, not MeshRenderer)
An important performance point: SkeletonAnimation creates a separate Mesh per instance. With 50+ characters on screen, this is at least 50 draw calls (without batching). Solution — SkeletonAnimation Batching via SubmeshSeparator + GPU instancing, or limiting the number of simultaneously visible Spine objects.
Spine Events — synchronization mechanism: an event in animation (footstep, attack_hit, spawn_particle) is dispatched to Unity code via AnimationState.Event. Correct architecture: Spine Event → UnityEvent → sound/particle/logic. Do not hardcode synchronization by time — animation can slow down via timeScale.
How to Reduce Draw Calls in 2D UI with Atlases?
Every individual sprite in Unity creates a separate draw call. 100 UI icons without an atlas = 100 draw calls just for UI. Sprite Atlas packs sprites into a single texture, allowing batching of draw calls for objects using the same atlas. Texture atlas is a technique used in 3D and 2D to reduce texture switching.
TexturePacker vs Unity Sprite Atlas
TexturePacker (CodeAndWeb) is an external tool, more flexible in packing settings. It supports many packing algorithms, transparent pixel trimming, edge extrusion to prevent bleeding, and export to platform-specific formats (PVRTC for iOS, ETC2 for Android). The license pays for itself on the first project with atlases.
Unity Sprite Atlas (built-in) is convenient for Addressables and dynamic loading. Two modes: Master Atlas (full control) and Variant Atlas (reduced version for low-end devices via Scale Factor).
Practical packing rules:
- Group by scene/screen: everything visible at once — in one atlas. Otherwise atlas doesn't help with batching
- Maximum atlas size: 2048x2048 for mobile, 4096x4096 for PC. Larger risks issues on old GPUs
- Trim transparent pixels: mandatory. A sprite with large transparent areas wastes space in the atlas
- Padding: 2-4 pixels between sprites prevents texture bleeding during mipmapping and UV filtering
Texture Compression Formats
| Platform |
Recommended Format |
Notes |
| Android |
ETC2 (RGB) / ETC2 RGBA8 |
Hardware acceleration on all modern Android |
| iOS |
ASTC 4x4 / 6x6 |
ASTC is universal: quality + size |
| PC/Console |
DXT5 (BC3) |
Or BC7 for high quality |
| WebGL |
DXT5 + fallback |
Check support via SystemInfo |
For atlases with many small sprites and sharp edges, ASTC 4x4 is preferable to ASTC 6x6 (fewer artifacts on fine details).
How Does 2D Asset Optimization Benefit in Practice?
Each of these points has been verified on dozens of projects: transparent pixel trimming in the atlas (saving up to 30% area), 2-4 pixel padding (eliminates bleeding), maximum atlas size 2048x2048 for mobile (stable on old GPUs), using ASTC 4x4 for iOS and ETC2 for Android, Mesh Deformation in Spine instead of extra bones for cheeks and clothing folds, grouping UI elements by screen into different atlases. Order 2D animation development with a performance guarantee — we will take into account all the nuances of your stack and platform.
What Pipeline for 2D Effects to Choose?
Particle System (Shuriken) — for most 2D effects, the built-in system is sufficient. For 2D it's important: Renderer Mode = Billboard or Horizontal Billboard, Simulation Space = World for effects that should not move with the character.
Visual Effect Graph (VFX Graph) in URP — GPU-based particles, suitable for complex effects with thousands of particles. For mobile — be cautious, requires Compute Shaders (not all devices support).
Shader Graph for 2D: dissolve effects, outline via SDF, distortion (water, heat shimmer), animated UV (lava, water). Sprite Lit Shader + custom nodes in Shader Graph — standard path for 2D in URP.
2D Animation Package (native Unity): PSDImporter for importing layers from Photoshop as separate sprites, Sprite Skin for skeletal animation inside Unity without Spine. Suitable for simple characters with a limited number of animations — if the team doesn't want to purchase a Spine license. These costs are recouped in one project if animations exceed 15.
We are ready to develop 2D graphics and animation for your game. Contact us to discuss details and get advice on asset optimization. Get an estimate of cost and timeline based on your brief — we will respond within one business day.