¿Por qué escribir tu propio motor de juego?

En diciembre del año pasado, en la conferencia Games Gathering 2017, hicimos un informe en el que hablamos sobre si las empresas que trabajan en la industria del juego necesitan escribir sus propios motores.

Unidad frente a una variedad de motores de juego.

¿Por qué en el mundo moderno, en el que existen gigantes como Unity, hacen algo propio, escriben sus propios motores de juego?

Aquí hay una diapositiva con datos de Unity Technologies sobre el uso de varios motores de juego en 2017. El año que viene, la situación, como comprenderá, cambiará. Lo que nos interesa aquí es el 41%, es decir, motores de nuestro propio diseño. Si observa las 5 compañías más grandes representadas en la conferencia, cada una de ellas tendrá su propio motor. Resulta que en la mayoría de las empresas que representan a la industria del juego, se utiliza algún tipo de desarrollo interno. No siempre es la decisión más razonable del mundo, pero lo es.

¿Qué tecnologías básicas pueden elegir las empresas que piensan desarrollar un proyecto de juego?

Ejército de las siete naciones

La pirámide que ves en la diapositiva se puede continuar tanto hacia arriba como hacia abajo. Absolutamente te limita. Abajo, el sistema operativo, incluso más bajo, algo de tecnología básica. Arriba están los complementos sobre los motores, un juego de herramientas listo para usar que viene con juegos, como las herramientas de Neverwinter Nights. Hagas lo que hagas, de una forma u otra, te encontrarás dentro de esta cosa.

Supongamos que quiero estar en el segundo nivel de esta pirámide a continuación. Sin embargo, todos los caminos eventualmente conducen a la cima de la pirámide. Usaremos algo del existente, pero es muy importante que podamos ver en la esquina superior izquierda del nivel superior de la pirámide, es decir, motores de nuestro propio diseño.

Ahora analizamos el tiempo, el esfuerzo y el dinero necesarios para desarrollar el juego.

De vuelta a lo básico

Si todo el gráfico circular que se muestra en la diapositiva es un juego, entonces el motor es su sector azul. En un mundo ideal, al desarrollar un juego, puedes eliminar este sector azul y ponerlo en rojo, amarillo o verde. Puede cambiar una "U" grande por otra "U" grande, o tomar una pequeña "x", y lo que elija funcionará allí mismo. En realidad, esto no es así, pero debemos luchar por esto. Una imagen similar, cuando se trata de proyectos reales, se observa constantemente en la industria del juego. También sucede que todo el diagrama está ocupado por el motor, pero esto es cierto solo para algunos productos de demostración.

En este caso, el dinero, el tiempo y todo lo demás se distribuye de esa manera. Hagas lo que hagas, tienes que lidiar con todo lo que cae dentro del área verde del diagrama. No cambia de motor a motor. Como resultado, si tiene recursos suficientes para respaldar todo el proceso de trabajo en un proyecto de juego, el desarrollo del motor no será tan costoso. Sin embargo, si alguien en la empresa comienza a hablar sobre el desarrollo de su propio motor, lo más probable es que encuentre un cierto conjunto de objeciones. Considéralos.

Mítico hombre-mes

Suponga que decide crear su propio motor y decirle al tomador de decisiones al respecto. En respuesta, escuchará sobre lo mismo que se puede ver en la diapositiva: "Lo hará durante mucho tiempo, es muy arriesgado, es irracional, no nos ayudará a lograr nuestros objetivos". ¿Qué se puede responder? El punto aquí es que todas estas objeciones, excepto la última, no resisten las críticas.

Largo desarrollo del motor? Pero si el desarrollo con su propio motor va más rápido, entonces esto no es un argumento. Quizás, en general, nadie sabe qué es "racional". Por lo tanto, todas estas objeciones son muy subjetivas.

