Idea
Una intención, fantasía o efecto deseado. Inspira el diseño, pero todavía no define comportamiento.
Diseño de mecánicas
Cómo diseñar una mecánica que sea divertida antes de programarla
Una idea puede sonar divertida y fallar en cuanto alguien intenta jugarla. En esta guía aprenderás a convertir una intuición en una regla, una hipótesis y un experimento antes de invertir horas o días implementándola.
No vamos a predecir la diversión. Vamos a reducir incertidumbre: definir qué esperamos que ocurra, construir la prueba más barata posible y observar qué sucede realmente.
Design loop
Testable
01
Intención
¿Qué experiencia intentas provocar?
02
Regla
¿Qué puede hacer el jugador y bajo qué condiciones?
03
Hipótesis
¿Qué comportamiento esperas observar?
04
Prueba mínima
Papel, cartas, hoja de cálculo o prototipo digital.
05
Evidencia
Observa, aprende y decide qué cambiar.
Aprende · 01
Una idea no es todavía una mecánica
“Quiero que esquivar sea emocionante” puede ser una buena intención, pero aún no hay nada que probar. Para llegar a una mecánica necesitas convertir esa intención en acciones, reglas, condiciones y consecuencias observables.
Verbo
Lo que el jugador puede hacer: saltar, negociar, colocar, esquivar, combinar, disparar.
Regla
Define cuándo puede ocurrir la acción, qué limita su uso y qué cambia en el estado del juego.
Mecánica comprobable
Un pequeño sistema de reglas que ya puede producir decisiones, consecuencias y feedback observables.
Definición operativa ColosOS
¿Qué llamaremos “mecánica” en esta guía?
No existe una única definición universal utilizada por todos los autores. Para trabajar de forma práctica, aquí usaremos una definición operativa:
Una mecánica es un conjunto de reglas que determina qué puede hacer el jugador, bajo qué condiciones, y cómo esas acciones cambian el estado del juego.
El feedback permite percibir ese cambio; el comportamiento y la experiencia aparecen después, cuando el sistema se juega repetidamente.
Prueba de claridad
Jugador hace
¿Cuál es el verbo o acción disponible?
Si...
¿Qué condición, coste, recurso o restricción debe cumplirse?
Entonces...
¿Qué cambia realmente en el estado del juego?
El jugador percibe
¿Qué feedback comunica que la regla se ha ejecutado?
Ejemplo sintético · no es una receta universal
Convierte “quiero un dash arriesgado” en algo que puedas probar
Pulsa cada etapa. El objetivo no es encontrar valores perfectos, sino observar cómo una intención vaga se transforma en reglas concretas.
Intención
“Quiero un dash que se sienta arriesgado.”
Sabemos qué sensación buscamos, pero aún no sabemos qué puede hacer el jugador, qué pierde, qué gana ni qué cambia en el juego.
Regla ilustrativa
“Al pulsar dash, avanzas rápidamente y consumes una carga.”
Ya existe una acción y un coste. Aun así, debemos definir cuándo puede usarse, cómo se recupera la carga, qué peligros evita y qué consecuencias produce.
Los valores concretos se decidirán después mediante prototipado y prueba.
Versión comprobable
“Tienes dos cargas de dash; cada uso evita daño durante un instante, pero deja una breve recuperación.”
Ahora podemos observar algo: ¿el jugador guarda las cargas?, ¿las gasta demasiado pronto?, ¿la recuperación crea tensión?, ¿el feedback deja claro cuándo vuelve a estar disponible? Ya hay preguntas que un prototipo puede responder.
Ejemplo pedagógico: no implica que dos cargas o una recuperación sean la solución correcta para cualquier juego.
Aprende · 02
¿Puede saberse si una mecánica será divertida?
No con certeza. Antes de jugarla solo tenemos una hipótesis. Lo que sí podemos hacer es reducir incertidumbre antes de programar demasiado: definir qué esperamos observar, construir una prueba mínima y buscar evidencia.
La pregunta equivocada
“¿Es divertida esta idea?”
Una idea no contiene por sí sola el comportamiento real del jugador. Dos implementaciones de la misma idea pueden producir experiencias muy distintas porque cambian sus reglas, costes, restricciones, feedback o ritmo.
Por eso, antes del prototipo, “divertida” es una predicción demasiado amplia. Necesitamos convertirla en preguntas observables.
La pregunta útil
“¿Qué tendría que ocurrir para considerar prometedora esta mecánica?”
Esperamos
un comportamiento concreto del jugador.
Porque
una regla o restricción debería incentivarlo.
Lo probamos con
el prototipo más barato que todavía pueda responder la pregunta.
Observaremos
conductas, errores, decisiones, tiempos, preferencias o comentarios relevantes.
Experimenta · niveles de evidencia
Cuanto más juegas, menos dependes de imaginar
Cambia entre los tres estados. No aumenta una “puntuación de diversión”: aumenta la cantidad de evidencia disponible para decidir qué hacer después.
Hipótesis débil
Todavía estás imaginando la experiencia
Puedes tener una intuición valiosa, pero aún no sabes si las reglas producirán decisiones interesantes, tensión, claridad o repetición útil.
Evidencia disponible
Baja · principalmente predicción.
Aprende · 03
Anatomía de una mecánica
Una mecánica útil para diseñar no se resume en un verbo. Para poder probarla conviene describir qué hace el jugador, cuándo puede hacerlo, qué limita la acción, qué cambia y cómo percibe ese cambio.
Empieza por lo que el jugador hace
El verbo describe una acción disponible: esquivar, colocar, comerciar, disparar, combinar o negociar. Es el punto de entrada, pero por sí solo todavía no explica cómo funciona la mecánica.
Ejemplo dash
Desplazarse rápidamente en una dirección.
Pregunta de diseño
¿Qué puede hacer exactamente el jugador?
Señal de alerta
Si solo puedes nombrar el verbo, todavía falta especificación.
Cadena causal mínima
Una mecánica no termina cuando pulsas el botón
Para diseñarla conviene seguir el cambio que atraviesa el sistema. Esta cadena no es una ley universal, sino una herramienta para localizar huecos en tu especificación.
Acción
El jugador ejecuta un verbo.
Condición
El sistema comprueba si puede ocurrir.
Coste
Se consume o compromete algo.
Estado cambia
Posición, recursos, información, amenaza...
Consecuencia
Aparecen nuevas oportunidades o riesgos.
Feedback
El jugador percibe lo sucedido.
Aprende · 04
Del diseño a la experiencia
El diseñador puede definir reglas, costes, restricciones y feedback. Lo que no puede escribir directamente en una línea de código es “el jugador sentirá tensión”. Entre lo que diseñas y lo que alguien experimenta existe una cadena causal que debes comprobar jugando.
No diseñamos la experiencia directamente
Diseñamos condiciones que pueden favorecer determinados comportamientos. Después observamos si esos comportamientos aparecen y qué experiencia producen.
Por eso una mecánica prometedora no se evalúa solo por lo elegante que suena en un documento, sino por la relación entre regla → conducta → experiencia.
Mecánica
Qué reglas y acciones ofrece el sistema.
Comportamiento
Qué termina haciendo el jugador repetidamente con esas reglas.
Experiencia
Cómo se percibe y se interpreta ese comportamiento al jugar.
Explora la cadena causal
Rastrea una mecánica desde la intención hasta la experiencia observada
Pulsa cada etapa para ver qué pertenece al diseño y qué empieza a depender del comportamiento real del jugador. Usamos de nuevo el ejemplo del dash para mantener una misma línea pedagógica.
01 · Intención
Queremos que el dash cree tensión
Esta es una meta de diseño, no un resultado garantizado. “Tensión” todavía no es una mecánica: necesitamos traducirla a reglas que puedan generar decisiones con coste, riesgo o escasez.
Grado de control directo
Alto
Puedes decidir y documentar esta parte antes de construir.
Lo que sí puedes especificar
Verbos, reglas, costes, límites, recursos, condiciones, probabilidades, estados y feedback. Todo eso puede escribirse, compararse y prototiparse antes de una implementación completa.
Lo que debes validar jugando
Si las personas conservan recursos, arriesgan, exploran, repiten una estrategia, encuentran una solución dominante, se confunden, se aburren o sienten la tensión que esperabas.
Aprende · Caso real
Caso real: LOOP — qué podemos aprender de Loop Hero
Loop Hero es útil aquí porque su origen documentado muestra una idea central sorprendentemente pequeña: un héroe recorre un camino y combate automáticamente, mientras el jugador interviene equipándolo y construyendo el recorrido. El caso permite separar núcleo comprobable de sistemas añadidos después.
El proyecto nació en Ludum Dare 45
Four Quarters explicó en su postmortem que el tema de aquella jam era “Start with Nothing”. El equipo recuperó una idea previa de juego idle: un héroe que camina por un camino y derrota monstruos automáticamente, mientras el jugador se ocupa del equipo y de construir el recorrido.
Núcleo inicial
Héroe recorriendo un bucle, campamento y cuatro jefes como plan inicial descrito por el estudio.
Intervención
El jugador equipa al héroe y coloca elementos en el recorrido en lugar de controlar cada ataque.
Juego publicado
La versión comercial usa cartas para colocar enemigos, edificios y terrenos alrededor de cada expedición en bucle.
La lección no es “haz un juego pequeño”
La lección útil para este artículo es más precisa: identifica qué relación entre reglas necesita existir para que tu idea pueda ser jugada y observada.
En Loop Hero, el núcleo ya permitía comprobar una relación importante: automatización del héroe + decisiones indirectas del jugador + repetición del recorrido. Sobre esa base podían aparecer nuevas preguntas de diseño sin necesitar que todos los sistemas finales existieran desde el primer día.
Explora el caso
De una premisa simple a un sistema más rico
Pulsa cada etapa. Las dos primeras describen el origen documentado; las siguientes muestran cómo el propio estudio relata que el juego siguió creciendo. La columna derecha distingue hechos del caso y lectura pedagógica.
La primera pregunta podía existir con muy poco
El concepto ya permitía comprobar si resultaba interesante observar a un héroe automático mientras las decisiones importantes se desplazaban a preparar y modificar su recorrido. No hacía falta conocer todavía todos los sistemas de la versión comercial.
El jugador modifica el bucle
La versión publicada permite colocar mediante cartas enemigos, edificios y terreno, mientras el héroe continúa recorriendo la expedición.
Preparar el futuro
Lectura ColosOS: las decisiones dejan de centrarse solo en reaccionar al combate inmediato y pasan a modificar qué encontrará el héroe después y en qué condiciones.
Anticipación y gestión
Lectura ColosOS: el interés puede emerger de intervenir indirectamente, observar las consecuencias y reajustar el sistema vuelta tras vuelta. Es una interpretación de diseño, no una experiencia universal garantizada.
Practica · 01
Autopsia A/B: el mismo verbo puede producir juegos distintos
“Hacer dash” no define una experiencia. Cambia las reglas que rodean al mismo verbo y cambiarán las decisiones que aparecen. Aquí comparamos dos versiones sintéticas para aprender a detectar qué variable está provocando qué comportamiento.
Comparador interactivo
Misma acción, distinta estructura
Alterna entre A y B. No buscamos declarar una versión “mejor” en abstracto, sino observar cuál encaja mejor con un objetivo concreto: crear gestión de riesgo y tensión.
El dash funciona casi como movilidad básica
El jugador puede usarlo con mucha frecuencia y con pocas consecuencias futuras. Eso puede ser perfecto si buscas fluidez y velocidad, pero ofrece menos presión para decidir cuándo reservarlo.
La clave no es “poner cooldown porque sí”, sino entender qué comportamiento necesitas generar.
Decisión
Baja: normalmente conviene usarlo cuando ayuda.
Coste futuro
Pequeño o casi inexistente.
Conducta esperada
Uso frecuente y reactivo.
Riesgo de diseño
Que se convierta en respuesta automática.
Disponibilidad
Si una acción está casi siempre disponible, puede favorecer ritmo y expresividad, pero reduce la necesidad de reservarla.
Coste de oportunidad
Gastar ahora significa renunciar a una opción futura. Ese “después” es una fuente potente de decisión.
Recuperación
La forma de recuperar una acción modifica el ritmo: tiempo, habilidad, riesgo, recursos o acciones concretas.
Consecuencia
El valor de una regla aparece cuando cambia lo que podrás hacer después, no solo lo que ocurre ahora.
Dos cargas y recuperación
Hemos cambiado una regla concreta y medible.
Guardar, gastar o arriesgar
Esperamos que aparezca gestión de disponibilidad y lectura del peligro.
Tensión y alivio
La hipótesis es que la escasez haga más significativos algunos momentos de uso.
Practica · 02
Diseña una hipótesis, no una feature
“Añadir dos cargas de dash” describe una solución. Una hipótesis de diseño explica qué comportamiento esperas provocar, por qué debería ocurrir y qué evidencia aceptarías para decidir si funciona o no.
Describe lo que vas a construir
Puede ser útil para producción, pero no te obliga a explicar por qué esa solución debería mejorar el juego ni cómo sabrás si ha funcionado.
Ejemplo
“Añadir dos cargas de dash con 4 segundos de recuperación.”
Describe una relación que puedas poner a prueba
Conecta una regla con un comportamiento esperado y deja claro qué observarás. También admite que tu predicción puede resultar equivocada.
Ejemplo
“Si limitamos el dash a dos cargas, esperamos que los jugadores reserven al menos una
para peligros futuros; lo comprobaremos observando cuándo gastan cada carga.”
Una fórmula útil para escribir hipótesis de diseño
No es una ley ni una plantilla obligatoria. Es una estructura para evitar frases vagas y convertir una intuición en algo que pueda fallar, medirse y mejorarse.
01
Si cambiamos...
Una regla, coste, restricción, frecuencia o condición.
02
Esperamos que...
Aparezca una conducta concreta del jugador.
03
Porque...
Existe una razón causal que conecta regla y conducta.
04
Observaremos...
Conductas, decisiones, errores, tiempos o elecciones relevantes.
05
La revisaremos si...
La evidencia contradice nuestra predicción o revela otro comportamiento.
Experimenta · Hypothesis Builder
Convierte tu idea en una hipótesis comprobable
Completa los campos. El sistema no puntúa si tu mecánica será divertida: solo te ayuda a detectar si tu hipótesis es concreta, observable y falsable.
¿Qué variable del sistema vas a modificar?
Describe una conducta, no una emoción abstracta.
¿Por qué crees que la regla podría provocar esa conducta?
Evita “parece más divertido”; busca algo que puedas registrar u observar.
Una buena hipótesis debe poder resultar equivocada.
Tu frase de prueba
Completa los campos y pulsa “Generar hipótesis”.
Practica · 03
Papel, cartas, hoja de cálculo o prototipo digital
“Prototipar antes de programar” no significa que todo deba hacerse en papel. La pregunta correcta es: ¿cuál es la representación más barata que todavía puede responder la duda de diseño que tengo ahora?
No prototipes el juego. Prototipa la pregunta.
Si quieres saber si un coste genera decisiones, quizá basten fichas o cartas. Si quieres estudiar una economía, una hoja de cálculo puede ser más útil. Si la duda depende de timing, física, cámara o respuesta inmediata, probablemente necesitarás un prototipo digital.
Regla práctica
Elige el medio más barato que conserve la variable que necesitas observar.
Confundir fidelidad con calidad de evidencia
Un prototipo bonito puede responder peor a tu pregunta que cuatro cartas escritas a mano. La fidelidad visual, técnica o narrativa solo importa si afecta directamente a lo que estás probando.
Construir más no siempre produce mejor evidencia; a veces solo hace más caro cambiar de dirección.
Papel y fichas
Excelente para reglas discretas, turnos, recursos, prioridades, posiciones abstractas y decisiones.
Pregunta típica ¿Este coste obliga a elegir?Cartas
Útiles cuando importan combinaciones, información, probabilidades, orden, mano o construcción de opciones.
Pregunta típica ¿Qué opciones aparecen con esta distribución?Hoja de cálculo
Muy útil para economías, progresión, daño, probabilidades, curvas, recursos y sensibilidad de valores.
Pregunta típica ¿Qué pasa si cambio este valor 20 veces?Prototipo digital
Necesario cuando la experiencia depende de tiempo real, input, física, animación, cámara, espacio o game feel.
Pregunta típica ¿Cómo se siente realmente esta acción?
Experimenta · Selector de prototipo
Empieza por la pregunta, no por la herramienta
Elige qué quieres descubrir. La recomendación es orientativa: su función es ayudarte a pensar qué información se perdería al simplificar demasiado.
Papel, fichas o una tabla muy simple
Si quieres observar si un coste obliga a elegir, no necesitas simular movimiento real. Representa recursos, opciones y consecuencias de forma discreta y compara qué decide la persona.
Practica · 04
Cuándo el papel miente
Un prototipo de baja fidelidad es útil mientras conserve la variable que intentas estudiar. Se vuelve peligroso cuando elimina precisamente aquello que determina la experiencia: timing, física, precisión espacial, cámara, respuesta sensorial o coordinación en tiempo real.
Cuando la estructura importa más que la ejecución
Si tu duda está en reglas discretas, costes, recursos, información o secuencias de decisiones, puedes abstraer mucho sin destruir la pregunta.
¿Qué opción consume un recurso escaso?
¿Una ruta domina siempre a las demás?
¿Qué información necesita el jugador antes de elegir?
¿Cuántos turnos tarda una economía en agotarse?
Cuando la variable crítica desaparece al abstraer
Puedes representar un dash con una tarjeta que diga “avanza tres espacios”, pero esa tarjeta no reproduce aceleración, input, ventanas de invulnerabilidad, lectura de cámara ni sensación de control.
¿Se siente preciso este salto?
¿La cámara permite leer el peligro?
¿La física genera control o caos?
¿El feedback hace clara una acción de 150 ms?
Experimenta · Test de fidelidad
¿Puede esta pregunta sobrevivir al papel?
Selecciona una pregunta. El objetivo no es decidir si el papel es “bueno” o “malo”, sino comprobar si conserva la variable que necesitas observar.
Papel suficiente para una primera prueba
La decisión puede abstraerse
Puedes representar opciones, recursos y consecuencias con fichas, cartas o una tabla. Lo importante es conservar qué se sacrifica al elegir una opción.
Hablas de milisegundos
Cuando diferencias pequeñas de tiempo cambian el resultado, necesitas un medio que reproduzca tiempo real.
Importa “cómo se siente”
Game feel, respuesta del control y feedback sensorial no pueden inferirse de forma fiable desde una abstracción estática.
La geometría decide
Distancias, colisiones, líneas de visión, cámara o trayectorias pueden requerir espacio y movimiento reales.
El prototipo cambia la pregunta
Si para simplificar eliminas la variable que querías estudiar, ya no tienes un prototipo barato: tienes otro experimento.
Practica · Laboratorio
Mechanic Lab
Convierte una idea en una mecánica que puedas discutir, comparar y poner a prueba. El laboratorio no decide si tu mecánica es divertida: organiza la información, detecta huecos y devuelve preguntas de diseño que necesitan evidencia.
1 · Especifica la mecánica
No busques escribir bonito. Busca que otra persona pueda entender qué hace el jugador, qué limita la acción y qué cambia después.
La acción que ejecuta la persona.
Qué intenta conseguir al usarla.
Qué ocurre cuando se ejecuta la acción.
Qué recurso, tiempo u oportunidad se sacrifica.
Qué puede salir mal al usarla.
Qué beneficio obtiene el jugador.
Qué impide usarla sin pensar.
Cómo percibe el jugador el resultado.
Con qué ritmo puede aparecer o repetirse.
Qué cambia en las decisiones futuras después de usarla.
¿Existen al menos dos opciones razonables?
Si solo hay una respuesta claramente correcta, quizá no exista una decisión real.
¿Elegir una opción implica renunciar a algo?
Busca coste de oportunidad, tiempo, riesgo, recursos o posición.
¿La persona puede anticipar parte de las consecuencias?
Sin información suficiente puede haber azar, pero no necesariamente decisión informada.
¿La regla puede producir resultados distintos según el contexto?
Esto puede favorecer variedad y evitar que la acción tenga siempre el mismo valor.
¿El jugador conserva agencia sobre cuándo o cómo usarla?
La mecánica puede ser automática, pero debes saber dónde reside la decisión humana.
3 · Compara dos versiones
Guarda el estado actual en A o B. No compara “qué versión es mejor”: permite ver qué cambió antes de prototipar.
Versión A
Vacía
Guarda aquí una primera versión de la mecánica.
Versión B
Vacía
Modifica una variable y guarda una segunda versión.
Practica · Diagnóstico
Qué podría salir mal
Una mecánica puede funcionar técnicamente y aun así generar un comportamiento que destruya la experiencia buscada. Antes de implementarla por completo conviene buscar de forma deliberada soluciones dominantes, decisiones falsas, bucles explotables, confusión y ausencia de consecuencias.
Solución dominante
Una opción ofrece demasiado valor para su coste y termina desplazando al resto. El jugador deja de comparar y empieza a repetir.
Decisión falsa
Parece que existen varias opciones, pero una es claramente correcta en casi todos los contextos.
Feedback insuficiente
La regla cambia el sistema, pero el jugador no entiende qué ocurrió ni por qué.
Coste irrelevante
Existe un coste sobre el papel, pero es tan pequeño o tan fácil de recuperar que no modifica decisiones.
Loop explotable
Una secuencia produce beneficios crecientes o evita la presión del sistema de una forma no prevista.
La mecánica contradice la experiencia
Las reglas incentivan exactamente el comportamiento opuesto al que querías provocar.
Experimenta · Failure Scanner
Busca problemas antes de buscar confirmación
Responde según tu diseño actual. El scanner no demuestra que exista un problema, pero convierte señales débiles en preguntas explícitas para el siguiente prototipo.
¿Una opción ofrece claramente más valor que las demás?
Piensa en coste, riesgo, frecuencia y recompensa.
¿El coste cambia realmente la decisión?
No basta con que exista: debe afectar al comportamiento.
¿El jugador entiende qué ha cambiado después de usarla?
Considera UI, animación, sonido, estado y consecuencia.
¿Puede repetirse una secuencia para obtener beneficio sin asumir el riesgo previsto?
Busca farming, loops infinitos, acumulación o bypass del coste.
¿La regla incentiva el comportamiento que realmente quieres?
Compara intención de diseño con conducta esperada.
Qué merece una prueba específica
Sin análisis todavía
Responde las preguntas y pulsa “Analizar riesgos”.
Practica · Anti-patrones
Anti-patrones: formas rápidas de diseñar mal una mecánica
Un anti-patrón no es simplemente “una mala mecánica”. Es una forma de trabajar que parece razonable, se repite con frecuencia y conduce a decisiones pobres. Detectarlos pronto evita semanas de implementación alrededor de una pregunta mal planteada.
Feature first
“Quiero doble salto, crafting y parry” antes de explicar qué problema resuelve cada sistema.
Corrección: empieza por la conducta que quieres provocar.Cooldown por reflejo
Añadir tiempo de espera porque “hay que limitarlo”, sin saber qué decisión debería generar.
Corrección: define qué sacrificio crea el cooldown.Más sistemas = más profundidad
Añadir capas, recursos y excepciones esperando que la complejidad produzca decisiones interesantes.
Corrección: busca relaciones, no acumulación.Copiar sin contexto
Importar una mecánica de otro juego porque allí funciona, ignorando economía, ritmo, objetivos y audiencia.
Corrección: identifica qué función cumple en su sistema original.Cambiar cinco variables a la vez
Modificar coste, daño, velocidad, cooldown y feedback juntos y después no saber qué causó el cambio.
Corrección: prueba hipótesis aislables siempre que sea posible.Enamorarse de la solución
Defender una implementación porque costó mucho construirla, aunque la evidencia no apoye la hipótesis.
Corrección: protege el problema, no la feature.
Experimenta · Detector de anti-patrones
¿Qué está mal en esta decisión de diseño?
Selecciona un escenario. La respuesta no juzga la idea en abstracto: señala qué información falta antes de convertirla en producción.
Feature first
No sabemos qué comportamiento debería producir la stamina ni qué problema del juego intenta resolver. La existencia de sistemas similares en otros juegos no demuestra que sea necesaria aquí.
Describe qué comportamiento actual quieres cambiar.
Explica qué regla podría modificar ese comportamiento y por qué.
Cambia lo mínimo necesario para observar la relación causal.
Mantén, cambia o elimina según lo que ocurre al jugar.
Practica · Reto de diseño
Mechanic Design Challenge
Ya has analizado reglas, hipótesis, prototipos, fallos y anti-patrones. Ahora toca diseñar una mecánica bajo restricciones y dejar una evidencia concreta. El objetivo no es “tener una idea original”, sino demostrar que puedes convertir una intención en una prueba.
Paso 1 · Elige un brief
Diseña dentro de una restricción
Cada reto cambia el problema, pero mantiene la misma disciplina: define una regla, predice un comportamiento y decide cómo comprobarlo antes de programar un sistema completo.
Movimiento · Escape con compromiso
Diseña una acción de movilidad que permita escapar de un peligro inmediato, pero cuyo uso reduzca las opciones disponibles durante los siguientes segundos.
Debe existir al menos un coste o restricción.
El jugador debe poder reservar la acción para más tarde.
La consecuencia debe afectar a una decisión futura.
2 · Resuelve el reto
No necesitas una GDD completa. Escribe únicamente lo necesario para que otra persona pueda entender la mecánica y saber qué debería observar durante una prueba.
Describe acción + regla, no solo el nombre de la feature.
Debe modificar la decisión, no existir solo como decoración numérica.
Busca una conducta observable.
Elige el medio más barato que conserve la variable crítica.
Evita “parece divertido”; describe qué registrarás.
Una prueba útil debe poder llevarte a decir “esto no funciona como esperaba”.
Demuestra · Artefacto
Mechanic Design Specification
Convierte tu prueba en un documento que puedas guardar, enseñar y reutilizar. Esta especificación reúne regla, intención, comportamiento esperado, prototipo y evidencia en una sola pieza preparada para GDD, portfolio, playtesting o una implementación posterior.
1 · Documento fuente
Resume solo lo que necesitas para que otra persona comprenda la mecánica, la reproduzca y sepa qué debería observar durante una prueba.
Nombre corto y reconocible.
Permite comparar iteraciones posteriores.
Qué hace la persona que juega.
Experiencia o conducta que quieres favorecer.
Debe permitir reconstruir el comportamiento básico del sistema.
La presión que hace que usarla tenga consecuencias.
Beneficio inmediato o futuro.
Visual, sonoro, UI, espacial, háptico, etc.
Qué altera las opciones siguientes.
Describe comportamiento observable, no una valoración vaga.
El medio más barato que conserve la variable crítica.
Una pregunta concreta, no “¿es divertido?”.
Decisiones, usos, tiempos, errores, rutas, elecciones...
La condición que evita proteger la feature por apego.
3 · Guarda tu evidencia
Copia el texto o descárgalo como .txt. El archivo representa una versión de trabajo: cuando cambie la mecánica, aumenta la versión y conserva la anterior para documentar la iteración.
Demuestra · Evidencia
Demuestra lo aprendido
Una especificación demuestra que sabes estructurar una idea. La evidencia completa aparece cuando puedes enseñar qué esperabas, qué ocurrió y qué cambiaste después. Ese rastro convierte el ejercicio en una pieza útil para aprendizaje, GDD, playtesting o portfolio.
Lo que predijiste
Conserva la hipótesis, la regla y la pregunta de prueba. Esto muestra que no estás explicando el resultado a posteriori: habías definido qué esperabas observar.
Lo que realmente ocurrió
Registra decisiones, errores, usos, tiempos, estrategias inesperadas o comentarios relevantes. La evidencia puede confirmar, matizar o contradecir tu predicción.
Lo que decidiste cambiar
Mantener, modificar o eliminar una regla también es diseño. Explica qué evidencia produjo esa decisión y qué probarías en la siguiente versión.
1 · Completa el rastro de aprendizaje
Importa lo planificado desde la MDS y añade lo que ocurrió realmente durante la prueba.
La mecánica que estás documentando.
Debe existir antes de interpretar los resultados.
Describe solo lo necesario para entender la evidencia.
Separa observación de interpretación siempre que puedas.
La evidencia inesperada suele ser especialmente valiosa.
No hay una respuesta “correcta”; debe estar respaldada por evidencia.
Conecta explícitamente resultado y decisión.
Una buena evidencia genera una siguiente pregunta.
Cierre · Fuentes y ruta
Fuentes, lecturas recomendadas y siguiente paso
Este artículo combina marcos académicos, teoría de diseño, formación profesional y un caso real. Las fuentes siguientes permiten rastrear los conceptos principales y continuar estudiando más allá de ColosOS.
Fuentes y lecturas recomendadas
Filtra por función. No todas las fuentes sostienen la misma afirmación: unas aportan marco teórico, otras proceso de prototipado y otras documentan casos reales.
MDA: A Formal Approach to Game Design and Game Research
Robin Hunicke, Marc LeBlanc y Robert Zubek. Marco para relacionar mecánicas, dinámicas y experiencia estética; sirve como antecedente directo de la cadena regla → comportamiento → experiencia utilizada en ColosOS.
Abrir fuente ↗Rules of Play: Game Design Fundamentals
Katie Salen Tekinbaş y Eric Zimmerman. Referencia amplia sobre reglas, sistemas, interactividad y meaningful play. Especialmente relevante para pensar la relación entre acciones, resultados y significado dentro del sistema.
Abrir MIT Press ↗Unity Learn · Prototyping
Recurso oficial de Unity centrado en utilizar prototipos para explorar una idea, probar aproximaciones y determinar qué elementos son realmente necesarios antes de desarrollar el proyecto completo.
Abrir Unity Learn ↗Play Early, Play Often: Prototyping Sid Meier's Civilization IV
Sesión de Soren Johnson y Dorian Newcomb sobre prototipado durante el desarrollo de Civilization IV, con aprendizajes sobre iteración rápida, diseño jugable y decisiones que resultaron callejones sin salida.
Abrir GDC Vault ↗Postmortem: Loop Hero
Four Quarters documenta el origen del juego, su paso por Ludum Dare 45, la premisa inicial y decisiones de desarrollo posteriores. Es la fuente principal utilizada para separar hechos documentados de la lectura de diseño de ColosOS.
Abrir postmortem ↗Unity Learn · Design and Publish Your Original Game
Curso de Unity y USC Games que organiza el proceso alrededor de diseño, prototipado, milestones, desarrollo ágil y playtesting. Es una lectura útil para continuar desde una mecánica aislada hacia un proceso de producción.
Abrir curso ↗Ahora puedes distinguir idea, regla y mecánica
También puedes relacionar una regla con comportamiento esperado, consecuencias, feedback y experiencia sin afirmar que la diversión pueda predecirse de antemano.
Ahora puedes convertir una intuición en experimento
Sabes formular una hipótesis, elegir la fidelidad mínima adecuada, buscar fallos deliberadamente y comparar iteraciones antes de ampliar producción.
Ahora puedes enseñar tu proceso
Mechanic Design Specification + Evidence Pack dejan un rastro visible: qué propusiste, qué probaste, qué observaste y por qué decidiste iterar.