Introduction to 2D Platformers

The lecture traces the evolution of the Mario franchise to illustrate core platformer components: tile maps, 2D animation, procedural generation, and physics. It frames the lesson as a technical guide for building a 2D platformer in Love2D, emphasizing reusable architecture over asset copying.

World Modeling

Tile maps store terrain as grids of numeric IDs, each ID mapping to a quad in a sprite sheet. This representation enables fast rendering of collidable and non‑collidable tiles. Camera movement relies on love.graphics.translate; shifting the world by a positive X value makes the view appear to move left, creating a smooth scrolling effect.

Character Implementation

Sprite sheets are sliced into frames, and an animation loop advances the frame index every 0.2 seconds using delta time. Flipping a sprite requires moving the origin to the center so rotation and scaling occur in place. Jump logic checks that vertical velocity (DY) is zero before applying an upward velocity of –300 units, preventing mid‑air jumps. Player states transition as follows: Walking reacts to horizontal input, Jump becomes active from Idle or Walking, and Falling triggers ground‑collision checks to avoid a “clunky” idle frame.

Procedural Level Generation

The generator iterates column by column, applying rules such as a 1‑in‑5 chance for a pillar and a 1‑in‑7 chance for a chasm. Tile sets provide visual variety, while toppers layer on ground tiles without affecting gameplay. Jump blocks may spawn gems with a 5 % chance; gems appear via a 0.1‑second tween animation and award 100 points when collected.

Collision & Entity Systems

Point‑to‑tile collision converts pixel coordinates to tile indices by dividing by the 16‑pixel tile size, then looks up the tile in the 2D array. This O(1) operation is more efficient than AABB checks for large maps. AABB collision handles interactive objects: solid objects push the player outward, while consumable objects trigger an onConsume callback and are removed from level.objects. Entities such as the Player and Snail use state machines to encapsulate behavior, whereas static game objects remain independent. The lecture mentions an Entity Component System as an alternative where behavior derives from attached components.

Snail AI

The snail enemy cycles through three states. Idle plays a shell animation and occurs with a 25 % chance each cycle. Moving selects a random direction. If the player comes within five tiles, the snail switches to Chasing, using a reference to the player to drive proximity logic.

Assignment 4 Requirements

Students must ensure the player never falls below the map, implement a key/lock system to open the level’s goal, and enable level transitions that generate larger subsequent maps. Additional features include ladder climbing (requiring a new state and Y‑axis movement) and a power‑up—such as a star—that grants temporary invincibility against enemies.

Mechanisms & Explanations

• Camera Translation – love.graphics.translate(x, y) offsets all draw calls; moving the world right makes the camera appear to move left.
• Animation Loop – A timer accumulates delta time; when it exceeds 0.2 seconds, the frame index increments modulo the frame count.
• Point‑to‑Tile Collision – Dividing pixel coordinates by the 16‑pixel tile size yields grid indices for direct tile lookup.
• Entity State Machine – A central object stores the current state; update and render delegate to that state’s methods.
• Object Removal – Consumable objects are deleted from level.objects immediately after consumption to stop further interaction.
• Interpolated Movement – timer.tween animates objects such as gems over 0.1 seconds, creating smooth spawn effects.