El último punto sobre si su motor contribuye a alcanzar los objetivos es muy importante. Si su objetivo es ganar gracias a una subvención de Unreal 4, entonces probablemente no necesite crear su propio motor, ya que no conduce a este objetivo. Si tiene una meta, dentro del marco de la cual necesita hacer algo en ciertas tecnologías, entonces no necesita escribir su propio motor, necesita tomar lo que es. Pero está lejos de ser siempre posible utilizar efectivamente los motores preparados. ¿Por qué, de todos modos, escribes tu propio motor?

13 razones por las cuales

¿Cuándo puede necesitar su propio motor? Analicemos esta diapositiva por puntos:

• Tiempo de comercialización: tiempo de comercialización de un producto. Esto es realmente serio. La mitad de los motores que ahora se usan en grandes empresas se desarrollaron precisamente porque en ese momento, cuando esta empresa necesitaba ocupar rápidamente un nicho, desarrollar el suyo era más rápido que tomar algo más y dominarlo.
  

Aquí hay una historia para ti. Una empresa tenía una tarea para los programadores en el sitio que se parecía a esto: “Chicos, si quieren trabajar con nosotros, escriban Asteroides, que deberían ejecutarse en la plataforma Android sin usar bibliotecas externas. Creemos que 8 horas son suficientes para usted. Ha llegado el momento ". Luego se aumentó el tiempo a 12 horas. Tal vez se ve divertido. Al principio vi esto, desde afuera, luego miré a esta compañía y me pidió que le contara lo que enviaron en forma de respuesta a esta tarea. Al final resultó que, más de doscientos programas pasaron la selección, es decir, estos programas se lanzaron y funcionaron. Esto significa que si de repente quieres publicar "Asteroides" para Android, entonces hay al menos 200 personas que pueden hacerlo en 8 horas. No estoy diciendo que se pueda vender. Pero conté esta historia al hecho de que muy a menudo, de hecho, el motor es Time to Market. Digamos, simplemente porque tienes necesidades tan pequeñas que estudiarás la documentación para el mismo Unreal por más tiempo que solo tomar y hacer la tuya.

• Lord of the Platform es el maestro de la plataforma. Hay plataformas para las que no hay herramientas listas para usar. Por ejemplo, STB, decodificador (receptor de televisión digital): una caja para televisión por cable, que está sobre la mesa en cada tercer estadounidense.
  

Warner tiene 120 millones de usuarios de este servicio. Si escribe software allí, incluidos los juegos, entonces tiene un dólar de la caja. Esto es 120 millones de dólares al año. Al mismo tiempo, nadie más puede escribir para esto excepto usted. Como no hay DirectX, no hay nada en absoluto. Si puede escribir programas para STB, entonces usted es el maestro de la plataforma, tiene estos ciento veinte millones de dólares al año. ¿Por qué no escribes tu propio motor?

Está claro que ahora estamos hablando más sobre algo como los juguetes de consola, pero, sin embargo, en algunas situaciones esto puede ser necesario. Aquí, por ejemplo, máquinas tragamonedas. Por supuesto, ahora hay, principalmente computadoras. Pero tenemos ante nosotros un dispositivo de hierro separado y un gran mercado, para el cual es bastante posible escribir algo propio.

Podemos decir que estamos interesados ​​en los teléfonos, pero estamos hablando de millones de dólares. ¿Por qué no escribir para otros dispositivos? Como resultado, hay razones absolutamente claras para hacerlo.
O, por ejemplo, tenemos los últimos relojes inteligentes. El SDK aún no ha llegado a ellos, nadie entiende qué hacer con ellos, y si puede, por su cuenta, escribir un producto de calidad para ellos, entonces, por ejemplo, gana un dólar con cada uno de esos dispositivos. Si se venderán dos millones, obtendrás dos millones de dólares. Escribir esto no es difícil, pero para esto necesitas crear tu propio motor, porque no hay extraños, y los fabricantes de tales dispositivos no harán motores públicos para el desarrollo para ellos.

• Los dispositivos débiles pero orgullosos son dispositivos pequeños pero orgullosos. Si crea juegos para teléfonos móviles, recopile al menos algunas estadísticas, entonces sabrá que con el hardware de los dispositivos Apple todo es más o menos normal, pero con la plataforma Android es solo un desastre.
  

