Un videojuego rara vez funciona sobre una sola tecnología
Cuando un personaje atraviesa una habitación, varios sistemas trabajan al mismo tiempo. El motor debe mostrar el escenario, determinar si el personaje toca el suelo, reproducir su animación de marcha, situar sus pasos en el espacio sonoro, comprobar las colisiones con los objetos, ejecutar la lógica del gameplay y actualizar a los personajes controlados por inteligencia artificial. Todo debe mantenerse suficientemente sincronizado para que el jugador perciba una única experiencia continua.
Ese es precisamente el papel de un motor de videojuegos, o game engine. Proporciona una infraestructura común para problemas que prácticamente todos los juegos terminan encontrando, de modo que cada equipo no tenga que reconstruir desde cero un sistema de renderizado, un motor físico, un gestor de audio, una arquitectura de animación o herramientas de edición.
Un motor de videojuegos es menos una máquina que “fabrica un juego” que un conjunto de sistemas y herramientas que permite a un equipo fabricarlo.
Esta distinción es importante. Unreal Engine, Unity, Godot, Frostbite o RE ENGINE pueden proporcionar una cantidad considerable de tecnología, pero ninguno de ellos decide las reglas del juego, la calidad de un nivel, el ritmo de un combate o la identidad visual de un proyecto. El motor permite ejecutar esas decisiones.
Lo que realmente gestiona un motor
La palabra motor puede dar la impresión de que designa principalmente la parte gráfica. Históricamente, el renderizado ha ocupado efectivamente un lugar central, pero un motor moderno reúne muchas más responsabilidades.
Las documentaciones actuales de Unreal Engine, Unity y Godot incluyen sistemas de renderizado, física, animación, audio, scripting, interfaces, navegación y herramientas. Unreal, por ejemplo, organiza su documentación alrededor de la construcción de mundos, el renderizado, los efectos visuales, el gameplay, Blueprints, la animación, el audio, las interfaces y el pipeline de producción. (dev.epicgames.com)
| Sistema | Función principal | Ejemplo concreto |
|---|---|---|
| Renderizado | transformar la escena en una imagen | mostrar un personaje, materiales, sombras y efectos |
| Física | simular colisiones y movimientos | hacer caer una caja, gestionar un vehículo o detectar un contacto |
| Audio | reproducir y espacializar sonidos | situar unos pasos detrás del jugador o mezclar un ambiente |
| Animación | controlar los movimientos | pasar de caminar a correr y después a atacar |
| Scripting / gameplay | definir comportamientos | abrir una puerta, activar una misión, gestionar un arma |
| IA y navegación | organizar determinados comportamientos autónomos | permitir que un enemigo encuentre un camino o reaccione |
| UI | construir interfaces | HUD, inventario, menús, diálogos |
| Herramientas de edición | crear y modificar contenido | colocar objetos, ajustar una luz, construir un nivel |
| Pipeline de recursos | importar y preparar archivos | transformar modelos, texturas y sonidos en datos utilizables |
| Build y plataformas | producir el programa final | generar una versión para PC, móvil o consola |
La lista varía según los motores. Algunos integran directamente numerosas funciones, mientras que otros dependen en mayor medida de extensiones, bibliotecas o herramientas externas. La frontera entre «motor», «editor» y «ecosistema» se ha vuelto, por tanto, mucho menos clara que en el pasado.
Una arquitectura construida por capas
Godot permite observar con bastante claridad esta lógica en su propia arquitectura. Su documentación distingue especialmente una capa de escenas utilizada para estructurar el juego, servidores encargados de subsistemas como renderizado, audio o física, y una capa inferior que se comunica con las API gráficas, los sistemas de audio y las plataformas. (docs.godotengine.org)
Podemos simplificar el conjunto de esta manera:
Proyecto y escenas
↓
Gameplay / scripts / componentes
↓
Renderizado · Física · Animación · Audio · Navegación
↓
GPU · CPU · sistema de audio · sistema operativo
↓
PC · consola · móvil · web…
Evidentemente, el jugador nunca ve esta arquitectura. Ve a un personaje saltando sobre una plataforma. Para el motor, sin embargo, ese salto implica varias capas que deben intercambiar información en el momento adecuado.
Antes de los motores generalistas, cada juego fabricaba más tecnología propia
Los primeros juegos no se desarrollaban dentro de un gran editor universal con un botón para añadir una luz, una cámara o un cuerpo físico. El código estaba mucho más directamente vinculado al juego y al hardware objetivo. Un equipo construía las funciones que necesitaba su proyecto, reutilizando a veces fragmentos de tecnología procedentes de un título anterior.
Esta reutilización acabó adquiriendo valor de manera natural. Si varios juegos comparten las mismas necesidades de renderizado, colisiones, animación o gestión de recursos, resulta útil separar estos sistemas del contenido específico de cada título.
Un motor aparece realmente cuando una parte suficientemente importante de esa tecnología se vuelve reutilizable. El programa deja de ser únicamente el juego: existe entonces una capa técnica capaz de albergar juegos diferentes.
Esta lógica sigue siendo visible en los estudios actuales. Un motor interno puede comenzar alrededor de las necesidades de un título o una franquicia y convertirse después en una base compartida entre varios equipos. EA explica, por ejemplo, que la primera generación de Frostbite se desarrolló en relación con Battlefield: Bad Company antes de convertirse en una tecnología común para numerosos estudios del grupo. (ea.com)
Un motor 2D y un motor 3D no resuelven exactamente los mismos problemas
Hablar de un motor «2D» o «3D» no significa simplemente distinguir un motor pequeño de uno grande. Ambos tipos de proyectos manipulan representaciones y limitaciones diferentes.
En 2D, el motor debe gestionar especialmente sprites, tiles, capas, cámaras ortográficas, colisiones 2D, scrolling, animaciones de sprites y, en ocasiones, sistemas de iluminación diseñados específicamente para un plano. Godot posee, por ejemplo, un renderer y un motor físico 2D dedicados, además de herramientas para TileMaps, partículas y animación 2D. (docs.godotengine.org)
En 3D hay que añadir profundidad, cámaras en perspectiva, meshes, materiales, luces, esqueletos, sistemas de visibilidad y una física que trabaja en tres dimensiones. Las necesidades de rendimiento y gestión de recursos suelen aumentar con la complejidad de las escenas.
Los motores generalistas modernos pueden abarcar ambos ámbitos. Unity se presenta explícitamente como una plataforma de desarrollo para experiencias 2D y 3D, mientras que Godot también reúne ambos enfoques dentro de una misma interfaz. (unity.com)
2D y 3D no forman, por tanto, una progresión en la que una sustituya a la otra. Corresponden a maneras diferentes de representar y organizar un espacio de juego.
El motor de renderizado transforma los datos en imagen
La parte gráfica sigue siendo uno de los subsistemas más visibles del motor. Recibe una descripción de la escena —geometría, texturas, materiales, luces, cámara, efectos— y debe producir la imagen final dentro del breve tiempo disponible antes del siguiente frame.
Como vimos en la evolución de los gráficos, este renderizado puede combinar hoy varios métodos: rasterización, cálculos de sombras, iluminación precalculada o dinámica, posprocesado, reconstrucción temporal y eventualmente ray tracing. Un mismo motor también puede ofrecer distintas rutas de renderizado para adaptarse a máquinas muy diferentes.
Godot 4 ilustra esta lógica con varios renderers destinados a usos diferentes, mientras que Unreal Engine reúne en sus sistemas gráficos iluminación, sombras, materiales, texturas, efectos visuales y posprocesado. (docs.godotengine.org)
Sin embargo, el motor de renderizado no define por sí solo el aspecto del juego. Proporciona un conjunto de posibilidades y restricciones que utiliza la dirección artística. Dos juegos construidos con el mismo motor pueden, por tanto, no compartir prácticamente nada visualmente.
La física no siempre intenta reproducir perfectamente la realidad
Un motor físico responde a problemas como las colisiones, la gravedad, las fuerzas, las articulaciones o los cuerpos rígidos. Permite, por ejemplo, determinar si un personaje entra en contacto con una pared, si una caja cae o qué ocurre cuando dos vehículos chocan.
Eso no significa que un juego intente reproducir sistemáticamente la mecánica real. Un coche arcade puede utilizar comportamientos deliberadamente simplificados, un personaje puede modificar su trayectoria durante un salto y una explosión puede proyectar objetos de manera exagerada porque el resultado resulta más legible o divertido.
Unity expone, por ejemplo, un módulo físico dedicado a propiedades globales, colisiones y cuerpos simulados, mientras que Godot ofrece sistemas físicos distintos para entornos 2D y 3D. (docs.unity3d.com)
El motor proporciona, por tanto, reglas de simulación. El game design decide hasta qué punto deben parecerse al mundo real.
Animación y audio: dos sistemas profundamente ligados al gameplay
La animación no consiste simplemente en reproducir un archivo producido en Blender o Maya. En un juego, debe reaccionar constantemente al estado del personaje: velocidad, dirección, contacto con el suelo, arma utilizada, acción en curso o evento activado.
Unreal Engine utiliza especialmente los Animation Blueprints para construir visualmente comportamientos complejos, mezclar animaciones y determinar la pose final de un personaje en cada frame. (dev.epicgames.com)
El audio responde a una lógica similar. Un sonido debe activarse a menudo mediante el gameplay, situarse en el espacio, atenuarse según la distancia y mezclarse con los demás elementos sonoros. Unity permite, por ejemplo, que una fuente de audio funcione como un sonido 2D o como un sonido completamente espacializado en 3D según su configuración. (docs.unity3d.com)
Estos sistemas muestran por qué un motor funciona como un conjunto integrado. Una animación puede activar un sonido de pasos; el material del suelo puede determinar qué sonido debe reproducirse; la posición del personaje influye en su espacialización. El interés del motor procede precisamente de la capacidad de estos componentes para comunicarse.
El scripting transforma los sistemas del motor en reglas de juego
Un motor puede saber mostrar un personaje y calcular su colisión sin saber qué se supone que debe hacer ese personaje.
La lógica del juego procede del código o del scripting desarrollado para el proyecto. Decide que un cofre contiene un objeto, que una puerta requiere una llave, que un enemigo cambia de estado cuando el jugador entra en una zona o que un nivel termina cuando se cumplen determinadas condiciones.
Los motores ofrecen distintas maneras de escribir esta lógica. Unity se apoya principalmente en C# y el ecosistema .NET. Godot ofrece especialmente GDScript y C#, mientras que Unreal combina programación en C++ con su sistema de scripting visual Blueprints. (unity.com)
Blueprints ilustra bien la evolución de los motores hacia herramientas destinadas a distintos oficios. Epic lo describe como un sistema de scripting visual basado en nodos, capaz de crear lógica de gameplay sin escribir directamente código textual. Los programadores pueden construir las bases técnicas en C++ y después exponer determinadas funciones a los designers, que las ensamblan visualmente. (dev.epicgames.com)
El objetivo no es eliminar la programación, sino hacer que determinadas partes del sistema sean más accesibles y rápidas de modificar.
La inteligencia artificial también es un conjunto de servicios
Cuando un enemigo rodea un obstáculo o busca al jugador, hablamos fácilmente de «la IA del motor». En realidad, esta expresión agrupa varios problemas diferentes.
Puede ser necesario representar el espacio navegable, calcular un camino, seleccionar un comportamiento, detectar estímulos u organizar distintos estados. El motor puede proporcionar parte de estos componentes, pero las reglas que dan una personalidad concreta a un enemigo siguen siendo propias del juego.
Un guardia de infiltración, un piloto de carreras y un grupo de unidades de un juego de estrategia no tienen las mismas necesidades. El motor puede proporcionarles herramientas comunes de navegación o decisión, pero su comportamiento final depende del trabajo de programadores y game designers.
Este matiz será especialmente importante en nuestro próximo artículo dedicado a la inteligencia artificial en los videojuegos: disponer de un sistema de navegación o de un árbol de comportamiento no basta para crear un adversario interesante.
El editor cuenta casi tanto como el motor que ejecuta el juego
Una parte esencial de los motores modernos no funciona en la máquina del jugador. Existe únicamente para las personas que fabrican el juego.
El editor permite colocar objetos en una escena, modificar sus propiedades, desplazar luces, construir niveles, crear animaciones, editar scripts o probar directamente el proyecto. Godot reúne, por ejemplo, dentro de su entorno un editor de código, un editor de animación, herramientas de TileMap, un editor de shaders, un debugger y un profiler. (docs.godotengine.org)
Unreal lleva también muy lejos esta lógica con herramientas dedicadas al world building, la animación, los efectos visuales, el sonido, las interfaces y la automatización del pipeline. Sus Blueprints pueden incluso utilizarse para construir herramientas internas que actúan directamente sobre los recursos y el editor. (unrealengine.com)
Esta parte es menos espectacular que una demostración gráfica, pero su influencia sobre la producción puede ser enorme. Si colocar cien objetos requiere cinco veces menos tiempo gracias a una buena herramienta, ese ahorro se repite en cada nivel y para cada persona que realiza la tarea.
El motor posee, por tanto, dos caras
| Para los creadores | Para el jugador |
|---|---|
| editor de niveles | mundo final |
| herramientas de animación | personajes animados |
| profiler | rendimiento |
| sistema de importación | assets listos para utilizar |
| visual scripting | comportamientos del juego |
| herramientas de build | programa instalado |
| debugging | experiencia normalmente libre de bugs |
Gran parte de la calidad de un motor se mide así por aquello que el jugador nunca verá directamente.
Unreal Engine: un motor convertido en entorno de producción
Unreal Engine representa actualmente uno de los ejemplos más completos de un motor generalista transformado en entorno de producción. Epic reúne dentro del mismo ecosistema herramientas de renderizado, creación de mundos, efectos visuales, animación, gameplay, audio, interfaces, programación y gestión del pipeline. (unrealengine.com)
Su posicionamiento sigue fuertemente vinculado a producciones 3D ambiciosas, aunque su ámbito de uso supera ampliamente el videojuego. El sistema de scripting visual Blueprints permite además repartir una parte de la lógica entre programadores y perfiles más orientados al diseño.
El interés de Unreal no reside, por tanto, únicamente en la calidad de su renderer. Se encuentra en la integración de una gran cantidad de sistemas dentro de un entorno común donde un nivel puede construirse, iluminarse, animarse, programarse y probarse.
Esto aporta enormes posibilidades, pero también una complejidad importante. Un motor rico exige tiempo para comprender su arquitectura y aprender a no utilizar cada función simplemente porque existe.
Unity: una lógica generalista y multiplataforma
Unity procede de otra historia y sigue otra filosofía de uso, pero persigue el mismo objetivo general: proporcionar una base reutilizable que permita producir experiencias interactivas para numerosas plataformas.
Unity presenta actualmente su motor como un entorno capaz de crear experiencias 2D y 3D en estilos muy diferentes y sobre una gran variedad de máquinas. Integra especialmente herramientas de renderizado, animación, audio, scripting en C#, física y análisis de rendimiento. (unity.com)
Esta versatilidad explica una parte importante de su difusión. El mismo entorno puede utilizarse para un pequeño juego 2D, un proyecto móvil, una producción 3D o una aplicación interactiva que ni siquiera sea un juego.
Su arquitectura también se apoya mucho en un sistema de componentes. Un objeto de la escena recibe distintas funciones según los componentes asociados: renderer, collider, fuente de audio, script u otro comportamiento. Este enfoque favorece la composición en lugar de una organización en la que cada objeto tendría que programarse como un caso totalmente particular.
Unity muestra así que un motor generalista no corresponde necesariamente a un tipo de juego concreto. Su valor procede sobre todo de la capacidad de proporcionar una base suficientemente flexible para albergar proyectos muy diferentes.
Godot: un motor abierto donde conviven 2D y 3D
Godot propone un tercer enfoque interesante porque es libre y open source, desarrollado bajo licencia MIT y sostenido por una comunidad y por la Godot Foundation. Su documentación lo presenta como un motor multiplataforma destinado a crear juegos 2D y 3D desde una interfaz unificada. (docs.godotengine.org)
El motor se basa fuertemente en las nociones de nodes y scenes. Un personaje, una cámara, un elemento de interfaz o un sistema de audio pueden organizarse en nodos y después reunirse dentro de escenas reutilizables. Esta estructura permite componer progresivamente objetos complejos a partir de elementos más pequeños.
Godot posee además una particularidad importante: su soporte de la 2D no se limita a colocar sprites en un entorno pensado principalmente para la 3D. Dispone de sistemas de renderizado y física específicamente diseñados para proyectos 2D. (docs.godotengine.org)
Su carácter open source también modifica la relación con la herramienta. Un equipo puede consultar el código del motor, modificarlo o desarrollar extensiones integradas más profundamente en su arquitectura. Esta libertad representa una ventaja para determinados proyectos, pero evidentemente no elimina el coste humano necesario para mantener modificaciones importantes.
Unreal, Unity y Godot responden al mismo problema con filosofías diferentes
Comparar motores preguntando únicamente cuál es «el mejor» rara vez lleva demasiado lejos. La verdadera pregunta útil se refiere al proyecto, al equipo y a sus limitaciones.
| Unreal Engine | Unity | Godot | |
|---|---|---|---|
| Posicionamiento general | entorno 3D muy completo y fuertemente integrado | motor generalista multiplataforma | motor generalista libre y open source |
| 2D / 3D | asociado principalmente a la 3D, con herramientas 2D disponibles | 2D y 3D | sistemas dedicados para 2D y 3D |
| Scripting habitual | C++ + Blueprints | C# | GDScript + C#, extensiones nativas posibles |
| Editor | conjunto muy amplio de herramientas integradas | editor extensible basado en componentes y paquetes | interfaz unificada alrededor de escenas y nodos |
| Acceso al código del motor | código fuente disponible según su marco de uso | motor propietario con posibilidades de extensión | código abierto bajo licencia MIT |
| Tipos de proyectos | producciones diversas, fuerte presencia en 3D de alta gama | enorme variedad de proyectos y plataformas | proyectos 2D/3D, independientes y equipos que buscan un motor abierto |
Esta tabla no constituye una clasificación. Los tres entornos evolucionan regularmente, sus funcionalidades se solapan y pueden realizarse proyectos muy diferentes con cualquiera de ellos.
El motor más apropiado es aquel que corresponde mejor al pipeline real del equipo, no el que posee la página de funcionalidades más larga.
¿Por qué algunos estudios siguen creando sus propios motores?
Con herramientas públicas tan completas, mantener un motor interno puede parecer innecesariamente costoso. Sin embargo, algunos grandes estudios siguen eligiendo esta vía porque un motor puede diseñarse alrededor de sus métodos de trabajo, sus franquicias y sus restricciones técnicas.
EA presenta Frostbite como una plataforma tecnológica compartida entre varios de sus estudios. Sus workflows cubren especialmente audio, animación, cinemáticas, scripting, física, destrucción, renderizado y efectos visuales. (ea.com)
Capcom sigue una lógica similar con RE ENGINE. En su informe integrado de 2025, la empresa describe un motor interno multiplataforma utilizado para sus títulos y adaptado a su propio proceso de producción, desde el renderizado hasta la edición, las pruebas y el control de calidad. Capcom también destaca la posibilidad de compartir recursos entre varias producciones. (capcom.co.jp)
Este enfoque permite adaptar profundamente la tecnología a las necesidades del estudio. Una función puede diseñarse exactamente para un pipeline interno, las herramientas pueden corresponder a los hábitos de los equipos y las mejoras realizadas para un juego pueden beneficiar a los siguientes.
El precio es considerable: desarrollar un motor significa también mantener su renderer, sus herramientas, sus sistemas de build, su compatibilidad con las plataformas y una enorme cantidad de tecnología que, de otro modo, gestionaría un proveedor externo.
Construir un motor propio no elimina una dependencia tecnológica: significa decidir asumirla por completo.
Un motor interno puede convertirse en una inversión a largo plazo
RE ENGINE ofrece un buen ejemplo de esta lógica. Capcom explica que su motor se desarrolló para responder a la creciente complejidad de sus producciones y a las necesidades específicas de sus creadores. La empresa lo utiliza actualmente para juegos con direcciones visuales muy diferentes y continúa haciendo evolucionar esta base tecnológica. (capcom.co.jp)
El motor se convierte entonces en una especie de memoria técnica del estudio. Las herramientas, optimizaciones y conocimientos acumulados durante un proyecto pueden reutilizarse en el siguiente. Los equipos no vuelven exactamente al mismo punto de partida con cada producción.
Esta continuidad puede convertirse en una ventaja importante cuando varios proyectos comparten necesidades similares. También puede convertirse en una limitación si el motor envejece mal o si nuevos tipos de juegos requieren funciones muy alejadas de aquellas para las que había sido diseñado.
Un motor interno debe, por tanto, evolucionar casi como un producto propio, con su equipo, su roadmap, sus pruebas y sus usuarios: los desarrolladores del estudio.
Elegir un motor significa elegir una parte del pipeline
El motor interviene muy pronto en la fabricación de un juego, pero sus consecuencias llegan hasta el lanzamiento. Influye en los formatos de archivo, los lenguajes utilizados, la estructura de las escenas, las herramientas de level design, los sistemas de animación, los métodos de profiling y la manera de producir las builds.
La elección depende, por tanto, de criterios mucho más amplios que la calidad gráfica.
Algunas preguntas realmente útiles
- ¿El equipo ya conoce el motor y sus lenguajes?
- ¿Las plataformas objetivo están correctamente soportadas?
- ¿Las herramientas corresponden al tipo de juego que se quiere producir?
- ¿El proyecto necesita un pipeline 2D específico, una 3D muy avanzada o ambas cosas?
- ¿El rendimiento esperado es compatible con la arquitectura elegida?
- ¿El equipo necesita modificar profundamente el motor?
- ¿El ecosistema de plugins y recursos aporta un valor real?
- ¿Cuál será el coste de mantenimiento del proyecto durante varios años?
Un prototipo realizado en unos pocos días puede tolerar determinadas limitaciones. Un juego destinado a mantenerse durante diez años no tiene las mismas necesidades.
La elección técnica adecuada siempre depende del contexto.
El motor no sustituye ni al game design ni a las competencias del equipo
Las demostraciones técnicas pueden dar a veces la impresión de que un motor moderno basta casi por sí solo para fabricar un juego espectacular. Puede producir rápidamente una iluminación avanzada, simular miles de objetos o proporcionar un personaje animado, pero estas funciones siguen siendo materias primas.
Un motor físico no sabe si un salto resulta agradable. Un renderer no sabe si una escena es legible. Un sistema de IA no sabe si un adversario resulta interesante de combatir. Un editor de niveles no sabe dónde colocar una puerta para construir una buena progresión.
Las herramientas reducen determinados costes técnicos y permiten a los equipos dedicar más tiempo a otros problemas. No hacen desaparecer esos problemas.
Esa es también una de las razones por las que dos juegos construidos con la misma tecnología pueden obtener resultados radicalmente diferentes. El motor proporciona una infraestructura común; son las decisiones de producción, arte, programación y diseño las que terminan construyendo la experiencia.
El motor moderno se convierte progresivamente en una plataforma de creación
Los motores actuales superan ampliamente al simple programa encargado de mostrar un juego. Integran editores, herramientas de profiling, sistemas de scripting visual, pipelines de importación, herramientas de terreno, cinemáticas, VFX, audio, animación y, en ocasiones, servicios destinados al multijugador o a la producción.
Esta evolución acerca el motor a un entorno de trabajo compartido entre distintos oficios. El programador desarrolla sistemas, el artista técnico construye shaders y herramientas, el level designer organiza el mundo, el animador ajusta sus comportamientos y el sound designer verifica sus eventos.
El motor se convierte entonces en el lugar donde terminan encontrándose las distintas disciplinas descritas en nuestro artículo sobre el pipeline de producción.
Probablemente sea la mejor manera de comprender su lugar: no es el juego en sí mismo ni solamente la tecnología escondida bajo sus gráficos. Es el terreno común sobre el que se ensambla el proyecto.
Del motor gráfico a la infraestructura de un mundo interactivo
Los primeros motores reutilizables respondían a una necesidad bastante evidente: evitar reconstruir la misma tecnología para cada juego. Con el aumento de la complejidad de las producciones, esta lógica se ha ampliado hasta abarcar gran parte del proceso creativo.
Actualmente, un motor puede gestionar la imagen, las colisiones, los sonidos, las animaciones y los scripts mientras proporciona las herramientas con las que un equipo construye sus niveles, importa sus recursos, analiza el rendimiento y prepara sus distintas versiones.
Unreal Engine, Unity y Godot muestran tres maneras de ofrecer esta infraestructura a creadores muy diferentes. Frostbite o RE ENGINE muestran la otra vía, la de empresas que invierten en su propia tecnología para adaptarla estrechamente a sus producciones.
Detrás de estas diferencias se encuentra, sin embargo, la misma idea: separar los problemas técnicos comunes de aquello que hace particular a cada juego.
Un motor sabe cómo mostrar un mundo, calcular una colisión o reproducir un sonido. Después corresponde al equipo decidir qué mundo merece ser construido, qué reglas deben animarlo y qué tendrá ganas de hacer allí el jugador.