Web Game Development Tools

Hola damas y caballeros, este es Mike Fleischer y bienvenidos a mi Cumbre de Desarrollo de Juegos Web. Ahora dirijo el canal GameFromScratch y GameFromScratch.com durante la última década, y durante esa década he cubierto literalmente cientos de motores de juego y frameworks. Y nunca hemos tenido más opciones. Si quieres desarrollar un juego en estos días, hay tantas opciones comerciales y gratuitas, de código abierto y de código cerrado. Estás absolutamente mimado por la elección.

Ahora el problema de tener muchas opciones es tener demasiadas opciones, y eso hace que cualquier decisión sea más difícil, especialmente cuando estás empezando. Así que si estás tratando de averiguar qué tecnología o motor de juego usar para tu próximo juego basado en la web, espero que esta charla te ayude. Hay dos enfoques principales sobre cómo puedes desarrollar un juego en el navegador. Uno es que puedes tomar el enfoque nativo, básicamente desarrollarlo como lo harías con cualquier otra aplicación basada en la web. Hay una serie de motores y frameworks que funcionan, estás escribiendo directamente en JavaScript. Esto tiene mucho sentido si tu plataforma de publicación principal es para la web. Si tu objetivo principal es la web, y la plataforma más importante es la web, este es un gran camino a seguir. Te da una integración estrecha con el navegador. Hace que tu experiencia de debugging sea un poco más fácil. La otra opción es básicamente compilada. Esto es tratar tu navegador más o menos como si fuera una máquina virtual. Usando tecnología como WebAssembly o ASMJS como relleno, y tecnología como Emscripten, las cadenas de herramientas para tu motor de juego o framework de elección, se compilan a casi un byte código que se ejecuta dentro de tu navegador. Esto generalmente no tiene una integración estrecha con el navegador, al menos no cuando se salta Pero el buen enfoque para el enfoque compilado es que estás tratando la web básicamente solo como otra plataforma. Así que en lugar de compilar para Windows y Mac y móvil y así sucesivamente, puedes agregar la web como un objetivo adicional. Este es el enfoque que toman muchos motores de juego tradicionales.

Complementario a la decisión de trabajar de forma nativa en el navegador o compilarlo usando una tecnología como WebAssembly y Emscripten, también tienes prácticamente tres decisiones principales diferentes en términos de qué tipo de tecnología de juego deseas usar para desarrollar tu juego. En la cima, tienes la idea de simplemente usar un motor de juego estándar listo para usar, el tipo de Unity, Unreal, Godot. Los conoces. Básicamente, tratan la web como otra plataforma. A veces es solo cuestión de incluso solo construir para la web y tu juego es creado. Ahora, además de eso, también tienes algunos de los motores de juego 3D y 2D específicos de HTML5 por ahí. Vamos a cubrir algunos de esos en este video también. Y luego, finalmente, tienes la opción de construir sobre un framework o una colección de bibliotecas que están ahí y más o menos hacerlo por tu cuenta. Ahora, tradicionalmente, no recomendaría hacer tu propio motor de juego porque hay un montón más trabajo del que te das cuenta, pero cuando se trata de desarrollo web, hay tantas bibliotecas y frameworks como Three.js o Box Physics, etc., en los que puedes construir, que la idea de hacer tu propio motor de juego en realidad no es tan desalentadora como lo sería en muchos otros escenarios. Y una de las cosas sobre el desarrollo web en general y las tecnologías de JavaScript es que tienden a ser muy modulares en su enfoque.

Y es más una cuestión de ensamblar piezas de Lego y construir tu propio motor a partir de componentes listos para usar en lugar de comenzar todo desde cero. Así que vamos a ver algunos de esos bloques de construcción con los que también podrías trabajar.

Pero primero, hablemos de los motores de juego tradicionales. Comencemos hablando de algunos de los motores de juego tradicionales que tienen alguna forma de exportación web. Creo que ahora en una época en la que los plugins de navegador ya no son una cosa, básicamente estás mirando un backend Emscripten backend compilando a WebAssembly en alguna forma para todas estas cosas que estábamos a punto de mencionar. Y estas son excelentes opciones, especialmente si ya estás desarrollando un juego y quieres simplemente agregar la web como otra plataforma.

