Cómo hacer un videojuego desde cero: idea, prototipo y pruebas

Para hacer un videojuego necesitas cuatro cosas en este orden: una frase que describa lo que el jugador hace una y otra vez (el bucle central), un prototipo feo pero jugable que pruebe esa frase, pruebas con personas reales y muchas versiones pequeñas que corrigen lo que las pruebas revelan. El arte, la música y la historia llegan después y multiplican lo que ya funciona. Aquí te contamos ese proceso con el caso real de ERCMart Survival, el juego del supermercado que se comió al mundo.
Qué necesitas para hacer un videojuego
Un videojuego es un sistema de reglas que reacciona a lo que haces. Todo lo demás (modelos 3D, música, interfaz, textos) existe para que esas reglas se entiendan y se sientan bien. Por eso el error más común al empezar es abrir un motor y pasar semanas en un personaje o un escenario sin haber probado si el juego en sí divierte.
Una forma útil de ordenar la cabeza es el marco MDA (mecánicas, dinámicas y estética) que Hunicke, LeBlanc y Zubek presentaron en 2004: tú como creador construyes las mecánicas (las reglas), de ellas surgen dinámicas cuando alguien juega, y el jugador vive una estética, es decir, lo que siente. Tú diseñas desde el primer eslabón; el jugador entra por el último. Eso explica por qué hay que probar tan pronto: la única forma de saber qué se siente es ver jugar a alguien.
Si quieres profundizar en esa primera capa, tenemos una guía completa de mecánicas de juego.
Cómo hacer un videojuego desde cero en 6 pasos
- Escribe el bucle central en una sola frase.
- Construye el prototipo más feo que puedas jugar.
- Elige herramientas según dónde se va a jugar.
- Prueba con otras personas y cambia una cosa a la vez.
- Publica versiones pequeñas y reversibles.
- Agrega arte, música e historia sobre lo que ya funciona.
Cada paso tiene su sección abajo, y en "En ERCMart lo hicimos así" verás cómo se vieron en un juego real.
Paso 1: escribe el bucle central en una sola frase
Antes de tocar código, escribe qué hace el jugador cada pocos segundos y por qué vuelve a hacerlo. Una buena frase tiene un verbo, una tensión y una recompensa.
La de ERCMart Survival, en su versión actual, es más o menos así: te mueves por un supermercado invadido, disparas a la plaga gastando la misma energía que te protege, y cada baja te da investigación que sube de nivel a tu unidad mientras la plaga también se refuerza.
Fíjate en lo que esa frase ya define:
- Verbo: moverse y disparar.
- Tensión: la energía es una sola para atacar y para defenderte.
- Recompensa: subir de nivel.
- Contrapeso: cada vez que subes, los enemigos también mejoran.
Si no puedes escribir tu frase, todavía no tienes un juego, tienes un tema. "Un juego de zombis en un súper" es un tema. Está bien empezar por ahí, pero hay que llegar a la frase antes de producir.
Paso 2: construye el prototipo más feo que puedas jugar
Si vas a hacer un juego desde cero, el prototipo existe para responder una pregunta, no para enseñarse. Usa cubos, cilindros y colores planos. Lo único que tiene que estar bien es la sensación de control: que moverse responda y que disparar se entienda.
Tres reglas que nos funcionan:
- Un solo nivel, una sola arma, un solo enemigo. Agregar variedad antes de que el núcleo funcione solo multiplica el ruido.
- Números en un solo lugar. Que el costo de disparar, la vida de un enemigo o la velocidad estén en un archivo de reglas, no regados por el código. Así puedes ajustar sin miedo.
- Reglas separadas del dibujo. Si la lógica de "cuánto daño absorbe la energía" vive en una función pura, la puedes probar sin abrir el juego.
En ERCMart esa separación es literal: la energía vive en un módulo de 15 líneas que no sabe nada de gráficos, y los niveles se arman con primitivas geométricas agrupadas en mallas instanciadas para que el navegador las dibuje con pocas llamadas. Incluso la Fer de la recepción navideña, en una versión del 2 de noviembre de 2026, estaba hecha con geometría simple y rótulos, sin imágenes ni descargas extra.
Paso 3: elige herramientas según dónde se va a jugar
La pregunta no es "cuál es el mejor motor", sino "dónde va a jugar la gente y quién lo va a construir". Un juego para consola y un juego que se abre con un enlace desde el celular piden herramientas distintas.
| Si tu prioridad es… | Piensa en… |
|---|---|
| Que se juegue desde un enlace, sin instalar | Un juego web (por ejemplo, con Three.js) |
| Gráficos de alto nivel en PC o consola | Un motor completo como Unreal |
| Un equipo pequeño que quiere un editor visual | Godot o Unity |
| Modelar, animar y renderizar assets | Blender (desde la versión 2.80, de 2019, ya no incluye motor de juego) |
Para cada decisión de esta tabla tenemos una guía:
- El motor. En qué motor gráfico elegir comparamos Three.js, Godot, Unity y Unreal por plataforma, equipo, licencia y peso.
- La herramienta de arte frente al motor. Blender y Unreal no compiten: uno crea los modelos y el otro corre el juego. Lo explicamos en Blender vs Unreal.
- Los modelos 3D. Si no modelas, puedes partir de una imagen y limpiar el resultado; así lo hicimos con el rostro de Fer en convertir una imagen en modelo 3D con IA.
- Los asistentes de IA. Si quieres que un asistente opere herramientas como Blender, el estándar que los conecta es MCP (Model Context Protocol).
Nosotros elegimos web porque queríamos que cualquiera entrara desde un enlace, sin instalar nada. Las razones están en por qué hacer un juego web y el cómo, en cómo hacer un juego para navegador.
Paso 4: prueba con otras personas y cambia una cosa a la vez
Probar no es preguntar "¿te gustó?". Es mirar en silencio y anotar dónde se traban, qué ignoran y qué repiten. Después cambias una cosa y vuelves a probar.
Algunas señales que conviene buscar:
- El jugador no usa una mecánica. O no la entiende o no le conviene. Las dos se arreglan distinto: con información o con números.
- Todo se vuelve fácil a partir de cierto punto. Casi siempre es un problema de economía: entra más recompensa de la que sale. Lo explicamos a fondo en economía de un videojuego.
- Muere sin saber por qué. Falta aviso: los ataques fuertes necesitan anticipación visible.
También ayuda escribir pruebas automáticas para las reglas que no deben romperse. No reemplazan a las personas, pero te dejan cambiar números sin miedo a romper lo que ya funcionaba.
Paso 5: publica versiones pequeñas y reversibles
Cada versión debe poder jugarse, compararse con la anterior y deshacerse. En la web esto es especialmente fácil si publicas cada versión en su propia carpeta que nunca se sobrescribe y solo cambias la página de entrada para que apunte a la nueva. Si algo sale mal, regresas la entrada a la carpeta anterior.
Esta disciplina parece burocracia al principio, pero es lo que te permite iterar varias veces al día sin miedo. Y es lo que te deja contar la historia de tu juego con evidencia: qué cambió, cuándo y por qué.
Paso 6: agrega arte, música e historia sobre lo que ya funciona
Cuando el bucle se sostiene con figuras simples, el arte deja de ser una apuesta y se vuelve un multiplicador. Agrégalo en capas: primero lo que ayuda a entender el juego (siluetas legibles, colores que distinguen amigo de enemigo, avisos de ataque) y después lo que da identidad (personajes, música, temporadas). Prueba cada capa igual que una regla: si algo confunde o estorba, se quita sin romper el juego.
En ERCMart lo hicimos así
ERCMart Survival es un juego de supervivencia por oleadas que corre en el navegador. La historia que tenemos registrada en el repositorio y en las notas de diseño cubre del 31 de octubre al 3 de noviembre de 2026, y en esos días el juego cambió de forma importante varias veces. No porque el plan fuera malo, sino porque cada vez que lo jugábamos notábamos algo.
Datos de ERCMart
Medidos en el código del juego al 3 de noviembre de 2026:
- Historial registrado: del 31 de octubre al 3 de noviembre de 2026.
- Energía: reserva de 100 puntos que se recarga 10 por segundo, con una pausa de un segundo después de cada golpe.
- Costo por ataque: 11 de energía la escopeta de Fer y 9 el proyectil cinético.
- Costo de la investigación: 150 × 1.6^(nivel − 1).
El núcleo que se quedó
Desde el principio hubo una regla que define el juego: una sola reserva de energía sirve para atacar y para absorber daño, sin ventanas de invulnerabilidad. Si te golpean, la energía absorbe el daño antes que tu vida, y cada disparo sale de esa misma reserva. Esa sola regla obliga a decidir a cada segundo: disparar o guardar escudo.
Lo que cambió en dos días de rebalance
| Momento | Qué cambiamos | Por qué |
|---|---|---|
| 2 nov, versión con mejoras en vivo | Las mejoras se compran desde una barra sin pausar; costo inicial 5 y sube de 5 en 5 | Subir de nivel era demasiado fácil |
| 2 nov, progresión navideña | Costo 60 × 1.45^(nivel − 1); se retira la mejora de oro (la oferta "money") que quedaba de la economía anterior | Seguía siendo fácil frente a equipos avanzados |
| 2 nov, rebalance de especiales | Costo 150 × 1.6^(nivel − 1); enemigos especiales con más vida, avisos y ataques propios | Los especiales necesitaban presencia, no solo más vida |
| 3 nov, rediseño | La subida de nivel es automática y elige una mejora al azar; el taller se paga con piezas que sueltan los enemigos al morir | Que la partida avance sola y el taller tenga su propia moneda |
| 3 nov, endurecimiento | Cada subida de nivel también refuerza a la plaga al azar; las piezas pasan a caer solo por probabilidad, sin botín garantizado | El juego debe endurecerse solo, no depender de que el jugador se equivoque |
Ninguna de esas decisiones salió de una hoja de cálculo hecha antes de jugar. Salieron de jugar, notar que algo se sentía mal y cambiar el número o la regla responsable.
Arte y contenido, después
El arte llegó en capas sobre un juego que ya funcionaba: tarjetas de mejora ilustradas, criaturas por temporada (Halloween, Navidad, el colapso del súper), música adaptativa que cambia según tu vida y una protagonista, Fer, que pasó de anfitriona en la recepción a personaje jugable con su escopeta. Cada capa se probó sobre reglas que ya existían, así que cuando algo no encajaba, se podía quitar sin romper el juego.
Errores comunes al hacer tu primer videojuego
- Empezar por el arte. Es lo más caro de rehacer y lo que más esconde si el juego funciona.
- Diseñar diez sistemas a la vez. Cada sistema nuevo multiplica las combinaciones que tienes que probar.
- No guardar versiones. Sin versiones no sabes qué cambio mejoró o empeoró las cosas.
- Balancear "a ojo" sin anotar. Escribe el número viejo, el nuevo y por qué. Dentro de una semana no te vas a acordar.
- Esperar a que esté "listo" para enseñarlo. El primer jugador externo siempre encuentra algo que tú ya no ves.
Siguiente paso
Si quieres ver en la práctica cómo se siente compartir energía entre disparo y escudo, entra a jugar ERCMart Survival y presta atención a cuándo dejas de disparar para protegerte. Luego sigue con mecánicas de juego para diseñar las tuyas, o con cómo hacer un juego para navegador si ya quieres montarlo.
La serie completa
Esta guía es el punto de partida del laboratorio. Cada paso tiene su artículo:
- Mecánicas de juego: qué son, cómo diseñarlas y probarlas
- Economía de un videojuego: fuentes, sumideros y curvas
- Qué motor gráfico elegir: Three.js, Godot, Unity o Unreal
- Blender vs Unreal Engine: qué hace cada uno y cuándo usarlos
- Qué es MCP (Model Context Protocol) y cómo usarlo con Blender
- Cómo hacer un juego para navegador con Three.js, paso a paso
- Por qué hacer un juego web: el enlace le gana a la descarga
- Imagen a modelo 3D con IA: de un retrato a un GLB para la web
Y si alguien te pregunta qué hace un supermercado ficticio enseñando a hacer videojuegos: el colapso del mundo también empezó con un prototipo.
Preguntas frecuentes
¿Cuánto tiempo toma hacer un videojuego?
No hay una cifra general honesta; depende del alcance. Te damos la nuestra: el primer commit de ERCMart Survival es del 31 de octubre de 2026 y para el 3 de noviembre ya era jugable en el navegador y había pasado por varios rebalances y un rediseño, programando con asistencia de IA. Eso es un prototipo que sigue cambiando, no un juego terminado.
¿Necesito saber programar para hacer un videojuego?
No necesariamente para empezar: hay motores con programación visual, como los Blueprints de Unreal, donde armas la lógica con nodos. Pero igual vas a pensar como programador: reglas, condiciones y números. Lo importante es poder cambiar un valor, volver a probar y entender por qué cambió la sensación. Para validar la idea, un prototipo en papel también sirve.
¿Qué hago primero: el arte, la historia o la mecánica?
Primero la mecánica central, probada con figuras simples. El arte y la historia cuestan mucho de rehacer y esconden si el juego funciona. Cuando el bucle de jugar, ganar algo y mejorar ya se siente bien con cubos, el arte multiplica lo que ya existe. Al revés, solo decora un problema.
¿Qué es un prototipo jugable?
Es la versión más pequeña del juego que alguien puede jugar de principio a fin para responder una pregunta concreta, por ejemplo si disparar y protegerse con la misma energía genera decisiones interesantes. No necesita menús, guardado ni arte final. Su trabajo es fallar rápido y barato para que la siguiente versión sea mejor.


