Se puede. Y no como curiosidad: hay juegos de JavaScript en itch.io con miles de partidas y estudios que viven de ello. Corre en cualquier navegador, en el celular, sin instalar nada, y lo compartes con un link.
Esta es la ruta completa. Sin rodeos.
Lo que necesitas
Poco:
- JavaScript básico — variables, funciones, arrays,
import. No necesitas clases avanzadas, ni async profundo, ni TypeScript. - Node y npm, para el servidor de desarrollo y el build.
- Un editor. VS Code.
No necesitas saber matemáticas de videojuegos, ni C++, ni haber usado un motor.
El juego más simple posible, sin librerías
Antes de meter nada, entiende qué hay debajo. Esto es un juego funcional en JavaScript puro:
<canvas id="c" width="480" height="270"></canvas>
<script>
const ctx = document.getElementById('c').getContext('2d')
const jugador = { x: 40, y: 120, vx: 200 }
let anterior = performance.now()
function frame(ahora) {
const dt = (ahora - anterior) / 1000 // segundos desde el frame anterior
anterior = ahora
// actualizar
jugador.x += jugador.vx * dt
if (jugador.x > 448 || jugador.x < 0) jugador.vx *= -1
// dibujar
ctx.clearRect(0, 0, 480, 270)
ctx.fillStyle = '#e63946'
ctx.fillRect(jugador.x, jugador.y, 32, 32)
requestAnimationFrame(frame)
}
requestAnimationFrame(frame)
</script>
Ahí está todo lo esencial de cualquier juego: requestAnimationFrame te da un bucle, calculas cuánto tiempo pasó (dt), actualizas el estado, y dibujas. Eso es un motor de videojuegos en veinte líneas.
Fíjate en el dt. Sin él, moverías el cuadro "5 píxeles por frame" y correría al doble de velocidad en un monitor de 144 Hz. Con él, la unidad es el segundo. Es el primer concepto real del oficio y está explicado a fondo en qué es el game loop.
Dónde se acaba el canvas puro
Ese ejemplo escala fatal. En cuanto quieras un juego de verdad necesitas:
- Cargar y cachear imágenes y sonidos sin que parpadeen al empezar
- Animar sprites por frames
- Detectar colisiones y separar los cuerpos, no solo detectarlas
- Escenas (menú, juego, game over) y transiciones entre ellas
- Input de teclado, mouse, touch y gamepad, con estados de "recién pulsado"
- Cámara que sigue al jugador
- Niveles hechos en un editor, no a mano en un array
Todo eso es de tres a seis meses de trabajo tuyo si lo escribes desde cero. Y no aprendes a hacer juegos escribiéndolo: aprendes a escribir un motor, que es otro oficio.
Por eso se usa una librería.
Qué librería
Corto y sin diplomacia:
- Phaser — framework completo de 2D. Escenas, física, input, audio, tilemaps, animación, cámaras. Es lo que quieres para tu primer juego.
- Pixi.js — solo renderiza, muy rápido. No trae física, ni escenas, ni input. Excelente si sabes qué haces; malo para empezar.
- Babylon.js — motor 3D. Otra liga, otro problema.
Lo desarrollo con más detalle en Phaser, Pixi o Babylon: cuál elegir. El resumen es: si es tu primer juego y es 2D, es Phaser, y la decisión no debería costarte más de un minuto.
Arrancar un proyecto de verdad
npm create vite@latest mi-juego -- --template vanilla
cd mi-juego
npm install phaser
npm run dev
Y el mismo cuadro rojo, ahora en Phaser:
import Phaser from 'phaser'
class Juego extends Phaser.Scene {
create() {
this.jugador = this.add.rectangle(40, 120, 32, 32, 0xe63946)
this.teclas = this.input.keyboard.createCursorKeys()
}
update(time, delta) {
const dt = delta / 1000
if (this.teclas.left.isDown) this.jugador.x -= 200 * dt
if (this.teclas.right.isDown) this.jugador.x += 200 * dt
}
}
new Phaser.Game({
type: Phaser.AUTO,
width: 480,
height: 270,
scene: Juego,
scale: { mode: Phaser.Scale.FIT, autoCenter: Phaser.Scale.CENTER_BOTH }
})
Mismo bucle, misma lógica de delta time. Lo único que cambió es que ya no tienes que escribir el loop, ni el input, ni el escalado. Ese es el trato completo: la librería no te ahorra entender, te ahorra teclear.
El camino, en orden
Este es el orden en el que lo enseño, y es el orden en que las cosas dejan de romperse:
- Game loop y delta time → artículo
- Sprites, spritesheets y animación → artículo
- Input — teclado, mouse, touch
- Colisiones y física → artículo
- Niveles con Tiled → artículo
- Estado, UI y guardado
- Game feel — lo que separa "funciona" de "da gusto" → artículo
- Build y publicación → artículo
Si haces esos ocho pasos con un solo juego pequeño, tienes un juego publicado. Si los haces con ocho proyectos distintos, tienes ocho carpetas abandonadas. Esa diferencia es casi todo.
Los tres errores que cuestan meses
Empezar por el juego que quieres hacer. Tu MMO, tu roguelike con 40 sistemas. Hazlo el tercero. El primero es un juego de una pantalla, un enemigo y una condición de victoria.
Escribir tu propio motor. Es tentador y se siente productivo. No estás haciendo un juego, estás haciendo herramientas para un juego que no existe.
No publicar. Un juego con bugs en itch.io te enseña más que uno perfecto en tu disco, porque la gente te dice cosas que tú ya no puedes ver.
Y luego qué
Cuando tengas el primero publicado, ya no eres alguien que quiere hacer juegos. Los conceptos —loop, delta time, colisiones, estados, feel— se transfieren enteros a Unity, a Godot o a lo que venga. Lo que cuesta meses son los conceptos; cambiar de herramienta cuesta días.
Esto es exactamente el temario de mi curso presencial de Phaser 3 en Tijuana: ocho sesiones, un juego publicado al final. Las grabaciones y el código quedan disponibles para los asistentes.