Y vamos a empezar con el ejemplo más obvio. Ahora no voy a cubrir todas las opciones de motores de juego que existen que compilan para la web porque hay simplemente tantas de ellas. Vamos a hablar de algunos de los jugadores más grandes en este espacio. Y el jugador más grande directamente es Unity. Ahora Unity tiene la mayoría de los desarrolladores. Tiene la comunidad community más grande. Probablemente tiene el soporte de plataforma más amplio que existe. Es un motor de juego 3D y 2D completamente funcional. Tu lenguaje de scripting principal va a ser el lenguaje de programación C sharp. Pero hay una serie de opciones de scripting visual incluyendo dos que son oficialmente soportadas por Unity ellos mismos. Tiene el mayor volumen de materiales de aprendizaje que existen. Y francamente, si no estás haciendo web primero y no sabes cuál elegir, Unity es probablemente la elección más fácil que podrías hacer, simplemente porque la comunidad community es tan buena como se puede obtener. La comunidad community de Unity es masiva. Eso significa que hay una serie de materiales de formación, hay una serie de tutoriales, hay una serie de personas con las que puedes hablar si necesitas ayuda y así sucesivamente. Así que Unity es una excelente opción, especialmente si la web no es tu plataforma principal. Si sólo quieres agregar otra plataforma a la lista, si estás desarrollando para escritorio y móvil y web, bueno, Unity podría ser una buena elección.

Otra opción que solía existir era Unreal Engine. Ahora Unreal Engine ha deprecado realmente su soporte de destino web. Hay plugins de terceros que traen esta funcionalidad pero no creo que yo recomendaría Unreal Engine para nadie a menos que ya estuvieras trabajando en un proyecto de Unreal Engine porque Unreal simplemente no ha expandido tanto en el espacio web. Hay formas de hacerlo y hay terceros trabajando en retomar donde Epic Games dejó su soporte. Pero sólo sé que Unreal Engine y Unity son probablemente los competidores directos más cercanos que puedes encontrar cuando se trata de desarrollar títulos basados en la web. No realmente. Unreal Engine está muy por detrás en ese aspecto. En el lado del motor si estás buscando más hacia lo gratuito y específicamente de código abierto otra opción para ti es el motor Godot.

Ahora bien, tanto Unreal como Unity tienen tarifas de licencia o tarifas por asiento adjuntas. Unity no es de código abierto en absoluto, mientras que Unreal Engine está disponible en código fuente. Godot es un motor de juegos 2D y 3D completamente de código abierto con licencia MIT. Ahora bien, no tiene el alcance de Unreal o Unity. Probablemente no tiene la fidelidad gráfica en 3D de alta gama de ninguno de ellos. No tiene los gigantescos recursos detrás de esos motores. Pero lo que sí tiene es una enorme comunidad detrás de él y un montón de potencial. Así que Godot en el espacio 2D ha sido muy fuerte. Mejorando con cada lanzamiento. Godot en el lado de las cosas 3D definitivamente está mejorando. Y próximamente, esperemos en este año calendario, quizás a principios del próximo año, deberíamos ver el motor Godot 4 con visuales 3D mucho mejores también. El enfoque de Godot es utilizar también la compilación de WebAssembly. De hecho, puedes compilar Godot, el editor y las herramientas para que se ejecuten en el navegador. Así que el soporte web de Godot está muy bien probado, probado en batalla y es una gran oportunidad allí.