La mitad de los dispositivos en el mercado se basan en el chipset ARM Mali-400, cualquier teléfono económico es un Mali-400. Y si le pagan por lo que hace con las aplicaciones telefónicas, debe escribir para estos dispositivos pequeños pero orgullosos que todavía no van a salir del mercado y lo dejarán muy pronto.

Además, en el caso del iPhone, puede hacer al menos algunas apuestas sobre el progreso. Por ejemplo, se espera que Unreal funcione con el iPhone 10, aunque hasta que se tenga en cuenta todo esto, ya habrá algunos iPhone 12, 15 o 17. Pero en el caso del mundo en general, es más difícil avanzar en el corto plazo. Porque la actualización de dispositivos es muy lenta.

Si desea una imagen competitiva, y si es muy importante, no elija dispositivos de baja potencia. Pero debe tener en cuenta que todos los motores modernos no se reducen mucho. Si no desea una imagen competitiva, tenga en cuenta las capacidades de los teléfonos débiles. Por lo tanto, si se encuentra en una situación en la que no está interesado en los dispositivos más rápidos, por ejemplo, si es el único distribuidor en algún lugar de Portugal o Brasil, tendrá que pensarlo.

• Lenguaje propio para ideas propias - lenguajes propios para ideas propias. Cuando hace el motor usted mismo, puede usar este concepto. El hecho es que el principal problema de nuestra industria es que el dominio del diseñador de juegos es la filología. Él piensa en lenguaje ordinario. No puede hacer nada más. Pero el programador piensa en el dominio de programación y hay una brecha entre ellos. Como resultado, una cierta iteración, que debe repetirse continuamente, cuesta, por ejemplo, dos dólares. Y constantemente gastas este dinero.
  

Los motores estándar intentan cubrir a todos. De hecho, vemos cómo intentan hacer transformaciones de dominio natural de un lenguaje a otro y de un espacio a otro. Pero para todos. Y usted tiene sus propias ideas, y puede implementarlas directamente, creando su propio conjunto de herramientas. Está claro que todo esto, en forma de complementos, se puede hacer sobre los motores existentes, pero su motor abre posibilidades completamente diferentes.

• Mecánica única = motores únicos - mecánica única = motores únicos. Mis amigos escribieron Minecraft en el decimoquinto año usando Unity. ¿Hubo algún punto en hacer todo esto? Una pregunta abierta. Pero eligieron el motor y se pusieron a trabajar. Sin embargo, el motor, obviamente, los estaba molestando mucho. Fue duro para ellos. Tenían iteraciones muy largas. Después de consultarlos, escribieron, literalmente en tres días, su propio render. Además, el resto del código responsable, por ejemplo, de construir el mundo, por supuesto, no ha desaparecido. Todo dejó de estar en C #, dejó de estar en Unity. Y el trabajo comenzó a hervir. No sé si lograron ganar dinero con eso, pero la conclusión principal de esta historia es que inicialmente no tuvieron que usar Unity.
  

Es decir, hay una gran cantidad de mecánicos para quienes los motores estándar, grandes y universales no son adecuados simplemente porque están diseñados para todo. Por lo tanto, si se le ocurre algo especial mañana, algún tipo de mecanismo vóxel complejo, trabajar con motores estándar será inconveniente para usted. Es decir, hay mecanismos para los que los motores estándar no son adecuados y que son bastante simples de implementar de forma independiente.

• El juego no es un render, el juego es todo lo demás, el juego no es un render, el juego es todo lo demás. Ya hemos hablado de esto. Si su único problema era dibujar algo o, por ejemplo, usar el sonido para hacer un juego multiplataforma, entonces podría ver historias similares en la pirámide discutidas anteriormente. Si dice: "Quiero reproducir sonido en tres plataformas", entonces no necesita una "U" grande para esto; una pequeña "c" será suficiente.
  

Consideramos las razones para desarrollar nuestro propio motor. Consideremos ahora qué ventajas ofrece la empresa con el desarrollo de su propio motor.

Las ventajas de desarrollar tu propio motor

