Develop Principles for 2D Game Systems

2D Game Development covers core principles for 2D game systems across sprites, tilemaps, physics, cameras, and genre-specific patterns, meant to pair with framework-choice guidance (game-development/web-games, game-development/engine-selection) rather than replace it. For web contexts it distinguishes two setups: a full-screen 2D game where systems live in the entire app (Phaser, Kaplay, Pixi, or Canvas), versus a hybrid DOM-plus-challenges setup where 2D systems are scoped only to guest viewports and must be fully torn down when the guest closes, rather than left running behind other app content.

Use it for canvas/Phaser/Kaplay/Pixi 2D systems, or guest viewports inside hybrid web apps. Sprite systems cover atlases (combining textures to reduce draw calls), animation as frame sequences typically at 8-24 FPS following squash-and-stretch, anticipation, and follow-through principles, pivot points for rotation/scale origin, and Z-order layering. Tilemaps typically use 16x16, 32x32, or 64x64 tile sizes, auto-tiling for terrain, simplified collision shapes, and a four-layer structure: background (non-interactive scenery), terrain (walkable ground), props (interactive objects), and foreground (parallax overlay).

2D physics uses box, circle, capsule, and polygon collision shapes chosen by object type (rectangular objects, balls, characters, and complex shapes respectively), with a fixed timestep for consistency and collision layers for filtering - and a deliberate choice between pixel-perfect and physics-based movement per game, never both. Camera systems include follow (track the player), look-ahead (anticipate movement), multi-target (two-player), room-based (Metroidvania-style), and static (board games, modal skill-checks) - plus screen shake kept short (50-200ms) with diminishing intensity and used sparingly. Genre-specific patterns cover platformers (coyote time, jump buffering, variable jump height) and top-down games (8-directional or free movement, aim-based or auto-aim, and a deliberate decision on whether rotation matters).

A dedicated anti-patterns checklist pairs each pitfall against its fix - separate textures, complex collision shapes, and mixed movement models each map back to the atlas/simplification/single-approach guidance above - plus two items not covered elsewhere: jittery cameras should use smooth following instead of hard-cutting to the target, and orphaned requestAnimationFrame loops or event listeners left running after a guest viewport closes need full teardown rather than being left to leak.

Developers building 2D games or 2D guest experiences inside hybrid web apps who want a concise, opinionated reference for sprite/tilemap/physics/camera systems and genre-specific feel - clarity-focused principles rather than framework-specific API documentation. The guiding principle throughout is that 2D design is about clarity: every pixel, animation frame, and camera movement should communicate information to the player rather than just look busy.