Haciendo juegos con Html5

Canvas Game HUD — Animated Health Bar, Mana & XP in JavaScript

noreply@blogger.com (namzug) — Fri, 04 Sep 2026 13:20:25 +0000

Every RPG, action game, and shooter needs a HUD. This demo builds the complete set: an animated health bar, mana bar, XP progress bar, skill cooldown slots, damage feedback, level-up effects, and a mini-map, entirely with Canvas 2D. You can adapt this system to almost any HTML5 game.

INFO

What you will build

A Canvas HUD that automatically cycles through damage, healing, XP gain, and level-up states. Bar values animate smoothly toward their targets instead of jumping instantly.

LIVE GAME UI DEMO

Canvas Game HUD - Health, Mana & XP

Watch the HUD animate through damage, healing, XP gain, and level-up states

How to build animated game bars in Canvas

Never set a HUD bar directly to the new game value if you want smooth animation. Instead, keep a displayed value and a target value. Each frame, move the displayed value toward the target.

A simple version looks like this: displayed += (target - displayed) * 0.05. This turns instant number changes into smooth visual movement without requiring a tweening library.

The demo above uses a frame-rate-independent version of the same idea. This means the animation remains consistent even when the game runs at different frame rates.

Health color can also change dynamically. In this example, the bar is green at high health, orange at medium health, and red when health becomes critical.

Damage feedback uses a red screen tint plus a red border. The important detail is that the full-screen tint is drawn before the HUD. This keeps HP, MP, XP, cooldown numbers, and the mini-map readable during the damage effect.

hud.js KEY IDEA

// Smooth a displayed HUD value toward its target
function smoothTo(current, target, speed, dt) {
  const amount = 1 - Math.exp(-speed * dt);
  return current + (target - current) * amount;
}

displayedHP = smoothTo(
  displayedHP,
  targetHP,
  7.5,
  deltaTime
);

// Change health color by percentage
const barColor =
  displayedHP > 0.50
    ? '#35dd68'
    : displayedHP > 0.25
    ? '#ff9028'
    : '#ff3030';

Smooth interpolation plus health thresholds creates a responsive animated HUD without a tweening library.

Skill cooldown slots

Each skill stores its remaining cooldown in seconds. Every frame, subtract delta time until the value reaches zero.

The HUD converts the remaining cooldown into a value between zero and one and uses that percentage to draw a dark overlay over the skill slot.

The remaining number of seconds is drawn in the center of the slot with: Math.ceil(skill.cd).

The icons in this demo are drawn directly with Canvas paths. They do not use emoji characters or HTML entities. This avoids font and character encoding problems that can occur when code is inserted into Blogger.

Add this HUD to your game

In a real game, the HUD should be drawn after the game world. Render your map, player, enemies, particles, and effects first, then render the HUD on top.

A typical game loop would look like this:

function frame() {

  updateGame();

  drawWorld();

  drawPlayer();

  drawEnemies();

  drawParticles();

  drawHUD();

  requestAnimationFrame(frame);

}

Keep the game's real state separate from the HUD's displayed state. For example, the game may instantly change player HP from 100 to 40 while the HUD smoothly animates its displayed value from 100 toward 40.

JavaScript Game Loading Screen — Animated Liquid Fill & Progress Canvas

noreply@blogger.com (namzug) — Fri, 04 Sep 2026 12:36:07 +0000

First impressions matter. This demo builds an eye-catching game loading screen — a liquid-fill progress bar with particle splashes, a pulsing logo, shimmer particles, and a smooth "Loading complete" transition. Zero libraries, pure Canvas 2D. Drop this into your HTML5 game as the first screen players see.

↗

What you will build

A Canvas loading screen with a sinusoidal liquid wave inside a progress bar container, particles that burst from the fill edge, a percentage counter, and a game title that pulses with a glow. The progress fills at a configurable rate and loops for demo purposes — in a real game, tie it to your asset loading callbacks.

LIVE GAME UI DEMO

Game Loading Screen — JavaScript Canvas

Watch the liquid fill animation loop

How the liquid fill effect works in Canvas

The liquid fill is a sine wave path clipped to the progress bar rectangle. Draw a wave by looping through X positions and computing y = barTop + Math.sin(x * frequency + time) * amplitude. Close the path back to the bottom-left corner and fill it. The advancing fill width is just fillWidth = barWidth * progress — the wave is drawn up to that point. Together, the animated wave inside a clipping region creates the liquid illusion.

Clip using ctx.save(); ctx.beginPath(); ctx.roundRect(...); ctx.clip(); before drawing the wave. Everything drawn inside the clip region is automatically masked to the bar shape. Call ctx.restore() to remove the clip for subsequent drawing.

loading.jsKEY IDEA

// Clip to progress bar shape
ctx.save();
ctx.beginPath();
ctx.roundRect(barX, barY, barWidth, barHeight, radius);
ctx.clip();

// Draw animated liquid wave
ctx.beginPath();
ctx.moveTo(barX, barY + barHeight);
for (let x = barX; x <= barX + fillWidth; x += 4) {
  const y = barY + barHeight - barHeight * progress
          + Math.sin(x * 0.06 + waveTime) * waveAmp;
  ctx.lineTo(x, y);
}
ctx.closePath();
ctx.fill();
ctx.restore(); // remove clip

Clip + sine wave = liquid fill. Advance waveTime each frame and the liquid appears to slosh.

Connecting to real asset loading

In a real game, tie progress to asset loading callbacks. Using Phaser, listen to the scene's progress event: this.load.on('progress', value => { loadingProgress = value; }). Using plain JavaScript, count loaded images with an onload counter: progress = loadedCount / totalAssets. The visual loading screen is completely decoupled from asset loading — it just reads the number.

Integrate into your HTML5 game

Show the loading screen as the first state in your game's state machine. Start asset loading immediately, update progress as callbacks fire, and transition to the title screen when progress >= 1. Add a minimum display time (0.5–1 second) so the screen doesn't flash instantly on fast connections — players need a moment to read the title.

Three.js 3D Game Level Selection — Draggable 3D Carousel with Momentum

noreply@blogger.com (namzug) — Thu, 03 Sep 2026 18:30:00 +0000

This is how game character select and level select screens should feel. Drag left or right and 8 panels orbit around a virtual cylinder — the panel in front depth-focuses, drag-release applies momentum that coasts to a stop, and the nearest panel snaps to front. Zero carousel libraries, just Three.js, trigonometry, and pointer events. Build your game's selection screen in an afternoon.

↗

What you will build

A 3D cylindrical carousel where 8 panels are placed around a circle using trigonometry. Drag velocity is applied as angular momentum with a 0.92 friction factor, so the carousel decelerates naturally and the closest panel snaps to front using a short easing interpolation.

LIVE 3D EXPERIMENT

Three.js 3D Carousel with Drag Interaction

Drag or move the pointer inside the 3D view

How the Three.js 3D carousel drag works

Position N panels at angle = (i / N) * Math.PI * 2 around a radius using Math.sin(angle) * radius for X and Math.cos(angle) * radius for Z. On pointermove, measure the horizontal delta between the current and previous pointer positions and add it to a rotationSpeed variable. Each frame, add rotationSpeed to the group's rotation.y and multiply rotationSpeed by the friction factor (0.92).

The panel closest to the camera (the one with rotation.y ≈ 0) gets a scale of 1.15 to visually pop it forward. Compute which panel is "in front" by finding the one whose world angle is closest to 0 after normalizing for the group rotation. After drag ends, lerp the rotation toward the nearest snap angle to settle it cleanly.

scene.jsKEY IDEA

const angle = index / cardCount * Math.PI * 2;

card.position.set(
  Math.sin(angle) * radius,
  0,
  Math.cos(angle) * radius
);

card.lookAt(0, 0, 0);

The cylinder layout is six trig lines. Drag physics is two lines: add delta to speed, multiply speed by friction each frame. The rest is Three.js scene setup.

Why Three.js for a carousel instead of CSS-only

CSS-only carousels with scroll-snap are excellent for flat layouts. Three.js is justified when you need perspective depth, per-panel 3D transforms, custom lighting on panels (for product showcase), or drag-with-momentum that feels physically natural rather than scroll-snappy. The 3D cylindrical layout is impossible in CSS without a fixed panel count and manually computed rotateY values per item.

This carousel also handles variable panel content naturally: each Mesh can have its own texture, color, or geometry. Add THREE.MeshStandardMaterial with a map texture and the panels become a product gallery with real lighting. The drag and momentum code stays identical regardless of what's on the panels.

Performance note

Keep panel geometry low-poly—each panel is a PlaneGeometry(2, 2.5, 1, 1) (4 vertices). Texture maps should be power-of-two dimensions (512×512, 1024×512) for optimal GPU memory alignment. Dispose of unused textures with texture.dispose() when panels scroll out of view permanently.

Extensions and variations

Add a raycaster click handler to detect which panel the user taps and trigger a view transition to a detail page. Replace flat planes with angled panels for a fan-carousel style. Add a subtle vertical parallax by moving the camera Y position slightly based on the device gyroscope for an AR-like depth effect on mobile.

Frequently asked questions

Can I use this 3D carousel with real images or video?

Yes. Pass a THREE.TextureLoader texture to MeshStandardMaterial.map for images, or a THREE.VideoTexture for video panels. The carousel code is geometry-agnostic—the positioning and drag logic work regardless of what the material shows.

How do I snap to the nearest panel after release?

After the drag ends (on pointerup), find the panel index whose world angle is closest to 0. Compute the target rotation as -(index / N) * Math.PI * 2. Lerp the group rotation toward that target each frame at a factor of 0.08–0.12 until the difference is below 0.001.

Related experiments

Part of a weekly series on visual JavaScript, modern CSS, browser graphics, and HTML5 games—one live experiment per post, production-ready code snippets, and the reasoning behind each technique.

JavaScript Neon Trail Effect for HTML5 Games — Hero Ability & Cursor VFX

noreply@blogger.com (namzug) — Thu, 03 Sep 2026 15:30:00 +0000

Every hero ability needs a trail. This neon trail effect — each glowing dot fades from electric cyan to black with a motion-blur afterglow — is the exact visual pattern used for lightsabers, energy weapons, dash abilities, and sci-fi cursors in HTML5 games. Under 1 KB of vanilla JavaScript, zero libraries, perfect on touch via pointermove.

↗

What you will build

A glowing trail of 20 fading dots that follows the cursor with a staggered delay. Each dot is 10% smaller than the previous, colored with decreasing opacity. A semi-transparent background fill on each frame creates the motion-blur afterglow effect.

LIVE EXPERIMENT

Neon mouse trail

Move the pointer to draw light

How the JavaScript neon mouse trail works

Store the last 20 cursor positions in a ring buffer (a fixed-size array where new values overwrite the oldest). Each requestAnimationFrame tick: draw a rectangle over the whole canvas with alpha ~0.18—this creates the fade-out effect by partially erasing the previous frame rather than clearing it. Then iterate the buffer drawing each point as an arc with radius and opacity proportional to its index. Older points are smaller and more transparent.

The key technique is ctx.globalCompositeOperation = 'lighter' combined with low-alpha color values. This additive blending makes overlapping dots bloom brighter instead of stacking to a solid color, which creates the neon glow without any blur filter (blur filters are expensive on Canvas). The trail appears to emit light at the cursor tip and decay to darkness behind it.

demo.jsKEY IDEA

points.push({ x, y, alpha: 1 });

ctx.globalCompositeOperation = 'lighter';
points.forEach((point, index) => {
  point.alpha *= 0.965;
  ctx.strokeStyle = `rgba(30, 200, 255, ${point.alpha})`;
});

Two details carry the whole aesthetic: globalCompositeOperation = 'lighter' for additive glow, and alpha *= 0.965 per frame for the fade. Change the alpha multiplier to tune the trail length.

Why mouse trails still work in 2026

Mouse trails never went out of style—they just evolved. The 2000s version was a cheesy GIF overlay. The 2026 version is a compositing-mode Canvas animation under 1 KB that responds to both mouse and touch, respects prefers-reduced-motion, and can be layered over any content with pointer-events: none. Studios use them on agency sites and product launches to signal that every pixel is intentional.

This demo also teaches three transferable Canvas patterns: ring buffers for time-series data, partial-erase animation (vs. full clear) for motion blur, and additive blending for glow without blur filters. All three appear in game engines, data visualization libraries, and generative art tools.

Performance note

20 arc draws per frame is trivially cheap. If you extend to 100+ trail points for a longer tail, batch the paths: call ctx.beginPath() once, chain all arc() calls, then ctx.fill() once. This reduces Canvas state-change overhead from O(n) to O(1).

Ways to extend this effect

Swap the cyan color for a rainbow gradient by cycling through HSL hues based on trail index. Add a splatter effect on click: burst 10 short-lived particles outward from the click point using the same ring-buffer pattern. Combine with the Three.js Tubes Cursor Trail post to see how a 3D version of the same idea looks with geometry.

Frequently asked questions

How do I make the trail follow touch on mobile?

The pointermove event fires for both mouse and touch on modern browsers. No separate touch handler is needed—just listen to canvas.addEventListener('pointermove', handler). Set touch-action: none on the canvas to prevent the browser from scrolling while the trail is active.

How do I change the trail color?

Replace the rgba(30, 200, 255, ...) value with any color. Use HSL for easy hue cycling: hsl(${180 + index * 3}, 100%, 60%) gives a rainbow trail that shifts color along its length. Keep alpha below 0.8 so the additive blending creates bloom rather than a solid stripe.

Related experiments

Part of a weekly series on visual JavaScript, modern CSS, browser graphics, and HTML5 games—one live experiment per post, production-ready code snippets, and the reasoning behind each technique.

Three.js 3D Particle Effect for Games — WebGL Spell & Explosion VFX

noreply@blogger.com (namzug) — Thu, 03 Sep 2026 12:11:00 +0000