Hoy vamos a hablar de dos opciones de game engine 2D en este espacio, game engine tradicionales. El primero es el game engine Default. Este proviene de King, los creadores de prácticamente todos los juegos móviles que probablemente hayas jugado en el pasado. Finalmente, abrieron en su mayoría el code. Ahora es completamente gratuito para usar y el code está totalmente disponible, aunque no está bajo una licencia estándar OSI, por lo que no puedo llamarlo de código abierto per se. Default es un excelente game engine. He sido un gran fanático de él durante mucho tiempo. Tienen su propio enfoque único para las cosas. El lenguaje de programación Lua es tu principal forma de comunicarte y utiliza un sistema de mensajes para mantener las cosas desacopladas. Recomendaría encarecidamente probar Default. Es un enfoque diferente. Puede que no atraiga a todos, pero me gusta bastante la forma en que funciona. Ahora, esto finalmente se compila en WebAssembly también, por lo que no crea code de navegador legible por humanos como resultado, pero también puedes crear versiones de escritorio móviles, y el performance es bastante bueno.

Ahora, la otra opción es GameMaker Studio. GameMaker Studio ha existido durante más de 20 años. Tradicionalmente, un game engine basado en 2D. Recientemente fue adquirido por Opera, el fabricante de navegadores, y por lo tanto, imagino que van a poner cada vez más énfasis en el lado HTML de la ecuación, pero GameMaker tiene objetivos para varias plataformas diferentes también.

De nuevo, Default y GameMaker se centran principalmente en el espacio 2D. GameMaker utiliza su propio script de GameMaker, así como una configuración de arrastrar y soltar 2D para la lógica de programación. También tiene su propio enfoque para las cosas. Es un entorno muy autónomo. Tiene todas las herramientas que necesitas en un solo lugar. Sin embargo, es un proyecto comercial, pero hicieron una versión de evaluación de este que es completamente funcional y está disponible gratuitamente. Muy esperado. Me alegra ver que finalmente hay una versión más accesible de GameMaker. Entonces, si quieres probar GameMaker, es una opción para el desarrollo de juegos basados en web también y con el hecho de que ahora son propiedad de Opera, espero ver cada vez más un enfoque en la web en el futuro.

Ahora pasamos a los motores de juegos donde la web es en realidad la plataforma de desarrollo principal. Si estás buscando el equivalente de Unity pero en el espacio web, eso es definitivamente PlayCanvas. PlayCanvas es completamente basado en navegador. Haces tu edición directamente dentro de PlayCanvas, pero te proporciona un Editor de Mundo 3D completamente funcional, soporte completo para importación de modelos 3D, soporte para animación, todo lo que esperarías. Entonces, si estás buscando crear un juego 3D con la web como tu plataforma principal en la web, es difícil equivocarse con PlayCanvas. Ahora, PlayCanvas es comercial. Partes de él, como la Biblioteca de UI PC UI, se han convertido en código abierto, pero de lo contrario es un software basado en suscripción. Si estás buscando algo que sea más completamente de código abierto pero que tenga un poco menos de las herramientas, eso sería Babylon.js. Babylon.js fue fuertemente respaldado por Microsoft. Es un motor de juegos 3D de código abierto y un framework. Realmente no tienes los entornos de edición tipo Unity, pero por otro lado es completamente y absolutamente de código abierto. Entonces, si estás buscando hacer 3D como plataforma principal de web como tus motores de plataforma, definitivamente PlayCanvas y Babylon.js son los dos a considerar. Otra opción en términos de motores de juegos tipo Unity 3D con la web como la plataforma principal que podrías considerar es Cocos Creator. Cocos Creator en sí no es de código abierto, pero es de uso gratuito y está construido sobre un framework de código abierto. Proporciona una especie de funcionalidad de Unity light, no tiene tantas características como esperarías en Unity, pero la mayoría de lo que necesitarías para crear juegos 3D o 2D está ahí. Importación de modelos 3D, soporte de animación, capa de UI, etc. Es muy popular en China, pero tiene documentación en inglés y una comunidad en inglés, solo que la comunidad asiática es mucho más grande alrededor de Cocos Creator.

No confundas Cocos Creator con Cocos 2D. Volveremos a eso en un segundo cuando comencemos a hablar de 2D.

