Holivar sobre si usar motores para crear juegos comenzó inmediatamente después de que aparecieron los primeros motores de juegos.
Esta publicación en reddit no
es un ejemplo ideal de contraargumentos razonables contra el uso constante de motores, pero creo que el deseo irresistible de usarlos da un poco de fanatismo.
Razonemos sabiamente
Creo que no hay una respuesta preparada a la pregunta de si el desarrollador debe usar el motor. Un desarrollador inteligente, antes de elegir una tecnología, evalúa todas las opciones posibles.
Nivel de habilidad
¿Tiene suficientes habilidades para usar efectivamente la opción seleccionada? Si no tiene experiencia en programación, tendrá que aprender mucho antes de estar listo para crear un juego a partir de un conjunto de bibliotecas dispares.
Si no tiene habilidades técnicas ni interés en aprenderlas, entonces realmente no hay opciones: debe trabajar con el motor (o convencer a alguien para que haga la parte técnica por usted; ¡buena suerte con eso!).
Hay un estado intermedio entre una falta total de habilidades y un nivel profesional. Se encuentra principalmente en el país de los lenguajes de secuencias de comandos: Scratch, Game Maker, Pygame, Unreal Blueprints, LOVE2D, etc. Todos ellos son para aquellos que desean obtener un cierto nivel de conocimiento técnico para lograr resultados rápidamente.
Si usted es un programador experimentado / profesional que es capaz de dominar con confianza el software de terceros, entonces puede usar esta habilidad y decidir qué tan minimalista / maximalista será su enfoque (ya sea un SDL extremadamente mínimo o un Unreal Engine totalmente equipado).
Objetivos de desarrollo
¿Cuáles son tus objetivos en este proyecto? Las tecnologías deberían maximizar su logro:
- Este es un pasatiempo para ti y, sobre todo, ¿quieres crecer como desarrollador? Quizás deberías mantenerte alejado de Unity e Unreal y buscar desarrollar juegos basados en bibliotecas de nivel inferior.
- ¿Es este un negocio para ti? En este nivel, las cosas se vuelven mucho más complicadas. Las opciones deben evaluarse en función de muchos factores: ¿puede contratar personas familiarizadas con la tecnología? ¿Estas personas quieren usar la tecnología? ¿Se ajusta a su marco de tiempo? ¿Tienes las habilidades para usarlo de manera efectiva? ¿A tus artistas / diseñadores les gusta la tecnología?
Interés
Si trabaja más (o planea trabajar) con los desarrolladores que solo, entonces necesita evaluar cómo otras personas están interesadas en la tecnología. Si trabaja con un viejo motor / marco que todos odian, será difícil encontrar desarrolladores motivados para su proyecto.
También considere cómo los artistas y diseñadores interactuarán con la tecnología. ¿Desea crear herramientas para ponerse al día con la funcionalidad de Unreal? Inevitablemente compararán las capacidades del motor y las suyas. Escuché que incluso los estudios AAA tienen un problema con los artistas que requieren características de Unreal que aún no están implementadas en la bifurcación actual del estudio de Unreal.
Si trabaja solo, debe mantener una fuerte pasión por los proyectos. Si odias la tecnología con la que trabajas, lo más probable es que dejes de trabajar. Si te rindes, todos tus esfuerzos se convertirán en polvo (con la excepción de una experiencia invaluable).
¿Qué te dan realmente?
Jonathan Blow tiene un video increíblemente sabio sobre lo
que realmente dan los motores de juego . Resuelven problemas "simples" para usted, pero luego se interponen cuando intentan resolver un problema difícil, que constituye juegos emocionantes.
Sí, por supuesto, obtienes un excelente editor, herramientas de nivel profesional y un motor que ha llegado a miles de desarrolladores, pero lo pagas con muchos otros aspectos:
- A veces, las soluciones utilizadas en él son demasiado generalizadas: quizás en tu juego la gravedad se aplica de una manera completamente nueva, pero luego tienes que luchar con el sistema de gravedad irreal rígidamente definido. Quizás esté creando un proyecto con un modelo de red complejo, y luego tendrá que deshacerse por completo de la arquitectura del servidor Unreal.
- A veces, las soluciones son demasiado especializadas: si alguna vez profundizó en las entrañas de Unreal Engine, vio que todo el motor está plagado de un código de tirador en primera persona. Si creas un juego de este género, entonces está bien. Si no, solo será confuso.
- A veces hay demasiadas cosas en el motor: esto ejerce presión tanto en el cerebro como en la computadora. Realizar una simulación completa de la física de estado sólido, una tubería 3D con animación esquelética y tres marcos es un fracaso absoluto para un juego en 2D. Tendrás que descubrir cómo deshabilitar todas estas funciones de Unreal, buena suerte con eso. Personalmente, encuentro que el rendimiento de Unreal es decepcionante incluso en mundos de prueba con pocos objetos.
Debe hacer la pregunta: "¿Qué es lo que realmente necesito?" Deshazte de todo lo superfluo. Todo sistema innecesario es desperdicio de recursos y tiempo.
¿Qué se necesita para su proyecto?
La tecnología debe ser administrada por su proyecto, a menos que sea una demostración de tecnología. Si está creando un juego, debe trabajar solo con aquellas tecnologías que influyen en el juego, solo con las más necesarias para transmitir su visión. Si el motor te proporciona la forma más rápida de lanzar tu juego, entonces esta es una buena opción. ¡Pero esto no siempre será así!
Hay juegos exitosos que servirían al mal servicio de cualquiera de los motores disponibles:
- Para Dreams , se escribió un renderizador personalizado que simplifica y acelera la creación intuitiva de activos 3D.
- No Man's Sky está utilizando activamente métodos completamente nuevos de generación de procedimientos. Al implementar tales cosas en el motor, tendrías que lidiar constantemente con eso.
- En Minecraft , solo se pueden usar algunas de las características de los motores estándar.
El futuro de su (y nuestra) industria
Al usar cualquier tecnología, vale la pena pensar en el
cierre . Joel Spolsky tiene una serie de artículos sobre una estrategia comercial para el desarrollo de software, en la que reflexiona sobre el
cierre del producto . En resumen, su idea es que las empresas estén interesadas en que usted use su producto, porque si usted no usa el producto, entonces no ganan dinero. Los maestros en capturar industrias enteras son Apple, Microsoft, Adobe y Autodesk, crean la sensación de que no hay otras alternativas además de su software.
El cierre afecta incluso a los desarrolladores de pasatiempos / solistas. Tengo un amigo que lucha constantemente con Unity (actualizaciones que rompen la compatibilidad, sistema de creación de prototipos, adware, soporte 2D deficiente ...). Quiere alejarse de Unity, pero está fuertemente bloqueado en este motor porque la mayor parte de su código (y datos) se basa en la API de Unity.
¿Por qué compran los motores?
Unreal y Unity están impulsadas por los requisitos del mercado. Sus clientes de nivel AAA, con la ayuda de contratos multimillonarios, determinan el curso de un mayor desarrollo de los motores. Si estás trabajando en un juego cuya estructura no coincide con los objetivos de estos jugadores AAA, entonces los desarrolladores de los motores no te servirán tan fielmente. Por ejemplo, los juegos bidimensionales, de procedimiento, experimentales, voxel y juegos con grandes cantidades de datos casi siempre tienen que buscar algo propio.
Cuanto más brillantes parecen las funciones, más busca la administración de las empresas (que con frecuencia no son expertos en tecnología) el uso de motores. Las características como los planos del motor Unreal son muy populares entre artistas y diseñadores, pero plantean muchos problemas para los programadores. (Esto es típico de cualquier lenguaje de programación; si permite que las personas que no han estudiado programación programen, el resultado será pobre, similar a lo malo que son los gráficos dibujados por los programadores).
¿Las nuevas funciones realmente hacen que sea más fácil completar tu juego? ¿Realmente agregan valor al producto final?
Lucha contra la centralización
Cada vez que uno de los estudios cambia de su propio motor a Unreal o Unity, las compañías de Epic y Unity obtienen aún más poder en la industria del juego. Al principio, tal centralización puede parecer rentable (después de todo, tienen 500 ingenieros trabajando en el motor, ¡excelente!), Pero en un par de décadas esto se convertirá en un problema real. Google me viene a la mente: esta compañía ha capturado la gran mayoría de las funciones que las personas usan en Internet, y les costó la pérdida de una gran parte de la privacidad.
Incluso a nivel de pasatiempo, abandonar la investigación en favor de Unreal o Unity perjudica a las generaciones futuras de motores. Esto puede dañar incluso a Unreal: si todos usan Unreal, Epic no podrá contratar a nadie más para crear una nueva generación del motor, ¡porque nadie sabrá cómo se escriben los motores de juego!
El futuro puede ser de código abierto
Si nosotros, como industria, queremos crecer, creando más y más productos de alta calidad, entonces necesitamos compartir más, no menos, para compartir tecnologías.
Creo que la industria se está moviendo en esta dirección, aunque de manera extremadamente lenta. Esto es especialmente cierto en los estudios de juegos de nivel AAA, que aún ocultan el código de sus motores para obtener una ventaja competitiva (¿imaginaria?).
- Microsoft ha dado grandes pasos en esta dirección. Si incluso cambian, entonces estoy seguro de que otros pueden hacerlo.
- El acuerdo de licencia de Unreal contiene una cláusula que le permite confiar en su código cuando trabaja en su propio motor (propietario o gratuito). Creo que este es un gran progreso.
- Gracias a su total apertura y acceso gratuito, Godot está ganando gran popularidad, y espero que si se le da suficiente tiempo y apoyo, se convertirá en un competidor de Unity (y, finalmente, Unreal).
- id Software (en la era de John Carmack) lanzó el código fuente completo de Doom a Doom 3 . Carmack tenía muchas razones para avanzar en tal decisión. Lo más convincente de esto para las empresas es que no daña las ventas. El modelo shareware utilizado por Doom, el desarrollador proporciona el motor y vende datos, puede ser una estrategia efectiva hoy en día. Si a su empresa le preocupa que los competidores “roben” su tecnología, puede publicar su código después de que se lance un nuevo juego (como lo hizo la identificación). Después de la partida de Carmack, la identificación parece haber perdido interés en publicar código.
Calidad del software
Jonathan Blow y
Casey Muratori son críticos ardientes de las prácticas modernas de escritura de software. Su punto de vista es que hemos estado creando complementos sobre capas de abstracciones durante tanto tiempo que obtenemos enormes capas frágiles de basura innecesaria, y esto no nos permite escribir mejores productos.
Quizás su filosofía esté más cerca del idealismo que del pragmatismo (que generalmente lleva a un retraso en el lanzamiento de los juegos), pero si está cerca de usted, entonces no debe ignorarlo.
¿Son importantes para usted la velocidad, la calidad y la elegancia de su tecnología? Muchas personas están bastante contentas con la respuesta negativa, pero algunas quieren crear programas de una manera más "limpia".
Cuales son las alternativas?
En lugar de usar el motor, solo estás escribiendo un juego.
Los principiantes a menudo piensan que necesitan un motor para crear un juego. Con un alto grado de probabilidad, deberían rechazar este punto de vista. Los principiantes perderán tiempo implementando funciones de motor inútiles, en lugar de dejar que el juego decida por sí mismo lo que realmente necesita. Solo el juego debe controlar lo que se necesita del motor (por supuesto, Unity puede tomarse como un contraejemplo, como un ejemplo del enfoque de "motor primero"; Unreal Engine 4 tiene Paragon, Fortnite y Unreal Tournament para apoyar este concepto, sin mencionar docenas de años de experiencia lanzando un número infinito de juegos en versiones anteriores de motores).
Usando bibliotecas
Comenzar desde cero solo tiene sentido si tiene la habilidad y el plan para crear innovación en un componente en particular (o tiene limitaciones). En todos los demás casos, hay muchas bibliotecas para la integración. Esto es especialmente bueno cuando sabe que, por ejemplo, el sistema de física estándar es completamente adecuado para los requisitos de su proyecto (esto es especialmente importante porque para implementar su propia física necesita mucho conocimiento en esta área).
Aquí hay algunas bibliotecas que pueden llenar el vacío entre trabajar desde cero y usar un motor completamente terminado:
- Gráficos: SDL, SFML, Ogro
- Física: Bullet, PhysX (que recientemente se convirtió en código abierto, ¡una gran victoria!)
- Sonido: SDL, SFML
Esta es solo una fracción muy pequeña de las bibliotecas existentes.
Una gran ventaja en el uso de bibliotecas es que le brinda la mayor flexibilidad entre todas las opciones. Si escribe todo el código en un motor, tendrá que hacer grandes esfuerzos para portarlo. Si escribe un juego como una colección de bibliotecas, tiene una gran movilidad y puede reemplazar subsistemas completos. Si la biblioteca no cumple con sus requisitos, puede probar con otro o incluso escribir su propio reemplazo.
Además, tanto Unreal como Unity admiten la importación de bibliotecas vinculadas dinámicamente. Esto significa que puedes comenzar a trabajar con bibliotecas y luego cambiar a Unreal sin tener que volver a escribir todo el código básico del juego, ya que está en la biblioteca. Para que el código sea lo suficientemente flexible para cambios tan grandes, se requiere una seria consideración, pero creo que vale la pena para un proyecto promedio o de largo plazo.
En conclusión
Presente varios puntos de vista bajo los cuales se pueden considerar las tecnologías al elegirlas. Pase un par de semanas en un estudio detallado, y esto puede ahorrarle varios meses de trabajo o incluso años de inconvenientes en el futuro.
Al final, su tarea principal es completar el proyecto. Debe hacer todo lo posible para encontrar el camino más corto para resolver este problema. ¡Puede ser bastante inesperado para ti!