This is what 3D game particle VFX looks like in the browser. 4 000 particles orbit through WebGL space — move your cursor and a displacement wave ripples outward exactly like a magic spell or shockwave hit in a 3D HTML5 game. Three.js handles the GPU rendering; you write the physics. The same technique powers particle explosions, portal effects, and enemy death bursts in browser-based 3D games.

↗

What you will build

A BufferGeometry-powered particle cloud where the cursor position is projected onto a 3D plane and a radial force field repels nearby particles. Each particle stores position and velocity in a Float32Array updated entirely on the CPU each frame.

LIVE 3D EXPERIMENT

Three.js Particle Cursor Effect

Drag or move the pointer inside the 3D view

How the Three.js particle cursor effect works

Create a THREE.BufferGeometry and attach a Float32Array of 4 000 × 3 floats as the position attribute. A parallel array stores velocities. Each frame, use a THREE.Raycaster to project the normalized mouse coordinates (NDC) onto a plane at z = 0 to get the 3D intersection point. For each particle within the repulsion radius, compute the distance, scale the impulse inversely, and add it to the velocity. Damp all velocities by 0.92. Update the position attribute and set needsUpdate = true.

The jump from Canvas 2D to Three.js WebGL is not just about particle count. It unlocks additive blending (blending: THREE.AdditiveBlending) which makes dense clusters bloom white—an effect that is physically expensive to fake in 2D Canvas. It also opens the door to vertex shaders that color each particle by speed or distance from center without any per-particle JS color logic.

scene.jsKEY IDEA

const geometry = new THREE.BufferGeometry();
geometry.setAttribute(
  'position',
  new THREE.BufferAttribute(positions, 3)
);

const points = new THREE.Points(
  geometry,
  new THREE.PointsMaterial({ size: 0.028 })
);

All 4 000 particle positions live in one Float32Array sent to the GPU as a single buffer. The key line after updating it: geometry.attributes.position.needsUpdate = true.

Canvas 2D vs Three.js particles: when to use which

Canvas 2D handles 200–800 particles comfortably on any device. Three.js WebGL handles 10 000–100 000, with the upper limit set by your vertex shader complexity and GPU fill rate rather than CPU cycles. Use Canvas 2D when you need simplicity and maximum browser compatibility. Use Three.js when you need scale, depth, custom shaders, or scene integration with 3D objects.

For this demo, 4 000 particles is the sweet spot: visually dense enough to feel like a cloud, simple enough that a mid-range phone can sustain 60 fps. The repulsion radius and force strength are the two tuning knobs that control how the cloud responds—wider radius for a softer "breath," higher force for a sharp scatter.

Performance note

Never construct a new Float32Array inside the animation loop—allocate once at init time and overwrite values in-place. Call geometry.attributes.position.needsUpdate = true after each update, not before. Cap renderer.setPixelRatio to 2 on Retina screens; 3× or 4× DPR triples the fragment shader work for minimal visual gain.

Where to take this next

Replace the PointsMaterial with a custom ShaderMaterial that reads each particle's velocity magnitude as a uniform and maps it to color—fast-moving particles glow white, slow ones fade to blue. Add a secondary attractor point that orbits the center to give the cloud a vortex shape at rest. Or scale to 20 000 particles and move the physics to a compute shader using WebGPU.

Frequently asked questions

How is this different from the Canvas 2D particle cursor post?

The Canvas version uses 520 particles on the CPU with 2D drawing. This Three.js version uses 4 000 particles on the CPU with WebGL rendering, additive blending, and perspective projection. The physics formula is nearly identical—comparing both posts side by side is an excellent way to understand when WebGL overhead is justified by the visual payoff.

Can I use a texture for each particle instead of a dot?

Yes. Pass a THREE.TextureLoader-loaded sprite to PointsMaterial.map and set transparent: true, alphaTest: 0.01. Use a white radial gradient PNG for soft circular glows, or a star sprite for a starfield effect. The rest of the physics code stays identical.

Related experiments

Part of a weekly series on visual JavaScript, modern CSS, browser graphics, and HTML5 games—one live experiment per post, production-ready code snippets, and the reasoning behind each technique.

JavaScript Neon Trail Effect for HTML5 Games — Hero Ability & Cursor VFX

noreply@blogger.com (namzug) — Wed, 02 Sep 2026 22:39:23 +0000

↗

What you will build

LIVE EXPERIMENT

Neon mouse trail

Move the pointer to draw light

How the JavaScript neon mouse trail works

demo.jsKEY IDEA

points.push({ x, y, alpha: 1 });

ctx.globalCompositeOperation = 'lighter';
points.forEach((point, index) => {
  point.alpha *= 0.965;
  ctx.strokeStyle = `rgba(30, 200, 255, ${point.alpha})`;
});

Two details carry the whole aesthetic: globalCompositeOperation = 'lighter' for additive glow, and alpha *= 0.965 per frame for the fade. Change the alpha multiplier to tune the trail length.

Why mouse trails still work in 2026

Performance note

Ways to extend this effect

Frequently asked questions

How do I make the trail follow touch on mobile?

How do I change the trail color?

Related experiments

Part of a weekly series on visual JavaScript, modern CSS, browser graphics, and HTML5 games—one live experiment per post, production-ready code snippets, and the reasoning behind each technique.

JavaScript Top-Down Shooter — Canvas 2D Bullet System Tutorial

noreply@blogger.com (namzug) — Wed, 02 Sep 2026 22:39:17 +0000

Build a top-down shooter in vanilla JavaScript — rotating player ship, auto-firing bullet stream, enemy waves that approach from all edges, hit detection, and score. Zero libraries, zero assets, pure Canvas 2D. Move with WASD or arrows, and watch the bullet system manage itself automatically for the video demo.

↗

What you will build

A Canvas top-down shooter with a player ship that rotates to face the nearest enemy, auto-fires bullets, spawns enemies from random edge positions, and removes them on hit. The score increments with each kill. The entire game loop — physics, bullets, enemies, collision — is under 90 lines.

LIVE GAME DEMO

Top-Down Shooter — JavaScript Canvas

WASD / Arrows to move — auto-fires at enemies

How the top-down shooter bullet system works

Bullets are objects stored in a flat array: { x, y, vx, vy, life }. Each frame, velocity is added to position, life decrements, and off-screen or expired bullets are spliced out. Collision is distance-based: Math.hypot(bullet.x - enemy.x, bullet.y - enemy.y) < hitRadius. Simpler than AABB for circular ships, and fast enough for hundreds of simultaneous bullets at 60 fps.

Enemy AI is three lines: compute the angle from enemy to player, multiply by a speed scalar, add to position. This "seek" behavior is the foundation of every homing enemy in top-down games. For variety, add a noise offset to the angle: angle += Math.sin(time * 0.05) * 0.4 and enemies weave instead of charging straight.

shooter.jsKEY IDEA

// Spawn bullet in aim direction
function fireBullet() {
  bullets.push({
    x: player.x, y: player.y,
    vx: Math.cos(player.angle) * BULLET_SPEED,
    vy: Math.sin(player.angle) * BULLET_SPEED,
    life: 60
  });
}

// Enemy seek behavior
const angle = Math.atan2(player.y - e.y, player.x - e.x);
e.x += Math.cos(angle) * ENEMY_SPEED;
e.y += Math.sin(angle) * ENEMY_SPEED;

The entire bullet system is array push/splice + two Math functions. No physics engine, no library — just a loop and trigonometry.

Scaling up to a real game

Add a weapon system: store bullet properties (speed, spread, damage) in a config object and switch between them on pickup. Add spread by randomizing the angle slightly: angle += (Math.random() - 0.5) * spreadFactor. Add boss enemies by scaling the HP and hitRadius. Add screen shake by offsetting the ctx.save()/translate() by a decaying random amount when a hit registers.

Optimization for many bullets

For bullet-hell scenarios (200+ bullets), avoid pushing/splicing the array every frame. Instead, maintain a fixed-size pool: pre-allocate 300 bullet objects and mark them as active/inactive with a flag. Reactivate inactive bullets instead of allocating new ones. This eliminates garbage collection pauses at peak fire rates.

JavaScript Card Battle UI — Flip, Attack & Game Card Effects Canvas

noreply@blogger.com (namzug) — Wed, 02 Sep 2026 22:39:10 +0000

Card games live and die by their animations. This demo builds the complete visual layer for a card battle game — 3D card flip with face/back reveal, attack slash effect, card draw, HP bar drain, and a turn-based rhythm. All Canvas 2D, no libraries. Use this as the visual foundation for any HTML5 TCG, deckbuilder, or Hearthstone-style game.

↗

What you will build

A Canvas card battle scene with two opponents, animated card hands, a 3D flip effect using the horizontal scale trick (no WebGL needed), a lightning slash attack, and a hit shake effect. The demo cycles through draw → flip → attack → damage automatically. Click to play cards yourself.

LIVE GAME DEMO

Card Battle UI — JavaScript Canvas

Click a card in your hand to play it — auto-demo runs continuously

How the card flip animation works in Canvas

The 3D flip is a scale trick — no WebGL required. Call ctx.scale(flipScale, 1) before drawing the card. As flipScale goes from 1 → 0, the card horizontally compresses until it disappears. Swap which face is drawn at scale 0, then animate back from 0 → 1. The result is an apparent 3D rotation achieved entirely with 2D canvas scaling.

card.jsKEY IDEA

// 3D card flip illusion with ctx.scale
function drawCard(x, y, w, h, card, flipScale) {
  ctx.save();
  ctx.translate(x + w / 2, y + h / 2);
  ctx.scale(flipScale, 1); // horizontal squeeze = flip illusion
  ctx.translate(-(x + w / 2), -(y + h / 2));

  // Show front if scale is positive, back if negative
  const showFront = flipScale >= 0;
  if (showFront) drawCardFront(ctx, card, x, y, w, h);
  else           drawCardBack(ctx, card, x, y, w, h);
  ctx.restore();
}

One ctx.scale() call fakes a 3D card flip. No WebGL, no CSS 3D transforms — just 2D canvas math.

Building the full card battle system

The battle runs as a state machine: idle → flip → attack → enemyAI → idle. Each state has a timer and transitions when the timer completes. The AI is simple: after the player's attack resolves, the enemy automatically attacks back with a random damage value. This two-state exchange is the core loop of every turn-based card game.

Build a full TCG from this base

Add a deck as an array shuffled with Fisher-Yates. Add mana cost to each card and a mana bar. Add special card effects: fire cards deal 2× to ice, ice cards freeze for one turn, thunder ignores defense. Add an animation queue so effects chain smoothly. Add a mulligan screen at the start. Each feature is 10–30 lines on this foundation.

Three.js 3D Particle Effect for Games — WebGL Spell & Explosion VFX

noreply@blogger.com (namzug) — Wed, 02 Sep 2026 12:15:00 +0000

↗

What you will build

LIVE 3D EXPERIMENT

Three.js Particle Cursor Effect

Drag or move the pointer inside the 3D view

How the Three.js particle cursor effect works

scene.jsKEY IDEA

const geometry = new THREE.BufferGeometry();
geometry.setAttribute(
  'position',
  new THREE.BufferAttribute(positions, 3)
);

const points = new THREE.Points(
  geometry,
  new THREE.PointsMaterial({ size: 0.028 })
);

All 4 000 particle positions live in one Float32Array sent to the GPU as a single buffer. The key line after updating it: geometry.attributes.position.needsUpdate = true.

Canvas 2D vs Three.js particles: when to use which

Performance note

Where to take this next

Frequently asked questions

How is this different from the Canvas 2D particle cursor post?

Can I use a texture for each particle instead of a dot?

Related experiments

Part of a weekly series on visual JavaScript, modern CSS, browser graphics, and HTML5 games—one live experiment per post, production-ready code snippets, and the reasoning behind each technique.

JavaScript Magnetic Button for Game Menus — Lerp Hover Effect Tutorial

noreply@blogger.com (namzug) — Tue, 01 Sep 2026 12:14:51 +0000

Game feel starts with the menu. This magnetic button effect — built in 40 lines of vanilla JavaScript with a single lerp formula — adds the satisfying pull-and-spring response that makes game menus feel alive. Use it on Start, Play, or Attack buttons to give your HTML5 game UI instant personality. No libraries. Works on every pointer device.

↗

What you will build

A button that detects cursor proximity, computes an attraction offset, and smoothly interpolates its position toward the cursor each frame. Remove the cursor and the button springs back to center via the same lerp formula.

LIVE EXPERIMENT

Magnetic button

Move the pointer around the button

How the JavaScript magnetic button effect works

On each mousemove event, compute the vector from the cursor to the button center: dx = pointer.x - center.x, dy = pointer.y - center.y. Calculate distance with Math.hypot(dx, dy). If the cursor is within the activation radius, compute a pull factor that peaks at 1.0 when the cursor is on-center and fades to 0 at the radius edge. Multiply dx * pull * strength to get the target offset for the button.

Apply linear interpolation (lerp) every animation frame: currentX += (targetX - currentX) * 0.15. This creates the inertia—the button chases but never instantly reaches its target, which makes the motion feel organic. When the cursor leaves the proximity zone, the target snaps back to (0, 0) and the button eases to rest.

demo.jsKEY IDEA

const dx = pointer.x - center.x;
const dy = pointer.y - center.y;
const distance = Math.hypot(dx, dy);

const pull = Math.max(0, 1 - distance / radius);
buttonX = center.x + dx * pull * 0.35;
buttonY = center.y + dy * pull * 0.35;

The pull factor is the whole trick: 1.0 at center, 0.0 at the radius edge. Multiply it by a strength below 1.0 so the button never fully reaches the cursor—that gap is what makes it feel magnetic rather than sticky.

Why this interaction feels great in game menus

The "game feel" in a menu comes from physics-based response. A button that snaps instantly feels mechanical and cheap. A button that follows the cursor with a slight lag but springs back to center feels like it has mass and personality. The lerp factor (0.08–0.2) controls the spring: slow lerp = heavy button, fast lerp = light, snappy button. For a heavy warrior class button, use 0.06. For a fast rogue class button, use 0.2. Same formula, different personality.