En el tema de 2D, tenemos algunas opciones. En el lado del game engine, muchas de las herramientas de desarrollo basadas en HTML5 son en realidad visuales en la naturaleza donde usas un lenguaje de programación visual y genera JavaScript code para ti. Los dos más destacados que puedo pensar son Construct 3, que es un software basado en suscripción donde usas una especie de configuración visual para crear tus juegos, pero también puedes extenderlos usando el lenguaje JavaScript así como el G develop de código abierto, que de nuevo, utiliza una especie de programación estilo hoja de cálculo, y puedes extender usando el lenguaje JavaScript. Ambos generan un proyecto basado en la web al final. Ambos proporcionan muchas de las herramientas 2D que necesitarías para crear un juego. Ambos son principalmente motores solo 2D, aunque ambos tienen soporte 3D naciente también, pero definitivamente no querrías considerar ninguno de esos para el desarrollo 3D en este momento. Pero para 2D, especialmente si buscas un enfoque un poco más visual, ambos son buenas opciones. Otro en esa área es Stencil. Ahora bien, este es un lenguaje de programación visual. En realidad utiliza hacks, pero puede compilar para las plataformas basadas en la web también. Así que si quieres trabajar visualmente, en un entorno 2D, Stencil es otro que deberías considerar revisar. Está en una especie de licencia híbrida gratuita, no gratuita que vas a querer mirar allí.

Eso es todo para la mayoría de los principales motores de juegos que quiero tocar. Pero luego entramos en el mundo de los frameworks. Ahora bien, esto es básicamente como los motores de juegos, pero más modulares, más basados en code, un poco menos de las cosas generales que los mantienen juntos. Así que tal vez te falta un editor de niveles o algo por el estilo. Pero aquí tienes varias opciones diferentes. Y puedes usar estos para construir tu propio game engine, o puedes construir tu juego completamente usando uno de estos frameworks. Ahora bien, algunos de los frameworks de alto nivel son PhaserJS, MelonJS y Cocos2DJS. Ahora bien, Cocos2D comenzó como, creo que era Python hace mucho tiempo, pero ha sido portado a casi todas las plataformas que puedes imaginar, incluyendo una plataforma basada en la web. Esto es lo que finalmente Cocos Creator está construido encima y proporciona toda la funcionalidad que puedes imaginar para crear un juego. No es la tooling de arriba. PhaserJS es probablemente mi favorito, personalmente, HTML5 code basado en 2D framework. Proporciona, ya sabes, todas las cosas que necesitarías para hojas de sprites, atlas, jugar sonido, cargar niveles, etc. Y luego tienes MelonJS, que es algo similar pero un poco más pequeño en general que PhaserJS. Así que si quieres construir un juego 2D, cualquiera de esos frameworks es una gran elección sólida. Ahora en el lado 3D de las cosas, tienes un framework muy predominante, y esa es una herramienta llamada 3JS. Ahora bien, 3JS proporciona una tonelada de funcionalidad.

Una capa de abstracción WebGL, soporte para la carga de modelos 3D, gestión de gráficos de escena, carga de objetos, etc. Básicamente, todo lo que necesitas para crear tu propio motor, excepto tal vez las herramientas, está disponible en 3JS.

De hecho, hay otras herramientas como A-Frame, que es un marco de VR que utiliza un tipo de marcado HTML para crear mundos 3D. En realidad, está construido sobre 3JS. Vas a encontrar que varios motores de juegos están construidos sobre o utilizando 3JS. Definitivamente es un bloque de construcción poderoso para crear tus propios títulos 3D.

Puedes construir tu juego directamente en 3JS si lo deseas o podrías construir tu cadena de herramientas sobre él. Pero hay otras bibliotecas basadas en JavaScript de interés para los desarrolladores de juegos. En el lado de la física, tienes un puerto de Box2D, Box2D es probablemente el motor de física 2D más popular que existe. Pero también están MatterJS y PlankJS. En realidad, no tengo experiencia con ninguno de ellos, pero ambos son marcos de juegos 2D que se ejecutan directamente en el navegador.