Considere las ventajas de desarrollar su propio motor, basado en las ideas principales presentadas en la diapositiva:

• La compra es a menudo mejor que la hipoteca; la compra es a menudo preferible a las hipotecas. El desarrollo del juego es dinero de todos modos. Hay formas de monetizar, usando qué comprar no es solo mejor que una hipoteca, sino que esta es solo la única opción.
  

Si alguien trabajó en tecnologías móviles, entonces lo comprende todo. Si el cuadro en el motor dice: "10 por ciento de las regalías", entonces esto es categóricamente inaceptable, no ganará tanto. Puede obtener una ganancia del cien por ciento, pero trabaja de 2. Es decir, si tiene regalías, entonces esta es una razón puramente económica para abandonar el motor. Pero debo decir que tres, o más bien, dos de los motores más populares en este momento, es solo una cuestión de deducciones. Es decir, esta opción desaparece de inmediato.

• La especificidad es mejor que la universalidad a largo plazo: a larga distancia, las herramientas especializadas siempre son mejores que las universales. Obviamente, la universalidad es siempre más lenta; es menos productiva y menos específica que las cosas especializadas. Un motor escrito para una tarea específica lo manejará mejor y más rápido que una herramienta universal. A larga distancia, las herramientas especiales son mucho más rentables que las universales.
  
• Las herramientas y las tuberías se desarrollan dentro de las tuberías y las herramientas de desarrollo creadas internamente. Cualquier motor inventado por personas ajenas a su empresa se guía por varias cosas. La primera es las mejores prácticas. Es decir, el motor de otra compañía se centra no en cómo pinta su artista, sino en cómo pintan los artistas, ideal desde su punto de vista. Es posible que tus artistas pinten de manera diferente. Tienen su propia tubería y tienen éxito.
  

Tiene 2 opciones: volver a entrenarlas como debería desde el punto de vista de las mejores prácticas, o usar las suyas propias. Hay ejemplos simples. Supongamos que dice: "Importamos modelos 3D". No sabes lo que hay del otro lado. Por lo tanto, necesita un formato intermedio. El formato intermedio lo deja ser FBX. FBX falla todos los que hacen esto lo saben. Y no tiene a dónde ir, porque no sabe qué se hará allí, no escribirá complementos para 450 herramientas de modelado 3D.

Cuando trabaja dentro de su empresa, puede implementar la misma tubería que ya tiene y poner encima de lo que está haciendo. De hecho, esto es muy importante. El hecho es que todo esto tiene que ver con el tiempo de desarrollo y, como consecuencia, con el costo. Por lo tanto, cuando se desarrolla en casa, puede deshacerse de la tubería que ya tiene. De lo contrario, tendrá un documento llamado "La regla para cargar modelos 3D y crear materiales para artistas" que será más que un documento de diseño, lo cual es incorrecto.

• Tiempo de reacción: tiempo de reacción. Estamos hablando del tiempo de reacción del fabricante del motor a sus solicitudes, de la posibilidad de equipar el motor con una nueva funcionalidad y de la investigación operativa de nuevas tecnologías.
  

Digamos, en la próxima oficina hay personas que hacen el motor. Todos los que intentaron corregir el error en el motor universal, es decir, escribir Unity o Epic en el rastreador de errores, saben que es mejor ni siquiera comenzar. Y si los desarrolladores están sentados en la próxima oficina, puede contactarlos y resolver el problema en 15 minutos.

Lo mismo se aplica a la propuesta de nueva funcionalidad, si tiene derecho a hacerlo. El estudio de las nuevas tecnologías también se simplifica mediante el uso de nuestros propios motores.
Supongamos que su programador fue a una conferencia y escuchó una conferencia sobre algo nuevo allí. Inmediatamente lo intentó, tienes una idea sobre esta nueva y sabes si la necesitas o no. Puedes reaccionar directamente para probar algo interesante del mundo de la ciencia. Y esto, por cierto, significa que la empresa puede tener una persona que se llamará "investigador". Al mismo tiempo, puedes investigar sobre el mismo Unreal, ya que viene en la fuente.

