Tras la polémica de Unity sobre precios y licencias, el debate sobre los motores de juego se reavivó: ¿conviene migrar a otro motor, quedarse o construir uno propio? Este artículo desmonta la idea de que un motor de juego es algo inherentemente enorme o complejo. El autor, desarrollador de un motor personal de unos 100.000 líneas de código con el que ha publicado más de una decena de juegos experimentales y un título comercial, propone una definición deliberadamente amplia: un motor de juego es cualquier conjunto de herramientas y bibliotecas pensado para crear videojuegos. Bajo esa lente, incluso un proyecto pequeño que combine SDL2, OpenGL y stb_image para dibujar sprites animados ya puede considerarse un motor.
El texto repasa las razones para embarcarse en uno propio —aprendizaje, disfrute del código, eliminación de frustraciones con herramientas ajenas y control total— y los inconvenientes, sobre todo el tiempo: para un plataformas 2D pixel art basta con unas semanas de trabajo (el motor representa apenas el 1% del esfuerzo total), pero aspirar a un título AAA exige entre cinco y diez años de dedicación a tiempo completo. A continuación enumera los bloques habituales de un motor medio: scripting, renderizado 2D/3D, animación, sonido, física, interfaz, gestión de assets, herramientas de edición y soporte multiplataforma. Incluye además una digresión sobre el scripting visual —que es programación, como lo son el Juego de la vida de Conway o la codificación de Gödel— y enlaces a recursos complementarios.