Además de eso, en el lado 3D de las cosas, tenemos AmmoJS que es un puerto de física 3D bullet para hacer simulaciones físicas 3D. Y luego tenemos OIMO, no tengo idea de cómo pronunciarlo realmente. Y no estoy realmente abrumadoramente competente con esa biblioteca, así que no voy a expandir sobre ella más que para informarte. Para la física, esas son tus opciones.

Además de eso, también tenemos una gran biblioteca de renderizado de la que probablemente deberías estar al tanto. Muchos de estos, incluyendo por ejemplo, Phaser y creo que Melon y posiblemente Cocos2D todos construyen sobre PixyJS. Ahora, PixyJS básicamente solo abstrae la capa de renderizado. Así que si necesitas hacer un dibujo 2D lo más rápido posible, esto hace que no necesites saber sobre WebGL o si estás haciendo renderizado de respaldo, usando algún otro método, PixyJS se encarga de todo eso por ti y mucho más. En muchos aspectos, es para 2D lo que 3JS es para 3D.

Así que si quieres seguir adelante y crear tu propio motor, lo bueno es que tienes todas estas varias bibliotecas por ahí que puedes juntar como bloques de LEGO virtuales, ponerlas juntas y crear un motor propio, o puedes, tu juego no necesariamente necesita un motor si no vas a reutilizar el código, y es lo suficientemente simple en su naturaleza. Puedes construirlo directamente sobre uno de estos marcos y seguir desde ahí, así que no necesitas un motor al final.

Si vas a seguir el enfoque de hacerlo tú mismo, o estás usando una biblioteca o marco que no necesariamente proporciona todas las herramientas que podrías obtener de un motor de juegos más completo, probablemente aún necesitarás algún tipo de herramienta de diseño de niveles 2D. Y en este espacio, tengo dos principales recomendaciones. Ahora, el más antiguo que ha estado por mucho tiempo es el proyecto de código abierto Tiled. Tiled es capaz de crear no solo mapas 2D, sino también proyecciones de mapas isométricos y hexagráficos. Y luego otro en este espacio que es mucho más joven es el LDTK, o el Toolkit de Diseño de Niveles. Ahora, ambas son excelentes herramientas para componer, visualmente componer tu mundo, así como poblarlo, establecer barreras y objetos de juego, etc. Así que si vas a seguir el enfoque de hacerlo tú mismo, no necesitas crear estas herramientas desde cero tampoco. Podrías traer herramientas como LDTK y Tiled y básicamente crear tu propio motor de juegos personalizado utilizando tales recursos.

Otra área que quizás debas considerar es el soporte de audio, especialmente si estás desarrollando el tuyo propio. Si usas algo como Phaser, tiene soporte para audio incorporado, y probablemente está construido a través de algunas de las bibliotecas de las que vamos a hablar ahora, pero si necesitas agregar audio a tu propio framework o motor de juegos, hay un par de opciones disponibles. Y en su mayoría están construidas sobre el audio web con alternativas al soporte de audio del navegador. Y ellas se encargan de esas complejidades por ti. Dos de las que probablemente quieras tener en cuenta son Sound.js y Howler.js. Ambas son excelentes para ocultar las complejidades de trabajar con audio y alejarse de algunas de las excentricidades de los navegadores que podrías enfrentar de otra manera. Ambos son proyectos de código abierto, pero no son los únicos y nada de esto es una lista exhaustiva. Hay un montón de otras bibliotecas disponibles. Solo quiero que sepas que si quieres hacer tu propio motor o framework, hay todas estas piezas disponibles, la mayoría de ellas de código abierto, que puedes utilizar para crear tu propio motor con una fracción del trabajo que tradicionalmente verías en estos espacios si no, ya sabes, construyes sobre el trabajo de otros.

A partir de este punto, tienes una base bastante buena de las opciones que existen desde motores de juegos tradicionales que pueden apuntar a la web hasta motores más enfocados en la web hasta lenguajes de programación visual y más que podrías usar para crear tu juego y luego el número de frameworks que podrías usar para crear el tuyo propio.