• Rendimiento - rendimiento. La industria del juego es siempre la productividad. El primer enfoque para lograr un alto rendimiento es utilizar soluciones personalizadas. Cuanto más específicas son las soluciones, más productivas son. El segundo enfoque, también, por cierto, querido, es la optimización de los motores listos para usar. Cómo se verá exactamente esto depende en gran medida de estos motores.
  

Desarrollar su propio motor no es solo una ventaja. Estos también son riesgos. Considéralos.

Riesgos asociados con el desarrollo de su propio motor.

Considere los riesgos que acompañan el desarrollo y uso de nuestros propios motores:

• Tiempo de desarrollo - tiempo de desarrollo. Este concepto se cruza con lo que hablamos sobre cuándo ingresar al mercado. El desarrollo del motor puede ser muy largo y rápido. Pero el tiempo de desarrollo del motor, en cualquier caso, contribuye al tiempo de desarrollo general del proyecto. Por lo tanto, esto también es un riesgo. Por ejemplo, conozco equipos en los que el tiempo de desarrollo del motor tiende al infinito.
  
• Cajas terminales de bloqueo de proveedor: cajas terminales de enlace con el proveedor. Esto se aplica no solo a las grandes empresas, sino también a las pequeñas. Digamos que contrataste a Vasya, él escribió el motor, luego se enamoró, te dejó y nadie entiende lo que escribió. Como resultado, tiene un bloqueo de proveedor peor que Google. Porque aún puedes escribir una carta a Google, aunque no responderán, pero aquí, con la partida del programador, todo había terminado. El resultado es la pérdida de tiempo de desarrollo y otras consecuencias desagradables. Debe poder evitar estos riesgos.
  
• Reinventar la rueda: la invención de la rueda. El punto es que vivimos en un mundo en el que todavía inventas bicicletas. Al desarrollar el motor, resulta que la fábrica de bicicletas se transfiere del código del juego al código del motor, aunque no pertenecen allí.
  
• Ecosistema cerrado: un ecosistema cerrado.Todo lo que se hace dentro de la empresa pertenece a esta empresa. Conozco un montón de empresas que tienen algo así como su propio lenguaje de secuencias de comandos. Puede ser algún tipo de XScript que solo funcione como parte de su solución.
  

Los programadores que conocen esta tecnología, de hecho, no pueden hacer nada más. Esto puede considerarse uno de los factores que ayudan a retener a los empleados. Por lo tanto, la respuesta a la pregunta de si es bueno o malo, si usar sus propias tecnologías es un riesgo depende de la situación específica. Por ejemplo, tratamos de no utilizar los conceptos de nuestra propia invención. Por ejemplo, sé de una compañía que tiene Lua, fuertemente tipada, con sintaxis Pascal. Se puede dominar, pero este conocimiento está muerto, como el griego. Nos esforzamos tanto para no actuar.

El tema principal de la vida, el universo y todo eso.

Considere un tema muy importante. ¿Qué recurso se requiere principalmente para desarrollar su propio motor? Un recurso sin el cual no tiene sentido pensar si hacer o no tu propio motor. La respuesta, por supuesto, no es 42. La pregunta es: qué se necesita para al menos poder decir: "Sí, tenemos al menos algo, podemos comenzar a hacer algo". La respuesta a esta pregunta es que se necesitan programadores para desarrollar su propio motor.

Programadores

Para crear su propio motor, necesita programadores. Si no sabe, busque en Google la diferencia entre las palabras "desarrollador" (desarrollador) y "programador" (programador). Esto es muy importante Los desarrolladores son el grupo principal. La industria de los juegos está tan organizada que la mayoría de las personas no pueden llamarse programadores. Lo siento, pero son desarrolladores. Los desarrolladores no pueden hacer correctamente el motor. Una vez más, si observa la diferencia entre el primero y el segundo, los desarrolladores crean los juegos y los programadores crean las herramientas. Los desarrolladores hacen un producto, la empresa gana con el producto, pero las herramientas deben ser hechas por programadores, de lo contrario simplemente no funcionarán.