Agencies like STRV, Locomotive, and Resn use this pattern on call-to-action buttons because it rewards cursor exploration. In a game, it rewards players for exploring the menu. The code is 40 lines including the lerp and the radius guard — drop it into your game's title screen tonight.

Performance note

Apply will-change: transform to the magnetic element so the browser pre-promotes it to its own compositing layer. Skip the lerp and apply the transform synchronously inside the mousemove handler if you want zero-lag snap instead of eased follow. Cancel the animation frame loop when the cursor leaves the proximity zone to avoid unnecessary work.

Ways to extend this pattern

Apply the same proximity-and-lerp formula to multiple elements simultaneously—a group of nav links that each deflect slightly as the cursor passes through creates an immersive navigation experience. Add a subtle rotateX/rotateY tilt based on the cursor offset relative to the button center for a 3D card-tilt variant. Or drive the magnetic pull strength from a scroll progress value so the button gets stronger as the user scrolls toward it.

Frequently asked questions

Does the magnetic button effect work on touchscreens?

Yes, using touchmove. Set touch-action: none on the element to prevent scroll interference, and read position from event.touches[0].clientX/Y. The lerp factor makes it feel natural on touch since the element follows the finger with a slight delay rather than teleporting.

How do I tune the feel of the magnetic effect?

Three numbers control everything: radius (how close the cursor must be to activate), strength (how far the button travels toward the cursor, typically 0.25–0.45), and the lerp factor (0.08 for sluggish, 0.25 for snappy). Start with strength 0.35 and a radius equal to the button's diagonal length.

Related experiments

Part of a weekly series on visual JavaScript, modern CSS, browser graphics, and HTML5 games—one live experiment per post, production-ready code snippets, and the reasoning behind each technique.

JavaScript 2D Platformer Physics — Jump Arc, Gravity & Coyote Time

noreply@blogger.com (namzug) — Tue, 01 Sep 2026 12:06:11 +0000

The jump is the heart of every platformer. This demo shows a complete 2D platformer physics loop in vanilla JavaScript and Canvas — gravity, variable jump height, coyote time so platform edges feel forgiving, horizontal acceleration, friction, and solid AABB collision. The character moves automatically when idle, but keyboard input instantly takes control.

↗

```

What you will build

A Canvas character that runs across platforms, jumps with a variable-height arc (hold longer = jump higher), and gets 80ms of coyote time after leaving a platform. Collision is resolved separately on the X and Y axes for predictable floor, wall, and ceiling detection.

```

LIVE GAME DEMO

2D Platformer Physics — JavaScript Canvas

Arrow keys or A/D to move, Space / W / ↑ to jump

```

How 2D platformer physics works in JavaScript

A simple platformer does not need a full physics engine. Each frame, the game updates horizontal velocity, applies gravity to vertical velocity, moves the character, checks for collisions, and corrects any overlap with the platforms.

The important part is resolving horizontal and vertical movement separately. First the player moves on the X axis and wall collisions are resolved. Then the player moves on the Y axis and floor or ceiling collisions are resolved. This approach keeps collision behavior predictable and avoids many common corner-sticking problems found in beginner platformer code.

```

platformer.js KEY IDEA

// Gravity
```

player.vy += GRAVITY * dt;

// Horizontal movement
player.x += player.vx * dt;
resolveCollisionsX(player, platforms);

// Vertical movement
player.y += player.vy * dt;
resolveCollisionsY(player, platforms);

// Jump
if (jumpPressed && player.coyote > 0) {
player.vy = JUMP_FORCE;
player.coyote = 0;
}

Separating horizontal and vertical collision resolution makes floor, wall, and ceiling detection easier to control and debug.

Variable jump height — tap or hold

Good platformer jumps are usually not fixed. A quick tap should create a short jump, while holding the jump button should allow the character to travel higher.

This demo implements variable jump height by watching for the moment the jump button is released. If the player is still moving upward, the game immediately reduces the upward velocity.

```

jump-cut.js VARIABLE HEIGHT

const jumpReleased =
```

!jump && player.jumpHeld;

if (jumpReleased && player.vy < 0) {
player.vy *= JUMP_CUT;
}

The result is simple: tap the button for a low jump or hold it for a higher arc. This small change gives the player much more control over landing precision.

Coyote time — why platformers feel more forgiving

Coyote time gives the player a tiny window to jump after walking off the edge of a platform. Without it, pressing jump one frame too late can feel unresponsive. With coyote time, the controls tolerate a small amount of human timing error.

This demo uses an 80ms coyote-time window. Whenever the player is standing on a platform, the timer resets. After leaving the platform, the timer counts down toward zero. A jump is still allowed while that timer remains active.

```

coyote-time.js 80 MS WINDOW