Elegir el motor correcto es realmente una cuestión de adaptarse a tus necesidades lo mejor posible. También debes saber que esta lista no fue de ninguna manera exhaustiva. Hay muchas más opciones por ahí. Solo para que lo sepas, a medida que se vuelve un poco más oscuro, la idea de encontrar soporte para ese motor también se vuelve más difícil. Si quieres contratar a alguien o intentar encontrar una respuesta a un problema que te tiene desconcertado, cuanto más grande sea el motor, más grande será la comunidad, mayor será la probabilidad de encontrar ese problema o persona por ahí.

Además de elegir el motor correcto, probablemente puedes pasar por una serie de preguntas para probablemente reducir cuál funcionará mejor para ti. Ahora la pregunta más fácil con la que podemos empezar es ¿mi juego es 2D o 3D? Solo con responder a esa pregunta, si estás creando un juego 3D, acabamos de eliminar aproximadamente la mitad de los motores de juegos de la lista, por ejemplo. Ahora la siguiente pregunta realmente fácil es, ¿tengo algún dinero? Si no tienes dinero disponible, de repente las tarifas de licencia, las tarifas de licencia por asiento de algo como Unity pueden no atraerte tanto. Ten en cuenta que Unity cuesta X cantidad por asiento si ganas más de $100,000 al año USD. Entonces, si estás tratando de mantenerlo lo más barato posible, es posible que quieras mantenerte alejado de los motores más comerciales en este espacio. Ahora, si no te importa el dinero, bueno, eso hace que sea una categoría abierta.

Ahora lo mismo sobre código abierto, ¿te importa el acceso al código fuente? ¿Necesitas que sea totalmente de código abierto, algo como el motor de juego Godot, en su mayoría de código abierto como el motor predeterminado, o código disponible como el motor Unreal. Si todos estos son importantes para ti, si el acceso al código fuente es realmente importante para ti, bueno, entonces puedes eliminar nuevamente la mitad de los motores de la lista. Así que tomar decisiones siempre se reduce a, ya sabes, agrupar cosas y proceso de eliminación.

Ahora también ten en cuenta, una de las grandes decisiones va a ser, ¿cuál es mi plataforma principal? Si estás desarrollando para web primero, la tecnología web primero tiene mucho sentido. Ahora ten en cuenta que, cuando implementas tecnologías web, necesitas ponerlo en algún tipo de capa de envoltura como Electron. Ahora, si haces esto, no vas a tener el mismo rendimiento que probablemente habrías obtenido si hubieras ido nativo. Entonces, por ejemplo, si desarrollas un juego en Unreal o Unity para el escritorio, probablemente superará en rendimiento a una aplicación 3D basada en web que se ejecuta en algo como Electron. Es solo la naturaleza de la bestia. Entonces, si necesitas obtener ese rendimiento máximo, web primero probablemente no sea para ti a menos que tu plataforma sea específicamente la web. Ninguna de las anteriores también es una opción. Y aquí es donde empiezas a tener la idea de crear el tuyo propio. Ahora, en el mundo de escritorio, básicamente nunca recomendaría a alguien que escriba su propio motor de juego a menos que fuera algún tipo de experiencia de aprendizaje. Generalmente pasarás más tiempo escribiendo el motor, escribiendo las herramientas que ejecutando tu juego. A menudo por un orden de magnitud. En el mundo web, sin embargo, es un poco diferente. Aquí tienes una serie de proyectos, hombros de gigantes sobre los que podrías construir. Si estás trabajando en el espacio 3D, 3JS proporciona más del 80 por ciento de la funcionalidad que necesitarás. Si necesitas bibliotecas de audio, están disponibles.

Si necesitas bibliotecas físicas, están disponibles. Es en su mayoría una cuestión de juntar estas cosas. Y luego, en el lado 2D de las cosas, hay una serie de renderizadores y motores de física que ya vimos, así como frameworks que hacen el 90 por ciento de lo que tu juego 2D requerirá. Cosas como Phaser o Cocos. Puedes construir sobre ellos y simplemente construir tu lógica de juego o tu propio game engine derivado encima. Hacerlo tú mismo siempre es una opción.