Por un lado, ahora es un mundo muy abierto. Por ejemplo, conozco el código de Unreal 4 y CryEngine, está abierto. Cualquiera que quiera saber puede encontrar el código de Unity, hay una gran cantidad de materiales relevantes. Esto significa que alguien que es programador y lee inglés puede hacer esto. No hay ciencia espacial allí. Pero, por otro lado, resultó que los programadores que leen en inglés son muy difíciles de encontrar. Por lo tanto, debe saber dónde se encuentran, debe poder reclutarlos, usarlos y promoverlos. Si sabe cómo, entonces ya puede pensar en su motor. Si no tienes a esas personas, entonces aún no tendrás éxito. Ejemplos de esto son la oscuridad. No es que haya malas y buenas soluciones. Hay cosas que no pueden funcionar inicialmente.

Los programadores necesitan poder contratar. Sepa cómo contratar: puede hacer un motor. No sabe cómo contratar, entonces debe tener algo listo. Además, lo curioso es que cuando tomas algo ya hecho, si eres una gran empresa, aún necesitas dos personas de estos programadores que lean en inglés.

Si se necesitan programadores para desarrollar el motor, inmediatamente tenemos algunas preguntas. ¿Dónde buscar programadores? ¿Cómo organizar su trabajo? ¿A qué debo prestar atención al pensar en las rutas de desarrollo de las compañías de juegos?

Epidemia técnica

Ahora es apropiado recordar otro aspecto de la búsqueda de empleados, que concierne principalmente a las grandes empresas. Dichas empresas tienen varios enfoques para la contratación de personal.

En primer lugar, puede reclutar personas, joons, organizar pasantías y, capacitándolos dentro de la empresa, de alguna manera crecer al nivel deseado. Este es un enfoque normal. Al mismo tiempo, muchos problemas tecnológicos también se resuelven, porque es más fácil encontrar un lenguaje común con una persona que inicialmente percibe la cultura corporativa y estudia ciertas tecnologías.

En segundo lugar, hay un enfoque que, en principio, profesamos. ¿Cómo funciona el kéfir? Convierte todo en sí mismo. Tomas leche, arrojas kéfir allí, y no hay leche, todo se convierte en kéfir. Esto se ve así para nosotros: "Chicos, tomemos 5 programadores fuertes, será un centro tecnológico interno". Y les digo a todos que si pueden permitirse hacer un departamento de RnD, si son una gran empresa, entonces háganlo. Que ni siquiera hagan nada útil desde el punto de vista del dinero. Si una empresa ha fortalecido su posición en el mercado y surge la pregunta de dónde expandirse, entonces la creación de un departamento de RnD puede ser la respuesta a esta pregunta. Cuando una empresa ya es rica, no es una pérdida de dinero, porque ya pierde tanto dinero en la eficiencia en la que nuestra industria del juego está trabajando ahora que simplemente no notará los costos de la investigación.

Ahora considere el enfoque, que es que la compañía organizará un equipo que haga el motor u otras cosas interesantes. Este es un trabajo para el futuro. Puedes realizar entrevistas, decir que das dinero, tienes una tarea interesante, haces un motor. Puede elegir entre solicitantes, las personas acuden a usted y, dentro de la empresa, siempre tiene un ambiente en el que puede motivar, alentar y, como resultado, alcanzar sus objetivos.

Por ejemplo, tengo algunos módulos desarrollados por compañías de alimentos, porque lo necesitan. Es decir, se ordenó una física y, en lugar de cortar algunas de nuestras cosas, decimos: “Hagámoslo. Acabamos de crear interfaces comunes, algo generalizadas, y usted lo hará ". Y como parte de las tareas típicas, esto es muy bueno. Es decir, en principio, es bueno difundir tecnología dentro de la empresa.

Si la compañía ya es tan grande que puede permitirse hacer algo interesante dentro de sí misma, entonces vale la pena incluso desde el punto de vista del dinero. Por lo tanto, si puedes, entonces pruébalo. Puede verse como desee, por ejemplo, se crea su propia rama Unreal y allí procesamos todo de la manera que desee. Por ejemplo, hice un navegador en una de las compañías que cabe en 2.5 megabytes de memoria. Y él trabajó. ¿Por qué? No lo sé, pero fue infinitamente interesante.