if (player.onGround) {
```

player.coyote = COYOTE_TIME;
} else {
player.coyote =
Math.max(0, player.coyote - delta);
}

if (jumpPressed && player.coyote > 0) {
player.vy = JUMP_FORCE;
player.coyote = 0;
}

Automatic demo without fighting the player

Interactive examples embedded inside articles have one useful problem: if the character starts completely still, some readers may never realize the Canvas is playable.

This demo therefore moves automatically while idle. However, automatic input must never compete with real keyboard input. The moment the reader presses a movement or jump key, automatic movement is disabled and manual controls receive full priority.

```

input.js PLAYER PRIORITY

const manualMode =
```

now < manualUntil;

const left =
manualMode ? manualLeft : auto.left;

const right =
manualMode ? manualRight : auto.right;

const jump =
manualMode ? manualJump : auto.jump;

After a short period without keyboard input, the automatic demo resumes. This keeps the example visually active while still making the controls feel immediate when the reader interacts with it.

Why the original input logic could fail

A common mistake is combining automatic and manual movement in the same condition:

```

wrong.js INPUT BUG

if (rightKey || autoRight) {
```

player.vx += acceleration;
} else if (leftKey) {
player.vx -= acceleration;
}

If autoRight is true, the first condition wins even when the player is pressing left. The automatic demo effectively fights the keyboard.

The corrected version keeps automatic and manual input separate and explicitly selects which input source controls the character.

Axis-separated AABB collision

The platforms and player are rectangles, so collision detection uses axis-aligned bounding boxes, usually called AABB collision.

An overlap exists when the player's rectangle intersects a platform on both the horizontal and vertical axes. Once an overlap is found, the game compares the penetration depth and pushes the character out along the appropriate axis.

```

aabb.js COLLISION

function aabb(a, b) {
```

return (
a.x < b.x + b.w &&
a.x + a.w > b.x &&
a.y < b.y + b.h &&
a.y + a.h > b.y
);
}

Delta time keeps movement more consistent

Browser animation is usually close to 60 frames per second, but it is not guaranteed to run at exactly the same speed on every frame. That is why this version calculates a small delta-time multiplier.

Movement and gravity are multiplied by that value, which reduces visible speed differences when frames are slightly delayed. The delta value is also capped so switching browser tabs does not cause a huge physics update when the tab becomes active again.

``` Add this physics loop to your HTML5 game

This structure can be used as the foundation of a larger Canvas platformer. Replace the rectangle with a sprite, add animation states, move platforms into level data, and introduce a camera for scrolling worlds. The same player state can also be extended with wall detection, dash mechanics, one-way platforms, enemies, checkpoints, and collectibles.

```

Next steps: make it a real game

Once the base movement feels good, add features one at a time. One-way platforms can ignore upward collisions and only catch the player while falling. Wall jumps can detect horizontal contact and apply a vertical impulse. Moving platforms can update their own position before player collision is resolved.

For a side-scrolling level, add a camera offset instead of moving the entire world manually. Draw platforms and the player relative to the camera position, while keeping physics coordinates in world space.

From there, the most important improvement is not adding more physics — it is tuning the values you already have. Experiment with GRAVITY, JUMP_FORCE, FRICTION, JUMP_CUT, and COYOTE_TIME until movement feels responsive. In platformers, small timing changes can completely change how the game feels.

Build a Phaser 4 Breakout Game — Complete HTML5 Browser Tutorial

noreply@blogger.com (namzug) — Tue, 01 Sep 2026 11:49:31 +0000

Build a fully playable Breakout brick-breaker in Phaser 4 — paddle, ball, 40 destructible bricks, score counter, and three lives — entirely in the browser, no downloads, no assets. Under 80 lines of Phaser 4 Scene code. The game auto-plays an AI paddle so you can watch the physics in action, or grab the mouse to play yourself.

↗

What you will build

A Phaser 4 scene with a ball bouncing off walls, a paddle controlled by the mouse (with AI fallback for auto-play), 40 bricks arranged in 5 color-coded rows, a score counter, and a lives system. When all bricks are cleared the game resets — a clean loop you can fork as an arcade game starter.

PHASER 4 LIVE GAME

Phaser 4 Breakout — Play in Browser

Move the mouse to control the paddle — or watch the AI play

How the Phaser 4 Breakout game is structured

The entire game lives in a single Phaser.Scene class with two methods: create() sets up the scene objects once, and update() runs every frame. Bricks are stored in an array of Phaser.GameObjects.Rectangle objects, each with an alive flag. When a brick is hit, the flag is set to false and the rectangle is hidden — no physics engine required for a game this size.

Ball physics is manual: add velocity to position each frame, flip the sign on collision. Paddle angle is computed from how far off-center the ball hits: const offset = (ball.x - paddle.x) / halfPaddleWidth. Multiplied by a max speed of 5.5, this gives a range from sharp angles at the edges to straight bounces at the center — the core feel of Breakout.

breakout.js KEY IDEA

// Place bricks in a grid
for (let row = 0; row < 5; row++) {
  for (let col = 0; col < 8; col++) {
    const brick = this.add.rectangle(
      60 + col * 76, 55 + row * 28,
      68, 20, rowColors[row]
    );
    brick.alive = true;
    this.bricks.push(brick);
  }
}

// Angle the ball based on paddle hit position
const offset = (ball.x - paddle.x) / halfPaddle;
ball.vx = offset * MAX_SPEED;
ball.vy = -Math.abs(ball.vy);

Breakout needs no physics engine — manual velocity + AABB collision is 10 lines and runs at 60 fps in every browser.

Why Phaser 4 is ideal for HTML5 arcade games

Phaser 4's Scene API gives you a deterministic create → update loop, an automatic renderer that switches between WebGL and Canvas 2D, and built-in input events — everything Breakout needs. The Phaser.Scale.FIT mode handles all screen sizes automatically, so your game looks correct on mobile and desktop without a single line of resize code.

For a game like Breakout, you don't need Phaser's physics engine (Arcade or Matter.js). Manual velocity math is faster to write, easier to debug, and runs identically everywhere. Reserve Phaser's physics for games with complex collision shapes or many interacting bodies.

Performance note

40 bricks as Rectangle game objects are batched into a single draw call in Phaser's WebGL renderer. If you scale to hundreds of bricks, switch to a Phaser.GameObjects.Graphics or a tilemap for even lower draw-call overhead.

Extend this into a full game

Add power-ups by spawning a falling rectangle when a brick is destroyed. Add multiple balls for chaos mode. Randomize brick layouts each round for a roguelike Breakout. Replace the rectangles with sprite textures using this.add.image() for pixel-art bricks. Add a high-score system with localStorage in three lines. This mini game is a complete, forkable foundation.

JavaScript Particle Hit Effect for HTML5 Games — Canvas Tutorial

noreply@blogger.com (namzug) — Tue, 01 Sep 2026 11:45:04 +0000

Every great game hit, explosion, or magic spell needs particles. This demo shows the complete particle system in 60 lines of vanilla JavaScript Canvas — a repulsion field that scatters 520 glowing particles on contact, exactly like an enemy hit reaction or a spell impact in an HTML5 game. Zero libraries, zero build step, 60 fps on every device.

↗

What you will build

A pointer-reactive particle field that responds to both mouse and touch at 60 fps. Each particle's velocity is computed from cursor proximity, creating an organic repulsion wave that feels alive on any screen size.

LIVE EXPERIMENT

Particle cursor field

Move the pointer through the particles

How the JavaScript particle cursor effect works

The effect keeps a flat array of 520 particles, each with just four numbers: x, y, vx, vy. On every requestAnimationFrame tick the loop measures squared distance from the cursor to each particle—skipping the expensive Math.sqrt until the force threshold is confirmed—then applies a velocity impulse inversely proportional to distance. A friction factor of 0.93 damps each velocity component per frame, and coordinates wrap at the canvas boundary so particles never escape.

The key architectural split is between physics (update velocities and positions) and rendering (clear canvas, draw each particle). Keeping these two passes separate means you can tune them independently: swap the repulsion formula without touching the draw code, or change the particle color scheme without re-testing the physics.

demo.jsKEY IDEA

canvas.addEventListener('pointermove', (event) => {
  mouse.x = event.clientX - bounds.left;
  mouse.y = event.clientY - bounds.top;
});

const distance = Math.hypot(dx, dy);
if (distance < radius) {
  particle.vx += (dx / distance) * force;
  particle.vy += (dy / distance) * force;
}

These two lines are the entire physics engine. The cursor position feeds the force; the damping factor controls how quickly particles settle. Change 0.93 to 0.99 for a much slower, dreamier decay.

How to use this particle system in your HTML5 game

This particle system is the building block for hit FX, explosions, magic effects, and environmental particles in any HTML5 game. When an enemy takes damage: spawn 20–40 particles at the hit position with a random velocity spread and their color set to the enemy's palette. When a spell lands: spawn 80+ particles with an outward spiral velocity. The demo uses the cursor as the spawn point — in your game, replace it with the collision point.

The core pattern — array of particles, physics update, draw, wrap — scales from 50 to 2 000 particles on mobile browsers. Euler integration (position += velocity * dt), damping (velocity *= 0.93), and boundary wrapping are the same three patterns used in every major game engine's CPU particle system.

Performance note

520 particles at 60 fps is about 31 000 vector operations per second—well within Canvas 2D limits. Cap devicePixelRatio at 2 to avoid doubling work on Retina screens. If you scale past 2 000 particles, switch to a Float32Array for positions and profile on mobile before shipping.

Extending this into game effects

Replace repulsion with attraction to create a gravity vortex — perfect for a black hole enemy or a vacuum power-up. Add color tiers based on particle speed: fast = bright orange (fire), slow = dark red (embers) for a fire particle effect. Add a life counter and fade alpha over time for explosion debris that disappears. Add gravity (vy += 0.1 each frame) for sparks that fall to the floor. These four tweaks turn this base system into four distinct game effects.

Frequently asked questions

Can I use this particle cursor effect on a production website?

Yes. The core is under 2 KB of vanilla JS with no build step required. Wrap the animation loop in a check for window.matchMedia('(prefers-reduced-motion: reduce)') and skip it for users who prefer less motion—an essential accessibility step for any animated canvas.

How do I make the particles attract instead of repel the cursor?

Change the impulse direction: multiply dx and dy by -1 before adding to velocity. Now particles accelerate toward the cursor. Combine with a damping factor above 0.95 for a sticky cluster that slowly falls back into place when the cursor leaves.

Related experiments

This is part of a weekly series on visual JavaScript, modern CSS, browser graphics, and HTML5 games—one live experiment per post, copy-paste ready code, and the reasoning that makes each technique reusable beyond the demo.

JavaScript Black Hole Animation with Canvas

noreply@blogger.com (namzug) — Sun, 30 Aug 2026 13:35:33 +0000

In this experiment, we'll build an interactive black hole animation with JavaScript and HTML5 Canvas, including an accretion disk, spiraling particles, adjustable gravity, and a visual approximation of gravitational lensing. You can run the demo directly in your browser and change gravity, mass, and density in real time.

LIVE DEMO

Interactive Black Hole Demo

Move the pointer near the black hole

CANVAS + JAVASCRIPT

Gravity 0.55 Mass 6.0 Particles 90

The idea in one line

We are not solving general relativity in the browser. We combine a simple inverse-distance force with real visual cues — shadow, accretion disk, gravitational lensing and asymmetric brightness — so the result looks and feels much more convincing.

How the JavaScript Gravity Effect Works

gravity.js

const dx = blackHole.x - particle.x;
const dy = blackHole.y - particle.y;
const distanceSq = dx * dx + dy * dy;

const force = (gravity * mass) / distanceSq;
const distance = Math.sqrt(distanceSq);
const nx = dx / distance;
const ny = dy / distance;

// Pull inward + add a tangential component so matter spirals.
particle.vx += nx * force - ny * orbit;
particle.vy += ny * force + nx * orbit;

The force stays intentionally simple; most of the visual realism comes from how the disk is projected, lit and bent around the shadow.

How the Black Hole Effect Is Built

1. Shadow + ringThe center stays completely dark while a thin light ring marks the strongly lensed region around the shadow.

2. Accretion diskHot gas orbits in an inclined disk: whiter near the center and more orange/red farther out.

3. Lensing + motionThe back side of the disk reappears bent above and below the shadow while outer particles accelerate and spiral inward.

↗

Challenge

Try maximum mass with low gravity. Then reverse the radial force: the disk and lensing remain, but the outer particles begin to escape.

This experiment is part of Can JavaScript Do This?, our series of visual effects, games, and experiments built directly in the browser. Try the demo, change gravity, and watch how the system responds.

Cómo crear un agujero negro con JavaScript y Canvas

noreply@blogger.com (namzug) — Sun, 30 Aug 2026 13:31:52 +0000

Una visualización interactiva inspirada en cómo reconocemos un agujero negro: sombra central, anillo de fotones, disco de acreción brillante y luz deformada alrededor. Mueve el cursor y cambia gravedad, masa y densidad para ver cómo responde la escena.

LIVE DEMO

Pruébalo

Mueve el cursor cerca del agujero negro

CANVAS + JAVASCRIPT

Gravedad 0.55 Masa 6.0 Partículas 90

La idea en una línea

No intentamos resolver relatividad general en el navegador. Combinamos una fuerza inversa con señales visuales reales de un agujero negro —sombra, disco de acreción, lente gravitacional y brillo asimétrico— para que el resultado se vea y se sienta mucho más convincente.

La línea que cambia todo

gravity.js

const dx = blackHole.x - particle.x;
const dy = blackHole.y - particle.y;
const distanceSq = dx * dx + dy * dy;

const force = (gravity * mass) / distanceSq;
const distance = Math.sqrt(distanceSq);
const nx = dx / distance;
const ny = dy / distance;

// Pull inward + add a tangential component so matter spirals.
particle.vx += nx * force - ny * orbit;
particle.vy += ny * force + nx * orbit;

La fuerza sigue siendo deliberadamente simple; el realismo visual viene de cómo proyectamos, iluminamos y curvamos el disco alrededor de la sombra.

Qué está pasando

1. Sombra + anilloEl centro permanece completamente oscuro y un anillo fino de luz marca la zona donde la luz fuertemente curvada domina la imagen.

2. Disco de acreciónEl gas caliente orbita en un disco inclinado: más blanco cerca del centro y más naranja/rojo hacia afuera.

3. Lente + movimientoLa parte trasera del disco reaparece curvada arriba y abajo, mientras las partículas externas aceleran y espiralan hacia el centro.

↗

Reto

Prueba masa máxima y gravedad baja. Después invierte la fuerza radial: conservarás el disco y la lente, pero las partículas exteriores comenzarán a escapar.

Este experimento forma parte de nuestra serie de cosas visuales hechas directamente en el navegador.

Canvas responsive en juegos HTML5: guía práctica con Phaser 4

noreply@blogger.com (namzug) — Tue, 25 Aug 2026 09:21:43 +0000

Hacer un juego responsive no significa simplemente poner width: 100% al canvas. En un juego HTML5 hay que coordinar al menos cinco cosas: el tamaño visual del elemento, la resolución interna del bitmap, la relación de aspecto, las coordenadas del input y la posición del HUD. En esta guía vamos a resolver cada una con ejemplos prácticos y después veremos cómo aplicar la misma idea en Phaser 4.

Canvas API · ResizeObserver · DPR · Phaser 4

Un juego responsive debe mantener gameplay, nitidez e interfaz utilizables en pantallas con proporciones muy diferentes.

Responsive no es igual a estirar

El objetivo no es deformar un juego de 16:9 hasta llenar cualquier pantalla. Primero decides qué permanece fijo, qué puede crecer, qué puede recortarse y qué elementos del HUD deben recolocarse.

El problema: un canvas tiene dos tamaños

Este es el concepto más importante de todo el tutorial. Un elemento <canvas> tiene:

Tamaño CSS

Es el tamaño que ves en la página.
Se mide en CSS pixels.
Puede ser width: 100%.
No cambia automáticamente la resolución interna.

Tamaño interno

Es el bitmap real del canvas.
Depende de canvas.width y canvas.height.
Determina cuántos píxeles renderizamos.
Influye directamente en nitidez y rendimiento.

Por ejemplo, esto hace que el canvas se vea grande:

CSS Solo tamaño visual

canvas {
  width: 100%;
  height: auto;
}

Pero si internamente el canvas sigue teniendo una resolución muy pequeña, el navegador deberá escalar ese bitmap y el resultado puede verse borroso.

1. Empieza con un contenedor, no con el canvas

Una estructura bastante segura para un juego embebido en una web es controlar primero el espacio disponible:

HTML Contenedor del juego

<div id="game-shell">
  <canvas id="game"></canvas>
</div>

CSS Wrapper responsive 16:9

html,
body {
  margin: 0;
  background: #071522;
}

#game-shell {
  width: min(100%, 1280px);
  aspect-ratio: 16 / 9;

  margin-inline: auto;

  position: relative;
  overflow: hidden;

  background: #071522;
}

#game {
  display: block;

  width: 100%;
  height: 100%;
}

Con aspect-ratio: 16 / 9, el espacio visible conserva la proporción del juego. En un blog o portal, esta estrategia es especialmente cómoda porque el canvas no intenta ocupar una altura arbitraria.

2. Haz que el bitmap interno siga al tamaño visible

Ahora vamos a resolver la nitidez. Leeremos el tamaño CSS real del canvas y crearemos un bitmap interno proporcional a la densidad de píxeles del dispositivo.

JavaScript Canvas HiDPI

const canvas = document.querySelector("#game");
const ctx = canvas.getContext("2d");

function resizeCanvas() {
  const rect = canvas.getBoundingClientRect();

  const dpr = Math.min(
    window.devicePixelRatio || 1,
    2
  );

  const width = Math.round(rect.width * dpr);
  const height = Math.round(rect.height * dpr);

  if (
    canvas.width !== width ||
    canvas.height !== height
  ) {
    canvas.width = width;
    canvas.height = height;
  }

  // Trabajaremos en CSS pixels.
  ctx.setTransform(
    dpr, 0,
    0, dpr,
    0, 0
  );
}

¿Por qué limitar DPR a 2?

Un teléfono puede tener un devicePixelRatio de 3 o más. Eso no significa que siempre sea buena idea renderizar cuatro, nueve o más veces la cantidad de píxeles. En juegos, limitar el DPR es una decisión útil para equilibrar nitidez y fill-rate de GPU.

3. Usa ResizeObserver en lugar de depender solo de window.resize

Un canvas puede cambiar de tamaño sin que cambie la ventana: por ejemplo, si se abre un sidebar, cambia el layout del blog o el juego está dentro de un panel responsive.

Para reaccionar al tamaño real del contenedor:

JavaScript ResizeObserver

const shell = document.querySelector(
  "#game-shell"
);

const resizeObserver =
  new ResizeObserver(() => {
    resizeCanvas();
  });

resizeObserver.observe(shell);

resizeCanvas();

Así no dependemos de adivinar por qué cambió el layout. Siempre que el contenedor cambie de tamaño, recalculamos el canvas.

4. No dibujes usando directamente canvas.width

Después de aplicar DPR, canvas.width ya no representa el tamaño visual. Puede ser el doble o triple del ancho CSS.

En su lugar utiliza el rect visible:

JavaScript Tamaño lógico visible

const rect =
  canvas.getBoundingClientRect();

const viewWidth = rect.width;
const viewHeight = rect.height;

Ahora podemos dibujar utilizando CSS pixels independientemente del DPR.

5. Ejemplo completo: escena responsive sin motor

Este ejemplo dibuja un pequeño escenario y recoloca los elementos usando el tamaño actual del canvas:

JavaScript Render responsive

function render() {
  const rect =
    canvas.getBoundingClientRect();

  const width = rect.width;
  const height = rect.height;

  ctx.clearRect(
    0,
    0,
    width,
    height
  );

  // Fondo
  ctx.fillStyle = "#071522";
  ctx.fillRect(
    0,
    0,
    width,
    height
  );

  // Suelo proporcional a la pantalla
  const groundY = height * 0.78;

  ctx.fillStyle = "#173d2c";
  ctx.fillRect(
    0,
    groundY,
    width,
    height - groundY
  );

  // Jugador
  const playerSize =
    Math.max(
      32,
      Math.min(64, width * 0.06)
    );

  const playerX = width * 0.18;
  const playerY =
    groundY - playerSize;

  ctx.fillStyle = "#22d3ee";

  ctx.fillRect(
    playerX,
    playerY,
    playerSize,
    playerSize
  );

  // Enemigo
  const enemySize =
    playerSize * 0.8;

  ctx.fillStyle = "#ff8a1f";

  ctx.fillRect(
    width * 0.72,
    groundY - enemySize,
    enemySize,
    enemySize
  );

  requestAnimationFrame(render);
}

resizeCanvas();
render();

Fíjate en que no existe un x = 900 que dependa de una resolución concreta. Las posiciones principales se calculan como porcentajes del espacio visible.

6. Pero un juego real necesita coordenadas lógicas

Calcular todo con porcentajes funciona para interfaces simples, pero puede convertirse en un problema para niveles, físicas y mapas.

En muchos juegos es mejor mantener una resolución lógica fija:

JavaScript Resolución lógica

const GAME_WIDTH = 1280;
const GAME_HEIGHT = 720;

Todo el gameplay vive en ese mundo de 1280 × 720 y el canvas visible solo decide cómo mostrarlo.

Esto produce una separación muy útil:

Game coordinates Posiciones del jugador, enemigos, colisiones, cámara y física.

Display coordinates Tamaño real del canvas dentro del navegador.

UI coordinates HUD, botones táctiles, safe areas y overlays adaptativos.

7. Calcular un escalado FIT manualmente

Supongamos que nuestro juego lógico mide:

Juego Base size

1280 × 720

y el contenedor disponible tiene cualquier otro tamaño.

Para hacer FIT sin deformar:

JavaScript Scale factor

const scale = Math.min(
  viewWidth / GAME_WIDTH,
  viewHeight / GAME_HEIGHT
);

const displayWidth =
  GAME_WIDTH * scale;

const displayHeight =
  GAME_HEIGHT * scale;

El juego completo queda visible. Si la relación de aspecto del dispositivo es distinta, aparecerán bandas libres en un eje.

FIT vs ENVELOP vs RESIZE

FIT conserva todo el juego, ENVELOP llena el área recortando extremos y RESIZE cambia realmente el tamaño lógico disponible.

FIT

Mantiene relación de aspecto.
Todo el juego permanece visible.
Puede dejar letterbox.
Excelente para gameplay con composición fija.

ENVELOP

Mantiene relación de aspecto.
Llena completamente la pantalla.
Puede ocultar los bordes del mundo.
Útil si el gameplay tolera crop.

RESIZE

Cambia el tamaño real disponible.
No obliga a mantener una proporción fija.
Ideal para interfaces adaptativas.
Necesita relayout del mundo y HUD.

EXPAND

Combina ideas de RESIZE y FIT.
Utiliza todo el espacio del parent.
Puede ser útil para layouts híbridos.
Conviene probarlo en dispositivos reales.

8. Input responsive: transformar pointer a coordenadas del juego

Si el canvas se está escalando, no podemos asumir que:

Incorrecto Pointer

const x = event.clientX;
const y = event.clientY;

sean coordenadas válidas dentro del mundo.

Primero calculamos la posición relativa al canvas:

JavaScript Pointer local

function getPointerPosition(event) {
  const rect =
    canvas.getBoundingClientRect();

  const x =
    event.clientX - rect.left;

  const y =
    event.clientY - rect.top;

  return { x, y };
}

Si además utilizas un mundo lógico 1280 × 720 escalado con FIT, debes compensar el factor de escala y el offset del letterbox:

JavaScript Display → game coordinates

const offsetX =
  (viewWidth - displayWidth) / 2;

const offsetY =
  (viewHeight - displayHeight) / 2;

const gameX =
  (pointerX - offsetX) / scale;

const gameY =
  (pointerY - offsetY) / scale;

Este error rompe muchos juegos móviles

Visualmente el botón parece estar en un lugar, pero su hit area queda desplazada porque el input sigue utilizando coordenadas de pantalla sin convertirlas al sistema lógico.

9. Responsive en Phaser 4: el caso sencillo con FIT

Phaser ya incluye un Scale Manager que resuelve gran parte del trabajo anterior.

Si tu juego está diseñado sobre una resolución lógica fija de 1280 × 720:

Phaser 4 Scale.FIT

import * as Phaser from "phaser";

const config:
  Phaser.Types.Core.GameConfig = {

  type: Phaser.AUTO,

  width: 1280,
  height: 720,

  parent: "game-container",

  scale: {
    mode: Phaser.Scale.FIT,

    autoCenter:
      Phaser.Scale.CENTER_BOTH,

    width: 1280,
    height: 720
  },

  scene: [
    MainScene
  ]
};

new Phaser.Game(config);

FIT mantiene la relación de aspecto y escala el canvas para que entre dentro del parent. Es una muy buena opción para:

plataformas;
puzzle;
arcade;
juegos con niveles diseñados sobre una composición fija;
juegos donde no quieres mostrar más mundo en dispositivos ultrawide.

10. CSS del parent para Phaser

El Scale Manager necesita un parent con un tamaño real y predecible:

CSS Phaser parent

html,
body {
  margin: 0;

  width: 100%;
  min-height: 100%;

  background: #071522;
}

#game-container {
  width: 100%;
  height: 100dvh;

  overflow: hidden;

  display: flex;
  align-items: center;
  justify-content: center;
}

#game-container canvas {
  display: block;
}

Utilizar 100dvh evita parte de los problemas históricos de 100vh en navegadores móviles donde la barra del navegador entra y sale.

11. ¿Cuándo utilizar RESIZE en Phaser?

Con RESIZE Phaser ajusta el canvas al espacio disponible en el parent:

Phaser 4 Scale.RESIZE

scale: {
  mode: Phaser.Scale.RESIZE,

  parent: "game-container"
}

Aquí la Scene debe reaccionar al nuevo tamaño.

Phaser 4 Resize event

create() {
  this.scale.on(
    "resize",
    this.onResize,
    this
  );

  this.onResize(
    this.scale.gameSize
  );
}

onResize(gameSize) {
  const width =
    gameSize.width;

  const height =
    gameSize.height;

  this.scoreText.setPosition(
    24,
    24
  );

  this.pauseButton.setPosition(
    width - 40,
    40
  );

  this.player.setPosition(
    width * 0.25,
    height * 0.72
  );
}

RESIZE no es gratis

Un canvas de mayor resolución obliga a la GPU a renderizar más píxeles. En un monitor 4K o un teléfono con DPR alto puedes multiplicar enormemente el fill-rate. Añade límites y prueba rendimiento real.

12. HUD responsive: usa anchors, no posiciones mágicas

Un error clásico:

Evita Hardcoded HUD

pauseButton.setPosition(
  1180,
  40
);

Si el ancho puede cambiar, utiliza el ancho actual:

Mejor Anchor al borde

pauseButton.setPosition(
  width - 40,
  40
);

Podemos pensar el HUD como anchors:

Top left Score, monedas, información secundaria.

Top right Pausa, settings, botones de sistema.

Bottom zones Controles táctiles y acciones principales.

13. No escales la UI de móvil como si fuera una miniatura

Imagina que un botón mide 44 px en desktop. Si todo el juego se reduce mucho en un teléfono, ese botón puede terminar visualmente en 25 px y convertirse en un mal target táctil.

Por eso muchos juegos separan:

world scale: cámara, escenario, personajes;
UI scale: HUD y botones;
touch layout: zonas específicas para móvil.

Esto significa que responsive no siempre consiste en escalar exactamente todo con el mismo factor.

14. Portrait y landscape

También debes decidir si tu juego:

Solo landscape

Más sencillo de diseñar.
Puedes mostrar un aviso al rotar.
Útil para platformers y juegos de acción.

Adaptativo

Requiere dos composiciones reales.
HUD debe relayout.
La cámara puede necesitar más o menos mundo visible.

No intentes convertir automáticamente un diseño horizontal 16:9 en uno vertical 9:16 si el gameplay no fue pensado para ello.

15. Safe areas en móviles

Si tu juego utiliza toda la pantalla, evita colocar controles esenciales pegados a los bordes. En dispositivos con notch o barras del sistema puedes utilizar las CSS environment variables:

CSS Safe area

#game-ui {
  padding-top:
    env(safe-area-inset-top);

  padding-right:
    env(safe-area-inset-right);

  padding-bottom:
    env(safe-area-inset-bottom);

  padding-left:
    env(safe-area-inset-left);
}

16. Meta viewport

En una página móvil, asegúrate de tener:

HTML <head>

<meta
  name="viewport"
  content="width=device-width,
           initial-scale=1,
           viewport-fit=cover">

Sin una configuración correcta del viewport, el navegador móvil puede simular un ancho de layout distinto y romper todos tus cálculos.

17. Ejemplo Phaser completo con HUD responsive

TypeScript MainScene.ts

import * as Phaser from "phaser";

export class MainScene
  extends Phaser.Scene {

  private scoreText!: Phaser.GameObjects.Text;
  private pauseButton!: Phaser.GameObjects.Text;

  constructor() {
    super("MainScene");
  }

  create() {
    this.cameras.main
      .setBackgroundColor("#071522");

    this.scoreText =
      this.add.text(
        24,
        24,
        "SCORE: 0",
        {
          fontFamily: "Arial",
          fontSize: "24px",
          color: "#ffffff"
        }
      );

    this.pauseButton =
      this.add.text(
        0,
        0,
        "II",
        {
          fontFamily: "Arial",
          fontSize: "28px",
          color: "#ffffff"
        }
      )
      .setOrigin(0.5)
      .setInteractive();

    this.scale.on(
      "resize",
      this.layout,
      this
    );

    this.layout(
      this.scale.gameSize
    );
  }

  private layout(
    gameSize:
      Phaser.Structs.Size
  ) {
    const width =
      gameSize.width;

    const height =
      gameSize.height;

    this.scoreText
      .setPosition(
        24,
        24
      );

    this.pauseButton
      .setPosition(
        width - 40,
        40
      );

    // Aquí puedes reposicionar
    // controles o elementos del mundo.

    console.log(
      `viewport: ${width} x ${height}`
    );
  }
}

18. Checklist responsive antes de publicar

Prueba 16:9 Por ejemplo 1920×1080 y 1280×720.
Prueba ultrawide Verifica que no revele partes del mapa que deberían estar ocultas.
Prueba móvil landscape Comprueba HUD, touch targets y barras del navegador.
Prueba portrait Aunque tu juego no lo soporte, la experiencia debe explicar qué hacer.
Prueba DPR alto Busca blur, GPU demasiado cargada y consumo de batería.
Prueba input Click y touch deben coincidir con lo que el jugador ve.
Prueba resize durante gameplay Gira el dispositivo o cambia el tamaño de la ventana.
Mide rendimiento No asumas que un canvas más grande es gratis.

Qué estrategia recomiendo

Para la mayoría de juegos 2D del blog empezaría con:

Recomendación Gameplay con resolución fija

scale: {
  mode: Phaser.Scale.FIT,
  autoCenter:
    Phaser.Scale.CENTER_BOTH,

  width: 1280,
  height: 720
}

y haría que el HUD tenga reglas específicas para móvil.

Elegiría RESIZE cuando el diseño realmente deba mostrar más o menos contenido dependiendo del viewport, por ejemplo:

estrategia;
editores;
simuladores;
interfaces tipo dashboard;
juegos donde revelar más mundo no rompe el gameplay.

Relacionados

Phaser 4 con Vite y TypeScript desde cero Cómo migrar de Phaser 3 a Phaser 4

Referencias

Phaser Scale Manager MDN ResizeObserver MDN devicePixelRatio MDN Optimizing Canvas

Un canvas responsive de calidad mantiene tres cosas alineadas: lo que el jugador ve, las coordenadas donde vive el juego y el input que recibe. Cuando esas tres capas utilizan la misma estrategia de escalado, el mismo proyecto puede funcionar correctamente desde un teléfono hasta una pantalla de escritorio.

Cómo migrar de Phaser 3 a Phaser 4

noreply@blogger.com (namzug) — Tue, 25 Aug 2026 09:11:43 +0000

Migrar de Phaser 3 a Phaser 4 es bastante menos traumático de lo que parece si tu juego utiliza principalmente Sprites, Images, Text, Tilemaps, input, física, escenas y tweens. La mayor parte de la API pública se mantuvo muy parecida. Los cambios importantes aparecen cuando el proyecto toca el renderer, pipelines WebGL, FX, masks, tint, iluminación o algunas APIs que fueron eliminadas.

Phaser 3 → Phaser 4.2.1 · Migration Guide 2026

Phaser 4 conserva gran parte del flujo de trabajo de Phaser 3, pero cambia profundamente el renderer y los efectos gráficos.

✓

La buena noticia

Si tu juego usa principalmente objetos estándar de Phaser, la migración suele ser mucho más pequeña que una reescritura completa. El trabajo crece sobre todo cuando hay pipelines WebGL, shaders o integraciones avanzadas con el renderer.

¿Vale la pena migrar a Phaser 4?

Phaser 4 no es simplemente una actualización de versión. El renderer WebGL fue reconstruido y la arquitectura interna cambió bastante, pero el equipo de Phaser intentó mantener la API que utiliza la mayoría de desarrolladores lo más familiar posible.

Esto significa que muchos sistemas habituales continúan funcionando con pocos cambios:

Normalmente cambia poco Sprites, Images, Text, Groups, Scene management, input, audio, tweens y física Arcade/Matter.

Requiere revisión FX, masks, tint, iluminación, DynamicTexture, algunas constantes y estructuras auxiliares.

Requiere más trabajo Custom WebGL pipelines, shaders avanzados y código que accede directamente al renderer.

Antes de tocar código

No hagas la migración directamente sobre tu única copia del proyecto. Crea una rama o un backup y asegúrate de que la versión Phaser 3 funciona correctamente antes de empezar.

1. Crea una rama exclusiva para la migración

GitRama de migración

git checkout -b migrate/phaser-4

Antes de continuar, ejecuta el juego en Phaser 3 y revisa al menos:

inicio y carga de assets;
cambio entre escenas;
input;
física y colisiones;
audio;
efectos visuales;
guardado;
game over y reinicio.

2. Haz un inventario de las partes delicadas

Búsquedas útilesVS Code / IDE

setPipeline
PostFX
preFX
postFX
BitmapMask
setTintFill
Phaser.Geom.Point
Phaser.Struct.Set
Phaser.Struct.Map
Math.TAU
DynamicTexture

Si ninguna de esas piezas aparece y el proyecto usa objetos normales, probablemente estás ante una migración relativamente sencilla.

3. Actualiza Phaser

npmActualizar dependencia

npm install phaser@4.2.1

Después inicia el proyecto sin intentar corregir nada por adelantado:

TerminalEjecutar

npm run dev

Los errores que aparezcan ahora se convierten en tu lista real de migración. Es mejor trabajar desde errores concretos que modificar cientos de líneas “por si acaso”.

4. Corrige el import de Phaser si utilizas NPM

Phaser 3

AntesImport habitual

import Phaser from "phaser";

Phaser 4

DespuésWildcard import

import * as Phaser from "phaser";

Si cargas Phaser como variable global mediante CDN, este cambio concreto de import no aplica.

5. El renderer cambió por completo

Phaser 3 utilizaba un sistema basado en WebGL Pipelines. Phaser 4 lo reemplaza por una arquitectura basada en RenderNodes.

Phaser 3

Pipelines WebGL personalizados.
Más responsabilidad sobre el estado WebGL.
Shaders y render custom muy ligados al pipeline.

Phaser 4

Arquitectura mediante RenderNodes.
Responsabilidades de render más separadas.
Modelo más predecible para extensiones gráficas.

Si tu juego solo utiliza Sprite, Image, Text, Tilemap y otros objetos estándar, normalmente no necesitas reescribir nada por este cambio.

Proyecto con custom pipeline

Si escribiste un Pipeline WebGL propio en Phaser 3, trátalo como una subtarea independiente. Esa parte debe migrarse al nuevo sistema de render nodes / filtros, no limitarse a un cambio de nombres.

6. FX y Masks ahora usan el nuevo sistema de Filters

BitmapMask: fue eliminado y su funcionalidad pasa al nuevo Mask Filter.
Bloom: ahora puede crearse mediante Phaser.Actions.AddEffectBloom().
Shine: ahora utiliza Phaser.Actions.AddEffectShine().
Circle: puede migrarse mediante Phaser.Actions.AddMaskShape().
Gradient: pasó a ser un Game Object propio.
preFX / postFX: el modelo anterior fue sustituido por el nuevo sistema de filtros.

La mayor parte del gameplay continúa igual; renderer, pipelines, FX y algunas APIs auxiliares concentran la migración.

7. setTintFill() cambió

Phaser 3

AntesFill tint

player.setTintFill(0xff0000);

Phaser 4

DespuésTint + modo

player
  .setTint(0xff0000)
  .setTintMode(Phaser.TintModes.FILL);

Phaser 4 separa el color del modo y ofrece modos como MULTIPLY, FILL, ADD, SCREEN, OVERLAY y HARD_LIGHT.

8. La iluminación se activa de forma más directa

Phaser 3

AntesLighting pipeline

player.setPipeline("Light2D");

Phaser 4

DespuésLighting component

player.setLighting(true);

Si utilizas normal maps o iluminación personalizada, revisa esa escena completa y no solo una línea.

9. Phaser.Geom.Point desapareció

Phaser 3

AntesPoint

const target = new Phaser.Geom.Point(
  400,
  300
);

Phaser 4

DespuésVector2

const target = new Phaser.Math.Vector2(
  400,
  300
);

10. Math.TAU ahora tiene su valor matemático correcto

En Phaser 3, Math.TAU tenía un valor equivalente a PI / 2. En Phaser 4 representa correctamente una vuelta completa:

Phaser 4Constante

TAU = Math.PI * 2

Si tu código antiguo lo utilizaba esperando PI / 2, cambia a:

Phaser 4Cuarto de vuelta

Phaser.Math.PI_OVER_2

11. Phaser.Struct.Set y Phaser.Struct.Map → JavaScript nativo

Antes

Phaser 3Struct

const enemies = new Phaser.Struct.Set();
const items = new Phaser.Struct.Map();

Después

Phaser 4JavaScript nativo

const enemies = new Set();
const items = new Map();

Si utilizabas métodos específicos de las estructuras de Phaser, revisa sus equivalentes en Set y Map nativos.

12. DynamicTexture requiere render()

Si una textura dinámica aparece vacía después de migrar, revisa si falta ejecutar:

Phaser 4DynamicTexture

dynamicTexture.render();

13. Cámara: lo normal sigue funcionando

Scroll, zoom, rotation y follow suelen continuar sin cambios importantes. Si accedes directamente a matrices internas de cámara, sí debes revisar la implementación.

14. APIs que fueron eliminadas

antiguos Game Objects Mesh y Plane;
plugins Camera3D y Layer3D;
soporte antiguo para IE9;
plugins Spine incluidos antiguamente en Phaser ya no son el camino recomendado.

Mesh2D no es el viejo Mesh

Phaser 4.2 introdujo un nuevo Game Object Mesh2D, pero no debes asumir que sea un reemplazo compatible línea por línea con el Mesh eliminado de Phaser 3.

15. roundPixels cambió de valor por defecto

En Phaser 4 roundPixels es false por defecto. Si tu pixel art dependía de esa opción, haz la intención explícita:

ConfigSi lo necesitas

render: {
  roundPixels: true
}

16. Cuidado con compressed textures

Phaser 4 cambió la orientación interna de texturas para alinearse mejor con WebGL. Si utilizas texturas comprimidas, vuelve a generarlas para la orientación usada por Phaser 4.

17. Checklist de migración

Backup / branchParte de una versión Phaser 3 que sabes que funciona.
Actualiza la dependenciaInstala Phaser 4 y ejecuta antes de cambiar APIs al azar.
Corrige importsSi utilizas NPM, cambia default import por wildcard import.
Revisa renderer avanzadoPipelines y shaders personalizados son la parte de mayor riesgo.
Migra FX, masks y tintSon cambios localizados pero muy visibles.
Revisa APIs pequeñasVector2, TAU, Set, Map y DynamicTexture.
Busca elementos eliminadosHazlo antes de invertir horas en la migración.
Prueba el juego completoNo basta con que compile y muestre la primera Scene.

18. Qué probar después de que compile

Gameplay

Input.
Física.
Colisiones.
Tweens.
Scenes.

Render

FX.
Masks.
Tint.
Luces.
Texturas comprimidas.

Plataforma

Chrome / Chromium.
Firefox.
Móvil real.
Resize.
Pérdida de foco.

Performance

FPS.
Frame time.
Memoria.
Carga inicial.
Errores de consola.

¿Cuánto trabajo puede tomar?

Riesgo bajo Sprites, Text, Tilemaps, Arcade Physics, input, tweens y Scenes estándar.

Riesgo medio FX, masks, tint, DynamicTexture, iluminación y utilidades antiguas.

Riesgo alto Pipelines WebGL, shaders custom, plugins gráficos propios o APIs eliminadas.

La estrategia más práctica es actualizar, ejecutar y dejar que los errores reales te muestren la lista de trabajo.

Si empiezas un proyecto nuevo

Si no estás migrando un juego existente, arranca directamente con Phaser 4 y un entorno moderno.

Phaser 4 con Vite y TypeScript desde cero

Referencias oficiales

Guía oficial de migración Phaser 3 vs Phaser 4 Phaser 4

La clave es no tratar Phaser 4 como un framework completamente diferente. Migra primero lo que realmente rompió, prueba por bloques y deja renderer avanzado, shaders y efectos para una fase controlada.

Phaser 4 con Vite y TypeScript desde cero: guía completa

noreply@blogger.com (namzug) — Mon, 24 Aug 2026 21:18:15 +0000

Phaser 4 ya es una versión estable del framework y, si vas a comenzar un proyecto nuevo en 2026, tiene sentido combinarlo con un entorno moderno de desarrollo. En este tutorial vamos a crear una base con Phaser 4, Vite y TypeScript, entender qué hace cada herramienta y dejar una estructura preparada para crecer sin convertir el proyecto en un único archivo enorme.

Phaser 4.2.1 · Vite · TypeScript

Proyecto moderno con Phaser 4, TypeScript, Vite y recarga rápida durante el desarrollo.

★

Qué vamos a conseguir

Al final tendrás un proyecto Phaser ejecutándose con servidor de desarrollo, TypeScript, recarga rápida con Vite y una separación inicial entre escenas, sistemas, assets e interfaz.

Por qué Phaser 4 + Vite + TypeScript

Phaser sigue siendo una de las opciones más directas para crear juegos 2D que corren en el navegador. Phaser 4 conserva gran parte de la filosofía y de la API pública de Phaser 3, pero su renderer fue reescrito y la rama 4 incorpora sistemas gráficos más modernos.

Para un proyecto nuevo utilizaremos tres piezas:

Phaser 4 Motor 2D: escenas, input, sprites, cámaras, audio, animaciones, física y render.

TypeScript Tipado estático, autocompletado y errores detectados antes de ejecutar el juego.

Vite Servidor de desarrollo, módulos ES, HMR y generación del build de producción.

La idea importante es que Vite no sustituye a Phaser. Vite se ocupa del entorno de desarrollo y del empaquetado; Phaser sigue siendo el runtime del juego.

1. Crear el proyecto con la herramienta oficial

Phaser dispone de una herramienta oficial para crear proyectos. Desde una terminal ejecuta:

Terminal Crear proyecto

npm create @phaserjs/game@latest

El asistente te preguntará qué tipo de proyecto deseas crear. Para esta guía selecciona:

Web Bundler No necesitamos React, Vue ni otro framework para este ejemplo.
Vite Será nuestro servidor de desarrollo y bundler.
TypeScript Utilizaremos archivos .ts desde el inicio.
Nombre del proyecto Por ejemplo: phaser4-starter.

También puedes indicar directamente la carpeta:

Terminal Nombre de carpeta

npm create @phaserjs/game@latest phaser4-starter

2. Ejecutar el servidor de desarrollo

Entra en la carpeta del proyecto y ejecuta el script de desarrollo que incluye la plantilla:

Terminal Development server

cd phaser4-starter
npm install
npm run dev

Vite levantará un servidor local. La dirección suele parecerse a:

Vite Servidor local

Local: http://localhost:5173/

No abras el index.html directamente con doble clic. Utilizar un servidor local evita problemas con módulos, carga de recursos y políticas del navegador.

Ventaja de Vite

Cuando modificas TypeScript, CSS o partes del proyecto, Vite reconstruye rápidamente el módulo afectado. Esto reduce mucho el ciclo editar → guardar → probar.

3. Una estructura de carpetas que pueda crecer

Para un experimento de veinte líneas cualquier estructura funciona. El problema llega cuando aparecen menús, enemigos, audio, guardado, efectos y varias escenas.

Una estructura inicial razonable puede ser:

Proyecto Arquitectura sugerida

phaser4-starter/
│
├─ public/
│
├─ src/
│  ├─ assets/
│  │  ├─ images/
│  │  └─ audio/
│  │
│  ├─ scenes/
│  │  ├─ BootScene.ts
│  │  └─ MainScene.ts
│  │
│  ├─ systems/
│  │  └─ InputSystem.ts
│  │
│  ├─ ui/
│  │  └─ HUD.ts
│  │
│  └─ main.ts
│
├─ index.html
├─ package.json
├─ tsconfig.json
└─ vite.config.ts

Una estructura sencilla separa escenas, assets, sistemas e interfaz sin complicar demasiado el proyecto.

No es una regla obligatoria. La arquitectura debe crecer con el juego. Lo importante es evitar que MainScene.ts termine controlando absolutamente todo.

4. Crear nuestra primera Scene

Vamos a crear una escena completamente procedural. No necesitaremos imágenes externas: Phaser dibujará los elementos con objetos básicos. Esto permite validar que la instalación funciona antes de añadir assets.

Crea:

Archivo src/scenes/MainScene.ts

import Phaser from "phaser";

export class MainScene extends Phaser.Scene {
  constructor() {
    super("MainScene");
  }

  create() {
    this.cameras.main.setBackgroundColor("#071522");

    this.add
      .text(32, 28, "Phaser 4 + TypeScript", {
        fontFamily: "Arial",
        fontSize: "28px",
        color: "#ffffff"
      });

    // Jugador
    this.add.rectangle(
      190,
      300,
      48,
      64,
      0x22d3ee
    );

    // Enemigos
    const enemyPositions = [
      [470, 150],
      [600, 220],
      [520, 360],
      [700, 285]
    ];

    enemyPositions.forEach(([x, y]) => {
      this.add.rectangle(
        x,
        y,
        42,
        42,
        0xff8a1f
      );
    });

    this.add
      .text(32, 420, "El proyecto está funcionando.", {
        fontFamily: "Arial",
        fontSize: "20px",
        color: "#94a3b8"
      });
  }
}

5. Crear la configuración principal

Ahora abre src/main.ts. La configuración indica a Phaser cómo crear el juego y qué escena debe arrancar primero.

TypeScript src/main.ts

import Phaser from "phaser";
import { MainScene } from "./scenes/MainScene";

const config: Phaser.Types.Core.GameConfig = {
  type: Phaser.AUTO,

  width: 960,
  height: 540,

  backgroundColor: "#071522",

  parent: "game-container",

  scene: [
    MainScene
  ]
};

new Phaser.Game(config);

Phaser.AUTO permite que Phaser seleccione el renderer apropiado. El tamaño 960 × 540 es nuestra resolución lógica inicial; más adelante veremos cómo convertirla en un layout responsive.

6. El contenedor HTML

El valor:

Config parent

parent: "game-container"

indica que Phaser insertará su canvas dentro de un elemento HTML con ese identificador.

En index.html asegúrate de tener:

HTML index.html

<div id="game-container"></div>

7. ¿Dónde entran preload, create y update?

El ciclo clásico de una Scene continúa siendo uno de los conceptos fundamentales de Phaser:

preload()

Carga imágenes.
Carga audio.
Carga atlas y JSON.
Se ejecuta antes de crear la escena.

create()

Crea objetos.
Configura input.
Construye el mundo.
Se ejecuta una vez.

update()

Se ejecuta durante el game loop.
Actualiza gameplay.
Lee input continuo.
No debe llenarse de trabajo innecesario.

Systems

Extraen lógica reutilizable.
Reducen escenas gigantes.
Facilitan test y mantenimiento.
No hace falta crearlos demasiado pronto.

8. Añadir assets después de validar el proyecto

Una vez que el canvas aparece y el servidor funciona, entonces sí conviene comenzar a cargar sprites. Por ejemplo:

TypeScript preload()

preload() {
  this.load.image(
    "player",
    "assets/images/player.png"
  );
}

Y dentro de create():

TypeScript create()

create() {
  this.add.image(
    480,
    270,
    "player"
  );
}

Separar primero el problema de instalación del problema de los assets hace que depurar sea mucho más fácil. Si el canvas procedural funciona y una imagen no aparece después, ya sabes que el problema está en la ruta o en la carga del asset, no en Phaser o Vite.

9. Crear el build para producción

Durante el desarrollo utilizamos:

Terminal Desarrollo

npm run dev

Cuando quieras publicar el juego:

Terminal Producción

npm run build

Vite generará la versión optimizada para producción, normalmente dentro de dist/. Esa es la carpeta que después podrás desplegar en un servidor, GitHub Pages, itch.io o un portal compatible con juegos HTML5.

10. Errores comunes al empezar

No copies configuraciones antiguas sin comprobar la versión

Muchos tutoriales de Phaser que todavía aparecen en Google fueron escritos para Phaser 2 o versiones tempranas de Phaser 3. El concepto puede seguir siendo válido, pero imports, renderer, plugins y tooling pueden haber cambiado.

Abrir index.html directamente: usa siempre el servidor de Vite durante desarrollo.
Rutas incorrectas: revisa dónde viven realmente los assets.
Una Scene gigante: extrae sistemas cuando la lógica empiece a crecer.
Instalar muchas librerías desde el inicio: primero consigue un game loop funcionando.
Ignorar TypeScript: evita abusar de any; el tipado es parte de la ventaja.

Qué tenemos hasta ahora

Con muy poco código ya tenemos una base moderna:

Phaser 4 ejecutándose como motor del juego.
TypeScript para escribir código con tipos.
Vite como servidor y sistema de build.
Una Scene independiente.
Una estructura preparada para assets, sistemas y UI.
Un build de producción listo para desplegar.

Siguiente tutorial

El siguiente paso será hacer que este canvas se adapte correctamente a móviles y escritorio sin deformar el juego. Ahí veremos resolución lógica, resize, relación de aspecto y HUD responsive.

Referencias oficiales

Phaser 4 Create Phaser Game

Este tutorial utiliza el flujo actual de Phaser 4 y está pensado como punto de partida para los próximos ejemplos del blog.

Cómo monetizar juegos HTML5 con FGL en 2026: qué cambió desde 2014

noreply@blogger.com (a) — Mon, 02 Feb 2015 15:12:00 +0000

FGL fue una de las plataformas más conocidas para distribuir y licenciar juegos web. Este artículo nació en la época de Flash Game License y ha sido revisado para separar claramente el proceso histórico de 2014 de lo que la plataforma documenta actualmente.

↻

Artículo histórico actualizado en agosto de 2026

Conservamos el contexto original, pero ya no presentamos como vigentes los precios, paneles o pasos comerciales que pertenecían al antiguo FGL.

¿Qué es FGL?

FGL nació como Flash Game License, una plataforma que ayudaba a conectar desarrolladores de juegos Flash con publishers interesados en comprar o licenciar esos juegos.

Con la desaparición de Flash, la marca evolucionó hacia otras tecnologías y continúa vinculada a juegos para navegador.

Visitar FGL Guía del SDK Contacto

Qué cambió desde el artículo original

2014

Game Library y Game Shop.
Licencias y patrocinio como eje principal.
Flujo de publicación mediante paneles separados.
Pruebas manuales de resoluciones y dispositivos.

2026

Portal activo de juegos web.
SDK JavaScript para publicidad.
Integración documentada para HTML5 y motores web.
Los términos comerciales deben verificarse directamente.

Importante

No recomiendo seguir literalmente el antiguo proceso de Game Library → New Game → Game Shop, ni asumir que siguen vigentes mínimos de licencia o condiciones comerciales descritas hace más de una década.

Flujo actual de monetización con el SDK

Prepara el juego webVerifica rendimiento, input, audio, responsive y comportamiento al perder el foco.
Configura la integraciónUtiliza la clave e instrucciones proporcionadas para tu juego.
Inicializa el SDKLa integración documenta un proceso de inicialización antes de solicitar publicidad.
Solicita anunciosColócalos únicamente en pausas naturales o como recompensas voluntarias.
Maneja los fallosEl juego debe seguir funcionando aunque el anuncio falle o sea bloqueado.

Ejemplo mínimo

JavaScriptEstructura básica

async function iniciarFGL() {
  if (typeof FGL === "undefined") {
    return;
  }

  const result = await FGL.init("TU_CLAVE_DE_FGL");

  if (!result.success) {
    return;
  }
}

async function mostrarAnuncio() {
  const status = await FGL.Ads.request("midgame");

  if (status === "success") {
    console.log("Anuncio mostrado");
  }
}

Preparar correctamente un juego web

Diseño responsive y HUD legible.
Mouse, teclado y/o touch según el juego.
Landscape y portrait cuando sean necesarios.
Carga inicial optimizada.
Audio compatible con las restricciones del navegador.
Pausa y reanudación al cambiar de pestaña.
Fallback cuando no existe publicidad disponible.
Pruebas en dispositivos reales.

Archivo histórico

Captura conservada del artículo original. La interfaz ya no debe interpretarse como guía actual.

Ver video histórico del proceso

La interfaz del video corresponde al FGL de aquella época.

Little Strong: juego HTML5 con Phaser

noreply@blogger.com (a) — Mon, 26 Jan 2015 14:56:00 +0000

Little Strong fue uno de los juegos HTML5 que desarrollé con Phaser durante una etapa en la que estaba explorando cómo crear, distribuir y monetizar juegos directamente para el navegador. Este artículo conserva la historia del proyecto, pero reorganizada y actualizada para que siga teniendo sentido hoy.

↻

Artículo original de 2015 · actualizado en 2026

El desarrollo de Little Strong y las experiencias con FGL que cuento aquí pertenecen a aquella etapa. Algunas plataformas, procesos de distribución y herramientas han cambiado desde entonces.

Little Strong, uno de mis proyectos HTML5 desarrollados con Phaser.

Qué era Little Strong

Después de un tiempo alejado del blog, gran parte de mi atención estaba puesta en mejorar dibujo e ilustración digital. Al mismo tiempo ya tenía preparado mi siguiente proyecto: Little Strong, un juego que había mencionado anteriormente pero del que todavía no había explicado el proceso.

A diferencia de Archaic Roll, que publiqué en varios portales para experimentar con tráfico y monetización, con Little Strong seguí un enfoque diferente: preparar el juego para presentarlo a posibles compradores y patrocinadores antes de distribuirlo ampliamente.

En aquel momento una distribución demasiado abierta podía reducir el interés de compradores que buscaban cierta exclusividad. También existía la alternativa de publicar el juego directamente en tiendas y tratar de construir audiencia por cuenta propia. Eran dos estrategias distintas y Little Strong nació dentro de la primera.

Publicar y buscar patrocinio en aquella época

Para Little Strong utilicé FGL. Durante aquellos años la plataforma estaba muy vinculada al mercado de licencias, distribución y patrocinio de juegos web, y mi experiencia con sus pagos había sido positiva.

Uno de los retos del proyecto fue conseguir un comportamiento consistente entre distintos dispositivos. El audio, por ejemplo, podía requerir bastante trabajo adicional en determinados navegadores y tablets como Kindle Fire HD.

Una de las capturas originales del proyecto y de su proceso de publicación.

Contexto actual · 2026

FGL continúa existiendo, aunque hoy su sitio se presenta principalmente como un portal de juegos online y browser games. Por eso esta parte del artículo debe entenderse como documentación histórica de cómo trabajábamos y distribuíamos juegos HTML5 en 2015, no como una guía actual de publicación.

Cómo funcionaba el juego

La mecánica era intencionalmente sencilla. El personaje avanzaba y el jugador debía reaccionar a los obstáculos utilizando click o touch para saltar. Algunos elementos podían utilizarse como apoyo para alcanzar mayor altura, otros podían derribarse golpeándolos y durante el recorrido también era posible recoger monedas.

Phaser permitió construir este tipo de interacción con bastante rapidez. El objetivo no era crear un sistema enorme, sino conseguir un juego fácil de entender, compatible con navegador y suficientemente sólido para probarlo en distintos dispositivos.

Gameplay original de Little Strong.

Herramientas que utilicé

Phaser Framework utilizado para construir la lógica y las mecánicas del juego en el navegador.

Inkscape Herramienta con la que preparé los gráficos vectoriales del proyecto.

ShoeBox Lo utilicé dentro del flujo de trabajo para preparar y organizar recursos de animación.

El intro de audio lo hice yo y la música de fondo procedía de recursos que permitían su utilización. El objetivo era mantener un proceso de producción accesible y resolver internamente la mayor parte de los elementos del juego.

Phaser hoy

El ecosistema ha avanzado enormemente desde este proyecto. Phaser mantiene la rama Phaser 3 y, en 2026, Phaser 4 ya es una línea estable del framework. Si reconstruyera Little Strong hoy, conservaría la idea sencilla del juego, pero actualizaría el proyecto al tooling y APIs modernas de Phaser.

Mirando Little Strong desde 2026

Lo más interesante de recuperar este proyecto no es solamente el juego final, sino observar cómo era desarrollar para HTML5 en aquel momento: compatibilidad móvil más complicada, audio inconsistente entre dispositivos, distribución mediante portales y un ecosistema que todavía estaba definiendo muchas de las prácticas que hoy damos por sentadas.

Little Strong representa justamente esa etapa del desarrollo web: crear algo pequeño, hacerlo funcionar en navegador, probar distintas formas de distribución y aprender del proceso.

Si vuelvo a publicar una versión jugable o recupero los archivos originales del proyecto, actualizaré esta entrada con una demo y más detalles técnicos.

Phaser 2014: minijuego de fuerza y lanzamiento

noreply@blogger.com (a) — Wed, 31 Dec 2014 20:38:00 +0000

Esta entrada cerró el primer año del blog repasando el código del minijuego de lanzamiento que habíamos construido con Phaser. Además de ser un tutorial, es una fotografía bastante clara de cómo escribíamos juegos HTML5 con Phaser 2 en 2014.

↻

Archivo técnico de 2014 · reorganizado en 2026

Conservo las ideas y el código original, pero los presento como documentación de Phaser 2. No deben confundirse con la API actual de Phaser.

Imagen original de la entrada con la que cerramos 2014.

Un año aprendiendo Phaser

Cuando publiqué esta entrada había pasado menos de un año desde el inicio del blog. Habíamos experimentado con física, sprites, input, grupos, partículas y pequeños prototipos. El objetivo de este último artículo era repasar el funcionamiento del minijuego de lanzamiento y explicar sus piezas con más calma.

Phaser 2 · diciembre de 2014

1. Variables e instancia del juego

JavaScriptPhaser 2

var estrellas, balon, stars, flecha;

var game = new Phaser.Game(
  400,
  400,
  Phaser.AUTO,
  "ejemplo",
  {
    preload: preload,
    create: create,
    update: update
  }
);

2. Cargar los recursos

preload()Assets

function preload() {
  game.load.image("star", "S.png");
  game.load.image("ball", "b.png");
  game.load.image("a", "arrow.png");
}

3. Crear física, objetivos e input

La escena inicializaba Arcade Physics, creaba un grupo para las estrellas, añadía la esfera y registraba dos eventos: pulsar y soltar. Las variables presionado, tiempoSostenido y estado controlaban la pequeña máquina de estados del lanzamiento.

create()Fragmento reorganizado

function create() {
  game.stage.setBackgroundColor(0x22aaff);
  game.physics.startSystem(Phaser.Physics.ARCADE);

  stars = game.add.group();
  stars.enableBody = true;
  stars.physicsBodyType = Phaser.Physics.ARCADE;

  balon = game.add.sprite(200, 350, "ball");
  game.physics.arcade.enable(balon);

  balon.body.collideWorldBounds = true;
  balon.body.bounce.setTo(1, 1);

  game.input.onDown.add(presiona, this);
  game.input.onUp.add(suelta, this);

  presionado = false;
  tiempoSostenido = 0;
  estado = null;

  comenzar(0);
}

4. Medir la fuerza de lanzamiento

El prototipo convertía el tiempo que manteníamos presionado el mouse en un valor de fuerza que subía y bajaba dentro de un rango. Era una forma compacta de crear un medidor sin necesitar una interfaz compleja.

InputPresionar, soltar y fuerza

function presiona(pointer) {
  presionado = true;
}

function suelta(pointer) {
  presionado = false;
}

function fuerza() {
  return Math.abs(
    ((game.time.now - tiempoSostenido + 600) % 1000) - 600
  );
}

5. La flecha como hijo de la esfera

La flecha se añadía como child de la esfera para mantener una posición relativa al proyectil. El artículo original ya señalaba un defecto importante: el cuerpo físico de la esfera no coincidía perfectamente con su apariencia, por lo que la rotación visual podía resultar extraña.

JerarquíaPhaser 2 / PIXI

function crearFlecha() {
  flecha = game.add.sprite(0, 0, "a");

  flecha.anchor.setTo(0.5, 0.5);
  flecha.pivot.x = -18;
  flecha.pivot.y = 30;

  balon.addChild(flecha);
}

function removerFlecha() {
  balon.removeChild(flecha);
  flecha.destroy();
}

6. Estados del lanzamiento

El juego alternaba entre dos estados simples: preparar la flecha y dejar que la esfera se moviera. Cuando el proyectil volvía prácticamente a detenerse, se preparaba el siguiente lanzamiento.

EstadoPhaser 2

function comenzar(nuevoEstado) {
  if (estado !== nuevoEstado) {
    if (estado === 1) {
      removerFlecha();
    } else if (estado === 0) {
      balon.body.velocity.setTo(0, 0);
      crearFlecha();
      tiempoSostenido = 0;
    }

    estado = nuevoEstado;
  }
}

7. Update: apuntar, lanzar y recoger estrellas

update()Lógica central

function update() {
  game.physics.arcade.overlap(
    balon,
    stars,
    destruye,
    null,
    this
  );

  if (estado === 0) {
    if (
      Math.abs(balon.body.velocity.x) < 10 &&
      Math.abs(balon.body.velocity.y) < 10
    ) {
      comenzar(1);
    }
  } else if (estado === 1) {
    flecha.rotation =
      game.math.angleBetween(
        balon.body.x,
        balon.body.y,
        game.input.x,
        game.input.y
      ) + Math.PI / 2;

    if (presionado) {
      if (tiempoSostenido === 0) {
        tiempoSostenido = game.time.now;
      } else {
        flecha.scale.y =
          1.0 + fuerza() / 500 * 2;
      }
    } else if (tiempoSostenido !== 0) {
      balon.body.velocity =
        game.physics.arcade.accelerationFromRotation(
          flecha.rotation - Math.PI / 2,
          fuerza() + 50
        );

      comenzar(0);
    }
  }
}

function destruye(a, b) {
  b.kill();
}

Qué sigue siendo útil hoy

Las APIs concretas han cambiado, pero las ideas siguen siendo muy actuales: separar estados, medir input, convertirlo en fuerza, calcular un ángulo, aplicar una velocidad y comprobar colisiones. Esa es justamente la parte que vale la pena conservar de este tutorial.

Phaser hoy

El Phaser que utilizábamos en este código pertenece a otra generación del framework. Phaser continúa activo más de una década después, con Phaser 3.90 disponible y una línea estable de Phaser 4. Si reconstruimos este ejemplo, debería hacerse como un tutorial nuevo en lugar de intentar adaptar línea por línea la API de 2014.

Esta entrada queda como archivo del primer año del blog y como punto de partida para una futura reconstrucción moderna del mismo minijuego.

Minijuego en Phaser: prototipo de lanzamiento y medidor de fuerza

noreply@blogger.com (a) — Thu, 18 Dec 2014 23:02:00 +0000

Este minijuego nació como un prototipo rápido en Phaser: una esfera, una dirección de lanzamiento, un medidor de fuerza y varias estrellas que el jugador debía recoger. El objetivo no era terminar un juego completo, sino validar primero una mecánica.

↻

Artículo original de 2014 · revisado en 2026

El concepto de prototipar sigue siendo válido. La implementación original, sin embargo, pertenece a Phaser 2 y el demo estaba alojado en el antiguo hosting web de Google Drive.

El prototipo original: lanzamiento, indicador de fuerza y objetivos.

La idea del prototipo

La mecánica era sencilla: lanzar un objeto hacia la parte superior de la pantalla para recoger estrellas. Este tipo de interacción aparece en muchos juegos porque combina una acción fácil de entender con variables suficientes para experimentar: dirección, potencia, gravedad, rebote y objetivos.

Antes de construir arte final, niveles o sistemas más grandes, quería comprobar si el lanzamiento era divertido. Esa sigue siendo una buena forma de trabajar: primero validar el gameplay y después invertir en producción.

Qué quería probar

DirecciónUna flecha indicaba hacia dónde sería lanzada la esfera.

FuerzaEl tiempo que el jugador mantenía presionado modificaba la potencia.

ObjetivosLas estrellas servían como primera condición de interacción y recolección.

Por qué prototipar con Phaser

Phaser permitía poner rápidamente algo en movimiento y comprobar la idea directamente en el navegador. Ese valor continúa vigente: Phaser sigue siendo un framework activo para juegos HTML5, aunque las APIs modernas son muy diferentes de las utilizadas en este prototipo.

Phaser 2 · código histórico

En la implementación original todavía había problemas evidentes, como la forma en que la flecha giraba con respecto a la esfera. El objetivo del prototipo era precisamente encontrar esos defectos antes de construir el resto del juego.

El demo original ya no está disponible

Estaba alojado mediante googledrive.com/host/.... Google retiró ese servicio de hosting en 2016. Si recuperamos los archivos originales, el demo debería republicarse en un hosting web actual.

Qué reconstruiría hoy

Escena mínimaCrear esfera, objetivos y una cámara sencilla.
Pointer inputRegistrar cuándo comienza y termina la pulsación.
PotenciaConvertir el tiempo de pulsación en una fuerza limitada.
DirecciónCalcular el ángulo entre el proyectil y el puntero.
LanzamientoAplicar velocidad en lugar de acoplar la solución a APIs antiguas de Phaser 2.

Idea que sigue siendo válida

Un prototipo no tiene que verse perfecto. Tiene que responder una pregunta concreta: ¿esta mecánica funciona y merece que sigamos construyendo sobre ella?

Plugins en Phaser: del antiguo phaser-debug al sistema moderno

noreply@blogger.com (a) — Wed, 10 Dec 2014 16:25:00 +0000

La comunidad siempre ha sido una de las fortalezas de Phaser. En 2014 escribí esta entrada para mostrar phaser-debug, un plugin que añadía paneles de rendimiento y un árbol de escena directamente al juego. Hoy esa implementación pertenece a Phaser 2, pero el concepto de extender el engine mediante plugins sigue existiendo.

↻

Tutorial histórico de Phaser 2 · actualizado para 2026

El código original se conserva como referencia. No debes copiar game.add.plugin(Phaser.Plugin.Debug) en un proyecto moderno de Phaser 3 o Phaser 4.

Imagen original de la entrada sobre plugins de Phaser.

Qué era phaser-debug

phaser-debug fue un módulo creado para Phaser 2 que mostraba información de rendimiento y diagnóstico directamente sobre el juego. Permitía inspeccionar tiempos de actualización y visualizar la jerarquía de objetos sin depender únicamente de las herramientas del navegador.

Phaser 2 · phaser-debug 1.x

Phaser 2Fragmento histórico

// Archivo externo usado entonces
// phaser-debug.js

var game = new Phaser.Game(
  500,
  500,
  Phaser.AUTO,
  "caja",
  {
    preload: preload,
    create: create,
    update: update
  }
);

function create() {
  game.add.plugin(Phaser.Plugin.Debug);
}

No utilizar como código moderno

Ese plugin pertenece al ecosistema de Phaser 2 y su última actividad publicada es de hace muchos años. Mantengo el fragmento porque documenta cómo trabajábamos entonces.

Cómo funcionan los plugins en Phaser moderno

Phaser 3 dispone de un PluginManager y distingue principalmente entre plugins globales y plugins de escena. Un plugin puede cargarse durante el preload, incluirse en la configuración del juego o instalarse desde una escena.

Phaser 3Ejemplo conceptual moderno

class MiPlugin extends Phaser.Plugins.BasePlugin {
  start() {
    console.log("Plugin iniciado");
  }
}

const config = {
  type: Phaser.AUTO,
  width: 800,
  height: 450,

  plugins: {
    global: [
      {
        key: "MiPlugin",
        plugin: MiPlugin,
        start: true
      }
    ]
  },

  scene: Juego
};

new Phaser.Game(config);

Phaser 2 frente a Phaser 3/4

Entrada original

game.add.plugin(...)
Phaser.Plugin.Debug.
PIXI y World descritos según Phaser 2.
Demo alojado en Google Drive.

Phaser moderno

PluginManager.
Global Plugins y Scene Plugins.
Game Config y Scene Config.
Tooling y arquitectura actuales.

¿Y el antiguo panel de Performance?

En aquella entrada me interesaba especialmente poder ver FPS, tiempos de actualización y el árbol de objetos. El objetivo sigue siendo válido: medir el rendimiento dentro del contexto real del juego, identificar qué sistemas consumen tiempo y entender qué existe en la escena.

Lo que ha cambiado es la herramienta concreta. No conviene construir un proyecto actual alrededor de phaser-debug; utiliza las herramientas, APIs y plugins compatibles con la versión de Phaser que realmente esté ejecutando tu proyecto.

Demo histórico retirado

La demostración original se servía mediante Google Drive Web Hosting, un servicio que dejó de funcionar en 2016.

Estado de Phaser en 2026

Phaser continúa activamente mantenido. Phaser 3.90.0 sigue disponible y Phaser 4 ya cuenta con releases estables. Antes de instalar cualquier plugin, comprueba explícitamente para qué rama y versión fue creado.

Cómo colisionar partículas en Phaser

noreply@blogger.com (a) — Thu, 04 Dec 2014 19:43:00 +0000

En esta ocasion veamos como colisionar particulas usando fisica y creando una reaccion despues de dicha colision.

↻

Artículo original de 2014 · revisado en 2026

Esta entrada forma parte del archivo histórico del blog. Se ha limpiado su HTML y conservado el contenido original; cuando utiliza APIs antiguas, se indica el contexto para no confundirlas con las versiones modernas.

Phaser clásico · código histórico

como hacer juegos con html5

Las particulas en Phaser heredan propiedades y metodos de la clase Sprite asi que podemos acceder a metodos del sistema de fisica directamente.

Usando los metodos propios de las particulas lo cual nos hace la tarea mas sencilla.

Comenzemos:

Creamos nuestras variables y una nueva instancia de Phaser.Game:

JavaScriptCódigo histórico

var game =new Phaser.Game(500, 500, Phaser.AUTO, 'caja', {

JavaScriptCódigo histórico

preload: preload, create: create, update: update }),

JavaScriptCódigo histórico

particulaDer, particulaIzq;

Cargamos las imagenes a utilizar en nuestra funcion Preload:

JavaScriptCódigo histórico

function preload() {
    game.load.spritesheet('diamante', 'diamantes.png', 64, 64);
};

En la funcion Create tenemos:

JavaScriptCódigo histórico

function create() {
    particulasIzq = game.add.emitter(50, game.world.centerY - 200);
   particulasIzq.bounce.setTo(0.5, 0.5);
    particulasIzq.setXSpeed(100, 200);
    particulasIzq.setYSpeed(-50, 50);
    particulasIzq.makeParticles('diamante', 0, 200, 10, true);

    particulasDer = game.add.emitter(game.world.width - 50, game.world.centerY - 200);
    particulasDer.bounce.setTo(0.5, 0.5);
    particulasDer.setXSpeed(-100, -200);
    particulasDer.setYSpeed(-50, 50);
    particulasDer.makeParticles('diamante', 1, 200, 10, true);

    // explode, lifespan, frequency, quantity
    particulasIzq.start(false, 5000,10);
    particulasDer.start(false, 5000, 10);
}

En el tutorial como crear particulas vimos algunos de estos metodos necesarios para agregar particulas, aqui agregamos las particulas iniciales con game.add.emitter, queremos que reboten pero no mucho asi que usamos bounce.setTo(0.5,0.5); (al rebote le coloca el 50%).

Para dar velocidad en sus ejes usamos el metodo setXSpeed(x,y),SetYSpeed(x,y) ,y para crear las particulas usamos el metodo makeParticles(key,frame,cantidad,colisiona con el mundo?).

Para terminar damos la orden que comienzen a generarse las particulas con el metodo start(explosion?,vida de las particulas ,cantidad).

En la funcion update generamos la reaccion:

JavaScriptCódigo histórico

function update() {
    game.physics.arcade.collide(particulasIzq, particulasDer, cambio, null, this);
}

Aqui hacemos que las particulas choquen entre ellas y de ser asi llamamos a la funcion cambio donde cambiaremos de color las particulas aunque tambien podriamos modificar velocidad,angulos entre otras propiedades.

La funcion cambio quedaria asi:

JavaScriptCódigo histórico

function cambio(a, b) {
    a.frame = 3;
    b.frame = 3;
}

En esta funcion recibimos como parametros los objetos que colisionan como esta imagen que cargamos es un spritesheet en el cual tenemos varios objetos(imagenes) con diferentes colores en diferentes partes(frames) entonces solo es cuestion de modificar el valor de dicha frame para asi acceder a otro objeto en nuestra imagen.

Asi conseguimos cada vez que colisionen cambien el color pero solo cuando colisionan con otra particula mas no con el cuadro(canvas) que lo rodea ademas cada que colisionan salen disparadas en direcciones contrarias tal como deberia ser una colision.

Resultado:

Demo histórico no disponible

El ejemplo original estaba alojado en Google Drive Web Hosting, un servicio retirado. Conservamos esta referencia para documentar el tutorial: https://5fd29cbe0d84bca10655114522028570a2400bbb.googledrive.com/host/0B9AohO0VxFJLell0VnlMMHhQUGs/particulascolision.html .

Hasta la proxima!!!

Contexto actual

El código de esta entrada pertenece a una versión antigua de Phaser. El concepto de sistema de partículas, colisiones y física, sprites y recursos sigue siendo útil, pero para un proyecto nuevo conviene consultar la API de la versión de Phaser que estés utilizando en lugar de copiar literalmente estas llamadas.

Cómo crear colisiones y rebotes en Phaser

noreply@blogger.com (a) — Mon, 24 Nov 2014 18:43:00 +0000

Despues de una temporada muy enfermo vamos a ver un poco mas el uso de la fisica en Phaser en el tutorial fisica hize una explicacion sobre como funciona el sistema de fisicas de este framework, ahora veamos cosas divertidas y utiles.

↻

Artículo original de 2014 · revisado en 2026

Phaser clásico · código histórico

como hacer colisiones con html5

Lo que vamos a hacer es accelerar una pelota en todas las direcciones y que esta colisione con todos los bordes y con cualquier otro objeto asi de simple.

Comenzemos:

Declaramos las variables e creamos la nueva instancia de Phaser.Game:

JavaScriptCódigo histórico

var juego,balon,muñeco, teclas;

var game = new Phaser.Game(500, 500, Phaser.CANVAS, 'caja',
 { preload: preload, create: create, update: update });

Creamos nuestra funcion create:

JavaScriptCódigo histórico

function create() {
    game.physics.startSystem(Phaser.Physics.ARCADE);
  teclas = game.input.keyboard.createCursorKeys();
    balon = game.add.sprite(400, 200, 'ball');
    muñeco = game.add.sprite(400, 200, 'dude');
    game.physics.enable([balon,muñeco], Phaser.Physics.ARCADE);
    muñeco.body.immovable = true;
    balon.body.velocity.setTo(200, 200);
    balon.body.collideWorldBounds = true;
    balon.body.bounce.setTo(1, 1);
}

Bueno inicializamos el sistema de fisica, creamos nuestras teclas, agregamos los sprites, activamos la fisica a ambos objetos.

No queremos que cuando la bola y el muñeco choquen, el muñeco salga disparado tambien entonces le decimos que no se mueva esto es que immovable sea verdadero, al balon le agregamos velocidad en sus ambos ejes, le permitimos colisionar con el mundo nuestro canvas y con la propidad bounce lo hacemos rebotar cada que colisione.

Esta propiedad no es mas que un punto(x,y) que es multiplicado a la velocidad, facil un ejemplo seria: velocidadBalon.x *= -fuerzarebote; Con colocarle 1 le estamos colocando el maximo valor seria como el 100% de fuerza al rebotar esto quiere decir que 0.5 seria 50%.

En la funcion update tenemos:

JavaScriptCódigo histórico

function update () {
    game.physics.arcade.collide(muñeco, balon);
    if (teclas.up.isDown)
    {
        muñeco.body.velocity.y = -300;
    }
    else if (teclas.down.isDown)
    {
       muñeco.body.velocity.y =  300;
    }
}

Aqui hacemos posible que los dos objetos (muñeco, balon) colisionen y que este muñeco se pueda mover en en su eje Y. Asi de manera simple tenemos algo llamativo, con el cual podemos usar para hacer el clasico pin-pong o otros juegos divertidos.

Demo histórico no disponible

El ejemplo original estaba alojado en Google Drive Web Hosting, un servicio retirado. Conservamos esta referencia para documentar el tutorial: https://12c4452b5cb31a16182543570478b168fcdade85.googledrive.com/host/0B9AohO0VxFJLeEp2R2xrLTVQZVk/rebote.html .

Hasta la proxima !!!.

Contexto actual

El código de esta entrada pertenece a una versión antigua de Phaser. El concepto de colisiones y física, sprites y recursos sigue siendo útil, pero para un proyecto nuevo conviene consultar la API de la versión de Phaser que estés utilizando en lugar de copiar literalmente estas llamadas.