Te he dado una serie de suggestions en un amplio número de categorías. Ahora te daré probablemente lo que sería mi sugerencia en cada una. Lo que yo personalmente elegiría. Puedes tomar esto con un grano de sal gigante, y está bajo una variedad de diferentes escenarios. La prioridad número uno para mí eran las plataformas. Quería hacer que mi juego se ejecutara en tantas plataformas como fuera posible. Así que si estás interesado en conseguir un objetivo móvil, quizás VR, web, lo que sea, es difícil superar a Unity. Así que si quieres tener un soporte lo más amplio posible, el game engine de Unity es algo como el IBM. Nadie fue despedido nunca por elegir IBM. Nadie fue despedido nunca por elegir Unity, especialmente para este tipo de juegos.

Sin embargo, si estás más limitado por el presupuesto o si estás más alineado con una ética de código abierto bueno, tienes el game engine de Godot. El game engine de Godot no tiene el dinero de investigación y desarrollo detrás de él, la gran cantidad de empleados detrás de él que verías con algo como Unity o Unreal Engine. Por otro lado, es completamente de código abierto y tiene una community muy activa y comprometida, y se está expandiendo a un ritmo tremendo. Y están poniendo un buen énfasis en el soporte web. Así que si mi alineación era más no quiero gastar dinero o prefiero el código abierto o ambos, probablemente elegiría el motor Godot.

Ahora si estuviera escribiendo un juego 2D, lo mismo, probablemente elegiría el motor Default. Ahora Default no va a ser para todos, especialmente si no soportas el lenguaje Lua, pero te recomiendo encarecidamente que si estás pensando en crear un juego 2D, eches un vistazo a Default. De nuevo, no va a ser para todos. Tienen su propio, son el game engine más único en la lista de hoy. Tienen un enfoque muy poco convencional para las cosas y me habla. Me gusta la forma en que se organiza el code, me gustan las herramientas de nivel que obtienes con él. Es un enfoque muy diferente. Así que si estás interesado en algo un poco diferente, 2D y en su mayoría de código abierto, echa un vistazo a Default. Ahora si estás más en la programación visual, no quieres meterte en la codificación en absoluto, ahí es donde opciones como GDevelop, Construct 3 y Stencil son buenas opciones.

GDevelop siendo la opción más económica de esas opciones, mientras que Construct 3 es probablemente la más madura de esas opciones. Todos ellos son principalmente 2D. Sé que de nuevo, Construct, por ejemplo, tiene algunos comienzos de soporte 3D en este momento, pero ni siquiera consideraría ninguno de esos para el desarrollo de juegos 3D.

Y por supuesto, si estaba haciendo web como mi objetivo principal, así que si estaba creando un juego 3D solo para web, usaría Babylon o PlayCanvas. No sé cuál. Si me importara más la construcción de niveles y el tipo de herramientas, probablemente iría con PlayCanvas. Si estaba tratando de ahorrar dinero o si estaba trabajando un poco más a nivel de código, probablemente iría con BabylonJS. Creo que hay una gran actualización para BabylonJS que llegará cualquier día de estos. Será interesante ver qué pasa allí.

Y por supuesto, si estaba buscando crear un juego 2D, un poco más centrado en el código, o si quería integrar herramientas externas, hay frameworks como Phaser. Y por supuesto, si vas a construir el tuyo propio, te recomiendo que eches un vistazo al framework de JavaScript 3JS para el desarrollo de juegos 3D.

Señoras y señores, es el final de la masterclass. Espero haberles ayudado un poco, si están buscando y tratando de averiguar qué motor debería elegir para crear mi próximo juego. Si también estás interesado en aprender más sobre motores de juegos y herramientas, etc., ve a revisar Game From Scratch. Espero que también encuentres algo interesante allí. Así que, espero que hayas disfrutado de esta masterclass, y hablaré con todos ustedes más tarde. Adiós.