Anteriormente mencionamos el problema de las compañías de juegos, que es la organización de una interacción efectiva entre programadores y diseñadores. Detengámonos en este problema con más detalle.

Dos mundos

Ha llegado el momento de mostrarte el lugar de trabajo de nuestro diseñador de juegos. Esta es una imagen real. Aquí se muestra alguna demostración, la implementación del comportamiento, un poco más adelante nos detendremos en esto con más detalle.

Dos mundos coexisten en la industria del juego. Las personas se centran en resolver problemas tecnológicos o en la narrativa. Y en el medio, algún tipo de artesanía. Es decir, prácticamente no hay herramientas. Palabras, palabras, palabras - explosión - código. Nuevamente las palabras, y nuevamente el código. Creemos que necesitamos herramientas que nos permitan conectarnos con lo que resultará de trabajar en el juego, un diseñador de juegos, gerente, otros empleados que no son programadores.

En la diapositiva puede ver el árbol de comportamiento, el árbol de comportamiento. En principio, esto es algo tomado de Wikipedia, pero delante de nosotros fue tomado de allí por Unreal. No hay nada de malo en eso. Entonces, la documentación para esto se encuentra en el sitio web de Unreal, no fue difícil para nosotros hacer una interfaz adecuada compatible con lo que se hace en Unreal. Es decir, puede tomar cualquier ejemplo del sitio de acción Anryl, un ejemplo del comportamiento en sí mismo, ya que el formato es bastante similar, reescribirlo de esta manera y funcionará. Esto significa que hice mi vida más fácil, no estoy escribiendo documentación. Y hay muchas cosas así.

En el ejemplo de la diapositiva, sucede algo, un cangrejo corre, atrapa a alguien, en general, no importa. En el interior, el programador resuelve problemas que parecen "ir a ...", "disparar a ...", "calcular la distancia", y eso es todo. El resto del comportamiento está escrito en este editor por una persona que no tiene absolutamente nada que ver con la programación. Y esto funciona, en lugar de traducir texto en código. Además, hablando de equilibrio, digamos. ¿Qué es el equilibrio? Estos son 15 factores que se pueden cambiar. Y aquí está el comportamiento, no los coeficientes.

Es decir, por ejemplo, el comportamiento del "patrullaje" lo describe el diseñador del juego, no el programador. Esto significa que hemos dado el paso que la mayoría de la gente no hace. Simplemente escriben en un documento de diseño: "patrullas". Y un programador puede traducir esto de 50 maneras diferentes. ¿Qué es patrullar en absoluto? Y aquí el diseñador del juego escribe exactamente lo que quiere decir. Y esta es una victoria, mis amigos. Para esto necesitas tus propias herramientas. Para facilitar la transición de la definición verbal de tu visionario que ve el juego, por así decirlo, dentro de su cabeza, a los programadores. De lo contrario, dejarán de ser programadores, se convertirán en desarrolladores y desmalezarán la hierba toda su vida.

Resumen

Para resumir. Hablamos de razones para escribir su propio motor. Digamos, si miras hacia atrás a los dispositivos obsoletos, entonces esto no es ni bueno ni malo. Es decir, desea que sus juegos se ejecuten en una cierta gama de dispositivos que ya no son compatibles con motores comerciales. Al mismo tiempo, quieres lucir moderno. ¿Cómo lograr esto? Escribe el tuyo.

¿Quieres tener una plataforma? ¿Tiene un proyecto específico que simplemente no requiere el uso de soluciones universales? O, por el contrario, ¿tiene un proyecto muy grande y complejo con una imagen específica? En estas situaciones, nuevamente, puede pensar en su motor. Al mismo tiempo, para hacer tu propio motor, necesitas recursos. Y los recursos son programadores.

Como resultado, si tiene razones para escribir su motor y tiene los recursos, tome y escriba.